Über Raumfahrzeuge und Weltraum. So erstellen Sie eine Funktion, indem Sie das gesamte Produkt auf dem Weg ändern

Am 24. April gab es eine wichtige Änderung in der Wrike-Plattform: Das Team kündigte die Veröffentlichung eines neuen Features an - "Spaces" in der russischen Version - "Spaces".
Das Ziel von Spaces ist es, die Arbeit der Teams im Task-Manager zu verbessern und die Navigation im Produkt zu vereinfachen, um die Prozesse organischer und transparenter zu gestalten. Haben wir es gemacht Lesen Sie weiter und lernen Sie, wie Sie ernsthafte Updates in einem großen Unternehmen einführen und nicht vermasseln, wie Sie die Interaktion von 30 Scrum-Teams sicherstellen und welche Lehren wir aus dem Produktentwicklungsprozess gezogen haben, dessen Veröffentlichung uns später viel Blut und einen bahnbrechenden Teamgeist gekostet hat.

Warum wurden Räume erfunden?

Als Wrike erstellt wurde, konzentrierte es sich auf die Lösung der Probleme der Effektivität kleiner Teams von 15 bis 20 Personen. Für solche Teams ist es praktisch, an einem Ort zu arbeiten, an dem für jeden ein „Raum“ vorhanden ist.

Im Laufe der Zeit hat sich die Größe der Konten um ein Vielfaches erhöht. Jetzt wird das Produkt von verteilten Teams in Konten mit Tausenden von Personen verwendet, und in Zukunft sehen wir Wrike als praktisches Werkzeug für die Arbeit vieler Abteilungen des Unternehmens: einerseits in verschiedenen Prozessen arbeiten, andererseits immer noch miteinander interagieren müssen.

Da in der realen Welt Teams in verschiedenen Büros, Büros und Ländern existieren, hat das Wrike-Team darüber nachgedacht, einen speziellen Raum für sie zu schaffen, damit sie gleichzeitig als Teil ihres Prozesses arbeiten und nicht den Kontakt zu anderen Abteilungen verlieren können.

Mithilfe von Bereichen können einzelne Arbeitsgruppen ihren Workflow effizient organisieren: Geben Sie ihnen die Tools und die Datenstruktur, die sie benötigen, greifen Sie auf verschiedene Arten von Abfragen zu, damit sie ihren eigenen Arbeitsbereich organisieren und fokussierter agieren können. Mit Spaces können Sie auch die Verteilung von Informationen in multifunktionalen Teams besser steuern und die Datensicherheit erhöhen.



Die Idee, Räume zu schaffen, gehört Sasha Plotvinov und Van Saveliev, Wrike-Produktmanager. Zuerst recherchierten sie, zeichneten einen Prototyp der Lösung für die Teams an der Tafel, stellten Modelle zusammen und validierten die Idee. Später wurde es beim Wrike Hackathon fertiggestellt , wo sie einen Schritt zur Seite traten und einen Personal Space-Prototyp zusammenstellten, der das Konzept ergänzte.

"Spaces" ist vor allem ein Feature für Teams. Es basiert jedoch auf dem Konzept des persönlichen Lebensraums, bei dem jeder unnötige Informationen und Fremdgeräusche ausschließen muss.

Welche Probleme lösen Spaces?

Zur Vereinfachung besteht Wrike aus Projekten und Werkzeugen für die Arbeit mit ihnen. Wenn Sie beispielsweise an einer umfassenden Version arbeiten, erstellen Sie eine Reihe von Projekten, überwachen deren Fortschritt anhand des Gantt-Diagramms, steuern die Belastung von Teams mithilfe von Workload und erstellen basierend auf den Ergebnissen einen Bericht für Stakeholder.

Alles scheint einfach zu sein, aber wenn Tausende von Personen in einem Konto in einer großen Anzahl von Teams mit überlappenden Prozessen arbeiten und viele Tools verwenden, treten zwei Probleme auf: Die Verwaltung von Prozessen wird schwierig und die Benutzeroberfläche ist mit unnötigen Elementen überlastet .


<sub>war


ist geworden</sub>

Solche Hindernisse für eine effektive Teamarbeit treten aus einer Reihe von Gründen auf: Erstens gibt es in demselben Ordnerbaum viele Teams; Der Benutzer sieht ständig irrelevante Informationen und verletzt versehentlich die Struktur des „Alien“ -Teams. Zweitens haben nur Administratoren Zugriff auf das Prozessmanagement, und die Kontostruktur wird häufig von den Chief Manager-Administratoren gebildet.

