Suche
Sie möchten eine aktivere Rolle bei ihren Softwareprojekten spielen? Werden Sie Software-Consultant!

Karrieretipp: So werden Sie vom „bloßen“ Programmierer zum Software-Consultant

Michael Thomas

© Shutterstock.com/Goodluz

Wie Michael Marsiglia auf dem Blog des Softwareentwicklungsunternehmens Atomic Object behauptet, verkauft sich jeder Entwickler, der ausschließlich Codezeile um Codezeile herunterreißt, eindeutig zu billig. Vielmehr, so Marsiglia weiter, sollten sich Programmierer die Mentalität eines Consultants zulegen, um sowohl Kunden als auch technisch weniger beschlagene Vorgesetzte dahingehend zu beraten, ein bestmögliches Produkt zu entwickeln.

Um die Unterschiede zwischen beiden „Denkschulen“ – Programmierer versus Consultant – zu veranschaulichen, präsentiert Marsiglia 3 Szenarien. Dabei ist es wichtig anzumerken, dass es sich bei diesen – insbesondere im Hinblick auf den Part des Consultants – um ideal- bzw. stereotypische, verkürzte Beispiele handelt, die einem in der Realität so vermutlich nie begegnen werden.

Szenario 1: Eine schwierige Frage beantworten

Der Stakeholder teilt dem Programmierer mit, dass er einen neuen Kunden gewinnen könnte, wenn das Produkt, an dem dieser zur Zeit werkelt, mit einer bestimmten neuen Technologie zusammenarbeitet. Der Stakeholder bittet den Programmierer um eine Einschätzung, wie lange eine Integration dieser Technologie dauern würde. Dem Programmierer ist die Technologie bislang nicht vertraut.

Ein Programmierer würde sich nun vermutlich direkt an die Arbeit machen und versuchen, sich in die gewünschte Technologie einzuarbeiten. Durch diese Mehrbelastung ist es sehr wahrscheinlich, dass sich der Zeitplan für seine reguläre Tätigkeit, z. B. die Fertigstellung eines Moduls, verzögert. Beim nächsten Interations-Meeting gibt er offen zu, dass er mehr Zeit braucht, um beide Arbeitsaufträge zu erledigen. Wie wird der Stakeholder auf diese Aussage vermutlich reagieren? Es sind mehrere negative Reaktionen denkbar: Der Stakeholder könnte aufgrund der Verzögerung in der ursprünglichen Planung beispielsweise frustriert reagieren oder den falschen Eindruck gewinnen, dass der Programmierer unzuverlässig und/oder zu langsam ist, weil er das Modul nicht zum ursprünglich angepeilten Datum abliefern kann. Vielleicht wollte der Stakeholder auch gar keine wirklich ins Detail gehenden Informationen über die neue Technologie, oder sah den Wunsch des Kunden eher als Gedankenspiel.

Im Gegensatz zum Programmierer würde ein Consultant, sich seiner dem Stakeholder überlegenen technischen Expertise bewusst, dem Stakeholder kurz nach dessen Anfrage beratend beispringen, ihm klar machen, dass die Bearbeitung seines Anliegens voraussichtlich mehrere Tage in Anspruch nehmen wird. Des Weiteren würde ein Consultant von sich aus um ein Meeting bitten, um wichtige Fragen zu klären, beispielsweise: Braucht der Kunde wirklich genau diese Technologie? Werden voraussichtlich auch andere Kunden nach dieser Technologie verlangen? Wie viel Zeit kann für den Auftrag erübrigt werden, bzw. wie sehr darf die alltägliche Arbeit unter der Bearbeitung der Kundenanfrage leiden?

Szenario 2: Umgang mit einem drohenden Problem

Ein Programmierer arbeitet seit Monaten an einem neuen, komplexen System, das mit maßgeschneiderter Hardware zusammenarbeiten soll, die von einem Dritthersteller entwickelt wird. Die Deadline für eine Präsentation rückt näher, dummerweise zeigt es sich, dass der Hardwarehersteller hinter dem Zeitplan liegt und sein Produkt zudem recht fehlerhaft ist – die Produktfreigabe wird also potentiell zum Desaster.

