ACHTUNG - NEUES BLOG

Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen EintrÃ¤gen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.

Warum "Mein Chef will ..."-Projekte meist in die Hose gehen ...

27.11.06 - Entwicklung, Projektmgmt.
Beitrag von Norbert Eder

Aufgrund meiner Tätigkeit bei tutorials.de stoße ich immer wieder auf junge Programmierer die als Praktikant oder als Einzelkämpfer in einem Unternehmen arbeiten, deren Chef ihnen ein Projekt aufträgt, welches den Horizont dieser Person eindeutig sprengt. Selten wird begriffen, dass diese Projekte einfach nur schief gehen können, zumal grundlegende Gegebenheiten einfach fehlen. Hier eine Liste, die ich mir oft bei Fragen zu Lösungen dieser Art denke:

1. Die Anforderungen werden nicht klar genug vorgegeben. "Wir brauchen ein Shop-System". Gut, die grundlegende Anforderung wäre definiert, aber der Rest? Hier liegt es am Entwickler nachzuhaken und alles notwendige in Erfahrung zu bringen. Sonst ab in die Hose mit diesem Projekt.

2. Der Chef (der kein Techniker ist) gibt das Projekt, als auch sämtliche Rahmenbedingungen wie etwaige Verschlüsselungen, Architekturen etc. vor. Auch das wird meist in die Hose gehen, da hier einfach das Know-How des Chefs auf dem Gebiet der Softwareentwicklung fehlt und etwas - nur weil man es zufällig irgendwo gehört hat - nicht unbedingt das Beste für das eigene Projekt ist.

3. Durch Zeitdruck wird dem kleinen Entwickler keine Zeit gelassen, sich mit der Materie zu beschäftigen, sich ein Design auszudenken, mit erfahrenen Programmierern darüber zu sprechen. Raus kommt ein Rucki-Zucki-Projekt, das den ursprünglichen Anforderungen eventuell entspricht, aber spätestens bei der ersten Änderung zusammenbricht.

Diese und weitere Punkte könnte ich an dieser Stelle aufzählen. Daher an dieser Stelle nur der Hinweis: Diverseste Statistiken zeigen, dass die meisten Projekte definitiv in der Hose landen und entweder nicht zur Zufriedenheit gelöst werden bzw. überhaupt gar nicht fertiggestellt werden. Daher: bitte unbedingt jedes Projekt genau spezifizieren, Rahmenbedingungen klären, ToDo's festlegen, Technologien und Techniken evaluieren und erst _dann_ mit der Implementierung beginnen. Es ist keine gute Lösung am nächsten Tag bereits einen ersten Prototypen zu sehen bzw. sehen zu wollen ...

Alex

27.11.06

	Leider beschleicht mich das ungute Gefühl, dass dieses Posting genau diese Leute nicht lesen werden, die ein solches Verhalten an den Tag legen und somit Ihre Entwickler ins Verderben prügeln.

Frank Hofmann

27.11.06

@Alex: richtig, aber dem Entwickler sei an dieser Stelle auch der Mut zugesprochen mal ein "mach mal langsam, Chef" auszusprechen. Aus eigener Erfahrung weiss ich, dass man hin und wieder den Projektverantwortlichen klar machen muss, dass die ein oder andere Anforderung oder Rahmenbedingungen nicht ok ist. Konstruktive Gespräche helfen hier sehr. Ohne Zweifel gibt es aber auch den Faktor "Kunde", der natürlich meist das letzte Wort hat...

@Norbert: auch richtig, gerade die unerfahrenen tun sich schwer mit der Erkennung von Fehlerquellen oder werden einfach ins kalte Wasser geworfen um schwimmen zu lernen. Deshalb hier ein ein Buchtipp für den Entwickler/Architekten UND den Chef:
Balzert: Lehrbuch der Softwaretechnik

Und ein Tipp für den Chef/Projektleiter:
Tom DeMarco: Der Termin

Norbert

28.11.06

Danke für die Buchtipps. Muss ich mir demnächst genauer ansehen.

@Alex: Da hast du leider recht. Die Personen die dies lesen sollten werden es nicht tun, da a) die Ressource unbekannt ist, b)sie soetwas nicht lesen wollen etc. Dennoch musste ich es einfach los werden.

@Frank: Gerade die unerfahrenen haben wenig Chance passende Argumente zu finden. Abgesehen davon ist es in einigen Fällen so, dass der Vorgesetzte (Projektverantwortliche) anderen mehr glaubt als den eigenen Leuten. Fragt mich aber bitte nicht wieso ...

