Acht Regeln für eine effektive Softwareproduktion

Im Laufe meiner Karriere habe ich an mehreren realen Softwareprojekten teilgenommen und beobachtet, wie die Dinge auf allen Ebenen erledigt werden: Entscheidungsfindung, Übernahme von Praktiken, Teambildung, Rekrutierung, Verteilung von Fähigkeiten usw. Offensichtlich führten unterschiedliche Ansätze zu unterschiedlichen Ergebnissen . Da ich ein verbesserungsorientierter Typ bin, habe ich die effektivsten Praktiken und besten praktischen Tricks bemerkt und gesammelt, die mir bei meiner Arbeit helfen.

Aus Beobachtung zu lernen ist ein schwieriger und langwieriger Weg, dies zu tun. Ich würde mich sehr freuen, dieses Wissen stattdessen früher aus Büchern zu entnehmen. Leider habe ich nichts zu dem Thema gefunden. Also beschloss ich, meine Erfahrung mit anderen Suchern dieser Art von Wissen zu teilen. Hoffentlich erspart es ihnen ein paar Jahre persönlicher Recherche.

In diesem Artikel erfahren Sie, wie Sie die durchschnittliche Branchenleistung übertreffen können, indem Sie robuste und zuverlässige Softwareprodukte entwickeln, die 5- bis 10-mal weniger Wartung erfordern. Ohne falsche Bescheidenheit kann ich sagen, dass ich (persönlich wie auch mein Team) in den vergangenen 10-15 Jahren alle Erwartungen übertroffen und eine Erfolgsspur hinterlassen habe. Manager können nicht glücklicher sein.

Einmal hat mein Team in unglaublich kurzer Zeit ein wichtiges Projekt auf die Beine gestellt, für das wir vom höheren Management mit dem Preis „High Performance Team“ ausgezeichnet wurden. All dies, ohne dass wir uns über Nacht und am Wochenende verausgaben. Ganz normale Arbeit.

Sie sehen, effektives Softwareproduktionswissen selbst ist eine Macht. Tatsächlich ist es eine Art schwarze Magie, die nicht viele Menschen verstehen können, selbst wenn sie in einfachen Worten erklärt wird. Sie erhalten es kostenlos. Lesen Sie weiter, wenn Sie als Magier der Softwareproduktion wahrgenommen werden möchten.

Für wen ist das?

Lassen Sie mich hier einen wichtigen, wichtigen, wichtigen Haftungsausschluss machen.

Ich wende mich an diejenigen, die einen Produktivitätsschub benötigen. Nicht alles im Leben dreht sich um Produktivität. Auch nicht alle Softwareprojekte. Es gibt Fälle, in denen Sie nicht nach Ihrer Leistung beurteilt werden. Offensichtlich würden diese Praktiken dann nicht helfen.

Diese Techniken sind am nützlichsten für Teamleiter, Architekten und Projektmanager, obwohl auch erfahrene Softwareentwickler davon profitieren können.

Regel Nr. 1: Verstehen Sie die IT-Mentalität

Die IT-Branche ist eine Mischung aus Wissenschaft, Technologie, Kunst und Wirtschaft. Es ist ziemlich schwierig, dorthin zu navigieren, ohne diese Aspekte auf einem ausreichend guten Niveau zu verstehen. Das größte Problem ist, dass die Branche selbst ziemlich komplex ist; Daher sind Best Practices auch komplex. Sie müssen viel lernen und Ihr Wissen durch viel Üben überprüfen, um erfolgreich zu sein.

Die unglaubliche Technologie-Update-Rate macht es doppelt schwierig. Nichts, was Sie vor zehn Jahren gelernt haben, wird mehr gebraucht. Sie müssen also in einem beschleunigten Tempo lernen.

Zusammenfassend können wir sagen, dass der Erfolg im IT-Bereich nicht auf angeborenen Fähigkeiten oder Gefühlen basiert, sondern auf harten praktischen Beispielen. „Folgen Sie niemals dem Bauchgefühl“ oder glauben Sie nur auf der Grundlage von Gefühlen, einschließlich Ihres.

Wenn ja, ist die Idee eine Überlegung wert. Fordern Sie andernfalls eine sehr gute und sehr detaillierte Erklärung darüber, wie die Wahl dieses Weges das Leben Ihres Teams verbessert. Wenn es diesen Test besteht, planen Sie ein einfaches Proof-of-Concept-Projekt, das experimentell beweist, dass es in Ihre Umgebung passt.

Es ist wichtig, hier zu verstehen, dass es keine richtigen und falschen Lösungen gibt, da es viele Möglichkeiten gibt, Softwareprobleme zu lösen. Es gibt jedoch gute und schlechte Verständnisse der Lösung.

Wenn eine Person eine Idee im Detail klar artikulieren oder einen Zusammenhang zwischen der Annahme dieser Lösung und dem Erfolg des Teams herstellen kann, um andere Teammitglieder zu überzeugen, dann können wir uns auf die Vision dieser Person verlassen und auf eine hohe Erfolgswahrscheinlichkeit hoffen.

Regel Nr. 2: Mischen Sie nicht Softwareproduktions- und Softwareentwicklungsmethoden

