Die Kavallerie des Programmierens

[Maikel]

Hallo,

ich bin auf der Suche nach Unternehmen, die man anheuern kann, um (Programmier-)Projekte dann fertigzustellen, wenn man sie selber bis zur Deadline nicht mehr auf die Reihe bekommt. Also eben eine Art "Kavallerie", die dann anrückt, wenn nichts anderes mehr geht.

Ich stelle mir dabei ein relativ kleines Team von Rockstar-Programmierern vor, die das hinbekommen, was der Normalprogrammierer nicht auf die Reihe krigt - dementsprechend muss dann eben auch die Bezahlung sein.

Gibt es sowas überhaupt? Gibt es dafür einen Fachbegriff, den man in Google einschmeißen kann?

Grüße
Maikel

 

[benediktibk]

mythical man month

 

[SchwarzeBeere]

.. oder die Grundlage davon, deren Erkenntnisse auch in entwickelten Scrum-Teams zu finden ist: Tuckman's stages of group development

Ergebnis: Fremde Teams brauchen immer Einarbeitungszeit. Diese hängt stark von der Anforderungsanalyse, der Projektplanung, dem Controlling, dem Zulieferermanagement (oder allgemein dem Projektmanagement) und dem bereits vorhandenen Code inkl. Dokumentation ab. In der Regel ist im bisherigen Projekt mindestens ein Aspekt davon fehlgeschlagen und muss daher gleichzeitig ausgebessert werden, wenn eine Effizienzsteigerung angestrebt werden soll. Diese Prozessverbesserung bedeutet aber wiederum zusätzliche Arbeit, für die keine Zeit da ist. Bei bereits vorhandenem Code ist das Einholen einer Deadline ohne Qualitätsminderung dazu erfahrungsgemäß nicht möglich. Das ist auch nur logisch: Die Arbeit, die für die Einarbeitung in den vorhandenen Code gebraucht wird, müsste eigentlich für die Entwicklung aufgebracht werden. Eine unzureichende Dokumentation erschwert dieses Problem massiv - und das ist ein oft völlig unterschätztes Problem, da PMs Code-Dokumentation in der Regel sträflich missachten.

Anders sieht es aus, wenn das Projektmanagement das Hauptproblem ist (und das ist meiner Ansicht nach in über 90% der Fällen der Fall, auch wenn PMs (logischerweise ) anderes behaupten). Hier kann eine externe Person wirklich helfen. Diese übernimmt die Gesamtleitung des Projekts. Ob man das Projekt in der Deadline fertig bekommt, ist eine Frage, die hier allerdings niemand wirklich beantworten kann. Sie hängt hauptsächlich von den Messungen ab, die nun durch den oder die neue PM angeleitet werden und auf deren Basis sich ein neuer Termin errechnen lässt.

Was muss also gemacht werden?
1. Problemanalyse: Was hält uns auf? Warum sind diese Probleme enstanden? Wie können diese Metriken quantitativ (d.h. in Zahlen) ausgedrückt werden ("If you can't measure it, you can't manage it.")?
2. Ergebnisanalyse: Welche Änderungen müssen *am Prozess* durchgeführt werden, um wieder auf den richtigen Weg zu kommen? Wichtig ist, dass ihr keine großen Umstrukturierungen machen dürft! Auch Schuldzuweisungen oder Kündigungen demotivieren und verängstigen oft mehr, als dass sie Klarheit und Effizienz bringen.
3. Projektmanagement: Neue Maßnahmen planen, umsetzen, überprüfen und ggf. korrigieren. Hierzu ist der Satz aus Punkt 1 wichtig: Wie ändern sich die Parameter (z.B. implementierte Storypoints pro Woche)? Wie sollten sie sich ändern? Warum ändern sie sich so?
4. Kommunikation: Macht dem Kunden klar, dass das Projekt aus den oben analysierten Problemen nicht im Zeitrahmen fertig wird, aber dass zur schnellen Beendigung externe Ressourcen aus eigenem Budget bezahlt werden. Kein Kunde reisst einem den Kopf ab, wenn man VOR dem Projektende ihn darauf anspricht. Das ist auch in der Regel durch Verträge und die Rechtsprechung gedeckt. Wenn man erst 2 Tage vor Abschluss mit der Nachricht rausrückt, dann hat man natürlich ein Problem...

 

