In letzter Zeit sehe ich viele Beispiele dafür, wie technische Projektmanager (auch bekannt als CTO) bei der Entwicklung und Verwaltung von Projekten den Kanonen des Frachtkultes folgen, anstatt Einheiten nach Bedarf einzuführen und den Prozess auf der Grundlage der aktuellen Bedürfnisse, verfügbaren Ressourcen und Fähigkeiten aufzubauen Darsteller. Wir werden darüber sprechen, wie man einen solchen Frachtkultisten identifiziert und welche Risiken er für das Projekt trägt.
Tägliche morgendliche Diskussionen (auch bekannt als Daily Standup)
Auf meine natürliche Frage an einen solchen CTO - wie greifbar ist der Nutzen dieses Ereignisses - antwortete der CTO ehrlich: "Ich weiß es auch nicht." Trotz einiger Vorteile für das Team, von denen ein Teil aus der Ferne funktionierte, gingen die Diskussionen sicherlich auf "Gestern habe ich Code geschrieben, heute schreibe ich Code und morgen habe ich vor, auch Code zu schreiben, aber nun, ich korrigiere solche und solche Fehler". Infolgedessen haben wir von jedem Teammitglied minus eine halbe Stunde Zeit. Ein Plus für Remote-Mitarbeiter ist die tägliche Kommunikation mit dem Team, für andere ist es wichtig. Meiner Meinung nach ist der Nutzen solcher täglichen Diskussionen für die Entwicklung eher gering, da die Hauptaufgabe solcher allgemeinen Zusammenkünfte darin besteht, allen Informationen über den aktuellen Entwicklungsstatus und Pläne für die nahe Zukunft (von einer Woche bis zu einem Monat) zur Verfügung zu stellen, um einige interessante Themen zu erörtern alle. Sehr oft schlüpfen solche Diskussionen in Diskussionen über einige Nischenprobleme, die für ein paar Leute interessant sind, und der Rest wird langsam langweilig und erwartet, wann es enden wird. Dies sollte sicherlich unterdrückt und später in einem engeren Format diskutiert werden. Der aktuelle Entwicklungsstand und die Pläne sind sehr wichtig, aber es reicht aus, sie einmal pro Woche oder sogar weniger zu besprechen, je nachdem, mit welcher Geschwindigkeit das Team arbeitet.
Cloud-Bereitstellung
Derzeit sind viele Tools verfügbar, mit denen Sie die Projektinfrastruktur (Dienste, Netzwerke, Abhängigkeiten) in einer praktischen Form beschreiben können, z. B. Terraform. Diese Sache ist sicherlich nützlich, aber bei einer bestimmten Projektgröße zum Beispiel, wenn es ziemlich kompliziert wird. Für die meisten Startups und kleinen Projekte ist dies ein redundantes Tool, da sich die Infrastruktur äußerst selten ändert und die Fähigkeit zur schnellen Bereitstellung einer anderen Produktion benötigt wird. Grob gesagt, einmal im Jahr überleben viele Startups möglicherweise einfach nicht. Je einfacher das Projekt beschrieben wird, desto besser ist Docker Compose für viele.
Codeabdeckung mit Unit-Tests
Übermäßige Begeisterung für Tests führt dazu, dass dafür wertvolle Entwicklungsressourcen aufgewendet werden, die Kosten für das Refactoring erheblich steigen (schließlich müssen alle betroffenen Tests neu geschrieben werden) und häufig die Illusion von zuverlässigem Code und dessen korrektem Betrieb entstehen. Ich habe ein Startup getroffen, bei dem nach einem Jahr der Entwicklung mehr als 2000 Tests nur für das Backend geschrieben wurden! Um die Entwicklung effektiv voranzutreiben, müssen Tests nur wirklich wichtige Abschnitte des Codes abdecken, in denen einige Berechnungen durchgeführt werden und die manuelle Fehlerdiagnose schwierig ist. Bei Startups kann die Testabdeckung häufig verzögert werden, bis die Codestruktur stabil ist und die Geschäftslogik klar wird und sich wahrscheinlich nicht wesentlich ändert. Für Frontend-Unit-Tests sind sie häufig ineffektiv, da normalerweise nicht genügend komplexe Berechnungen und Algorithmen vorhanden sind. Es ist besser, die grundlegenden SPA-Funktionen wie das Drücken von Tasten während der BlackBox-Testphase über Selen oder dergleichen abzudecken.
Entwicklungsprozessmanagement
Der CTO Cargo-Kultist verwendet immer die Werkzeuge und Technologien, die früher für ihn gearbeitet haben. Er hat früher über einige coole Dinge gelesen oder ihm wurde davon erzählt. Die Anwendbarkeit all dessen unter den gegenwärtigen Bedingungen ist für ihn schwer einzuschätzen, daher folgt er eindeutig den Kanonen des Frachtkults - „Immerhin ist ein Flugzeug vorher geflogen, also mache ich es richtig. CTO davon zu überzeugen, dass es besser ist, andere Tools und Technologien für das aktuelle Projekt zu verwenden, wird zu einer mühsamen und nicht trivialen Aufgabe, da CTO nicht daran gewöhnt ist, die Konsequenzen zu analysieren.
Teammanagement
Es gibt einen Weg für den Frachtkultisten, und er folgt ihm. Die Tatsache, dass das Management des Teams auf der Grundlage des aktuellen Standes des Projekts, seiner Anforderungen, Qualifikationen und Einschränkungen des Auftragnehmers aufgebaut werden muss, ist für ihn neu und er misst dem keine Bedeutung bei, da er einem hohen Risiko ausgesetzt ist, dass er nicht in der Lage ist, damit umzugehen. Es fällt ihm nicht leicht zuzugeben, dass es eine unterschiedliche Einstellung gegenüber Senior- und Middle-Entwicklern geben sollte, dass es Entwickler gibt, die sich auf Kommunikation, Geschäftsansatz und Verantwortung spezialisiert haben. Für ihn sind alle Figuren auf dem Schachbrett ungefähr gleich, er macht die Bewegungen ungefähr gleich. Er hat höchstwahrscheinlich nicht davon gehört, dass es notwendig ist, die Stärken jedes Entwicklers zu identifizieren und zu nutzen. Aus diesem Grund wird die Arbeitseffizienz des Teams erheblich reduziert, die Entwickler bemerken dies sehr gut und dies macht sie weniger zufrieden mit der Arbeit, normalerweise ist sie durch einen anständigen Umsatz gekennzeichnet. Oft sagen solche CTOs gerne, dass sie alle Fullstack-Entwickler haben, obwohl ich persönlich selten gleich starke Frontend- und Backend-Entwickler gesehen habe, müssen zu viele Technologien auf einem guten Niveau bekannt sein.
Wie man kein Frachtkultist wird / nicht wird
- Gehen Sie bei der Einführung neuer Einheiten (Dienste, Technologien) immer kritisch vor. Wenn es in Ihrem Team Leute gibt, die MySQL gut kennen, aber nicht mit Postgres gearbeitet haben, macht es keinen Sinn, sich für Postgres zu entscheiden, wenn dies Ihnen keine wesentlichen Vorteile bringt.
- Der Entwicklungsprozess muss an das Team und das Geschäft angepasst werden. Wenn Vasya an Scrum arbeitet und alles mit Unit-Tests abdeckt, bedeutet dies nicht, dass dieser Ansatz auch für Sie funktioniert. Sie sollten ihn immer kritisch bewerten und mit anderen Optionen vergleichen (Wasserfall). Was für ein kleines Team funktioniert, funktioniert in der Regel nicht mehr für ein großes Team und umgekehrt.
- Identifizieren Sie die Stärken der Teammitglieder und nutzen Sie sie maximal. Dies erhöht die Effizienz des gesamten Teams und die Mitarbeiter sind zufriedener, da sie mehr Vorteile bei geringerem Aufwand bieten.