Nun hat es der Laden in dem ich arbeite sogar in die Top 100 geschafft! Das sind keine Verkaufscharts, eher so etwas wie die Mittelstandsplakette mit Halsband und Standarte am grünen Band. Ich hoffe, es waren mehr als 100 Bewerber. Wir erinnern uns noch alle an die Bundesjugendspiele, als man mit 15 Sekunden auf 100m noch locker "8. Sieger" wurde. Wenn auch nur 9 mitrannten.
Woran liegt es denn? Was sind denn die Geheimnisse, mit denen die Firma ihre Ergebnisse, hoffentlich bald sogar wieder mehr Gewinn als eine schwarze Null erwirtschaftet? Der IT-Service Teil ist einfach, er lebt einfach von den Projekten und der Fähigkeit, nach Bedarf Kräfte hinzuzunehmen oder abzulegen. Hier sind vor allem vermutlich die Kontakte zu Siemens und Daimler-Chrysler hilfreich, die von altersher beitrugen, Aufträge an Land zu ziehen.
In der Softwareentwicklung sieht es anders aus. Hier sind Neukunden und Projekte deutlich schwerer zu gewinnen. Die Konkurrenz ist härter. Durch Bugs und Support verbrauchen wir wieder eine Menge Geld, oft mehr, als die Kunden für Wartung, Neuentwicklung und Lizenzen ausgeben.
In regelmäßigem Abstand werde ich gefragt, jedoch mindestens wöchentlich, wie man es denn besser machen könnte. Dann krame ich jedesmal meinen Rezeptzettel aus der Hosentasche und lese ihn laut vor. Nein, quoka, ganz so einfach ist es nicht. Ich kann darauf meistens keine offene Antwort geben, da ich fast immer die Gefühle des Fragestellers verletzen würde. Man kann es aber andersherum ausdrücken. Es ist wie beim Schachspiel, es verliert immer der, der die meisten Fehler macht. Nicht so viel an dem Prozeß herumdoktern, sondern einfach Fehler vermeiden. Welche Fehler fallen denn offensichtlich ein? Hier eine kleine unvollständige Liste, ohne Priorisierung:
- Mehrere inkompatible Produktlinien pflegen. Je größer das Projekt, desto wichtiger ist es, daß zentrale Komponenten nicht mehrfach existieren
- Schlechte Kommunikation. Nicht auf den Bürofunk sollte man vertrauen, sondern seine Mitarbeiter in regelmäßigen Abständen über laufende Projekte informieren. Damit sind keine täglichen oder wöchentlichen Meetings gemeint. Einmal im Jahr ist aber entschieden zu wenig.
- Weiterbildung der Mitarbeiter ist kritisch. Man muß sie dazu nicht auf teure Seminare schicken, sondern einfach ab und zu in Neuentwicklungen einbinden. Ihnen die Arbeits-Zeit geben, sich neue Sachen anzueignen. Es ist fatal, wenn in einer Gruppe von 15 Entwicklern alle Innovationsarbeit von 2-3 Leuten gemacht wird.
- Sparen an technischer Ausstattung. Entwickler sind genügsame Mitmenschen. Viele von ihnen halten es sogar aus, in dunklen, schlecht belüfteten Räumen eng beieinander zu sitzen. Aber die klapperlahmen Rechner sollte man wenigstens ab und an austauschen, da sind sich wirklich alle einig.
Es gibt natürlich noch viel mehr. Oft sind es Themen aus der "zweiten Reihe", die helfen Wartungskosten in der Entwicklung zu reduzieren. Dazu gehört zum Beispiel, daß zentrale Codeelemente so gut kommentiert wie möglich sein sollten. Und so primitiv wie möglich in der Konstruktion, denn viele Leute müssen den Code verstehen um Fehler zu finden und darauf neue Funktionalität aufzubauen. Oft haben wir den Fall, daß manche neuentwickelte Elemente schreckliche Performance oder unnötige Fehler aufweisen die nur daher kommen, daß der betreffenden Entwickler den Code drumherum nicht begriffen hat.
Ich bin schon gespannt, was ich heute wieder zum besten geben werde, wenn ich gefragt werde, "du Daniel sag mal, warum würde das denn so lang dauern, das müßte doch irgendwie besser gehen ..?"
nunja, klingt sehr mittelstaendisch.
andere mir wohlbekannte mittelstaendler in deutschland haben es tatsaechlich geschafft ihre komplette produktpalette (je architektur) zu pruegeln und sind damit der insolvenz von der schippe gesprungen. das heisst ja nicht dass es keine projektspezifischen branches gibt, aber es gibt eben auch keine undokumentierten ausnahmen mehr und alles zieht am selben strang.
ein ehemaliger arbeitgeber von mir fasst die wesentlichen musskriterien in einem buch zusammen an das sich alle softwerker in dem laden zu halten haben:
practical software metrics for project management and process improvement
von robert grady
leider haelt sich trotz anweisung niemand dran und entsprechend viel geht schief.
das schlimme an dem oben beschriebenen szenario ist vor allen dingen dass der frage was man denn verbessern koennte nicht der ernsthafte wille zu grunde liegt dinge zu aendern.
Naja die Produktpalette glatt zu schleifen löst auch nicht alle Probleme. Wenn ich Produkte von der Stange habe befinde ich mich einfach in einem völlig anderen Marktsegment. Die Großkunden wollen Systeme, die genau auf ihre Prozesse zugeschnitten sind (deshalb kriegen die SAP Berater so einen Haufen Geld). Genau darin liegt der Mehrwert. Die Kunst als Softwareanbieter ist es also, den Kosten für die kundenspez. Anpassungen so weit wie möglich zu drücken. Also durch die Palette: Modularisierung, Wiederverwendbarkeit, automat. Tests usw.
Das gelingt aber nicht bei jedem Kunden gleich gut.
aehmm … ich glaub ich hab im posting “in einen einzigen sourcetree” vergessen …
Tja die “practical software metrics” müssen halt auch überwacht werden. Hey, Lead Dev!! Wobei das meiste, was da drinne steht ohnehin die meisten wissen [müssten]. Der Wille es richtig zu machen liegt nicht jedem inne und genau da liegt der Has’ begraben. Du musst die Leute von ihrer 9-5 Mentalität wegbekommen oder die betreffenden gar nicht erst einstellen. Leider erkennt man das nicht immer im Vorstellungsgespräch wie ich derzeit schmerzhaft erfahren muss. Als technischer Leiter mußt du deine Leute eben pflegen, damit sie motiviert werden, es besser zu machen (das ist auch mit der Sinn meines ursprünglichen Postings). Leider liegt das nicht innerhalb des mir bemessenen Kompetenz-Rahmens.
auch den grossen scheints so zu gehen *lol* :
http://www.spiegel.de/wirtschaft/0,1518,499324,00.html