Frank

28.11.06

Auch das kann ich bestätigen, Norbert. Habe selbst mehr als einmal gesagt bekommen "Sie gehören nicht unserer Firma an, also sind Sie der Experte".

Zurück zum Thema. Ich kann "meinen" Newbies auch immer nur raten, sich vertrauensvoll an erfahrene Kollegen oder Kolleginnen zu wenden und keine Scheu vor Fragen zu haben. Obwohl der Spruch "Es gibt keine dummen Fragen, nur dumme Antworten" abgedroschen klingt, ist er aktueller denn je.
Wenn ein Anfänger die Möglichkeit hat sich leiten zu lassen, so soll er unbedingt diese Chance nutzen. Es gibt keine steilere Lernkurve als unter Anleitung eine Architektur, einen Algorithmus oder eine Spezifiktation/Dokumentation zu entwerfen. Fast immer können die "alten Hasen" nützliche Tipps geben und Quellen aufzeigen, in die man sich reinwühlen kann.

Zum Beispiel Dein Blog. :-)

Norbert

28.11.06

Vielen Dank für die Blumen :)

Mir persönlich ist es auch lieber, wenn ich oft gefragt werde. Denn nur so kann man gut Wissen weitergeben und ist auch informiert wo Probleme existieren, wo noch zusätzliche Hilfe notwendig ist und dass überhaupt Interesse besteht. Stellt jemand nie Fragen liegt es doch sehr nahe, dass die entsprechende Person alles kann (unwahrscheinlich) oder sich mit der Materie gar nicht auseinandersetzen möchte. Zusätzlich ist es im Sinne des Knowledge-Managements hier "Backups" zu schaffen ...

Für einen Einzelkämpfer in einem Unternehmen bietet sich diese Chance so direkt nicht. D.h. es bleiben nur externe Wege (Foren, Blogs, Bücher, etc.) um sich weiter zu bilden um dann später (nach zahlreichen "Schnell-Schnell-Projekten") dem Chef gegenübertreten zu können und zu sagen: "Moment. Stop! Können wir das bitte genau Spezifizieren, denn ...". Keine leichte Aufgabe, muss aber gemacht werden um Projekte erfolgreich abschließen zu können.

Christian Leverenz

28.11.06

Dass mit dem Fragen ist so eine Sache. Ich ertappe mich auch immer dabei zu fragen, wie denn die Umsetzung genau sein soll. Was soll mit den Eingaben passieren uswusf. Kennen wir alle.
Meint ihr nicht auch, das eine Menge Probleme daher kommen, dass Auftraggeber und Auftragnehmer aus unterschiedlichen Wissendomänen kommen? Der Auftraggeber will meist ein Businessproblem gelöst haben. Der Auftragnehmer meistert aber im allgemeinen eine technische Herausforderung. Wenn ich da ganz ehrlich zu mir selber bin, stelle ich die passenden Fragen zum Businesscase manchmal einfach garnicht oder zu selten. Ich lasse mich dann auch von aufgeschnappten technischen Sprüchen leiten wie: ich brauche da mal einen iframe, der dies oder jenes anzeigt. Dies ist eine technische Anforderung. Der Anwendungsfall dahinter ist so etwas wie: Wenn ich in meinem crm-System einen Kontakt erfasse möchte ich wissen, ob in der Nähe dieses Kontaktes andere Kontakte als Referenz dienen können.
So gut wie ich TDM Bücher finde (und sie sind alle großartig): selbst wenn manche Auftraggeber das lesen haben die nicht den Hauch einer Chance zu erkennen, wieso sich Leute über Terminkürzungen beschweren oder warum Software nicht einfach alles kann, was sie erwarten.
Ich würde dem "wer fragt der führt" zustimmen und hinzufügen wollen, dass man mit seinen Fragen die Domäne des Auftraggebers betreten muss und nicht erwarten kann, dass dieser die eigene Domäne betritt (auch , wenn er es versucht).

Norbert

28.11.06

Ich stimme dir zu, auch wenn wir uns hierbei ein wenig von der ursprünglichen Thematik verabschieden.

Die eine Geschichte ist natürlich was der Kunde überhaupt will. Welche Anforderungen an das Produkt hat er, Ablauf etc. Hier musss der Auftragnehmer viel Basisarbeit leisten um diese Punkte in Erfahrung zu bringen. Und oft grenzt diese Arbeit an das Thema "Gedanken lesen".

