: Bei der Diskussion über SystemAdministratoren ist glaube ich der Link zum "egoless Administrator" gewesen, wo empfohlen worde (wichtigere) Anfragen via Email zu verlangen um dem Management einen AuditTrail? zu haben. Analog stelle ich mir vor, daß hier durch entsprechende organisatorische Maßnahmen (Protokolle, Aktennotizen, wiederholte Emailanfragen, Eskalation zu Vorgesetzten, UnlessFurtherOrders?-Modelle) ein entsprechender Termin- und Entscheidungsdruck aufgebaut werden könnte. -- DavidSchmitt |
: Bei der Diskussion über SystemAdministratoren ist glaube ich der Link zum "egoless Administrator" gewesen, wo empfohlen worde (wichtigere) Anfragen via Email zu verlangen um gegenüber dem Management einen AuditTrail? zu haben. Analog stelle ich mir vor, daß hier durch entsprechende organisatorische Maßnahmen (Protokolle, Aktennotizen, wiederholte Emailanfragen, Eskalation zu Vorgesetzten, UnlessFurtherOrders?-Modelle) ein entsprechender Termin- und Entscheidungsdruck aufgebaut werden könnte. -- DavidSchmitt |
::: Ja. Jetzt wo ich es nochmal lese... Das ist natürlich nur in größeren Organisationen wichtig/notwendig wo Verantwortung und Durchführung schon sehr stark entkoppelt sind um sich als "kleinen Programmierer" abzusichern. --DS |
Der "Kunde" steht für Fragen zur Verfügung und entscheidet über die Priorität der einzelnen Entwicklungsschritte.
"Kunde" bezeichnet dabei nicht zwangsweise den Auftraggeber oder Geldgeber des Projektes, sondern die Rolle der Person(en), die die Kompetenz und Befugnis haben, fachliche Entscheidungen zu treffen. In diesem Sinne kann es sich bei dem Kunden durchaus auch um ein Team handeln, von dem aber erwartet wird, zu den Entwicklern MitEinerStimme zu sprechen.
Diskussion |
Frage: Was passiert wenn ein KundeVorOrt eine Frage nicht zeitgerecht beantworten kann oder sich in einer Frage einfach nicht entscheiden will? (Hintergrund: ich habe in zwei nicht-XP-Projekten unabhängig voneinander erstmals große Schwierigkeiten mit Kunden, die durch Entscheidungsunfähigkeit Verzögerungen und Verteuerungen verursacht haben). -- HelmutLeitner
Dann sollten beim Team die Alarmglocken läuten und alles daran gesetzt werden, eine Lösung für dieses Problem zu finden. Letztendlich liegt es aber dann wieder in der Entscheidungsgewalt des Kunden, ob die Entwickler trotz mangelnder Informationen ruhig "ins Blaue hinein" entwickeln sollen (in der Hoffnung, dass das Präsentieren einer vorläufigen Implementierung den Nebel lichtet) oder die Entwicklung des entsprechenden Features bis zur Klärung verschoben werden soll.
Wenn es sich bei dem Vorkommnis nicht um einen Einzelfall handelt, könnte es für das Projekt essentiell sein, die damit zusammenhängenden Probleme (z. B. steigende Kosten) an die entsprechenden Stakeholder zu kommunizieren.