Benutzerdefinierte Webentwicklung: Skalieren eines ständig wachsenden Projekts

In der Regel träumen alle Agenturen im Bereich der benutzerdefinierten Webentwicklung nur von Kunden, deren Projekte im Jahresumsatz doppelt wachsen, regelmäßig Fälle liefern, mit denen Sie angeben können, und für die Agentur Auszeichnungen für Profilbewertungen erhalten. Solche Kunden sind Branchenführer. Dies sind entweder Unternehmen, deren Geschäft im Internet aufgebaut ist, oder große Offline-Netzwerke, die dank beeindruckender Investitionen die führenden Positionen im Webkanal einnehmen.

Wenn Sie ein paar solcher Kunden haben, können Sie sich auf Ihren Lorbeeren ausruhen - hören Sie auf zu verkaufen und kontrollieren Sie einfach den ständig wachsenden Fluss von Aufgaben. In Wirklichkeit stellt das Projekt mit dem Wachstum des Unternehmens neue und neue Herausforderungen dar, um den Kunden zu bewältigen und zu retten. Gleichzeitig wird es eine sehr schwierige Aufgabe sein, kostengünstig zu arbeiten.

Projektwachstum und damit verbundene Herausforderungen

Es ist wichtig, rechtzeitig proaktive Maßnahmen zu ergreifen und die mit der Skalierung verbundenen zusätzlichen Kosten zu tragen. Dies kann sich zunächst nachteilig auf die Rentabilität auswirken, doch bei Erreichen bestimmter Volumina wird deutlich, dass die Erstinvestition gerechtfertigt war.

Hier sind die wichtigsten Herausforderungen, denen sich die Agentur bei einem solchen Projekt stellen kann:

• Das Problem der Skalierung ist die Umstrukturierung der Teamstruktur mit zunehmendem Volumen.
• Die Notwendigkeit, die Produkt- und Geschäftsaufgaben zu verstehen - ohne eine starke Produktanalyse ist es unmöglich, effektiv an einem großen Projekt zu arbeiten.
• Anspruchsvolle Software- und Serverarchitektur - Hand in Hand mit dem Wachstum des Produktionsvolumens im Rahmen des Projekts steigt auch der Datenverkehr, was zu einer komplexeren Architektur und der Notwendigkeit führt, Hochlastlösungen zu verwenden.
• Hohe Qualitätsanforderungen.
• Die Notwendigkeit, einen unterbrechungsfreien 24-Stunden-Betrieb und eine hohe Reaktionsgeschwindigkeit auf Vorfälle, auch außerhalb der Geschäftszeiten, sicherzustellen.
• Hohe Verantwortung für die Einstellung des Verkaufs.
• Überwachung und Kontrolle von Geschäftsindikatoren.

Nicht alle Agenturen auf dem Markt verfügen über die erforderlichen Kompetenzen, um all diese Herausforderungen zu bewältigen. Heute werden wir über das Problem der Skalierung des Teams sprechen - meiner Meinung nach der schwierigste Aspekt bei der Arbeit mit einem wachsenden Projekt.



Ich hatte die Gelegenheit, an mehreren Projekten mit explosivem Wachstum zu arbeiten, darunter dem größten Online-Shop für Kinderwaren und der führenden Versicherungsgesellschaft.
Ich habe an diesen Projekten zuerst als Manager und dann als Leiter eines Managementteams teilgenommen und möchte die gesammelten Erfahrungen teilen.

Rollen bei einem kleinen Projekt und warum Sie skalieren müssen

Das Rollenschema sieht im allgemeinen Fall folgendermaßen aus:



Bei AGIMA verwenden wir ein dreistufiges Management, bei dem alle taktischen Fragen im Rahmen der Interaktion innerhalb des Projektteams entschieden und strategische Fragen auf die Ebene des Account Directors und des Leiters der Kundendienstabteilung gebracht werden. Innerhalb des Projektteams wird eine Hierarchie aufgebaut, abhängig vom Umfang des Projekts. Ich werde im Folgenden darauf eingehen.

So sieht ein typisches Rollendiagramm in einem Projektteam eines kleinen Projekts aus:



Das Projekt hat zwei Schlüsselrollen: Projektmanager (RP) und Teamleiter.