Die Softwareproduktion basiert auf der Softwareentwicklung. Diese beiden haben jedoch völlig unterschiedliche Ziele, Denkweisen und Praktiken. Der Versuch, ein Problem aus einem dieser Bereiche mit den Methoden eines anderen zu lösen, führt zu lächerlichen Ergebnissen. Es ist wichtig, die Unterscheidung zu verstehen und für jede dieser Welten geeignete Methoden anzuwenden.

Softwareentwicklung ist eine Kombination aus Kunst und Handwerk. Die Kunstkomponente wird immer da sein, unabhängig von Automatisierungstools und Softwareentwicklungsmethoden da draußen. Daher erfordert das Lösen von Entwicklungsaufgaben maximale Konzentration und Abschirmung von allen anderen ablenkenden Signalen.

Der beste Weg, einen erfahrenen Entwickler zu motivieren, besteht darin, ihm eine Aufgabe in ihrer rein technischen Form ohne alle menschlichen Faktoren zu präsentieren. Alle Anforderungen sollten auch in Fachsprache formuliert werden. Sie sollten leicht überprüfbar sein, damit sie während ihrer Solo-Recherchephase zum Ziel navigieren können.

Die Softwareproduktion hingegen ist eher im Bereich der Betriebswirtschaftslehre angesiedelt. Sie wissen von der einen Seite, was Ihr Kunde braucht, und von der anderen wissen Sie, welche Teamressourcen Ihnen zur Verfügung stehen. Jetzt versuchen Sie also, Ihre Teamanstrengungen auf das Erreichen des Ziels auszurichten. In der Zwischenzeit können Sie auch Ihre Fortschrittsgeschwindigkeit einschätzen und dem Chef einen versierten Plan präsentieren. Die wichtigen Fähigkeiten sind, die Wünsche Ihrer Kunden zu verstehen, die Stärken Ihres Teams zu verstehen und formelle Pläne und Zeitpläne zu kommunizieren.

Vor diesem Hintergrund möchte ich hervorheben, dass viele Rollen in der Softwareentwicklung in beiden Welten arbeiten – beim Bau einer Brücke zwischen Business und Technologie – wie Teamleiter, Architekten, Analysten und Projektmanager. Menschen in diesen Rollen sollten in der Lage sein, problemlos zwischen zwei Ebenen der Realität zu wechseln und zu verstehen, wann es Zeit ist, über Geschäfte zu sprechen, und wann es Zeit für Kunst ist.

Regel Nr. 3: Verwenden Sie persistente Speicherung als Erweiterung des menschlichen Gedächtnisses

Das menschliche Gedächtnis hat, obwohl es eine erstaunliche Kapazität hat, seine Grenzen. Sie erinnern sich an Dinge mit unvorhersehbarer Genauigkeit und Dauer, und wenn Sie es vergessen, gibt es keine Möglichkeit, es nach Belieben abzurufen.

Aus diesem Grund verwenden wir einen dauerhaften Speicher, um uns mit einer vorhersehbaren Geschwindigkeit fortzubewegen. Hier geht es nicht um formelle Dokumentation wie Benutzerhandbücher, die Sie lange nach der Tat erstellen und die andere verwenden können. Hier geht es darum, Dokumente buchstäblich als externe Erweiterung Ihres Gedächtnisses während der Arbeit zu verwenden, die Ihnen hilft, den Softwareentwicklungsprozess zu durchlaufen.

Ich empfehle Ihnen, Ihre Gedanken und Pläne auf dem Weg dorthin zu dokumentieren, wenn Sie vor nicht trivialen Aufgaben oder Aufgaben stehen, an denen mehr als eine Person beteiligt ist. Versuchen Sie, es so billig wie möglich zu machen. Erstellen Sie keine formellen Dokumente mit Firmenlogo darauf. Ein gutes Werkzeug wäre ein Firmenwiki mit Ihrem Projektbereich darin. Erstellen Sie spezielle Seiten für die Aufgaben oder Probleme (30 Sekunden). Aktualisieren Sie es dann jedes Mal, wenn Sie eine Idee haben oder mit anderen darüber diskutieren möchten.

Sagen Sie in einem Meeting „Moment mal, lassen Sie mich das aufschreiben“ und nehmen Sie sich 10-30 Sekunden Zeit, um es schriftlich auszudrücken. Das Schreiben sollte nicht umfangreich sein, aber es sollte vollständig und kohärent sein, als würden Sie die Idee in ihrer Gesamtheit auf das Papier übertragen. Später sollten Sie oder jeder andere, der Ihren Abschnitt liest, ihn so klar verstehen, wie Sie ihn jetzt verstehen. Dieser Trick spart viel Zeit und erlaubt Ihnen dennoch, spontan zu dokumentieren.

Diese Technik dient zwei Zwecken.

Erstens blockiert es Ihren Fortschritt auf dem Weg zum Erfolg, indem es fest in den Stein gedrückt wird. Kein Risiko mehr, dass jemand etwas vergisst, dasselbe immer wieder wiederholt oder dasselbe, was bereits verhandelt wurde, neu verhandelt.

