Bitte beachten Sie, dass der Titel kein Fragezeichen enthält. Ich möchte nicht darüber streiten, ob Projektmanager in der modernen Softwareentwicklung benötigt werden oder nicht. Die Praxis zeigt, dass nein. Ich versuche nur herauszufinden, warum es passiert ist.
Nachdem ich mehr als 20 Jahre in der IT-Branche gearbeitet hatte, begann ich, jede neue Entwicklung vom Projektbüro aus aufzubauen. Außerdem musste ich dem Management mehrmals erklären, warum man Piems anstellt. Angesichts der Anwesenheit von Abteilungsleitern ist es nicht so einfach, Personen, die nicht direkt an der Entwicklung von Software beteiligt sind, zu erklären, was genau Projektmanager tun werden. Ich musste spürbaren Widerstand überwinden.
Für mich war es jedoch ein Grundsatz, dass das Projektbüro und die Projektmanager die Grundlage für den Erfolg sind. Und sagen Sie mir vor ungefähr fünf Jahren, dass Projektmanager nicht benötigt werden, ich würde bis zum Ende mit ihm streiten.
Anmerkung des Herausgebers: Dieser Text ist das Ergebnis eines Berichts von Dmitry Kruglov von der Ankunft bei der Piemnaya-Kundgebung.
Oder brauchst du noch
Beginnen wir mit dem Versuch, diesen Beruf zu schützen. Schon allein deshalb, weil die Ergebnisse an den letzten Arbeitsplätzen erzielt wurden, auch dank erfolgreich errichteter Projektbüros.
Projektmanagement ist nicht das Vorrecht der IT. Dies ist eine Wissenschaft, die mehr als 50 Jahre alt ist. Eine Wissenschaft, die ihr eigenes heiliges Buch hat . Natürlich ist PMBoK kein Unikat, es gibt PRINCE und wahrscheinlich mehrere weitere Bücher, die mehr oder weniger Lorbeeren beanspruchen. PMBK ist jedoch die Grundlage internationaler Standards, was auf seine hohe Anerkennung hinweist. Also werden wir darauf aufbauen.
Lassen Sie uns das Spiel spielen: Wenn Sie als Projektmanager arbeiten, versuchen Sie, ohne nach vorne zu schauen, Ihre Haupttätigkeitsbereiche aus der Sicht eines internationalen Standards und eines Instituts, das älter als 50 Jahre ist, in Erinnerung zu rufen.
Verwalten Sie beispielsweise die Projektanforderungen. Oder Erwartungen verwalten. Vielleicht erinnern Sie sich an Zeitmanagement. Sicherlich fragen Kollegen, die das Unternehmen vertreten, regelmäßig, wann genau diese oder jene Aufgabe fertig sein wird. Vielleicht erinnern Sie sich an das Management von Stakeholdern, das viel seltener vorkommt. Was noch? Kommunikationsmanagement. Letzteres ist so selten wie Stakeholder. Dies ist jedoch eine wichtige und schwierige Aufgabe in unserer Zeit, in der alle Projektteilnehmer lieber wichtige Informationen über Telegramm austauschen als die im Entwurf der Charta geforderten E-Mails. Wie können Sie die Kommunikation verwalten, wenn Sie einfach nicht zu einem Chat eingeladen werden, in dem beispielsweise die Qualität Ihrer Arbeit besprochen wird?
Vergleichen Sie das, was Sie zurückgerufen haben, mit der Liste von PMBoK:
Alle Artikel sind sehr gesund. Es scheint, dass diese Aktivität wirklich von jedem Projektmanager durchgeführt werden muss. Einige davon sind möglicherweise weniger offensichtlich, z. B. die Projektintegration. Wenn Sie jedoch die Leistung mehrerer Teams genutzt haben, um ein wirklich großes Feature zu erstellen, das Sie vor dem Start zusammenstellen müssen, dann verstehen Sie, worum es in diesem Punkt geht. Die Aufgabe, eine Funktionalität in mehreren Teams parallel zu entwickeln, ist übrigens noch nicht systematisch gelöst.
Gantt-Diagramm
Wenn es eine Aktivität gibt, muss es ihr Ergebnis geben. Meine persönliche Meinung ist, dass die Arbeit mit dem entsprechenden Artefakt durchgeführt wurde. Für einen Programmierer ist dies Arbeitscode. Für einen Testspezialisten wurden Testskripte entwickelt oder ausgeführt, Fehler im System eingeführt oder Autotests erstellt. Für den Designer - grafische Layouts.
Was ist ein Projektmanager-Artefakt? Von allen möglichen Artefakten, einschließlich der Nachrichten im Telegramm: "Füge mich schließlich zu deinem Chat hinzu, kann ich das Projekt ohne es nicht verwalten!", Würde ich zuerst das Gantt-Diagramm notieren. Dies ist ein großartiges Tool, das viele Fragen zum Projekt beantworten und dabei helfen kann, die meisten Tätigkeitsbereiche des Projektmanagers zu visualisieren. Schließlich enthält ein gutes Gantt-Diagramm Timing, Ressourcen, Kosten und Abhängigkeiten. Dort können Sie Kommunikationsanforderungen als Aufgaben hinzufügen. Mit Meilensteinen und einer Beschreibung des erwarteten Ergebnisses können Sie den Stakeholdern und ihren Erwartungen sogar die Kontrolle hinzufügen. Es stellt sich als universelles Werkzeug für alle Gelegenheiten heraus.
Die meisten Aufgaben in diesen Bereichen werden durch die Verwaltung einer Entität gelöst - des Gantt-Diagramms.
Die Popularität und Vielseitigkeit wird durch die Anzahl der Tools und Services bestätigt, mit denen Sie Ihre Diagramme erstellen können. Versuchen Sie, nach "Gantt online" zu suchen und sehen Sie, wie lang die Liste der Links für jeden Geschmack und jede Farbe ist, die Sie erhalten.
Was sich herausstellt: Wir haben einen Beruf, eine Tätigkeit und ein gutes Artefakt. Also, was ist der Haken?
Es geht nur um die Nuancen. Zum Beispiel ist bei Gantt nicht alles so gut.
Erstens werden die Diagramme großer Projekte früher oder später unlesbar. Ich hatte Erfahrung mit einem "über ein Jahr" -Projekt bei Microsoft Project. Um seinen Plan zu drucken, mussten sechs Blätter A4 geklebt werden. Auf einem Blatt war der Text zu klein.
Zweitens ist die Pflege von Diagrammen großer Projekte sehr arbeitsintensiv. Änderungen können häufig nur vom Autor selbst vorgenommen werden, andernfalls fällt der Plan aufgrund eines komplexen Abhängigkeitssystems auseinander.
Drittens muss zugegeben werden, dass niemand außer vielen Projektmanagern viele Diagramme liest. Es stellt sich heraus, dass dieses Artefakt vom Premierminister hergestellt wurde und er allein es braucht und versteht.
In der modernen Softwareentwicklung wurde Gantt größtenteils aufgegeben. Wir haben aufgehört, dieses Artefakt bei der Erstellung eines Produkts zu verwenden. Brauchen wir wirklich seinen Autor?
Wenn Sie versuchen, das Thema der Nützlichkeit von Projektmanagern in der IT zu googeln, wird deutlich, dass diese Diskussion schon lange andauert. Sie hat es geschafft, ein weiterer Holivar zu werden, wie die Konfrontation zwischen Liebhabern von iOS und Android, Windows oder OS X. Nur die Zitate in den Suchergebnissen sind noch emotionaler: „Brauchen wir PM?“, „Warum haben wir uns entschieden, PMs loszuwerden“, „Ist Ist die Arbeit von PM wertlos? “
Ich gehe nicht davon aus, dass das Gleichgewicht im globalen Streit für die Ablehnung von PM spricht, aber zumindest die Anzahl der Befürworter dieses Standpunkts ist bedeutend.
Agile Methoden
Als ich anfing, in einem Unternehmen zu arbeiten, in dem ich die Aufgabe habe, ein Entwicklungsteam von Grund auf neu aufzubauen, stellte ich fest, dass ich für die nächsten sechs Monate bis zu einem Jahr keine Aufgaben für PM habe. Zuerst habe ich es aus Gewohnheit zur Organisationsstruktur hinzugefügt. Und dann schlug er mit seiner eigenen Hand aus. Intuitiv durchgestrichen, aber gefragt: "Warum ist es passiert?".
Meine Untersuchung der Gründe führte zu dem Verständnis, dass die IT eine Reihe einzigartiger Eigenschaften aufweist, die die Implementierung flexibler Methoden ermöglichten. Es gibt einen klassischen Vergleich: Haus bauen und Software entwickeln. Dies sind etwas ähnliche Disziplinen, nicht ohne Grund gibt es in beiden eine Rolle des Architekten. Sowohl dort als auch dort gibt es eine Reihe von funktionalen und nicht funktionalen Anforderungen: Infrastruktur, interne Kommunikation, Montage, Lieferung und Integration.
Die Konstruktion wird jedoch in der realen Welt ausgeführt und hat einen sehr langen und teuren Produktionszyklus bis zum ersten Test, bevor das erste Feedback und das Ergebnis eingeht. Der Preis für einen Konstruktionsfehler ist sehr hoch.
Das IT-Produkt ist digital. Und der Produktionszyklus kann sehr kurz sein. Zwei Jahrzehnte lang konnten wir Werkzeuge und Technologien entwickeln, die zur Entwicklung flexibler Entwicklungsmethoden führten. Hier bin ich bereit zu argumentieren, dass ein Kausalzusammenhang genau dies ist: Die Fähigkeit, schnell zu experimentieren und ein Arbeitsergebnis zu erzielen, hat zur Entwicklung von Methoden geführt, wie dies zu tun ist. Dies ist natürlich ein kurzes positives Feedback, und die Tools wurden weiterentwickelt. Und dann wurde die Methodik wieder fertiggestellt. Und so weiter in einer Spirale eilen wir zu einer immer kürzeren Markteinführungszeit.
Rollen
Agile Methoden sind zum De-facto-Standard geworden und haben dem Softwareentwicklungsprozess neue Rollen verliehen. Und diese neuen Rollen begannen, Projektmanagern Aktivitäten und Artefakte zu nehmen.
Product Owner (PO)
Es gibt Projekte mit mehreren Kunden, mehreren Eigentümern und mehreren Entscheidungsträgern. PM für sie ist die Person, die einen Kompromiss sucht. Er bringt sie alle zusammen, hilft bei der Priorisierung, versöhnt sich. Er sagt zu jemandem: "Nein", jemandes Lobbyarbeit. Das Unternehmen versteht jedoch, dass bei einer kontinuierlichen Suche nach Kompromissen Ressourcen ineffizient verschwendet werden. Die wertvollste Ressource wird am meisten ausgegeben - Zeit.
Flexible Methoden tun genau das - sie sagen einer Person aus dem Unternehmen etwas im Geiste: „Sie sind extrem für Geld, Verkehr und Konversion. Und um ehrlich zu sein, ist es uns egal, was und mit welcher Priorität Sie im Produkt tun. Die Hauptsache ist, dass die Umwandlung bis Ende des Jahres von 1% auf 1,1% steigen wird, sonst wird das Projekt unrentabel. “ Und die PO hat das Recht, Entscheidungen individuell zu treffen, sie legt die Priorität fest, erstellt die entsprechenden Artefakte (Pläne, Roadmaps, Anforderungen) und nimmt dem PM ein Stück Arbeit ab.
Techlide (TL)
Vor etwa zehn Jahren begann die IT, die etablierte Architektur zu ändern.
Vor diesen Änderungen wurden Technologien und Tools hauptsächlich für die „Schichtarchitektur“ erstellt - die Datenbankschicht, die Geschäftsprozessschicht, die Aggregationsschicht, die Clientschicht. Sobald dieser Ansatz jedoch klassisch wurde und die Unternehmen die entsprechenden Abteilungsschichten erwarben, kamen flexible Methoden. Und alle entschieden einstimmig, dass „Puff Pies“ schlecht sind und es notwendig ist, funktionsübergreifende Teams zu bilden.
Nicht zu sagen, dass dies eine neue Idee war. Wie heißen Universalentwickler? Voller Stapel Einer der über 30-jährigen Entwickler sagte im Interview: "Ich war ein Full-Stack-Entwickler zu einer Zeit, als der Begriff Full-Stack nicht existierte." Früher waren wir alle voll, weil wir alles tun mussten, einschließlich der Datenbankverwaltung und der Einrichtung des Computers des Direktors.
Funktionsübergreifende Teams haben eine neue Rolle gebracht: Techlides. Tehlid drückte nicht nur die Abteilungsleiter, sondern übernahm auch den technischen Teil der Arbeit von PM. Zunächst alles, was mit der Beurteilung von Komplexität und Timing zu tun hat. Bis zum Übergang zu flexiblen Methoden haben sich viele damit abgefunden, dass das Entwicklungsteam die Bedingungen seiner Arbeit selbst bewerten muss.
System Analyst (SA)
Ein Systemanalytiker ist keine neue Rolle, und viele agile Methoden tun dies nicht. Ich nehme nicht an, sicher zu sagen, aber es ist möglich, dass es explizit in SAFE verfügbar ist. Aber SAFE ist im Allgemeinen eine Grenzmethode. Diese Rolle ist jedoch äußerst nützlich und interessant. Es ermöglicht wie ein Schmiermittel in einem komplexen Mechanismus ein leises und reibungsloses Arbeiten. Ein Systemanalytiker ist teilweise der Eigentümer des Produkts, teilweise der Architekt. Es klärt und detailliert die Geschäftsanforderungen auf der Ebene der spezifischen Funktionen. Die besten Systemanalysten können ihre Ideen und Visionen mithilfe einer Kombination aus technischer Kompetenz und Soft Skills in beide Richtungen vorantreiben. Wenn Systemanalysten arbeiten, werden dem Projektmanager die Aktivitäten zum Anforderungsmanagement vorenthalten.
Scrum Master (SM)
Scrum Master hat die Rolle des Projektmanagers stark eingeschränkt. Es ist schade, dass jetzt SMs selbst Kandidaten für das Aussterben geworden sind.
Im Ernst, früher oder später wird Scrum Master in Schulen unterrichten. Es wird Lektionen über Agile geben, in denen Scrum Master 12-jährigen Schülern erklärt, wie agile Methoden funktionieren und welche Praktiken es gibt. Agile Erfahrung ist mittlerweile zu einer allgegenwärtigen Entwicklungserfahrung geworden. In einem Interview arbeiten 19 von 20 Personen an zweiwöchigen Iterationen, und wenn über Prozesse gesprochen wird, werden ihre Parameter aufgelistet:
- Wie ist die Bewertung?
- Story Points.
- Was ist Geschwindigkeit?
- 68.
- Wie planen Sie Projekte?
- In "T-Shirt" Bewertungen von S, M, L.
Dies ist ein sehr schnelles Gespräch. Mit aktuellen Techlides können alle Prozessparameter in einer Stunde besprochen werden. Danach arbeiten sie mit dem Team zusammen und benötigen dafür keinen Scrum Master. Die Branche hat diese Rolle fast verdaut und geht weiter.
Dies ist natürlich nicht überall der Fall. Sicherlich gibt es viele Unternehmen, die Marktstandards erreichen müssen, und dies ist kein schneller Prozess. In Russland wird es nach 10 Jahren möglich sein, einen Job als Scrum Master in einer Art „Lenoblkhozpromlespoval“ zu finden, wenn die Organisation beschließt, ihre drei Programmierer auf Agile zu übertragen.
Während ihrer Popularität gelang es Scrum Master, alle Fragen des Projektteams von PM vollständig zu entfernen. Sie nahmen es nicht für sich selbst, sondern für die Teammitglieder und erleichterten ihre Beteiligung an der Entwurfsarbeit. Dies hat übrigens den IT-Reifegrad in den Augen des Unternehmens erheblich erhöht.
Oder immer noch nicht benötigt
Was bleibt übrig? Ich habe mir erlaubt, die Aufgaben hervorzuheben, die bei der Arbeit an flexiblen Methoden durch andere Rollen gelöst werden.
Was bleibt danach bei den Projektmanagern? Verbleibende Kommunikation, Integration und Beschaffung. Es scheint, dass es nicht viel gibt, um eine engagierte Person in dieser Rolle zu halten? Es ist Zeit zu sagen, dass PMs nicht benötigt werden. Aber nein.
Noch brauchen
Es gibt Kategorien von IT-Projekten, bei denen ein Ausfall ohne dedizierten Manager praktisch garantiert ist.
Projekte in der realen Welt
Diejenigen, die mit mobiler Entwicklung arbeiten, wissen, dass mit der Geschwindigkeit der Änderungen und den Kosten für Fehler die Dinge nicht so reibungslos laufen. Wenn Sie einen Fehler in der mobilen Entwicklung verpasst haben und ihn nicht sofort bemerkt haben, ist es schwierig, ein Update für das gesamte Publikum durchzuführen. Einige Benutzer aktualisieren ihre Anwendungen nicht und der Fehler bleibt bestehen. Aus diesem Problem sind beispielsweise Ansätze mit Fernsteuerung der Funktionalität mobiler Anwendungen gewachsen.
Dies ist jedoch der hundertste Teil des Schmerzes von PMs, die die Entwicklung von Software verwalten, um beispielsweise den Sortierförderer in einem Lager mit einer Größe von 5 Millionen Wareneinheiten zu verwalten. In solchen Projekten werden Dutzende von Abhängigkeiten von Ausrüstungslieferanten, Iterationen in Monaten gemessen und der Preis für Fehler steigt um eine Größenordnung.
Gerätebezogene Projekte bringen uns von den digitalen Welten zurück in unsere Realität, in der die klassische PMBoK-Steuerung noch relevant ist.
Dachprojekte
Bei Dachprojekten kamen flexible Methoden zum Stillstand. Solche Projekte sind groß und komplex. Komplexität bedeutet explizite und implizite Abhängigkeiten, und in einem bestimmten Umfang wird die Entwicklung ohne einen dedizierten Projektmanager äußerst ineffizient. In solchen Projekten sind die Hauptaufgaben von PM die Projektintegration, die Abhängigkeit und das Timing-Management.
Projekte mit hohen Fehlerkosten
Es wird immer Branchen geben, in denen Fehler maximal beseitigt werden müssen - Medizin, Luftfahrt, Raumfahrtindustrie und Militär. Wenn in diesen Bereichen ein Fehler auftritt, sterben entweder Menschen oder es geht viel Geld verloren. Beispiele sind im Internet leicht zu finden. Beginnen Sie mit einer Geschichte über die europäische Arian-5-Rakete.
In solchen Bereichen wird PM weiterhin gefragt sein, aber es werden sehr hohe Anforderungen an sie in Bezug auf Kompetenzen und Erfahrung gestellt. Und je geringer der Anteil solcher Projekte ist, desto strenger wird die Auswahl der Kandidaten sein.
Projekte ohne Rollenteil
Das Leben ist eine harte Sache, und es ist nicht immer möglich, für jede der Rollen eine engagierte Person zu nehmen. Bis die Welt perfekt ist, bleiben PMs übrig, die die Arbeit des Product Owner erledigen. Oder PMs, die de facto als Techlides arbeiten. Solche Kombinationen sind häufig charakteristisch für Startups.
Wenn wir die Trends, die derzeit in der Branche stattfinden, rechtzeitig verlängern, werden wir eine Zukunft haben, in der die Rolle von PM in seiner reinen Form für eine kleine Anzahl von Softwareentwicklungsprojekten relevant bleibt, deren Arbeit wir noch nicht automatisieren oder unter anderem verteilen können Teammitglieder.
Text erstellt von:
Autor - Dmitry Kruglov
Herausgeber - Eugene Shklyar, Denis Vonsarovsky
Die Meinung des Autors zu einigen Themen stimmt möglicherweise nicht mit der Meinung der Redaktion des Blogs und der Firma Yandex.Money überein.