Das Unternehmen kommuniziert mit dem Kunden, formalisiert Aufgaben, erstellt einen Rückstand, legt Prioritäten fest, erstellt Pläne und übt die Kontrolle über Aufgaben zur Einhaltung der Geschäftslogik aus. Außerdem kommuniziert RP in allen Phasen der Arbeit mit den Abteilungen Design, Design, Analytics und Systemadministration.

Timlid führt die technische Formalisierung von Aufgaben durch, definiert die verwendeten Technologien / Tools, führt eine Codeüberprüfung durch, führt Releases durch, überwacht die architektonische Integrität des Projekts und koordiniert Entwicklungsteams.

Die verbleibenden Ressourcen können nach Bedarf mit dem Projekt verbunden werden und sind in hohem Maße austauschbar.

Ein wichtiger Meilenstein für das Wachstum des Projekts und ein besonderer Paradigmenwechsel treten zu einem Zeitpunkt auf, an dem es unmöglich ist, alle Informationen in einem Kopf zu behalten. Ein Teamleiter kann physisch nicht die gesamte Architektur des Projekts steuern, da es zu schnell wächst. Ein Manager hat keine Zeit, sich auf alle Aufgaben einzulassen und die gesamte Arbeit zu kontrollieren.

Es besteht die Notwendigkeit, die Pflichten der Mitarbeiter zu trennen und zu verdoppeln, und das Standardrollensystem wird erweitert und komplizierter.

Struktur des Managementteams

Eine der am schwierigsten zu skalierenden Einheiten ist RP.
Wenn das Projekt wächst, ist es sinnvoll, das klassische Pair Account Manager-Projektmanager-Schema zu implementieren, wenn sich ein RP um den Kundenservice einschließlich Produktproblemen kümmert und der zweite den Produktionsprozess innerhalb des Unternehmens organisiert.



Ein solches Schema wird jedoch mit anschließendem Wachstum zum Stillstand. Im Rahmen eines Projekts kann es bis zu mehreren zehn Produkte geben, von denen jedes aus Sicht der Geschäftsprozesse besondere Aufmerksamkeit erfordert. In diesem Fall treten in regelmäßigen Abständen Situationen auf, in denen die parallele Entwicklung verschiedener Produkte zu logischen Konflikten im Rahmen der Webanwendungsarchitektur oder Geschäftslogik führt, die mit extrem hohen Risiken verbunden sind.

Daher ist das ideale Schema unter dem Gesichtspunkt der weiteren Skalierbarkeit wie folgt:



Der Gruppenleiter (GH) verwaltet die Führungskräfte des Projekts und ist verantwortlich für die Kontrolle der Budgets, der Rentabilität, der Teambildung (sowohl der Manager als auch der direkten Ausführenden) und der Ressourcenzuweisung und löst strategische Probleme des Projektmanagements. Er führt auch die Produktkontrolle durch und überwacht das Fehlen von Konflikten in parallelen Prozessen. Er verbringt keine Zeit mit operativen Aktivitäten und der Überwachung der Umsetzung jeder spezifischen Aufgabe.

Dank der Einführung dieser Rolle werden Fälle beseitigt, in denen mehrere große Aufgaben parallel ausgeführt werden und im Endstadium Widersprüche und logische Konflikte aufgedeckt werden, die im am wenigsten erfolgreichen Fall zu einem vollständigen Refactoring führen.

Bei Bedarf ist eine zusätzliche Product Owner-Rolle verbunden, an die GH einen Teil der Produktverantwortung delegiert. Meistens basiert dieser Mitarbeiter auf der Kundenseite und leitet alle Wünsche des Unternehmens in Form von formalisierten Aufgaben zur Ausführung weiter.

Jeder RP im Team ist für seinen „Teil“ des Projekts verantwortlich und übernimmt die Kontrolle über alle aktuellen Aufgaben für eine Reihe von Produkten (im Idealfall sollten dies verwandte Bereiche sein). Zu seinen Aufgaben gehören das Timing und die Qualität aller Aufgaben im Rahmen der Entwicklung verantwortlicher Produkte.

Das Schema ist leicht skalierbar und hat eine relativ niedrige Einstiegsschwelle, da beim Anschließen eines neuen RP nicht gleichzeitig die gesamte Wissensbasis des Projekts abgedeckt werden muss, sondern das Funktionsprinzip "Ihrer" Produkte verstanden werden muss.