Zweitens klären Sie Ihren Geist und werfen das Problem aus, das Sie gequält hat. Jetzt ist Ihr Geist hungrig nach der nächsten Herausforderung. Was für ein Produktivitätsschub!

Dies gilt für jede Größe von Projekten oder Aufgaben. Für größere haben Sie einfach größere Bereiche mit einer Seitenhierarchie, die mit der Entwicklung Ihres Projekts allmählich wächst. Das wichtige Konzept hier ist, einen Dokumentationsraum und eine Dokumentationsstruktur vorzubereiten, bevor Sie mit Ihrer Aufgabe beginnen, ein schnelles Speicherauszugsprotokoll zu erstellen!

Für Leute, die technologische Analogien bevorzugen, würde ich unseren Verstand mit einem Prozessor mit immenser Rechenleistung, aber begrenztem Arbeitsspeicher vergleichen. Sie können im Wesentlichen an eine Sache gleichzeitig denken. In dieser Analogie dient Ihre Dokumentation als dauerhafter Speicher, während Ihr Verstand komplexe Probleme in einem iterativen Ansatz löst. Irgendwann beschließen Sie, die nächste Iteration zu starten, die vorherige Dokumentation zu lesen und den aktuellen Stand in Ihr operatives Gedächtnis zu laden, eine Weile darüber nachzudenken und den Code und die Dokumentation mit Ihren neuen Erkenntnissen zu aktualisieren. Schritt für Schritt bis zur Fertigstellung.

Alles in allem ermutige ich die Leute nicht, viele Aufgaben auf einmal zu bearbeiten. Im Gegenteil, je weniger Aufgaben Sie haben, desto besser. Nicht viele Arbeitssituationen sind jedoch wirklich für den Menschen optimiert, und Multitasking kann erforderlich sein, und Sie müssen irgendwie damit umgehen. Der obige Trick hilft, damit besser umzugehen.

Regel Nr. 4: Hören Sie auf, Zeit mit formeller Zeitschätzung zu verschwenden

Kein Projekt gleicht dem anderen. Wenn Sie das nächste Mal ein ähnliches Projekt durchführen, haben Sie andere Kunden, andere Ziele, ein anderes Team; vielleicht sogar verschiedene Technologien. Selbst wenn Sie Standardtools und -komponenten verwenden, müssen Sie deren Konfiguration und Architektur noch anpassen. Wenn Sie Softwareprojekte abwickeln, denken Sie daran, dass sie zwischen 50 % und 100 % kundenspezifische Arbeit beinhalten. Sie erfordern Forschung, Diskussionen, Nachdenken, Versuche und andere höchst unvorhersehbare Aktivitäten. In der Praxis werden Sie möglicherweise einen enormen Unterschied zwischen dem, was oberflächlich als exakt derselbe Projekttyp erscheint, und dem, was Sie zuvor getan haben, feststellen. Ein neuer Projekttyp ist folglich fast unmöglich genau abzuschätzen.

Wenn es so unvorhersehbar ist, wie sollen Projektmanager dann einen Projektplan präsentieren und sich daran halten?

Es gibt eine formale Methode, dies in der Literatur zu tun; Das heißt, das gesamte Projekt in kleinere Schritte aufzuteilen, abzuschätzen, wie lange jeder Schritt dauert, und dann die Gesamtprojektlänge zu berechnen, indem die Arbeitslänge der einzelnen Teile kombiniert wird. Hinter dieser Methode, die in MBA-Kursen gelehrt wird, steckt jede Menge Theorie.

Leider kann es keine noch so große Mathematik retten. Diese Methode ist notorisch ungenau, da sie völlig unbrauchbar und unpraktisch ist, ganz zu schweigen davon, wie unglaublich zeitaufwändig sie ist. Ich habe noch nie einen Projektleiter gesehen, der formale Berechnungsmethoden ohne Anpassungen verwendet, auch nicht unter Methodenfanatikern. Auch dann nicht, wenn das Unternehmen eine solche Methodennutzung strikt vorschreibt! Tatsächlich verwenden die leistungsstärksten Manager völlig andere alternative Methoden, wie unten beschrieben:

Ein guter Projektmanager beachtet den Projekttyp, die Umgebung, die beteiligten Ressourcen, den Organisationstyp und alle anderen Arbeitsaspekte, die die tatsächliche Projektdauer beeinflussen. Natürlich muss niemand nur aus eigenen Fehlern lernen. Solche Beobachtungen können sowohl direkt als auch indirekt erfolgen; zum Beispiel durch Bücher oder durch das Studieren von Projekten, die von anderen Menschen durchgeführt wurden, oder sogar durch bloßes Weitergeben des Wissens von Person zu Person. Dieses statistische Top-Level-Wissen verbessert die Navigation im persönlichen Projektplan.

Ich möchte zwei wichtige Konsequenzen der oben beschriebenen Methode hervorheben.

