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.

.NET BlogBook Ausgabe 6

14.04.08 - Entwicklung, Diskussionen, Patterns, Software Testing, Projektmgmt., Qualitätsmgmt., .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder

Ab sofort steht die 6. Ausgabe des .NET BlogBooks zur Verfügung. Insgesamt stehen nun fast 330 Seiten an puren Informationen und Praxiswissen zur Verfügung.

Noch dazu wurden einige Anregungen aufgegriffen. Es gibt ein neues Cover (ein herzliches Dankeschön an 69° media solutions). Ebenfalls wurden unnötige dunkle Stellen entfernt, die beim Ausdrucken maximal Toner verbrauchen, sonst jedoch keinerlei Wirkung erzielen.

Hauptsächlich wurde das BlogBook um Wissen rund um die Windows Presentation Foundation erweitert, aber auch andere Punkte kamen hinzu. Ein Blick lohnt sich allemal.

Weitere Informationen sind auf der Homepage unter http://www.dotnet-blogbook.com zu finden.

Für Anregungen, Wünsche und (konstruktive) Kritik haben wir natürlich weiterhin ein offenes Ohr.

6 Kommentare - 1357 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

Den Projekt-Sumpf hinter sich lassen. Jetzt!

28.11.06 - Entwicklung, Projektmgmt.
Beitrag von Norbert Eder

Unterschiedlichste Studien (beispielsweise von der Standish Group [1]) zeigen auf, dass nur ein Bruchteil sämtlicher IT-Projekte auch tatsächlich fertiggestellt werden. Populieren wir diese Studien zusätzlich mit Zufriedenheitsdaten, dann sieht die Statistik noch weit schlechter aus.

Woran diese scheitern möchte ich nun anhand meiner ganz persönlichen Erfahrung beschreiben.

Wie schon in der Post Warum "Mein Chef will .."-Projekte meist in die Hose gehen (und in der darauffolgenden Diskussion, siehe Kommentare) beschrieben, sind oft ungenaue Spezifikationen und/oder Beteiligte mit fehlender Kompetenz, Faktoren für das Scheitern von Projekten. Dem kann im Grunde recht einfach entgegengewirkt werden, allerdings entsteht hierfür anfangs ein erhöhter Aufwand, als auch möglicherweise (sogar eher wahrscheinlich) zusätzliche Kosten.

1) Fehlende interne Kompetenz durch externe Berater kompensieren. So kann vermieden werden, dass in den wichtigen Anfangsschritten grundlegende Fehler gemacht werden. Dies gilt sowohl für die gemeinsame Spezifikation mit dem Kunden, als auch der Entscheidung bezüglich zu verwendender Technologien, Entwurf der Architektur und verwandten Themen.

2) Kommen aufgrund der Unternehmensgröße Business Consultants zum Einsatz empfiehlt es sich auf technisch versierte Personen zu setzen. Hier denke ich unter anderem an Spezifikationen die so technisch nicht umsetzbar sind oder den Aufwand ins quasi Unermessliche treiben. Auch Techniker können den Umgang mit dem Kunden lernen und wirtschaftliche Zusammenhänge begreifen. Aus meiner Erfahrung erzielen Business Consultants die größten Erfolge, die in "ihrem Leben davor" die Rolle des Umsetzenden inne hatten.

3) Technische Entscheidungen, Lösungswege etc. sollten auf jedem Fall mit der Entwicklungsabteilung (den zuständigen Personen) abgestimmt werden. Der Kunde versteht im allgemeinen dass bestimmte Punkte nicht sofort fixiert werden können, da notwendige Zusagen der Umsetzenden fehlen. Dadurch erhöht sich für ihn die Chance das zu bekommen was er auch tatsächlich möchte.

Eine zusätzliche Problematik ergibt sich bei der Kommunikation. Oftmals werden bereits vorhandene Kanäle nicht benutzt oder es existiert eine Scheu vor neuen Möglichkeiten. Ablagesysteme für Dokumente aller Art fehlen oft (nun, wer findet ein bestimmtes Dokument als erstes?). Zuständigkeiten, Tasklisten werden oft nicht kommuniziert. Missverständnisse stehen also an der Tagesordnung. Vielfach kommt zusätzlich folgendes Verhalten zu Tage: Ein Thema wird lieber über mehrere Tage hinweg via Email diskutiert, anstatt für 10 Minuten zum Höhrer zu greifen, das Thema zu besprechen, danach kurz in einem Protokoll zusammen zu fassen um es dann endlich erledigen zu können.

Das Thema der Kommunikation ist jedoch nicht nur auf interne Prozesse beschränkt. Ebenfalls wird oftmals die Kommunikation zum Kunden vernachlässigt. So ist ein Projekt spezifiziert, das Projekt begonnen, aber eine laufende Absprache und Kontrolle mit dem Kunden fehlt vollkommen. Der Kunde möchte über den Fortschritt bescheid wissen, kommt im Zuge diverser Demonstrationen auf Veränderungswünsche usw.

Fehlende Kontrolle. Wir bereits angesprochen: In vielen Fällen fehlen Kontrollmechanismen. Nein hier soll nicht der Mitarbeiter überwacht werden, sondern vielmehr der Fortschritt des gesamten Projektes. Denn nur dadurch kann festgestellt werden ob der Fertigstellungstermin zu halten ist. Nur dadurch kann dem Kunden ständig Feedback über den aktuellen Implementierungsstand geliefert werden. Fakt ist: man weiß wo man steht.

Dokumentation. Nein, nicht nur die Software sollte dokumentiert werden. Besprechungen, Telefonate, eben sämtliche Entscheidungen. Dadurch kann festgestellt werden, wann etwas definiert wurde, wer anwesend war und dadurch kann vermieden werden, dass immer wieder über bereits beschlossene Tasks diskutiert wird (sogenannte Endlos-Tasks die wie ein Damokles-Schwert über alle Beteiligten hängen). Zusätzlich zur daraus resultierenden Historie können Entscheidungswege nachvollzogen werden, können beispielsweise auch neue Mitarbeiter einfacher ins Boot geholt werden.

Lange Rede kurzer Sinn:
Ein Projekt erfolgreich abzuschließen ist im Grunde nicht schwer. Es erforderd Konsequenz von allen Beteiligten und eine realistische Planung. Ein Kunde ist bereit einen Monat länger auf die Software zu warten, wenn es zu Beginn so definiert wurde. Aber dann muss sie ausgerollt werden. Er soll ja als Kunde erhalten bleiben ...

Natürlich habe ich jetzt viele Punkte nicht beachtet, aber ich denke, dass ich viele wichtige Punkte erfasst habe. Leider steht jedem Projektmanagement Aufwand und Kosten gegenüber, aber durch eine effiziente und genaue Planung können Kosten, Aufwand, Ungemütlichkeiten, Streit etc. eingespart werden.

[1] Homepage Standish Group Inc

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

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 ...

9 Kommentare - 1791 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Zurück