[ByteSurfer]

ich denke auch das die Einarbeitung und Integration der "Teammember", sowie die Verteilung der Arbeit nicht mit aussicht auf Erfolg gekrönt ist. Mangelnde Dokumentation wird hier auch ein nicht zu vernachlässigendes Problem sein. Andere, bereits intergierte Teammember werden mit in die Analyse, und somit aus ihrer eigentlichen Arbeit herausgeholt, um die anderen einzuweisen.

Umsonst sagt man nicht, dass in der Softwareentwicklung die Planung für die Programmierung über 75% des gesamten Projektes ausmacht.
Und das beinhaltete
- Pflichten-/Lastenheft
- Diagramme (Aktivitäten-/Flussdiagramme, usw.)
- Bedarf-/Problemanalyse
- Test bzw. QS

Kommunikation: Macht dem Kunden klar, dass das Projekt aus den oben analysierten Problemen nicht im Zeitrahmen fertig wird, aber dass zur schnellen Beendigung externe Ressourcen aus eigenem Budget bezahlt werden. Kein Kunde reisst einem den Kopf ab, wenn man VOR dem Projektende ihn darauf anspricht. Das ist auch in der Regel durch Verträge und die Rechtsprechung gedeckt. Wenn man erst 2 Tage vor Abschluss mit der Nachricht rausrückt, dann hat man natürlich ein Problem...

Und der direkte Kontakt zum Kunden ist unabdingbar, denn nur so ist dieser immer aktuelle und auch in die Problematiken eingebunden...

 

[Chromatin]

Generell gilt: Kein Projekt lässt sich in einer kritischen (End)Phase beschleunigen, indem man zusätzlich Personal hinzuzieht. Meistens sind das eher Kurzschlussreaktionen von irgendjemandem, der die Hosen voll hat - und die führen zu nichts. Wenn so etwas getan wird, dann hat das den Hintergrund das sich irgendjemand rückversichert hat und durch so eine Aktion Verantwortung abgibt.

Ist ein Projekt zeitlich drüber: Keine Panik - nützt ohnehin nichts. Redet mit dem Kunden und macht reinen Tisch - seid Transparent und arbeitet _gemeinsam_. Ich habe schon x-mal gesehen dass sich gerade dann die Fronten verhärten und alles schlimmer wird. Im Zweifelsfall wechselt den Projektleiter, wenn er auf mehr Personal beharrt oder sonstige "Lösungen" anbietet um seinen Arsch zu retten. Scheisze zu bauen gehört dazu - und kein Projektleiter hat sich noch nicht bei einem Projekt verzettelt. Wichtiger als schnell zu sein ist dann elegant zu sein...

1. Problemanalyse: Was hält uns auf? Warum sind diese Probleme enstanden? Wie können diese Metriken quantitativ (d.h. in Zahlen) ausgedrückt werden ("If you can't measure it, you can't manage it.")?

Jo - und dann haste erst mal die schönste Schlammschlacht.
Ich finde es - wenn es brennt - völlig egal wer wann was verbockt hat. Das blockiert und schafft eher ängstliches Klima.
Stand der Dinge ermitteln und an Lösungen arbeiten ist der Weg. Und wer sich da als Blockade herausstellt - abziehen.

 

[Maikel]

Hallo,

vielen Dank für die Antworten. Ich hatte gedacht mal von solchen Firmen gehört zu haben, muss mich dann aber wohl vertan haben.

Klingt auf jeden Fall sehr logisch, was ihr so von euch gebt. Frederick Brooks werde ich mir dann mal zu Gemüte führen.

Grüße
maikel

 

[ikkebins]

Programmieren ist auch nichts magisches und Projekte von Halbstarken können immer von einem "Meister" des Fachs "gerettet" werden.

Der Chat hat mich gerade an "smart motherfuckers" erinnert, hierzu das recht amüsante Video von icculus (Ryan C. Gordon / Loki Software).

Interessante Stelle bei 41:52

"Man, there are some smart motherfuckers out there. [...] One of them worked for Activision Central Technology, its like: they parachute into a project, rescue it and parachute it out. That's all they do. There is a massive bug in Call of Duty, this guy came in, fixed it..."