Erstens verbessert sich die Schätzgenauigkeit mit der Erfahrung. Es gibt keine Möglichkeit, dass eine unerfahrene Person, die mit einer starken Methodik bewaffnet ist, darin gut sein kann. Zweitens ist auch die beste Schätzung nur statistisch gut. Das heißt, man kann sagen, dass ein bestimmtes Projekt zwischen vier und zwölf Monate dauern kann. Unter der Annahme, dass dies richtig ist, sollte man verstehen, dass es eine 50-prozentige Chance gibt, dass das Projekt seine achtmonatige Durchschnittszeit überschreitet.

Das Verständnis der statistischen Vorhersage hat eine so unglaubliche Wirkung. Ein kluger Manager würde ein solches Projekt einfach auf zwölf Monate kalkulieren und dann alle begeistern, indem er es vorzeitig abschließt. Mit anderen Worten, niemand würde erwarten, dass ein Team den Projektplan auf den Tag genau einhält.

Der allgemeine Ratschlag für Projektmanager und ihre Chefs wäre, keine Zeit mehr mit formalen Zeitschätzungsmethoden zu verschwenden. Fördern Sie stattdessen das Sammeln statistischer Informationen über die Projektdauer und teilen Sie diese Informationen im gesamten Unternehmen. Ich kenne Unternehmen, in denen ein solcher Ansatz unternehmensweit implementiert wurde, was zu einer wunderbaren Vorhersagegenauigkeit führte.

Regel Nr. 5: Verstehen Sie die Kosten für das Wechseln von Aufgaben und das Jonglieren von Prioritäten

Der menschliche Geist ist von der Natur erstaunlich konstruiert. Obwohl es unglaublich ist, hat es seine Grenzen. Mit anderen Worten, es wurde entwickelt, um in bestimmten Bereichen und bei einer bestimmten Art von Aufgabe hervorragende Leistungen zu erbringen.

Der Verstand eines Entwicklers ist definitiv ein großer Vorteil in der Softwareentwicklung. Wären Sie als Projektleiter daran interessiert, es besser zu verstehen und in eine Position zu bringen, in der es am besten funktioniert?

Lassen Sie es uns einfach ausdrücken und zu viel Theorie vermeiden. Denken Sie daran, dass Theorie Sie nur so weit bringt, bevor Sie aus Erfahrungen lernen müssen, entweder aus Ihren eigenen oder aus denen anderer.

Der menschliche Geist hat ein starkes Problemlösungs- und Ideenfindungspotential. Leider ist es nicht immer möglich, dieses Potenzial auszuschöpfen, vor allem, weil Sie zur Unterstützung der Ideenfindung alle Teile des Problems gleichzeitig in Ihrem aktiven Gedächtnis zusammenhalten müssen. Aus diesem Grund durchläuft das Lösen komplexer Probleme eine Vereinfachungsphase, wenn eine Aufgabe verallgemeinert oder neu formuliert wird, um unwichtige Teile herauszuschneiden und die Anzahl der gleichzeitig im Gedächtnis behaltenen Elemente zu verringern. Mit anderen Worten, wir können entweder ein sehr enges komplexes Problem oder mehrere einfache Probleme lösen.

Das Verhältnis ist jedoch nicht linear. Die Erhöhung der Anzahl der Dinge, die Sie gleichzeitig tun, beeinträchtigt Ihre Fähigkeiten zur Problemlösung drastisch. Deshalb hat und wird die Menschheit schon immer Rollentrennung als Lebensoptimierung eingesetzt haben. Zwei Personen, die getrennt an zwei Aufgaben arbeiten, werden schneller einen Durchbruch erzielen, als wenn sie beide gleichzeitig an beiden Aufgaben arbeiten.

Eine weitere wichtige Eigenschaft des menschlichen Geistes ist seine Unfähigkeit, sofort zwischen Aufgaben zu wechseln, wie es Computer tun. Tatsächlich kann man nicht einfach nach Belieben aufhören, an etwas zu denken. Man kann auch nicht sofort mit voller Kraft über ein neues Konzept nachdenken. Diese Art von mentaler Trägheit wird perfekt von Flugsicherungsbetreibern veranschaulicht. Auch wenn sie auf das Radar schauen und das ganze Bild sehen, müssen sie es dennoch in ihren Speicher laden, um schnell arbeiten zu können. Es dauert zehn Minuten, bis ein neuer Bediener den Bildschirm betrachtet, bevor er den alten bei einem Schichtwechsel ersetzen kann.

Was es noch schlimmer macht, ist, dass wir Dinge nicht nach Belieben vergessen können. Alles, was wir gelernt haben, bleibt bei uns und verblasst nur allmählich mit der Zeit und nimmt Platz ein, den wir für neues Wissen nutzen könnten. Und noch schlimmer, dieser Effekt wird manchmal durch das Gefühl einer „unerledigten Sache“ verstärkt. Es ist viel einfacher, etwas zu vergessen, das abgeschlossen ist und das Sie in Zukunft nie mehr brauchen werden. Wenn Sie hingegen Dinge beiseite legen, um sie später zu beenden, klammert sich Ihr Gehirn natürlich an die Informationen, die als „für zukünftige Referenz“ gekennzeichnet sind, und ist nicht bereit, neues Wissen an seine Stelle zu setzen.