Es ist wichtig, dass jeder RP nicht nur für den Produktionsprozess verantwortlich ist, sondern auch mit der Geschäftslogik seiner Produkte vertraut ist. Dank dessen sind alle Managemententscheidungen nicht nur aus Sicht des Projektmanagements korrekt, sondern auch nützlich für Unternehmen und architektonisch verifiziert.

In einigen Fällen sollte die Rolle des Projektadministrators separat herausgearbeitet werden - dieser Mitarbeiter taucht nicht in die Produktkomponente oder den Produktionsprozess ein, sondern erstellt Berichte, ist für das Dokumentenmanagement verantwortlich und spielt auch die Rolle der „ersten Zeile“, um die Kontinuität der Kommunikation sicherzustellen und schnelle Antworten auf alle Kunden- und Partneranfragen zu erhalten .

Gleichzeitig umfasste das gesamte Managementteam in erster Linie die kollektive Motivation, die mit dem Management der Kundenerwartungen verbunden war - den Einstieg in die Projektplanung.

• 10 Arbeitstage vor Monatsbeginn weist jedes RP selbst drei bis fünf seiner Hauptaufgaben für den nächsten Monat zu.
• 5 Arbeitstage vor Monatsbeginn wählt GH zwei oder vier davon für jeden Manager aus und legt die Fristen fest: 1 - Kundenlaufzeit (50%), 2 - interne Laufzeit (100%) und in die Tabelle eintragen.

Bonusbedingungen (gemäß den Ergebnissen des Monats):

• Der Manager erhält 100% Bonus, wenn alle seine Aufgaben innerhalb der internen Frist erledigt sind.
• Der Manager erhält 50% der Boni, wenn mindestens eine seiner Aufgaben die interne Laufzeit verlassen hat, aber in der Laufzeit des Kunden abgeschlossen wurde.
• Keiner der Manager erhält einen Bonus, wenn mindestens eine Aufgabe aus der allgemeinen Liste zum Zeitpunkt des Kunden nicht erledigt wurde.

Dieses Schema ermöglicht es dem gesamten Managementteam, effektiv zu arbeiten und die Kundenerwartungen korrekt zu verwalten.

Testen nicht nur des endgültigen Codes - QS-Befehl

Wenn das Projekt wächst, sammelt sich eine solide Wissensbasis an, die Anzahl der Nuancen und Merkmale wächst, logische Beziehungen werden komplexer und vielfältiger. Irgendwann üben diese Faktoren einen so starken Einfluss aus, dass das Debuggen vor der Veröffentlichung entsprechend der Entwicklung Zeit in Anspruch nimmt und dieselbe Menge an Ressourcen benötigt.

Um diese Situation zu vermeiden, kamen wir auf die Idee, ein vollwertiges QS-Team basierend auf dem Testteam zu erstellen. Der Hauptunterschied besteht darin, dass die Tests nicht nur in der Phase der Entwicklung, Fehlerbehebung und Freigabe durchgeführt werden, sondern in allen Phasen des Projekts:

• Die Qualitätssicherung ist für die Qualität des Produkts und dessen stilistische und logische Übereinstimmung mit anderen Produkten verantwortlich und in den Projektregeln allgemein anerkannt.
• Die Qualitätssicherung untersucht alle Artefakte, die im Projekt auftreten: die anfängliche Formalisierung der Aufgabe, der Prototypen, der Spezifikationen, des Designs und natürlich das Testen des Codes und des Layouts, das Schreiben von Testfällen, das Abdecken der vorhandenen und neuen Funktionen mit einem Raster von Autotests.
• Ohne die Validierung der Materialien durch das QA-Team hat der RP nicht das Recht, die nächste Stufe zu starten oder Materialien zur Annahme an den Kunden zu senden.

Ein solcher Ansatz kann das Risiko eines längeren Debuggens und einer Verzögerung der Veröffentlichungsdaten erheblich verringern.

Timlids - Effizienz oder Austauschbarkeit?

Sobald der zweite Teamleiter in das Projekt eingeführt wird, stellt sich sofort die Frage: Welches Verteilungsschema der Verantwortlichkeiten sollte angewendet werden?

