Warum Entwickler auch Business Developer sein mĂĽssen
Seite 3: Business Development inklusive
Dieses Aufgabenportfolio geht weit über die Definition des Entwicklerberufs im landläufigen Sinn hinaus. Die Fachkraft ist nicht nur damit beschäftigt, Lösungen umzusetzen. Die Tätigkeit setzt viel früher an und zwar mit Beratungsleistungen: Prognosen zu Änderungen, Entwicklung möglicher Szenarien, Aufzeigen von Alternativen und Kostenbewertungen – das sind Tätigkeiten, die eher im Bereich Business Development verortet sind, als in der reinen Softwareentwicklung. Die damit aufgerufene Beratungskompetenz ist dabei nicht nur etwas, was Digital- oder Innovationsfirmen leisten, auch interne Entwickler sollten für diese Art des Mit- und Weiterdenkens erhöhte Wertschätzung erfahren. Auch das ist Teil der oben erwähnten Verantwortung in kooperativen Firmenkulturen.
Zurück zum Beispiel: In dem Fall war die Lösung relativ einfach. Man entschied sich, den Kunden ein Minimalszenario vorzuschlagen, das sich schnell und kostensparend umsetzen ließ. Statt die beiden Services aufwendig zu kombinieren, wurde eine ID in die Kontaktformulare eingefügt. Diese Kennung nutzt auch der Dienst, der für den Telefon-Support zuständig ist. Die Arbeitskräfte im Support können dadurch schneller und effektiver auf Anfragen eingehen.
Wachsen mit den Anforderungen
Bedeutet das nun, dass Teammitglieder der Entwicklung als Business Development Manager eingesetzt werden und diese so den Bezug zum Programmieren, zur technischen Seite, verlieren? Das Gegenteil ist der Fall. Vor allem Beratungsfirmen können es sich nur selten leisten, Entwickler*innen in einem eng umgrenzten Umfeld einzusetzen. Stattdessen ist Vielseitigkeit gefragt.
Ein Teammitglied der Entwicklungsabteilung setzt beispielsweise im Rahmen eines Projekts Nginx- oder Linux-Webserver auf und verwaltet sie über SSH. In einem anderen Fall entwickelt man Algorithmen, welche die Ausfallwahrscheinlichkeit von Komponenten in Stromversorgungseinrichtungen oder Fertigungsumgebungen vorhersagen. Auch der Umgang mit Container-Techniken und DevOps kann zum Alltag gehören ebenso wie spezielle Projekte. Ein Beispiel: Um Legacy-Anwendungen über DevOps-Verfahren debuggen zu können, kann es nötig sein, die Applikation mit dem JavaScript-Framework Redux zu "verheiraten". Ein Mangel an technisch orientierten Aufgaben besteht also nicht.
Technologie ist wichtig – aber bei weitem nicht alles
Apropos Legacy-Anwendungen: Zu den anspruchsvollsten Aufgaben zählt, die Code-Basis der Services beziehungsweise Applikationen auf einen aktuellen Stand zu bringen. Die meisten Entwickler*innen kennen Probleme wie Spaghetti-Code, lückenhafte oder fehlende Dokumentationen, komplexe technische Abhängigkeiten, bei denen häufig veraltete Komponenten mit im Spiel sind, und fehlende Testmöglichkeiten.
Sicherlich gibt es etliche Optionen, solche Klippen zu umschiffen. In den Diskussionen von Entwickler*innen fallen dann häufig Begriffe wie React-Hooks, Serverless Computing, Infrastructure as Code und Cloud. Selbstverständlich sollten Entwicklungsprofis damit vertraut sein. Für sie geht es jedoch primär darum, Anwendern die Möglichkeit zu geben, der Kundschaft zu einem Mehrwert zu verhelfen. Die Arbeit besteht in diesem Fall darin, Services zu entwickeln, welche die Wertschöpfung von Angeboten und Produkten verbessern. Der Code und andere technische Details spielen dabei eine untergeordnete Rolle.
Für klassische Programmierer mag das wie Hochverrat oder blanke Hybris klingen. Aber für ein Teammitglied der Entwicklung ist ein solcher Ansatz nur konsequent. Höchste Priorität ist es, den Anwendern eine praktikable Lösung zu bieten, die sich nicht in technischen Spielereien verliert, sondern neben Technologien auch Faktoren wie Wirtschaftlichkeit, Value-to-Market und Zukunftsorientierung berücksichtigt.
Praxisbeispiel: Predictive Maintenance in der Energieversorgung
Wie das in der Praxis aussehen kann, zeigt das Beispiel einer Software, die "proaktiv" Ausfälle von Systemen in einem Stromnetz erkennt: Stichwort Predictive Maintenance. Der vorhandene Software-Stack und Sourcecode der Services waren in diesem Fall nicht auf dem Stand der Technik. Doch daran ließ sich nichts ändern. Zwei Herausforderungen des Projekts waren:
- Es galt, die Software um eine Predictive-Maintenance-Funktion zu erweitern. Das war wegen des alten Sourcecodes eine anspruchsvolle technische Aufgabe.
- Dabei sollte gleichermaßen das Ziel im Auge behalten werden: Die Betreiber des Stromnetzes wollten die Möglichkeit erhalten, Servicefachleute bereits dann zu Kraftwerken oder Umspannanlagen zu schicken, bevor diese überhaupt ausfielen. Denn die Netzbetreiber können so Ausfallzeiten reduzieren und die Servicequalität steigern.
