Soft-Skills als Software- Developer – Teil 2


Verbreitet die Message!

 

Hier geht es zum ersten Teil dieses Beitrages: Soft-Skills als Software Developer – Teil 1

Business-Nutzen im Blick behalten

Wir Developer lieben Code. Wir lieben die Technologie und die guten von uns bemühen sich um konstante Weiterbildung. Wir wollen den neuesten Stack ausprobieren, kennen best-practises und haben ein gutes Gespür dafür welche Lösungen “hässlich” sind und welche “schön” sind. Wir sind eben.. Techies.

Doch bei all der Liebe zur Technik bleibt oft der Business-Nutzen auf der Strecke. Wenn man zum dritten Mal die Lösung umbauen musste, weil der Code noch nicht wiederverwendbar und wartbar genug ist, leidet unsere Umgebung. Die Projekte kommen nicht voran, die Qualitätskontrolle fragt sich, wofür wir unsere Gehälter eigentlich bekommen und die Kollegen raufen sich die Haare, wann wir unser Features endlich abschließen.

Ich habe dabei ein klares Vorgehen: Ich versuche im ersten Schritt eine Proof-Of-Concept Lösung zu erstellen, an einer Stelle. Diese bespreche ich mit meinem Team und diskutiere Vor- und Nachteile. Wir einigen uns auf eine Lösung und setzen diese um. Dabei habe ich im weiteren Vorgehen eine klare Werteordnung: Wartbarkeit, Wartbarkeit, Wartbarkeit.

Deshalb lege ich so großen Wert auf Testbarkeit von Anwendungen, Kapselung und guter Struktur. Mein Ziel ist es, dass man schnell den Code verstehen, anpassen und testen kann.

Ich bin der Ansicht, dies gehört zu einer gewissenhaften Arbeit dazu.

Natürlich darf aus diesem Anspruch nicht vergessen werden, dass es so etwas wie eine Deadline gibt. Es ist oft ein schmaler Grad zwischen dem eigenen Anspruch und dem Liefertermin zu balancieren. Deshalb muss der Developer pro-aktiv auf den Projektleiter zugehen und sich informieren, wie der aktuelle Stand des Projektes ist und wie der Fokus gerade ist. Alles ist ein Kompromiss, doch was unabdingbar ist, ist die Notwendigkeit Verantwortung zu übernehmen.

Dinge auf den Punkt bringen

Als absolut wichtigste Eigenschaft eines Developers sehe ich die Kunst in der verbalen und schriftlichen Kommunikation Dinge auf den Punkt zu bringen. Schon bei einem Daily oder Jourfixe merkt man schnell, wer diese Disziplin beherrscht: In ca. 30 Sekunden sollte ausgedrückt werden können, woran man gerade arbeitet, was Impediments (Hindernisse) sind und mit wem man weitere Details klären muss. 

Auch hier ist diese Eigenschaft in der Kommunikation mit dem Fachbereich noch essentieller, da Meetings einerseits zeitlich knapp bemessen (und begrenzt) sind, andererseits nach mehr als einer Stunde die Luft bei jedem Beteiligten raus ist (und meistens auch aus dem Meetingraum). Man sollte darauf achten sich kurz zu fassen und zielgerichtet, dafür klar und deutlich zu kommunizieren. 

Leider ist dies nicht der reale Berufsalltag – sich klar und effizient auszudrücken ist eben eine Kunst, die man weder in der Schule, noch im Studium ausreichend lernt. Es ist eine Fähigkeit die man im Alltag lernt und großer Ausdruck der eigenen Person ist. 

Kritik an dieser Eigenschaft kann deshalb schnell als persönlich aufgefasst werden und sollte daher sensibel und unter vier Augen vorgebracht werden.

Am besten ist es jedoch auch hier pro-aktiv zu handeln und das Gegenüber zu beobachten. Geht derjenige auf mich nicht ein, hat er mich vielleicht nicht verstanden, oder ich leiere zu viel. Die Haltung sollte aufrecht und energetisch sein, die Tonalität aktiv und neugierig und die Wortwahl simpel. Ich selbst baue meine Sätze sehr oft viel zu komplex und empfinde derweil Freude daran mich “gehoben” auszudrücken. Es ist jedoch nicht der Sinn von Kommunikation dem Anderen zu vermitteln, dass man selbst gebildet sei.

Praxistipp: Als Student habe ich mehrere Seminare zur Stimmbildung und logopädischen Praxis besucht, sowie auch (im Rahmen des Lehramtstudiums) ein phoniatrisches Gutachten erstellen lassen. Später habe ich dann zuhause Reden gehalten, die ich aufgezeichnet und ausgewertet habe. Das ist eine Übung die ich jedem nur empfehlen kann. Ebenso kann man sich bei Toastmasters als Redner üben.

Fazit

Als Developer bietet es sich an, sich auf technische Probleme und Herausforderungen zu fokussieren und sich so hinter dem bunten Code zu verstecken. Stattdessen müssen wir aber die Fachlichkeit, den Projektzustand und letztlich den Business-Nutzen immer im Blick behalten. So sind wir effektiv und unser Geld wert.

Um diesen Business Nutzen und das Gesamtprojekt gut mitzuverfolgen, müssen wir viel sprechen und kommunizieren (siehe Teil 1), doch wie wir kommunizieren ist dabei entscheidend. Zu leise, zu unselbstbewusst oder zu unscheinbar macht es schwerer und schwerer zuzuhören. Sich in diesem Skill zu verbessern, heißt sich gegenüber der Konkurrenz abzuheben.

Verbreitet die Message!

Schreiben Sie einen Kommentar