In Ordnung. Nachdem wir nun die Idee des Aufgabenwechsels skizziert haben, wollen wir sehen, wie es in einem realen (sozusagen) Gedankenexperiment funktioniert.

Stellen Sie sich vor, Ihre zehn regulären Entwickler arbeiten an zehn regulären Aufgaben – eine Aufgabe pro Person. Vorausgesetzt, wir können sie in eine perfekte ablenkungsfreie Umgebung einschließen, kann jede Aufgabe in einer bestimmten Zeit von einem einzigen Geist gelöst werden. Das Ganze wird so lange dauern, wie es dauert, um die längste einzelne Aufgabe zu erledigen.

Lassen Sie uns nun das gleiche mentale Experiment wiederholen. Diesmal werden wir ohne (wichtigen) Grund ständig die Aufgabenzuweisungen zwischen den Entwicklern wechseln. Jeden Tag erhält jeder Entwickler eine neue Aufgabe, an der er arbeiten kann. Noch besser, schalten wir es jede Stunde hoch. Wie schnell werden sie fertig sein, denken Sie? Vielleicht nie.

Der Projektmanager im ersten Szenario konnte das Projekt effektiv durchführen. Die zweite hat es geschafft, es zu „exekutieren“, das ist sicher … in dem Sinne, dass sie seinen Tod erleichtert haben. Glückwünsche. Diese Technik der Projektvernichtung ist besonders effektiv, weil sie neben der reinen Zeitverschwendung auch die Arbeitsmoral der Mitarbeiter auf Null sinken lässt.

Die meisten Menschen würden dem obigen Beispiel zustimmen, wenn es ihnen auf rein akademische Weise präsentiert wird. Im wirklichen Leben jedoch vergessen sie beim geringsten Druck plötzlich alles. Der große Boss verlangt einen Fortschrittsbericht oder der Kunde fragt nach einem bestimmten Implementierungsdatum einer Funktion – fast jedes externe Ereignis kann dazu führen, dass ein Projektmanager zum Team eilt und seine Bedenken äußert, gefolgt von einer Flut von Aufgabenneuzuweisungen und Prioritätenjonglieren in einem versuchen, hier und da ein bisschen Zeit zu gewinnen, was letztendlich nur dazu führt, dass das Projekt noch mehr aus der Bahn geworfen wird.

Das ist ein Szenario aus dem wirklichen Leben, das leider ziemlich oft vorkommt.

Ein guter Manager steht auf und schützt das Team vor solchen kleinen Störungen, indem er die emotionale Schockwelle absorbiert und in produktive Diskussionsthemen für die Zukunft umwandelt. Das ist emotional sicher hart, aber nur so kann man die Mannschaft im guten Arbeitsrhythmus halten und liefern lassen.

Regel Nr. 6: Verwenden Sie Architekturüberprüfungen zur Verbesserung des Systemdesigns

Die IT-Branche arbeitet mit Vorstellungen von Over- und Under -Engineering. Wenn es in einem Interview zur Sprache kommt, sagen alle, dass Overengineering schlecht ist. Das ist leicht zu beantworten, weil die Frage selbst eine negative Konnotation von „über“ vermittelt, was „zu viel“ bedeutet. Das wirkliche praktische Know-how besteht darin, zu erkennen, wann Ihre Architektur übertechnisiert ist, und dies frühzeitig zu vermeiden.

Lassen Sie mich Ihnen einige meiner bewährten Hinweise dazu geben.

Zunächst einmal kann die Lösung als überentwickelt angesehen werden, wenn es eine andere einfachere Lösung gibt, die alle erforderlichen Funktionen bereitstellt. Das heißt, wenn Sie keine einfachere Lösung kennen, dann ist die einfachste Lösung, die Sie anbieten können, in Ihren Augen die beste, es sei denn, jemand beweist Ihnen das Gegenteil.

Wenn unser imaginärer Architekt wirklich nach Perfektion der Lösung strebt, garantiert die übliche Architekturprüfung, dass sie optimal genug ist. Leider erfordert die Architekturprüfung mindestens ein paar andere qualifizierte Architekten. Es besteht die Gefahr, dass es in vielen Fällen nicht verfügbar oder unpraktisch ist. Ohne Peer Review neigen Architekten zu häufigen Fehlern. Lassen Sie uns sie einzeln durchgehen und mögliche Abhilfemaßnahmen für jede besprechen.

Einer der häufigsten Fehler ist das Entwerfen ohne ein Geschäftsziel im Hinterkopf. Es liegt auf der Hand, dass jede Arbeitstätigkeit an die Zufriedenheit des Endverbrauchers oder den Unternehmenserfolg oder ein ähnliches Geschäftsbedürfnis gebunden sein sollte. Doch oft sieht man Architektur, die ganz oder teilweise ohne einen solchen Zweck entworfen wurde. Die Argumentation fehlt entweder oder läuft darauf hinaus, so viele moderne Schnickschnack wie möglich zu verwenden.

Der Architekt tut in diesem Fall nicht das, wofür der Verbraucher bezahlt hat. Vielmehr spielen sie zu ihrem eigenen Spaß und Vergnügen mit coolen Spielzeugen. Dies ist in der formellen Industrie in keiner Weise akzeptabel. Und doch scheint es sowieso ziemlich oft vorzukommen.