Bei der Entwicklung von Spaces kamen wir zu zwei Hauptaufgaben:

• Der Benutzer sollte nur sehen, was für ihn relevant ist
• Delegation und Selbstorganisation sollten an den Ort des vertikalen Managements kommen

Wrike ist eines der Unternehmen, die glauben, dass horizontales Management vertikale und „türkisfarbene“ Organisationen übertrifft und sich am effizientesten zeigt. Der in Spaces implementierte Ansatz wird dem Team helfen, ein neues Maß an Transparenz und Selbstorganisation zu erreichen, bei dem horizontales Management Vorrang hat.

"Wenn der Account-Administrator zuvor ein hohes Maß an Verantwortung für die Prozesse hatte, kann er jetzt die Organisation des Workflows des Teams seinem direkten Vorgesetzten anvertrauen, der die Funktionen seines Teams oft besser kennt."

- Ivan Savelyev, Wrike-Produktmanager

Auf welche Schwierigkeiten sind wir gestoßen?

Wesentliche Änderungen am Produkt sind natürlich mit großen Risiken und einer Reihe von Schwierigkeiten verbunden. Hier sind einige davon:

Schwierigkeit 1. Risiken reduzieren

Das Anpassen eines Kontos an eine neue Art der Arbeitsorganisation ist eine ziemlich zeitaufwändige Aufgabe. In Wrike wurde das Problem fast sofort entdeckt: Als Unternehmen mit vielen Teams und Prozessen fallen wir in die Kategorie der Kunden, die wir als unser eigenes Publikum betrachten und unser Produkt täglich verwenden. Innerhalb des Teamkontos (mehr als 800 Mitarbeiter aus allen internationalen Niederlassungen) haben wir Releases gestartet und sofort Feedback von innen erhalten. Dies hat dazu beigetragen, eine öffentliche Veröffentlichung vorzubereiten und die Risiken im Voraus zu maximieren.
Für diejenigen, die Wrike noch nie verwendet haben, haben wir in der Anfangsphase eine Reihe von Lösungsinterviews durchgeführt , Tests mit dem UserTesting- Dienst gestartet und für interessierte Kunden ein Frühzugriffsprogramm für die Spaces-Funktionalität erstellt.

Vor dem Start für das gesamte Publikum haben wir außerdem A / B-Tests für neue Tests durchgeführt, um sicherzustellen, dass das neue Navigationsparadigma für neue Benutzer intuitiv ist. Beim Testen wurde deutlich, dass neue Benutzer das Produkt erfolgreich verwenden. Wir haben auch die Test- und Kontrollgruppen befragt und festgestellt, dass Benutzer unter den Befragten viel häufiger über die Verständlichkeit der Benutzeroberfläche und die Benutzerfreundlichkeit von Wrike sprechen.

Schwierigkeit 2. Bringen Sie den Wert der Lösung zum Client

Wrike hat viele Kunden, die den Service bereits nutzen und ihre Arbeitsprozesse einrichten. Daher bestand das Risiko, dass die neue Funktionalität nur ungern verwendet wird.

Wir haben die private Beta für Schlüsselkunden gestartet und unsere Professional Services- Abteilung mit dem Prozess verbunden.
Um das Problem und anschließend die Lösung für die Kunden zu vermitteln, identifizierten Customer Success Manager zusammen mit Account-Administratoren frühzeitig die Probleme bei der Organisation von Prozessen und erklärten den Kunden, wie Spaces sie lösen könnten. So haben wir den Maximalwert von Spaces übermittelt, der die Höhe der Kosten der Restrukturierung überwog. Wir haben die Funktion nicht nur plötzlich eingeführt, sondern die Kunden systematisch auf ihr Erscheinungsbild vorbereitet: Kundenerfolgsmanager führten Webinare durch, brachten Kunden das Navigieren in den neuen Funktionen bei, schulten E-Mail-Newsletter und sprachen über Best Practices.

Später haben wir überhaupt keine Anrufe getätigt: Kunden kamen selbst zum frühen Testprogramm und nutzten eine neue Funktion.

Schwierigkeit 3. Eine Verbesserung erfordert viele Änderungen

Die Plattformverbesserung wirkt sich auf verschiedene Aspekte des Produkts aus. Wir haben uns für eine Modernisierung entschieden, um nicht an einem Ort zu stehen. Wir hatten Glück mit einem Entwicklungsteam, das die unglaublichsten technischen Knoten löste und während der gesamten Projektarbeit optimale Lösungen fand. Darüber hinaus haben alle die Notwendigkeit dieser Initiative verstanden, sodass wir immer eine starke Unterstützung von VP und CEO hatten.

Von Anfang an entschied sich das Entwicklungsteam, eine minimal verbundene Architektur zu erstellen und die gesamte Lösung in eine Reihe separater Geschäftskomponenten und Minianwendungen umzuwandeln, die nur zwischen Workspace (dem Endprodukt, das der Wrike-Benutzer sieht) integriert und interagiert werden.

Für diese Komponenten wurde ein separates Repository erstellt, einschließlich einer Sandbox. Es war nicht nur möglich, jede Komponente in Aktion zu betrachten und sie beispielsweise in einem Sprint-Review zu zeigen, sondern auch ihre vollständige Entwicklung und Erprobung durchzuführen. Montage, Unit-Testläufe und Autotests dauerten um eine Größenordnung weniger als bei der Entwicklung in einem vollwertigen Arbeitsbereich. Auf diese Weise konnten Entwickler schnell iterieren, die Ergebnisse am Ende jedes Sprints anzeigen und bei Bedarf schnell Änderungen sowohl an der Funktionalität als auch an der API vornehmen. Nach einiger Zeit wurde der nächste Schritt unternommen - die Schaffung einer Art „Spielplatz“, auf dem eine sehr vereinfachte Oberfläche des Hauptprodukts erstellt wurde, einschließlich der Integration der meisten Komponenten. Dies ermöglichte es uns, ihre Interaktion miteinander zu entwerfen und zu debuggen.

Wie haben die Teams miteinander interagiert?

Wrike hat ungefähr 30 Scrum-Teams, die an ihrem Teil des Produkts arbeiten, von denen jedes derzeit von Funktionen betroffen ist oder in naher Zukunft in den Prozess einbezogen wird. Das Problem der Interaktion zwischen Teams während der Entwicklung von Spaces trat manchmal sehr scharf auf - schließlich hat jedes Team seine eigenen Produkt-OKRs für das Quartal.

Das Thema Kommunikation hatte Priorität: Wo es möglich war, alles im Voraus zu besprechen, die Vereinbarungen zu vereinbaren und zu formalisieren, erwies sich die Interaktion als besser als bei den Teams, mit denen keine Vorgespräche geführt wurden. Im letzteren Fall musste das Entwicklungsteam selbst Änderungen vornehmen oder die Funktionen anderer ändern.

„Es gab außergewöhnliche Fälle: Früher musste eine ziemlich große und komplexe Komponente, die von einem externen Team entwickelt wurde, integriert werden, bevor sie von diesem Team fertiggestellt wurde (daher erschien sie in unserer Funktionalität früher als im Grunde). Was zu tun ist - wir haben versucht, die Arbeit im Rahmen der Fristen zu beenden und mussten raus. Und die Zeit, die wir damit verbracht haben, alles in Ordnung zu bringen, nachdem die Komponente fertig war, mussten wir bei der Arbeit an anderen Funktionen mit einer dünnen Schicht verschmieren - die planmäßige Integration war lange vorbei! “

- Alexey Kartavenko, Frontend Teamlead

Die Anzahl der Probleme, die auftreten, wenn 30 Teams in einer sehr intensiven, agilen Umgebung miteinander interagieren, sollte nicht entmutigen. Für fast jedes Unternehmen ist das Arrangieren eines Scrum-Prozesses bereits eine Errungenschaft, und Scrum of Scrums ist eine Fantasie: Hier müssen Produktbesitzer, Leads und normale Entwickler lernen, wie man miteinander arbeitet.

Dies sind die Tipps, die das Spaces-Team denjenigen gibt, die sich auf ein großes Projekt vorbereiten:

1. Besprechen Sie so oft wie möglich die Zwischenoptionen des Projekts mit verschiedenen Teilnehmern des Prozesses, sammeln Sie ständig Feedback und suchen Sie nach zusätzlichen Denkanstößen.
2. Wenn das, was Sie tun, intern verwendet werden kann (wir hatten großes Glück bei Wrike), starten Sie ein Pilotprojekt. Rollen Sie alle an, informieren Sie alle, führen Sie Feedback-Formulare aus!
3. Bestimmen Sie den Grad der Bereitschaft, mit dem Sie Funktionen für treue Kunden aktivieren können: Unter ihnen gibt es immer diejenigen, die mit der Zeit Schritt halten und alle möglichen experimentellen Funktionen aktivieren möchten. Ihr Feedback ist besonders wertvoll, da sie Ihre Zielgruppe sind. Alle frühen Testmechanismen stehen Ihnen zur Verfügung: A / B-Experimente, begrenzte und kontrollierte Einführung von Alpha- und Beta-Versionen, Early Access-Zugriff auf Anfrage usw.
4. Gleichgewicht zwischen Entwicklungsgeschwindigkeit und Qualität wie auf einem Surfbrett: Haben Sie keine Angst, im aktuellen Sprint technische Schulden zu hinterlassen, sondern starten Sie sofort Aufgaben, um diese zu beseitigen, sobald die Situation klar wird. Denken Sie daran, diesen Aufgaben die höchste Priorität einzuräumen. Es ist nicht kurzsichtig, die Funktions- und Autotests von Einheiten, die sich nach Rückmeldung im nächsten Sprint ändern können, vollständig abzudecken. Darüber hinaus ist es nicht nur dumm, sondern auch kriminell für den Ingenieur, den Junk-Code am Ende zu belassen und ihn zur Veröffentlichung zu bringen.
5. Versuchen Sie, sich auf jeden nächsten Sprint richtig vorzubereiten: Führen Sie PBRs (Product Backlog Refinement) durch, stellen Sie sicher, dass Sie Aufgaben im aktuellen Sprint übernehmen, um zu untersuchen, was Sie im nächsten Sprint planen, und sprechen Sie mit dem Product Owner und dem UX-Designer, so viel Sie für richtig halten sie in der Küche und im Raucherzimmer, um die Details zu klären. Versuchen Sie, das Backend, das Frontend und die Tests so zu synchronisieren, dass die Interaktion „überlappt“ wird, sodass niemand untätig ist und auf die Bereitschaft von Kollegen einer anderen Spezialisierung wartet, damit Sie nicht auf dem Mok sitzen und sie dann wegwerfen müssen usw.
6. Näher am Veröffentlichungsdatum, wenn sich die Leidenschaften verschärfen und der größte Teil der Arbeit von Entwicklern auf QS-Ingenieure übertragen wird, ersetzen Sie sie durch Ihre Schulter: Testen Sie Ihren Code selbst, führen Sie eine Regression durch, helfen Sie beim Parsen und versuchen Sie, Autotests zu schreiben.
7. Beginnen Sie bei der Interaktion mit anderen Teams im Voraus regelmäßige Diskussionen darüber, wie genau Sie dies tun werden. Schreiben Sie alle Vereinbarungen und Pläne auf, erstellen Sie Unterlagen, Sie können sogar Verträge erstellen - nicht weil jemand versucht, Sie zu täuschen und nicht zu viel zu tun, sondern weil jeder seinen eigenen Schaum von Tagen hat und Ihre Probleme nur zu fünf Prozent fremd sind. Die Sprint-Synchronisation ist ideal, zielen Sie darauf ab.
8. Seien Sie vorsichtig, wenn Sie etwas verwenden, das von anderen Teams entwickelt wurde, dass "fast alles fertig ist, nehmen und integrieren". Zuerst müssen Sie herausfinden, ob Sie nicht in ein Chaos geraten möchten, blind nehmen, was sie geben, und Ihre Pläne darauf aufbauen (insbesondere Kalenderpläne).
9. Und das Wichtigste: In einer komplexen IT-Welt wird keine einzige ernste Sache auf Knopfdruck erledigt. Wenn sich das Projekt also lange in der Entwicklung befindet und sie beginnen, „seitwärts zu schauen“, kümmern Sie sich um Ihre Nerven und wissen: Auch wenn nicht heute, sondern morgen oder morgen übermorgen werden sich endlos abrutschende Fäden verflechten, der Nebel wird sich zerstreuen und der Erfolg erwartet Sie - Sie glauben an das, was Sie tun, oder?