Die zweite - und meine ursprüngliche - Sache ist das weiterleiten dieser Informationen an den Entwickler und ihm vor allem auch die technische Entscheidung zu lassen. Kunde + Consultant (oder wer auch immer diese Tätigkeit auf Seiten des Autragsnehmers einnimmt) definieren dass beispielsweise einen technischen Ansatz weil sie darüber einmal etwas gelesen haben und genau dieser Ansatz so wunderbar ist. Dies wird dann dem Entwickler aufgedrückt, selbst wenn dieser der Meinung ist, dass es Problem A, B und C geben wird. Ein erfahrener Entwickler wird hier die notwendigen Kniffe kennen und kann auch entsprechend argumentieren. Ein Newbie hat diese Chance nicht, weil A einfach zu unerfahren, B das notwendige Wissen nicht da ist oder C in ihn kein Vertrauen gesetzt wird, weil er zu jung ist und es "eigentlich gar nicht wissen kann".
Genau an diesem Punkt sollten einige Projektleiter/-manager/Chefs ansetzen. Meinungen der Mitarbeiter einholen und erst dann einen technischen Punkt abschließen. Wenn das notwendige Wissen nicht vorhanden ist, dann das Wissen einer kompetenten Person einholen.

Auf der anderen Seite macht es natürlich auch keinen Sinn einen Newbie die Architektur eines Shop-Systems entwerfen zu lassen. Dieser sollte daran mitarbeiten, ja, aber im schlimmsten Falle (keine entsprechende Ressource vorhanden) einfach jemanden zukaufen der dies zusammen mit dem Newbie macht. Das Ausimplementieren der Funktionen sind immer noch Herausforderung genug.

Christian Leverenz

28.11.06

2Norbert: Das ist wohl wahr (sowohl mein Off Topic als auch Deine Argumente). Ich nehme manchmal Fachinformatikerprüfungen mit ab und in der Tat kommt dabei häufig raus, dass die technischen Entscheidungen von eigentlich dafür nicht zuständigen Personen gefällt wurden.
Ich habe daraus allerdings noch nie den Schluss gezogen, dass man in der Ausbildung (egal ob FI oder Akademiker oder sonstwie) wohl mal mehr "Rückenstärkungsprogramme" einbauen müßte (sowohl zum Gegenargumentieren als auch zum Hilfesuchen). Ich habe bisher auch nur einmal die Frage nach den "soundsovielen Seiten einer Nachricht" gestellt, obwohl diesem Thema offenbar eine nicht zu unterstützende Bedeutung zukommt (und erst nach leidigen Erfahrungen ernster genommen wird).
Wenn ich genau drüber nachdenke ist diese "Rückentherapie" eigentlich Sinnfrei, da die newbies da echt chancenarm sind. Da ist sicherlich "Mein Chef wollte es so" ein guter Indikator für einen Crash.
Anders herum ist es bei Expertenbefragungen manchmal auch so wie früher bei Werner Höfer: sechs Architekten mit sieben Meinungen...

BTW super blog, lese ich echt gerne

Norbert

28.11.06

Auch dir ein herzliches Dankeschön für die Blumen.

6 Architekten, 7 Meinungen: Ja, es ist hier nicht anders als in anderen Branchen. Aber dennoch macht es meiner Meinung nach sinn, den jungen, neuen Mitarbeitern, den Newbies, dem Einzelkämpfer-Newbie, einen Experten (auch wenn andere Experten eine andere Meinung haben) zur Seite zu stellen. Die Erfahrungen, das gelernte Wissen kann zukünftig gut eingesetzt werden und daher lohnt es sich für das Unternehmen, wenn auch für das "erste" Projekt höhere Kosten (zusätzlicher Experte) anfallen.

"Rückenstärkungsprogramme": Ich persönlich denke, dass derartige Programme gar nicht schlecht wären. Ich kenne so einige Entwickler, die eigentlich sehr gut sind, ein gutes Architektur-Verständnis haben, aber im Grunde doch der Meinung sind, sie wären nicht "reif" dafür ihre Meinung kund zu tun. Und das, obwohl es ein Projekt weiterbringen würde, neue Aspekte aufdeckt oder einfach nur den Blickwinkel ein wenig ändert.

Kommentar hinzufügen

Bitte das Formular ausfüllen, um Deinen Kommentar hinzuzufügen.