Manchmal liegt das Problem in der Persönlichkeit des Architekten und seiner Besessenheit von bestimmten Technologien oder Werkzeugen. Sie verwenden sie einfach gerne und können nicht zusammenhängend erklären, welche geschäftlichen Anforderungen sie zu lösen versuchen. Ähnlich ist es in einem anderen Fall, in dem die Leute nichts anderes wissen, als etwas aus kleinen Stücken zu bauen. Sicherlich löst jedes externe Ereignis ihren Drang aus, in die Designwelt einzutauchen und nie wieder zu einem echten Kunden zurückzukehren. Auch wenn der anfängliche Auslöser ein gültiger geschäftlicher Input sein kann, verringert ihre anhaltende Loslösung von der Realität die Nützlichkeit ihrer Kunstwerke.

Die Heilung dafür ist sehr einfach, erfordert aber Selbstdisziplin. Ein guter Architekt sollte nie Stift und Papier anfassen, bis er für sich selbst klar und ehrlich beantworten kann, warum es nötig ist. Ein solches Bedürfnis kann in unterschiedlichen Formen auftreten. Dies kann eine formale Anforderung, ein implizites Bedürfnis nach Produktverbesserung oder das Aufkommen neuer Technologien sein, die das vorherige Design weniger effektiv machen. Auf jeden Fall sollte es kein formaler Auslöser sein, solange die Architekten selbst die treibende Kraft verstehen. Dann können sie diese Kraft als ultimativen Nachweis ihrer Designqualität verwenden.

Ein weiteres schwerer erkennbares Problem hängt mit dem Denken in Blockarchitekturen zusammen. Menschen mit einer solchen Mentalität glauben, dass es für alles eine Lösung gibt und diese immer als Baustein umgesetzt wird. Mit anderen Worten, sie übersetzen Funktionalität direkt in Komponenten, ohne die Architektur als Ganzes zu bewerten. Sie können einfach eine Komponente hinzufügen, die die gewünschte Funktionalität an das System liefert, wenn ein Bedarf für eine solche Funktionalität entsteht. Meist genügt dies den formalen Anforderungen, lässt das System aber in einem inkohärenten Zustand zurück. Der neue Block wurde nicht auf der Grundlage bestehender Systemkompatibilität für Entwicklung, Support oder sogar das Lizenzmodell des Unternehmens ausgewählt. Daher versucht das Team, die vorhandene Konfiguration zu ändern oder diese Funktionalität über die vorhandene Systemkapazität zu implementieren. Infolgedessen verwandeln sich die Systemunterstützung und -wartung allmählich in einen verschlungenen Albtraum, gefolgt von Leistungseinbußen.

Für dieses Problem gibt es keine einfache Lösung, da das Engineering des Systems eine Kunst ist und es nie vorhersehbar ist, ob eine neue Komponente hinzugefügt werden muss oder vermieden werden kann. Die beste Vorgehensweise wäre wahrscheinlich, einen Rückstand von Wartungs- und Architekturproblemen zu halten, die sich im Laufe der Zeit ansammeln, gefolgt von regelmäßigen Überprüfungen der gesamten Systemarchitektur. Diese regelmäßige Überprüfung kann auch neue Technologien in Betracht ziehen. Der allgemeine Zweck von Architekturüberprüfungen sollte also nicht darin bestehen, Probleme zu beheben, sondern die potenzielle Realisierbarkeit gewünschter Verbesserungen und des Systems als Ganzes gegen die drohende Unvermeidlichkeit der Veraltung zu bewerten.

Regel Nr. 7: Werte Teamplayer

Die meisten Fachleute der IT-Branche wurden in einem Interview gefragt, ob sie gute Teamplayer sind oder ob sie gut im Team arbeiten. Dennoch hat wahrscheinlich niemand jemals eine klare Definition dafür in der Literatur gesehen. Offensichtlich würde eine solche Person zum Teamerfolg im Allgemeinen beitragen, aber nur wenige Menschen können tatsächlich charakteristische persönliche Eigenschaften definieren, die einen solchen Erfolg sicherstellen.

Ich habe viele Menschen auf verschiedenen Ebenen beobachtet und gesehen, wie ihre persönlichen Qualitäten den Projektfortschritt beeinflusst haben. Ich möchte die folgenden Hinweise auf persönliche Eigenschaften geben, die bei der Teamarbeit am hilfreichsten sind.

Kommunizieren

Die erste und wichtigste Eigenschaft ist natürlich die Fähigkeit zu kommunizieren.

Stellen Sie sich eine Person ohne Kommunikationsfähigkeiten vor. Wenn Sie kein Feedback von Teammitgliedern erhalten, sind diese sicherlich völlig nutzlos. Dies ist so offensichtlich, dass niemand diese Fähigkeit während des Interviews tatsächlich misst, was impliziert, dass die Fähigkeit auf einem ausreichend guten Niveau ist, solange die Person gut sprechen kann.