Es gibt verschiedene Möglichkeiten: Entweder das Projekt nach Art der Aktivität aufteilen, dh Team A konzentriert sich auf Architektur, Codeüberprüfung und technische Formalisierung von Aufgaben, während Team B Entwicklungsteams verwaltet und Builds veröffentlicht, ist für die Kontinuität und Sicherheit verantwortlich. Die zweite Option ist eine Produktaufschlüsselung, bei der jeder Teamleiter die volle Verantwortung für seine Produkte innerhalb des Projekts trägt.

Beide Optionen sind hinsichtlich der Ressourcennutzung gut, bergen jedoch große Risiken hinsichtlich der Austauschbarkeit.

Was soll ich zum Beispiel tun, wenn einer der Teamleiter krank wird, Urlaub macht oder aufgibt? Es wird schwierig sein, einen neuen Teamleiter in den Prozess einzubeziehen, da die Zeit des Eintauchens in diese Rolle extrem lang ist.

Daher lohnt es sich, für das Projekt ein hybrides Schema zu verwenden, bei dem jeder Teamleiter seine eigenen Aufgaben wahrnimmt. Es gibt jedoch eine Reihe von Aktivitäten, bei denen sich alle oder mindestens zwei Teamleiter des Teams widmen.

Zu diesen Aktivitäten gehören die risikoreichsten, zum Beispiel: Projektarchitektur, Kontinuität, Sicherheit, Schlüsselprodukte, die den aktivsten Umsatz ausmachen und deren Leistung in der SLA festgelegt ist.



Dieses System verringert natürlich die Arbeitsproduktivität, beseitigt jedoch die meisten Risiken. Es ist notwendig, ein Gleichgewicht zwischen Effizienz und Austauschbarkeit zu finden und eine Liste der wichtigsten Momente zu erstellen.

Unabhängig davon ist es sinnvoll, Teamleiter mit entfremdeten Aktivitäten zu verbinden: einem Produkt, das architektonisch vom Hauptteil des Projekts getrennt ist, oder einer Aktivität, die parallel ausgeführt werden kann. Zum Beispiel ist es durchaus möglich, ein Team-Lead-Layout auszuwählen, das die Kontrolle über alle Front-Line-Operationen vollständig übernimmt. getrennt unterschieden werden die Rollen des Teamleiters QS, Design, Analytik.

Austauschbarkeit der Teammitglieder

Je mehr Personen an dem Projekt beteiligt sind, desto aktiver müssen Sie Tools verwenden, um die Einstiegsschwelle für neue Mitarbeiter zu senken. Außerdem vereinfachen sie die Austauschbarkeit bestehender Teammitglieder und reduzieren den Busfaktor.

Hier finden Sie eine Reihe von Tools, die bei fast allen Projekten eine gute Leistung erbringen.

Design-System

Das Design-System ist ein umfassendes und aktuelles Design-Kit und eine Komponentenbibliothek im Repository. Es spiegelt den vollständigen Satz von Standardelementen im Projekt wider und ermöglicht es Ihnen, neue Seiten aus diesen Blöcken zu sammeln. Das Entwurfssystem enthält nicht nur eine Reihe von Elementen, sondern beschreibt auch deren Interaktion sowie Codebeispiele.

Die Verwendung eines Designsystems kann das Verständnis eines neuen Mitarbeiters, ob Manager, Designer oder Programmierer, für die visuellen Regeln des Projekts erheblich vereinfachen und vorhandene Lösungen anwenden, anstatt ständig neue zu erfinden.

Die Verwendung solcher Tools erfordert einen hohen Ressourcenaufwand für Entwicklung und Support. Außerdem ist es oft sehr moralisch anstrengend, dem Kunden zu erklären, warum es notwendig ist, sich an dieses System zu halten, und aus welchem ​​Grund Vorschläge wie „Hinzufügen eines neuen grünen Buttons auf dieser Seite, wie auf Site N, die so schön aussieht“ abgelehnt werden.

Die Dokumentation

Je größer das Projekt ist, desto sorgfältiger sollte jedes Produkt und jede Funktion dokumentiert werden. Andernfalls wird immer mehr Zeit von Experten für das Debuggen und Herausfinden der Funktionsweise der einen oder anderen Funktion aufgewendet.

Die Projektdokumentation ist sinnvoll in vier Typen zu unterteilen:

• Schnittstellenspezifikationen - eine Beschreibung des Verhaltens der implementierten Funktionalität (Arbeitslogik, Feldvalidierung, Satz von Bildschirmen).
• Testfälle (Beschreibung der Benutzerszenarien und die Ergebnisse ihrer Passage), auf deren Grundlage gegebenenfalls Autotests entwickelt werden.
• Dienstspezifikationen (Beschreibung der Interaktion mit Webdiensten, Testdaten, Beispiele für Anfrage-Antwort).
• Codedokumentation (Beschreibung der Komponenten, Klassen und ihrer Hierarchie, Vorlagen).

Alle Dokumentationen sollten in einer Online-Wissensdatenbank (Wiki) zusammengefasst und auf dem neuesten Stand gehalten werden.

Git

Um die Verbindung neuer Entwickler aus anderen Projekten des Unternehmens zu beschleunigen, wird ein Standardansatz für GitFlow eingeführt. Bei AGIMA verwenden wir den Ansatz „Arbeiten mit zwei Hauptzweigen“.

Anstatt den Hauptzweig zu verwenden, werden zwei Hauptzweige des Projektverlaufs verwendet: Master für Releases und Entwicklung zum Zusammenführen der entwickelten Funktionalität aus Feature-Zweigen.

Workflow

Ein weiteres Tool, das die Arbeit aller Teammitglieder reguliert und standardisiert, ist der Workflow nach Wochentag.

Jede Woche ist ein Standardproduktionszyklus: Die Veröffentlichung erfolgt ausschließlich dienstags und donnerstags. Mittwoch - Tag der Bewertungen; Die Rückschau und Planung neuer Sendungen erfolgt am Ende der Woche - am Donnerstag und Freitag. Dies ist ein Beispiel für einen Workflow aus einem der Projekte. Für jeden speziellen Fall sollte ein Ansatz entwickelt werden.

Der Client muss auch in den Workflow eingebunden sein - ein solches System kann nicht einseitig arbeiten.

Nicht weniger wichtig ist der Workflow für Aufgabenstatus, der den Übergang von Mitarbeitern zwischen Projekten vereinfacht. Es sollte bei allen Projekten des Unternehmens identisch sein. In AGIMA sieht es so aus:

Teammitglieder auf dem Laufenden halten

Selbst wenn die Dokumentation im Projekt perfekt organisiert ist und alle Prozesse wie am Schnürchen ablaufen, ist es unmöglich, alle Risiken vorauszusehen, die mit dem mangelnden Bewusstsein jedes einzelnen Künstlers verbunden sind. Hierzu werden regelmäßig Veranstaltungen in verschiedenen Formaten organisiert.

1. Produktbesprechungen

Bei solchen Besprechungen informieren erfahrene Mitarbeiter das Team über bestimmte Produkte. Die Aspekte der Geschäftslogik, der technischen Implementierung und der Architektur werden hervorgehoben. Das Bewusstsein jedes Mitarbeiters für die Hauptnuancen der Produkte hilft, nützliche Ideen vorzubringen und in allen Phasen der Implementierung die richtigen Entscheidungen zu treffen.

2. Infrastrukturabschnitte

Das Projekt wächst dynamisch, dies beinhaltet die ständige Weiterentwicklung und den Ausbau der Infrastruktur. In regelmäßigen Abschnitten werden aktuelle Probleme und Aufgaben für die Entwicklung der Infrastruktur erörtert und Fortschritte bei deren Umsetzung erörtert.

3. Rückblicke und Arbeitsplanung

Es ist notwendig, wöchentliche Besprechungen abzuhalten, um die in der letzten Woche durchgeführten Aufgaben zu besprechen, Fehler hervorzuheben und die Arbeit für den nächsten Abrechnungszeitraum zu planen.

Schlussfolgerungen

Durch die sorgfältige Anwendung aller oben genannten Tools und Ansätze kann ein kohärentes und belastbares Team aufgebaut werden, das sich mit dem weiteren Wachstum des Projekts problemlos skalieren lässt.

Zweifellos ist die Organisation eines solchen Systems mit einer Reihe von Schwierigkeiten verbunden und erfordert sowohl tiefe Kompetenzen innerhalb der Agentur als auch die Bereitschaft des Kunden, in solche Entscheidungen zu investieren, die in unserem sich entwickelnden Markt schwierig sein können. Diese Bemühungen zahlen sich jedoch aus und führen zu einer langfristigen und fruchtbaren Zusammenarbeit und ermöglichen die Herausgabe Der Markt ist wirklich Qualitätsprodukte.