In diesem Artikel möchte ich ein wenig über den Aufbau von Teams in IT-Projekten berichten. Ich möchte über eine nicht immer offensichtliche Sache wie die "Team Maturity Pyramid" sprechen.
Dieser Indikator ist kein strenger wissenschaftlicher Begriff und hat keine genauen Berechnungsformeln, aber sein Prinzip ist im Namen selbst gut formuliert.
Ein typisches Team in mittleren und großen Projekten besteht aus verschiedenen Teilnehmern: Projektmanager, Geschäftsanalysten, Entwickler, Tester und Operationsingenieure. In jeder Richtung gibt es normalerweise Leads - führende Mitarbeiter in der Richtung, zum Beispiel ein führender Entwicklungsingenieur, ein führender Testingenieur und so weiter.
Wenn wir die Struktur eines solchen Teams in Form einer Pyramide darstellen, die die Erfahrung der Mitarbeiter und ihren Einfluss auf die Entscheidungsfindung widerspiegelt, erhalten wir eine solche Pyramide:
Wir haben eine Art "Maslows Pyramide für das Team". Vergessen Sie aber nicht, dass IT-Projekte nicht nur Ingenieure haben. Zum Beispiel können Entwickler in Junior / Middle / Senior unterteilt werden, und je nach Berufserfahrung und Kenntnissen (oder der Vorstellungskraft des Arbeitgebers) weiß Gott Bescheid.
Es kommt vor, dass eine Person einen niedrigen Titel hat, aber aufgrund ihrer Erfahrung und ihres Wissens ist diese Person in der Lage, die Rolle des Lösungsarchitekten zu übernehmen (aber aufgrund der Umstände erfüllt sie diese Rolle nicht). Offensichtlich beeinflussen solche Personen die Entscheidungsfindung innerhalb des Teams, auch ohne formelle Positionen innerhalb des Projekts einzunehmen. Und solche Menschen müssen zum zweiten Schritt in unserer Pyramide erhoben werden. Es ist wichtig, dass es auf der zweiten Ebene nicht mehr Menschen gibt als auf der dritten.
Sie können jedem Teammitglied je nach Erfahrung und Einfluss auf die Entscheidungsfindung eine bestimmte Menge „Manna“ zuweisen. Zum Beispiel erhalten einfache Teammitglieder 1 Punkt, Leads und Manager 2 Punkte.
Stellen Sie sich vor, wir haben ein Team von 15 Leuten, dann wird eine typische Pyramide so betrachtet:
1 :
Project Manager + Technical Lead = 4 pts
2 :
2x Stream Leads + 2x Senior Engineer = 8 pts
3 :
9x Middle and Junuor Engineers = 9 ptsUnd wir bekommen so eine Pyramide:
Nun, Sie sagen, das ist genau der richtige Weg oder nicht bei unserem Projekt, und bei uns ist alles in Ordnung. Und was ist das praktische Ergebnis davon?
Wenn Sie ein Team mit dieser Methode bewerten, können Sie zwei Dinge verstehen: Wie überschaubar (stabil) ein vorhandenes Team ist und wie seltsam es ist, wie angenehm es für alle ist, in einem solchen Team zu arbeiten.
Noch wichtiger ist, was passiert, wenn die Pyramide der Reife des Teams auf den Kopf gestellt wird. Oder wenn es flach, quaderförmig oder etwas anderes wird. Und das ist ein sehr schlechtes Szenario.
Die richtige Pyramide ist sehr stabil, die umgekehrte jedoch nicht. Sie können sich an das heimtückische Experiment mit der Kolonie "White Swan" erinnern, in der einige kriminelle Behörden saßen und wie es für sie endete.
Und wenn Sie nicht von der IT-Branche abweichen, können Sie sich zwei reale Situationen vorstellen:
- Sie schlagen vor, einen effektiven Projektmanager billig und gut gelaunt zu machen - 30 "Inder" einzustellen und das Projekt in einem Monat anstatt in sechs Monaten einzureichen.
- Ein sehr wichtiger Kunde schneidet bei Interviews alle Ingenieure mit Ausnahme derjenigen mit Senior- oder Lead-Titeln ab.
Im ersten Fall erhalten wir einen „Ziegelstein“ anstelle einer Pyramide und ein eindeutig unkontrollierbares Projekt mit einem traurigen Ende.
Im zweiten Fall erhalten wir die gleiche Kolonie "White Swan" für das Projekt. Hier versammeln sich angesehene und erfahrene Menschen in einem Raum und in zwei Stunden kann keine einfache Lösung gefunden werden. Nur weil sie alle erfahren und cool sind, möchte jeder von ihnen das Wort ergreifen und glaubt, dass seine Idee gut ist. Der Sinn solcher Gespräche ist in der Regel sehr gering. Außerdem ist unklar, wer "die Seife anheben" soll, oh, wer soll dieses Feature sehen?
In meiner Karriere gab es Projekte mit so vielen Leuten in Teams, und ich sage ehrlich, dass die Arbeit in der ersten und zweiten Version nicht sehr angenehm ist. Sowohl der Manager als auch der normale Angestellte. Wenn ein Team zu viele kluge Leute hat, wird es dumm. Die Pyramide wird instabil und fällt oft sorglos zusammen.
In der Tat ist alles einfach, ein IT-Projekt sollte genügend Ingenieure haben, die die Arbeit erledigen, davon profitieren und keine Fragen stellen. Ohne eine ausreichende Anzahl solcher Leute hat das Projekt einfach nicht genug „Pferdestärken“ und es lohnt sich nicht für eine glückliche Zukunft.
Die umgekehrte Situation ist, wenn Sie zu viel "PS" und wenig Kontrolle haben, dann wird Ihr Rennwagen einfach auf den ersten Zaun prallen.
Die ideale Anzahl von Mitarbeitern in einem IT-Team beträgt 5 bis 15 Personen. Bezos von Amazon hat dies als Prinzip des "Two Pizza Teams" zusammengestellt. Eine weitere Erhöhung der Personenzahl erschwert die Kommunikation im Team und hat keinen Multiplikatoreffekt mehr.
Die ideale Verteilung der Teammitglieder nach Reifegrad beträgt pro Lead 2 bis 5 Ingenieure der mittleren Ebene. Wenn es sich um Junioringenieure handelt oder um
Vasiliev - dann sollte es nicht mehr als 1-2 pro Ableitung geben (oder die Person, die für sie verantwortlich ist). Nur weil er körperlich nicht in der Lage ist, auf mehr Menschen zu achten. Elementary Code Review für 5 Personen kann bereits die Hälfte der Arbeitszeit in Anspruch nehmen. Darüber hinaus haben die Leiter immer noch alle Arten von Besprechungen mit anderen Teams und dem Kunden, sodass er die Arbeit nicht zu 100% als regulärer Ingenieur erledigen kann.
Das heißt Wir können sagen, dass wir innerhalb der Team-Reifepyramide kleine Pyramiden aus separaten Subteams bauen müssen, um zusätzliche Stabilität zu erreichen.
Was die obere Ebene der Pyramide angeht - es ist nicht so wichtig, wie viele Personen Sie ganz oben haben, wenn Sie über ausreichend 2 untere Ebenen verfügen - sie werden das gesamte Projekt abschließen. Die Pyramide wird in den meisten Fällen nicht perfekt sein, aber es ist nicht beängstigend. Die Hauptsache ist, genug Leute von unten zu haben.
Berücksichtigen Sie nicht in der Pyramide der Vorgesetzten - d. H. Menschen, die eine ganze Richtung leiten und einfach den Prozess in mehreren Projekten steuern, ohne in das Management einzugreifen.
Der Product Owner von Agile ist Teil des Teams, sollte jedoch den Verwaltungsprozess nicht stören. Wenn er anfängt, sich mit Mikromanagement zu befassen, oder Sie sofort 5 Product Owners haben, dann haben Sie große Probleme. Dies sind jedoch bereits Fragen eines kompetenten Projektmanagements und der Kundenbeziehung. Wenn Sie in diese Falle tappen, ist die umgekehrte Pyramide bereits Ihr kleinstes Problem.
Ein anderer Punkt ist, wenn zu viele Leute das Projekt leiten wollen und Sie als einzige Person, die arbeitet, sich an die Arbeit von Saltykov-Shchedrin erinnern: "Wie ein Mann zwei Generäle ernährte." Oder diese
Geschichte . Aber eine solche Situation lässt sich anhand der "Team-Reife-Pyramide" leicht vorhersagen, und ein solches Projekt kann nicht durchgeführt werden.
In einem kompetenten Unternehmen sollten Dinge wie die Teamzusammensetzung bereits in der Verkaufsphase des Projekts geplant werden. Dann wählen sie einen Projektmanager aus, der das Rückgrat des Leitungsteams bildet und mit dessen Hilfe Pyramiden baut, Projekte sägt und Galaxien erobert.