Kommunikation ist keine binäre Ja/Nein-Fähigkeit; es ist eher ein Informationsübertragungsfenster. Je breiter es ist, desto schneller und klarer ist der Informationsaustausch.

Da der Bereich der Öffnung dieses Fensters in der Bevölkerung stark variiert, ist das Maß für die Breite eines solchen Fensters ein wichtiges Merkmal eines Teamplayers. Denken Sie daran, dass wir in diesem Zusammenhang über die Übermittlung von Informationen sprechen, aber nicht über das reibungslose Reden oder das Ermutigen oder Motivieren oder Organisieren von Menschen durch Reden und Kommunikation.

Auch der Kommunikationsstil spielt keine Rolle. Informationen können mündlich, textlich, in Bildern oder auf gemischte Weise übermittelt werden. Die Person kann schnell oder langsam sprechen. Sie können freundlich sein, als würden sie dir in die Augen schauen und die ganze Zeit lächeln, oder sie können wegsehen und mit monotoner Stimme sprechen. Der Stil kann Ihre persönliche Wahrnehmung Ihres Kollegen beeinflussen, aber solange Sie klar verstehen, was sie bedeuten, ist jeder Stil ausreichend.

Kommen wir zu praktischen Fällen zum Erkennen und Messen von Kommunikationsfähigkeiten.

Es gibt zwei Hauptaspekte der Kommunikationsfähigkeiten im Allgemeinen. An erster Stelle steht die Bereitschaft, Informationen zu teilen. Einige Leute sind bestrebt, Informationen zu teilen, andere versuchen, Informationen zu verbergen. Diese Neigung ist mehr oder weniger natürlich, kann aber durch Eigenmotivation und Training langsam geändert werden. Es ist davon auszugehen, dass die Person, die eine Art von Informationsbereitschaft zeigt, diese auch in Zukunft zeigen wird. Aus diesem Grund ist diese Eigenschaft gut geeignet, um den zukünftigen Erfolg eines Kandidaten in einem Team vorherzusagen.

Im wirklichen Leben fallen Menschen, die versuchen, Informationen zu verbergen, leicht auf. Sie versuchen normalerweise, absichtlich nutzlose Informationen preiszugeben, anstatt etwas, das tatsächlich benötigt wird. Oder sie stellen vorläufige Fragen, um den Informationsfluss nach innen zu lenken und ihre Antworten auf ein „Need-to-know“-Ereignis zu reduzieren. Was auch immer ihre Taktik ist, Sie werden am Ende das Gefühl haben, dass Sie nicht die gewünschten Informationen von ihnen erhalten haben oder dass es zu viel zusätzlichen Aufwand erforderte, die Informationen zu erhalten.

Es ist wichtig, die Absicht zu verstehen, da einige Arten von offenen Personen Ihnen möglicherweise vorläufige Fragen stellen, um Ihre Frage besser zu verstehen, und dann die Antwort auf die für Sie bequemste Weise liefern. Die Person, die beabsichtigt, die Informationen zu verbergen, wird zusätzliche Fragen stellen, nur um die Konversation abzulenken, und stattdessen niemals Ihre ursprüngliche Frage beantworten.

Ein weiterer Teil der Kommunikationsfähigkeit ist die Fähigkeit, sich auf den Zuhörer einzustellen.

Unterschiedliche Menschen haben ein unterschiedliches Themenverständnis, einen unterschiedlichen Kommunikationsstil und vielleicht sogar ein unterschiedliches Interesse an bestimmten Details. Einige kommunikative intelligente Menschen würden ihren Gesprächsfluss je nach Fähigkeit des Zuhörers, ihn zu verstehen, variieren und ihre Antwort vorbereiten, um bestimmte Informationen zu liefern. Bei einer solchen Vorbereitung können einige vorbereitende Fragen gestellt werden, um das Interesse des Zuhörers einzugrenzen. Die Fähigkeit, die Kommunikationsunterschiede „herauszuarbeiten“, ist eine wirklich große Fähigkeit, da wir damit in fast allen Fällen Verständnis erreichen können. Flexible Redner hingegen können manchmal einfach in unlösbaren Sackgassen von Missverständnissen stecken.

Stärken und Schwächen verstehen

Konzentrieren wir uns auf eine andere persönliche Eigenschaft, die für einen Teamplayer unerlässlich ist.

Die meisten Menschen würden zustimmen, dass eine Teamumgebung freundlicher sein sollte als die durchschnittliche Umgebung, um die Zusammenarbeit zu fördern und die Produktivität zu steigern. Daher ist es für ein Team wichtig, die Stärken und Schwächen jedes Mitglieds zu verstehen, um Aufgaben richtig zu verteilen und Schwächen mit Stärken zu überdecken. Der erste Schritt auf diesem Weg ist, dass alle Mitglieder ihre Fähigkeiten ehrlich miteinander messen. Psychologisch kann dies schwierig sein, da wir von Natur aus dazu neigen, unsere Schwachstellen vor anderen zu verbergen und uns selbst zu schützen.

Hier hilft die freundschaftliche Teamatmosphäre.

Es wird also erwartet, dass das neue Mitglied nach Teamregeln spielt. Leider können manche Menschen auch in einer freundlichen Umgebung nicht auf der Hut sein. Sie verhalten sich ihr ganzes Leben lang wie einsame Wölfe. Das ist stärker als sie. Leider trägt eine solche Einstellung nicht zur Teamleistung bei.

Es gibt eine einfache Technik, um solche Einzelgänger im Vorstellungsgespräch zu erkennen. Sie geben nie zu, dass sie etwas nicht wissen. Natürlich zeigen Menschen gerne ihr Bestes, zeigen all ihre Fähigkeiten und versuchen, jedes einzelne schwierige Problem zu lösen. Dennoch gibt es eine Wissensgrenze für alle. Unsere Grenzen prägen unsere Fähigkeiten. Grenzen nicht zuzulassen bedeutet, dass sich die Kandidaten als Tausendsassa präsentieren, die alles und nichts gleich gut können.

Wenn Sie einen Spezialisten einstellen, möchten Sie solche Leute wahrscheinlich vermeiden. Außerdem geht diese arrogante Haltung oft mit einem weiteren Warnzeichen einher: der mangelnden Bereitschaft, um Hilfe zu bitten. Die Fähigkeit, um Hilfe zu bitten, ist für die Teamarbeit absolut unerlässlich. Ohne sie können wir nicht so schnell vorankommen und uns entwickeln. Solch eine sture Person würde Ressourcen und Zeit des Unternehmens verbrennen, schwierige Aufgaben auf unbestimmte Zeit bekämpfen, aber niemals Teamkollegen um Hilfe bitten. Es gibt einen einfachen Trick, um solche Kandidaten im Vorstellungsgespräch zu erkennen. Stellen Sie ihnen eine Frage, die keinen Sinn ergibt, oder erwähnen Sie einen unsinnigen Begriff. Eine normale, idealerweise neugierige Person würde einfach sagen, dass sie es nicht weiß, und fragen, was es ist. Eine defensive Person würde das niemals tun, selbst wenn Sie betonen, dass es keine richtigen oder falschen Antworten gibt und dass „Ich weiß nicht“ sie nicht disqualifiziert.

Regel Nr. 8: Fokus auf Teamwork-Organisation

Es gibt so wenig Informationen über die Organisation von Teamarbeit wie zu jedem der vorangegangenen Themen oben. Jeder weiß, dass Teamarbeit besser ist, aber wie man ein Team aufbaut und pflegt, bleibt ein Rätsel. Auch wenn es unmöglich ist, alle Aspekte des Teambuildings abzudecken, können wir hier zumindest einige wichtige Teambuilding-Techniken untersuchen.

Gebäudekompetenz

Jedes IT-Projekt ist einzigartig. Um darin erfolgreich zu sein, muss man Projektspezifika lernen und beherrschen. Sie können sowohl technisches als auch nicht-technisches Wissen umfassen. Ein Beispiel für nicht-technisches Wissen könnte ein persönliches Netzwerk für Management, Kunden, technische Support-Teams usw. sein. Spezielles technisches Wissen sind zusätzliche Details zu allgemeinen IT-Kenntnissen.

Beispielsweise müssen Sie möglicherweise Maven kennen, um ein Projekt zu erstellen. Die genaue Build-Struktur, der Standort der Eigenschaften und die Filterung variieren jedoch weiterhin je nach Projekt. Wie bei jeder Art von Wissen braucht es Zeit, solche Details zu beherrschen; Je mehr Zeit man darin investiert, desto besser können sie performen. Zeit ist die wertvollste Ressource, die Sie haben. Sie möchten Ihr Teammitglied so lange wie möglich auf denselben Funktionsbereich konzentrieren, um sein Fachwissen zu nutzen und weiterzuentwickeln und so die Teamleistung ständig zu verbessern.

Leider ist es nicht möglich, dies auf unbestimmte Zeit zu tun. Auf der einen Seite langweilen sich die Leute vielleicht einfach. Auf der anderen Seite laufen Sie Gefahr, ihr Fachwissen zu verlieren, wodurch Ihr Projekt unerwartet gefährdet wird.

Mal sehen, ob es Möglichkeiten gibt, mit den Nachteilen fertig zu werden, ohne die Teamleistung stark zu beeinträchtigen.

Verteilen Sie die Schwerpunkte auf die Teammitglieder und lassen Sie sie ihr Fachwissen darin aufbauen. Irgendwann erreichen sie ein Niveau, das hoch genug ist, um im Rahmen dieses Projekts Sinn zu machen. Zusätzliche Lernanstrengungen werden es an dieser Stelle nicht wesentlich verbessern. Ohne Motivation und Herausforderung langweilen sich kluge Menschen und fangen an, ihren Job zu hassen.

Verhindern Sie dies, indem Sie ihnen Lernmöglichkeiten an anderer Stelle eröffnen. Halten Sie sie über Projekte und den technologischen Stack des Unternehmens auf dem Laufenden und eröffnen Sie neue Herausforderungen. Wenn ihr Interesse im Rahmen des Projekts liegt, erhalten Sie die doppelte Belohnung, indem Sie Ihr Team herausfordern und gleichzeitig nützliche Teamfähigkeiten erweitern. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!