Programmieren braucht Projektmanagement
Unser CEO Sven Schweiger ist seit vielen Jahren Lektor an Fachhochschulen in Wien. Unter anderem unterrichtete er dort das Fach "Projektmanagement" in Studiengängen mit Informatik- und IT-Schwerpunkt.
Als er eines Tages die Feedback-Bögen der Studierenden durchging, fand er folgendes Kommentar: "[Projektmanagement] ist nur leider für mich als Vollblut-Informatiker vollkommen uninteressant. Dafür gibt es doch Wirtschaftsinformatik, oder?".
Dieser Kommentar löste bei Sven ein leichtes Augenzucken aus. Sollte es ein Scherz gewesen sein, wäre er gelungen. Einem ernst gemeinten Kommentar müssen wir vehement widersprechen.
Unsere Erfahrung der letzten 25 Jahre hat uns eines immer wieder gezeigt: Viele IT-Projekte gehen nicht wegen technischer Probleme schief – der Hund liegt meistens im Projektmanagement begraben. Wer ein reiner Code Monkey ist (also nur programmieren kann und will), setzt leicht ein Softwareprojekt in den Sand.
Zwei Bereiche des Projektmangements: Außen und Innen
Eines vorneweg: Wenn wir über Projektmanagement sprechen, geht es uns um zwei Bereiche: Zum einen das Projektmanagement mit direktem Bezug zum Kunden. Zum anderen um das Projektmanagement innerhalb des eigenen Unternehmens bzw. unserer Teams.
Die Kundenseite im Projektmanagement
Zum ersten Bereich: Kundenseitig haben wir – ganz nach Scrum-Art – unsere "Product Owners", die verantwortlich für das übergreifende Projektmanagement sind und sich zusätzlich um Dinge wie Anforderungsanalyse, Spezifikation, Tests und das Thema Usability kümmern. Sie sind alle "Vollblut-Informatiker*innen", die in die Product Owner Rolle hineingewachsen sind und gleichzeitig die technischen Herausforderungen verstehen.
Unsere Product Owners haben eine Aufgabe, die vielen vielleicht undankbar erscheint: Sie hinterfragen die Vorstellungen, Wünsche und Anforderungen unserer Kunden. Das mag manchmal lästig sein (für beide Seiten) aber es ist immer immens wichtig, um mögliche Missverständnisse zu vermeiden und die tatsächlichen Ziele zu finden.
Tut man das nicht, kann das Softwareprojekt besonders gegen Projekt-Ende hin eine teure und mühsame Angelegenheit werden. Im schlimmsten Fall entsteht Software, die niemand braucht und keinen Mehrwert für die Kunden und Anwender:innen bringt. Jedenfalls entsteht keine Software, die glücklich macht.
Unsere Product Owners repräsentieren intern unsere Kunden und vertreten deren Wünsche, Werte und Ziele. gegenüber unseren Softwareentwicklungs-Teams. Sie verstehen sich nicht nur als Projektmanager:innen, sondern wollen Probleme lösen. Und diese Probleme sind oft nicht technischer Natur, sondern finden sich auf der Prozess- oder auch auf der menschlichen Ebene beim Kunden.
Die interne Seite des Projektmanagements
Als IT-Unternehmen, das mit und nach agilen Prinzipien arbeitet, legen wir auch großen Wert auf das interne Projektmanagement.
Soll heißen: Wirklich jede/r unserer Software-Entwickler:innen trägt als Teil eines Teams Verantwortung für den Verlauf eines Softwareprojektes.
Jedes Team entscheidet selbst – mit Blick auf den Zeitplan und mögliche spezielle Anforderungen des Kunden – welche Features von wem innerhalb des kommenden Sprints umgesetzt werden. Für diese Planung und die zugesagten Features stehen unsere Teams den Product Owners (und damit den Kunden) dann auch gerade.
Product Owner sorgen auch für einen reibungslosen Ablauf von Demo-Meetings für Kunden. Das sind jene Meetings, in denen die Fortschritte im Projekt ausgewählten Vertreter:innen des Kunden gezeigt werden - und zwar durch Mitglieder der Entwicklungsteams.
Unsere "Vollblut-Informatiker:innen" stehen so in direktem Kontakt mit dem Kunden und können live erleben, wie ihre Umsetzung der Lösung ankommt und ob sie den Vorstellungen entspricht.
Vollblut-Informatiker:innen sind Allrounder:innen
Wie man an diesem kurzen Einblick in die Welt der CSS sehen kann, ist die Zeit der IT-Gurus im dunklen Kammerl, die nur in 0101-Welten leben, längst vorbei.
Heute sind Vollblut-Informatiker:innen nicht nur technisch gefordert, sondern müssen auch Teamplayer mit Problemlösungskompetenz sein. Sie arbeiten eigenverantwortlich und sind sozial kompetent.
Auch bedeutet Veränderungsmanagement für sie nicht, es als furchtbar und lästig zu finden, dass der Kunde schon wieder "alles geändert" hat. Sie wissen, dass sich innerhalb eines Projektes Anforderungen ändern können, auch wenn diese zuvor mit höchster Sorgfalt spezifiziert und geplant wurden.
Wesentlich ist agil zu sein, also kurzphasige und exakte Kurskorrekturen durchzuführen, ohne dabei "planlos zu wurschteln".
Unsere Softwareentwickler:innen sehen es nicht als Zeichen von Professionalität an, nur mit technischen Raffinessen zu glänzen oder als "Code Monkeys" einfach eine Zeile Code nach der anderen zu kreieren. Vielmehr ist es ihr Anliegen, für unsere Kunden einen Mehrwert zu schaffen und eine optimale Lösung zu entwickeln.
Also: Programmieren und Projektmanagement sind keine zwei unabhängigen Disziplinen. Nur wer beides beherrscht und verinnerlicht hat, darf sich unserer Ansicht nach zu Recht Vollblut-Informatiker:in nennen!