Ein Programmierer hätte vermutlich seit längerem ein schlechtes Gefühl im Magen mit sich herumgetragen, dieses jedoch aufgrund der eigenen Arbeitsbelastung und des hohen Drucks immer wieder verdrängt. Schlussendlich hält er es jedoch nicht mehr aus, nimmt seinen Mut zusammen und teilt dem verantwortlichen Vorgesetzten seine Bedenken hinsichtlich der Produktfreigabe mit.
Eine mögliche negative Konsequenz könnte sein, dass der Vorgesetzte enttäuscht darüber ist, dass die Bedenken zu spät geäußert wurden, gleichzeitig jedoch keine Idee hat, wie das Problem gelöst werden könnte – und den Programmierer dabei auch nicht um Rat fragt.

Der Consultant würde sich beim ersten Anzeichen möglicher Probleme mit dem Vorgesetzten in Verbindung setzen. Im Gespräch würde er zusammen mit dem Vorgesetzten alle möglichen Szenarien, inklusive harsche Entscheidungen wie eine Verschiebung der Produktfreigabe oder ein Wechsel des Hardwarehersteller, mit allen Pro- und Kontra-Argumenten, durchgehen. Im Rahmen dieses Zusammenspiels würde sich die beste Vorgehensweise herauskristallisieren.

Szenario 3: Das Unbekannte abschätzen

Der Stakeholder möchte, dass einer Anwendung ein gutes und sinnvolles, jedoch komplexes neues Feature hinzugefügt wird. Der Programmierer weiß aus dem Stehgreif nicht, wie er es implementieren könnte und bittet um Bedenkzeit. Er bricht das Feature auf kleinere Komponenten herunter und muss dabei feststellen, dass diese schwer zu implementieren und mit einem hohen Risiko behaftet sind.

Bei Schätzung des Zeitaufwands für die Implementierung präsentiert der Programmierer dem Stakeholder den schlimmstmöglichen Fall, geht gleichzeitig jedoch davon aus, in Wirklichkeit deutlich schneller liefern zu können. Dies könnte beispielsweise dazu führen, dass der Stakeholder das Feature desillusioniert abbläst, weil ihm der Aufwand zu hoch erscheint. Wird die Entwicklung trotzdem vorangetrieben und schafft es der Programmierer, die Arbeit in der Hälfte der angepeilten Zeit zu schaffen, könnte der Stakeholder den Einschätzungen des Programmierers in Zukunft misstrauen.

Als erfahrener Programmierer ist dem Consultant sofort klar, dass ein derartiges Feature viel Zeit in Anspruch nehmen wird und eine zu pessimistische Aufwandsschätzung beim Stakeholder die Alarmglocken klingeln lässt. Deshalb ergreift er die Initiative und entwirft einen Implementierungsplan, der die größten technischen Risiken bereits in den ersten Wochen angeht. Während des Meetings mit dem Stakeholder stellt er den Wert des Features heraus und macht klar, dass seine pessimistische Schätzung das Worst-Case-Szenario abbildet. Im Anschluss erläutert er mithilfe seines Implementierungsplans, dass es vermutlich nie zum schlimmsten Fall kommen wird.

Fazit

Welche Schlussfolgerungen kann man nun aus den präsentierten Szenarien ziehen? Was macht die Consultant-Mentalität aus? Ein mögliches Fazit könnte sein, dass ein Consultant sich im Gegensatz zum reinen Programmierer nicht nur Gedanken um den Code, sondern um das Softwareprodukt als Ganzes macht, und zwar in allen Stadien der Entwicklung. Oder, wie Marsigila es ausdrückt: Gute Entwickler sind gut darin, von Beschränkungen definierte Probleme zu lösen, während gute Consultants den Rahmen dieser Beschränkungen sprengen bzw. erweitern. Beide Fähigkeiten zusammengenommen ergeben eine äußerst mächtige Kombination.

Aufmacherbild: Business people meeting for budget definition von Shutterstock.com / Urheberrecht: Goodluz

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: