Warum Entwickler auch Business Developer sein müssen
Code zu "schrubben" ist eine Sache, zusammen mit Kunden kreative Lösungen für deren Anforderungen zu finden, eine ganz andere.
(Bild: Black Jack/Shutterstock.com)
- Antti Pitkänen
Code zu schreiben oder Softwaretests und Entwicklungswerkzeuge zu konzipieren – diese Aufgaben haben lange Zeit das Beschäftigungsfeld der Entwickler*innen maßgeblich bestimmt. Doch im Zuge der Digitalisierung hat sich dieses Spektrum deutlich erweitert – und ist dabei spannender geworden. Denn heute ist ihr kreativer Beitrag gefragt, um Geschäftsmodelle von "analog" auf "digital" umzustellen. Das gilt nicht allein für die Innovations- und Digitalberatungen, sondern auch für die "klassischen" Softwareentwickler.
Man sollte sich von dem Gedanken verabschieden, dass Entwickler*innen oft nur das umsetzen, was Kollegen*innen aus dem Beratungsteam zusammen mit Kunden vereinbart haben – etwa Web-Anwendungen zu erstellen oder Legacy-Applikationen per "Lift and Shift" in eine Cloud-Umgebung zu überführen. Gefordert sind hingegen zunehmend Fachleute, die die Rolle von kreativen Problemlösern übernehmen. Das heißt, sie müssen sich vermehrt in die speziellen Anforderungen der Kunden hineindenken. Das gilt nicht nur für technische Aspekte, sondern auch für wirtschaftliche und strategische Erwägungen.
Sanft beginnen
Doch nach diesem Ausflug in strategische Höhen zunächst einmal zurück auf den Boden der Realität. Begonnen sei mit dem Berufseinstieg von Entwickler*innen oder dem in den Arbeitsalltag. Empfehlenswert ist, die neuen Kolleg*innen zu Beginn mit Aufgaben zu betrauen, die weniger "kritisch" sind. Das kann zum Beispiel das Abarbeiten von Tickets bei Produkten sein, die bereits bei Kunden im Einsatz sind. Häufig geht es dabei darum, Features hinzuzufügen oder Bugs zu beseitigen. Ein solch sanfter Einstieg ist vor allem für Mitarbeiter*innen hilfreich, die erst am Anfang ihrer Karriere stehen, sprich "frisch von der Schulbank" kommen. Selbiges mag aber auch für Quereinsteiger gelten. Durch diese Vorgehensweise hat das neue Teammitglied die Chance, sich ohne allzu großen Druck mit den Workflows und eingesetzten Tools vertraut zu machen.
Wichtig ist zudem, dass die bestehenden Beschäftigten den Neueinsteigern das Gefühl geben, dazu zu gehören, und dass die neue Meinung im Team ebenso zählt. Nicht förderlich ist dagegen, wenn den neuen Kolleg*innen gleich zu Beginn klar gemacht wird, dass ihre Python- oder JavaScript-Kenntnisse unterirdisch seien. Es hängt maßgeblich von der sozialen Kompetenz und den "Soft Skills" der Kolleg*innen und der Teamleads ab, ob sich eine produktive und vertrauensvolle Zusammenarbeit ergibt. Das bestätigt auch eine Studie des Personaldienstleisters Manpowergroup von 2018. Demnach suchten 78 Prozent der Unternehmen Mitarbeiter*innen, die gut kommunizieren können, an die 86 Prozent wollten Beschäftigte mit ausgeprägten Team-Fähigkeiten. Das galt auch für technische Sparten wie die Softwareentwicklung und das Programmieren.
Soft Skills machen den Unterschied
Allerdings hat laut der Studie etwa ein Drittel der Unternehmen Probleme damit, Mitarbeiter*innen mit solchen Soft Skills zu finden. Daher hängt es in hohem Maß von der Unternehmenskultur und der Vorbildfunktion der Belegschaft ab, inwieweit die Mitglieder*innen von Entwicklungsteams diese Fähigkeiten erwerben. Hilfestellung geben dabei Unternehmensgrundsätze (z. B.), die mittlerweile viele Technologieunternehmen definiert haben.
Doch was in einem Mitarbeiterhandbuch steht und wie Unternehmenskultur in der Praxis gelebt wird, sind leider in vielen Unternehmen oft grundverschiedene Dinge. Dennoch lohnt sich ein Blick auf die Versprechen, die Unternehmen ihren Mitarbeiter*innen machen. Wichtig ist beispielsweise, dass sie nicht ausschließlich Kundenbedürfnisse in den Mittelpunkt stellen.
Eine zentrale Rolle spielt zudem die Weiterentwicklung der Fähigkeiten der eigenen Mitarbeiter*innen, sowohl auf der fachlichen Ebene als auch im Bereich der Soft Skills. Hierfür sollte Arbeitgeber regelmäßig Möglichkeiten einräumen. Diese sollten auch nicht einfach nur vorgesetzt werden – nachhaltiger wirken die Programme, wenn diese Fortbildungen kooperativ erarbeitet werden, also dass das Unternehmen auf die Vorstellungen der Mitarbeiter in puncto Weiterbildung und Entwicklungswünsche eingeht.
Zur Kultur der Arbeitgeber zählt auch ganz wesentlich die interne Kommunikation. Hier hat sich in den letzten Jahren ein Wandel bemerkbar gemacht. Hierarchische Führungskulturen nach dem Motto "Ich bin der Chef und weise hiermit an" treten mehr und mehr hinter kooperativen Ansätzen zurück, die den Mitarbeiter*innen zunehmend Freiheit und Eigengestaltung zugestehen. Ob diese Ansätze im Alltag auch gelebt werden, zeigt sich dann allerdings erst in der Praxis. Wie auch immer hier die Erfahrungen sind, sicher ist, dass sich hier das Klima geändert hat und viele junge Arbeitnehmer die kooperativen Kulturen bevorzugen. Allerdings sollte man sich dabei vor Augen halt, dass mit diesem Mehr an Freiheit auch ein Mehr an Verantwortung verbunden ist.
Mit den Aufgaben wachsen
Nach der Aufwärm- und Eingewöhnungsphase folgt für Entwickler*innen typischerweise ein erster Schritt in Richtung Kundenberatung. Ein Beispiel: Ein Unternehmen will zwei Services zusammenfassen, die bei der Kundenbetreuung eingesetzt werden: das Übermitteln von Kontaktformularen via E-Mail sowie das Buchen eines Telefontermins bei einem oder einer Support-Mitarbeiter/in. Das Problem dabei: Beide Services haben aus technischer Sicht nichts miteinander zu tun; sie zu kombinieren – so der Ausgangsplan des Unternehmens – hätte neue Backend-Services erfordert.
In einem solchen Fall gilt es, auch beratend tätig zu werden:
- Es ist zu prüfen, welche Relevanz die gewünschten Änderungen für den Geschäftsbetrieb der Anwender haben. Das kann auch die Entwicklung von Szenarien umfassen, mit denen das Unternehmen seinen Kunden ergänzende Services anbieten und somit Mehrwert generieren kann.
- Es gilt zu ermitteln, welche technischen Alternativen es gibt, um diese Anforderungen umzusetzen.
- Außerdem sollten die technischen und finanziellen Aufwendungen, die damit verbunden sind, geprüft und im letzten Schritt mit den Kunden diskutiert werden, welches Szenario für sie akzeptabel ist.
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.
Dauerhafte Partnerschaften statt "Code and Forget"
Ein positiver Nebeneffekt dieser Arbeitsform ist, dass Entwickler*innen in den meisten Fällen sehen, wie sich die Arbeit in der Praxis bewährt. Es kann also nicht einfach darum gehen, nur Code zu erstellen und zu testen, dann ab zum Kunden und fertig. Ganz nach dem Motto "Code and Forget".
Vielmehr muss es darum gehen, dass Entwickler*innen im Idealfall oft mehrere Jahre lang einen Account betreuen. Für Kunden bedeutet das, dass Software und Services aus einem Guss sind. Zudem gibt es weniger Reibungsverluste in der Abstimmung zwischen beiden Parteien, und die Kundschaft profitiert von einer länger andauernden Co-Creation-Partnerschaft. Schließlich haben es die Entwickler*innen in der Hand, eine Applikation "sauber" zu designen und zu testen. Das reduziert den Wartungsaufwand der Lösung. Außerdem ist es dann einfacher, sie auf Wunsch, um neue Funktionen zu erweitern.
Rotation erhält den Spaß an der Arbeit
Vernünftige Unternehmen handeln sicherlich nicht nach dem Motto "Einmal dieser Kunde, immer dieser Kunde". Denn dann würde vermutlich ein Großteil der Entwickler*innen spätestens nach 18 Monaten davonlaufen. Die Regel sollte sein, dass ein Teammitglied bei mehreren Accounts mitarbeitet. Außerdem besteht die Möglichkeit, nach einiger Zeit den Schwerpunkt von einem Projekt auf ein anderes zu verlagern. Das ist das normale Prozedere, allerdings sollten Interessierte im Vorfeld nachfragen, wie es das Unternehmen mit der "Job-Rotation" hält.
Jedoch sollte nicht nur die Möglichkeit bestehen, zwischen den Projekten zu wechseln. Auch eine Bewegung in "vertikaler" Richtung ist denkbar, vor allem bei Projekten mit einer längeren Laufzeit. So hat der Autor dieses Beitrags mittlerweile die Funktion eines Scrum Master bei einem solchen Vorhaben übernommen. Dadurch hat sich das Aufgabenspektrum deutlich erweitert. Die Agenda umfasst nun die Kommunikation mit Kunden und die Verteilung von Entwicklungsaufgaben an die Teammitglieder, aber auch das Coding auf der Anwendungsebene und Aufgaben aus dem Bereich DevOps.
Selbst das Onboarding neuer Mitarbeiter*innen, die Teilnahme als Sprecher an Fachveranstaltungen sowie Meetings mit Vertrieb und Account-Management stehen auf der Tagesordnung. Das untermauert, dass Entwickler*innen ein weitläufiges und interessantes Betätigungsumfeld vorfinden, allerdings auch eines, das durchaus herausfordernd sein kann und weit mehr Skills erfordert als nur das Programmieren.
Developer müssen keine Nerds sein
Doch welche Ausbildung oder speziellen technischen Fertigkeiten müssen Entwickler*innen mitbringen? Zumeist kommt es nicht darauf an, perfekten Code erstellen zu können. Sicherlich ist Coden ein Bestandteil des Jobs, aber eben nur einer von vielen. Daher können auch Personen, die quer einsteigen, eine Entwicklerlaufbahn einschlagen – etwa Absolvent*innen einer Ausbildung mit dem Schwerpunkt auf Betriebswirtschaft.
Wichtig ist, dass Bewerber*innen bereit sind, sich mit technischen Fertigkeiten wie Programmieren sowie den Technologien vertraut zu machen, die bei der Digitalisierung von Prozessen und Geschäftsmodellen des Unternehmens eine Rolle spielen. Aber ebenso relevant ist, dass Entwickler*innen mehr erreichen können, als nur die technischen Hausaufgaben umzusetzen, die andere definiert haben. Zu ihren Tätigkeiten gehören, zusammen mit Kunden neue Ideen zu entwickeln und umzusetzen, kreative Lösungen zu finden und das eine oder andere Mal auch eine konstruktive Auseinandersetzung zu führen.
Dabei steht immer ein Gedanke im Mittelpunkt: gemeinsam mit den Kunden Strategien und digitale Ansätze zu erarbeiten, die einen klaren Mehrwert bieten. Langweile kommt bei dieser Interpretation des Entwicklerberufs jedenfalls nicht auf.
Antti Pitkänen ist 29 Jahre jung und arbeitet als Software- und Business Developer in der Digitalberatung Futurice. Sein Arbeitsplatz befindet sich in der finnischen Stadt Tampere, einem der acht internationalen Standorte des Unternehmens.
(ane)
