Mein Name ist Alexandra Kamzeeva, ich arbeite seit 9 Jahren als Systemanalytikerin, davon 3,5 Jahre bei Lamoda. Ich lese viel, analysiere die aktuelle Dokumentation und erstelle eine neue. In meiner Arbeit strukturiere ich Informationen immer und mache sie so bequem wie möglich.
Die Vorteile einer guten Systembeschreibung sind:
- hilft Ihnen, die benötigten Informationen schneller und einfacher zu finden als in einer unstrukturierten Beschreibung;
- reduziert das Risiko eines Projektversagens;
- erleichtert den Mitarbeitern den Einstieg.
Wir haben eine Vorlage für eine solche Beschreibung erstellt, die jedes Team verwenden kann. In diesem Artikel werde ich Ihnen anhand von Beispielen erläutern, was uns dazu veranlasst hat, eine Systembeschreibungsvorlage zu erstellen, den Verlauf ihrer Erstellung und wie sie jetzt in Lamoda verwendet wird.
Was ist eine Vorlage und warum wird sie benötigt?
Zuerst beschreibe ich mein Verständnis des Musters. Stellen wir uns vor, ich müsste ein kleines Auto in einem unordentlichen Raum finden. Es ist keine Tatsache, dass ich damit umgehen kann. Aber ich kann versehentlich auf den Lego-Teil treten.
Stellen wir uns nun vor, dass alle Spielzeuge an ihren Platz gebracht und sortiert werden. Ich kann im Voraus sehen, in welcher Box sich alle Autos befinden, ich werde die, die ich brauche, schneller und einfacher finden und ich werde meine Nerven nicht damit verschwenden.
Ebenso mit der Dokumentation. Eine Vorlage ist eine solche Bestellung. Wir haben einen Rahmen für die Beschreibung eines Systems erstellt, das jedes Team verwenden kann.
Unter welchen Bedingungen arbeiten wir mit Dokumentation
Lamoda verfügt über mehr als 100 Systeme, die die Auftragslieferung, das Contact Center, das Lager, das Fotostudio und andere Betriebs- und Geschäftsprozesse automatisieren. Mehr als 300 Ingenieure sind an Entwicklung und Support beteiligt. Jeder von ihnen benötigt möglicherweise eine Beschreibung eines dieser 100 Systeme.
Jedes Team beschreibt sein System unabhängig in einem separaten Bereich in Confluence. Der technische Leiter ist notwendigerweise an der Dokumentation beteiligt, da er verpflichtet ist, die Informationen aufzuzeichnen. Das System wird auch von aktiven Testern und Entwicklern beschrieben, denen es leid tut, nur ihr Wissen verloren zu haben. Und natürlich Analysten, denn Dokumentation ist eines unserer Hauptinstrumente.
Es mag scheinen, dass diese Freiheit zu Chaos führt. Dies ist jedoch nicht der Fall, da wir eine Unternehmenskultur haben: eine verantwortungsvolle Haltung gegenüber der Dokumentation, ein offener Wissensaustausch, die Gewohnheit, Projekt- und Systemartefakte aufzuzeichnen. Diese Tradition hat sich teilweise aufgrund erfolgloser Projekte entwickelt. Die Vorfälle haben den Entwicklungsteams gezeigt, wie wichtig es ist, die Prozesse und Funktionen des Systems zu dokumentieren.
Im Folgenden werde ich einige Fälle hervorheben, in denen verwirrende oder fehlende Dokumentation zu Problemen führte.
Fügen Sie einfach zwei Schaltflächen hinzu.
Das erste Problem, das uns zum Erstellen einer Vorlage veranlasste - wir hatten keine Beschreibung einiger Systeme, was zu Fehlern und Verbesserungen führte.
Wir hatten ein Self Order Management (SOM) -Projekt. Wir haben beschlossen, dem persönlichen Konto des Kunden zwei Schaltflächen hinzuzufügen: "Lieferdatum übertragen" und "Bestellung stornieren". Zuvor konnte ein Kunde eine Bestellung nur stornieren oder neu planen, indem er das Contact Center anrief. Es ist klar, dass einige Käufer nicht die Zeit oder den Wunsch hatten, mit dem Betreiber zu kommunizieren. Infolgedessen könnte der Vertriebsmitarbeiter eine unnötige Bestellung aufgeben oder den Kunden nicht zu Hause finden. In solchen Fällen trägt Lamoda die Kosten. Das Projekt war notwendig und wichtig.
Es scheint zwei Schaltflächen hinzuzufügen! Tatsächlich steckte in den vier Systemen viel Logik dahinter. Das Ändern der Reihenfolge erfolgt über das Verarbeitungssystem - ein riesiger Monolith, in dem Sie an einer Stelle etwas berühren und an einer anderen schießen können. Leider wurden die Feinheiten ihrer Arbeit in der Dokumentation nicht beschrieben, sie haben dies bei der Gestaltung des Projekts nicht berücksichtigt. Nach der Freigabe funktionierten die Schaltflächen nicht wie erwartet und es wurde ein Rollback durchgeführt. Infolgedessen dauerte dieses Projekt anstelle von zwei Mannmonaten sechs Monate.
Natürlich haben wir dieses Ergebnis nicht nur aufgrund der fehlenden Dokumentation erhalten. Wenn wir jedoch eine klare Beschreibung der Prozesse zum Stornieren und Übertragen einer Bestellung hätten, wäre das Ergebnis möglicherweise anders.
Komplexes Onboarding
Das zweite Problem, das uns dazu veranlasste, eine Vorlage zu erstellen, ist die Komplexität des Onboarding. Ich kam für das Team des Auftragsabwicklungssystems. Zum Eintauchen las ich die Dokumentation im Systemraum und fand in drei Abschnitten drei verschiedene Beschreibungen des Hauptbestandteils unseres Systems - des Bestellstatus.
In diesem Fall hat es nicht geklappt, das Onboarding zu vereinfachen. Diese Dokumentation hat nicht dazu beigetragen, Wissen an Kollegen weiterzugeben, die zuvor noch nicht auf unser System gestoßen waren.
Leeres Schieferproblem
Die dritte Voraussetzung für die Erstellung von Vorlagen ist das Problem mit dem leeren Schiefer. Für jedes neue System muss der technische Leiter von Grund auf den entsprechenden Platz schaffen. Der Tech Lead überlegt, welche Abschnitte erstellt werden sollen. Vor dem Erstellen der Vorlage hat der Mitarbeiter andere Bereiche untersucht und untersucht, welche Abschnitte verwendet werden und für sein System nützlich sind. Das hat früher lange gedauert.
Wie wir die Vorlage erstellt haben und was passiert ist
Jede Woche halten Systemanalysten einen Stand-up und diskutieren Probleme, die nicht nur bei Projekten auftreten. Und mehr als einmal haben sich Kollegen darüber beschwert, wie schwierig es ist, Informationen zu finden und die Räume verschiedener Systeme zu verstehen. Da wir aus diesem Grund ständig brannten, beschlossen wir, die Beschreibung der Systeme, an die wir angeschlossen sind, selbst in die Hand zu nehmen. Und dann wird klar, was zu tun ist.
Zuerst haben wir die Attribute einer guten Vorlage identifiziert:
- .
- . , , . , . .
- . , , , .
- .
Als nächstes analysierten wir die aktuelle Beschreibung verschiedener Systeme und identifizierten gemeinsame Abschnitte:
Im Abschnitt für Projekte und Funktionen gab es Spezifikationen für die Entwicklung von Projekten. Die Abschnitte Entwicklung und Qualitätssicherung enthielten spezifische Informationen für Entwickler und Tester. Im Abschnitt Vorfälle wurden die im System aufgetretenen Vorfälle und ihre Lösungen beschrieben.
Wir haben die Idee einer Vorlage bei informellen Treffen mit anderen Kollegen geteilt (Mittagessen in der Küche, Stand-Ups, Teamnachbarn, mit denen Sie regelmäßig sprechen) und eine Arbeitsgruppe von Freiwilligen gebildet. Sie waren Vertreter unterschiedlicher Kompetenzen: zwei Manager, drei technische Leiter und zwei Tester. Sie haben der Vorlage die folgenden Abschnitte hinzugefügt:
Als nächstes testeten wir die Systembeschreibungsvorlage mit Kollegen mit breiter Kompetenz: Leiter von IT-Abteilungen, erfahrene technische Leiter und Testleiter großer Integrationsprojekte. Am Ende fügten sie einige weitere nützliche Abschnitte hinzu:
Überprüfen der Qualität der Vorlage
Wir haben das resultierende Dokument anhand unserer Definition einer guten Vorlage in Lamoda überprüft:
- Es hilft Ihnen, die benötigten Informationen schneller und einfacher zu finden. Wir haben eine bequeme Struktur: Ich bewege mich entlang des Baumes und verstehe, was sich wo befindet. Wenn Sie Informationen zu den Prozessen des Systems benötigen (z. B. Stornierung einer Bestellung), gehe ich zu „Beschreibung der Hauptprozesse“.
- Systeminformationen werden aufgrund der Atomizität der Partitionen nicht dupliziert. Sie können beispielsweise druckbare Formulare in einem Abschnitt beschreiben und dann im Abschnitt „Beschreibung der Hauptprozesse“ darauf verweisen, damit sich die Informationen nicht wiederholen.
- . Lamoda, . , -. — .
- . .
Wir haben eine schöne Vorlage erstellt, um Lamoda-Systeme zu beschreiben. Ich hoffe, dass es auch für andere Unternehmen nützlich sein wird. Ich möchte insbesondere die folgenden drei Abschnitte hervorheben:
Beschreibung der Hauptprozesse des Systems . Ja, es scheint offensichtlich, dass dieser Abschnitt benötigt wird. Aber aus irgendeinem Grund existiert es nicht immer, wie wir es mit den Stornierungs- und Übertragungsschaltflächen getan haben. Wenn wir die Stornierungs- und Neuplanungsprozesse im Voraus beschrieben hätten, würde sich das Risiko eines Projektversagens verringern.
Checklisten- Ein Abschnitt, der an das Wichtigste im regulären Prozess erinnert. Zum Beispiel haben wir eine "Checkliste zum Verbinden einer neuen Zahlungsmethode" in der Beschreibung des Zahlungsmethoden-Managementsystems. Es heißt, dass wir das Hinzufügen oder Ändern einer Zahlungsmethode mit der Buchhaltung, dem Contact Center, der Lieferung und anderen Geschäftsbereichen koordinieren müssen.
Sobald wir vergessen haben, das Contact Center über die Änderung der Zahlungsmethode zu informieren. Und als der Kunde unser Contact Center anrief und danach fragte, konnte der Betreiber nichts sagen. Dies führte zu einem Konflikt zwischen dem Contact Center und dem für die Zahlungsmethoden zuständigen Entwicklungsteam. Nach diesem Vorfall erstellen wir Checklisten für wichtige Projektstarts, die Verbindung neuer Partner usw.
Space Homepage- Ein Abschnitt mit Informationen darüber, warum dieses System benötigt wird, über die Zusammensetzung des Teams und der Stakeholder. Wir müssen Systemänderungen und Entwicklungsressourcen mit den Stakeholdern koordinieren. Es ist also großartig, wenn Sie diese Informationen erhalten, indem Sie sich Confluence ansehen.
Genau dort geben wir Informationen über die Zusammensetzung des Teams an, um zu verstehen, an wen Sie sich bei Fragen zum System wenden können. Es hilft auch Anfängern mit einem geschwollenen Kopf. Es ist großartig, wenn ein neuer Mitarbeiter ausspionieren kann, mit wem er gerade gesprochen hat, wer diese Person ist, welche Rolle er spielt und wie er heißt.
Wie ich angefangen habe, die Vorlage auf meinem System zu verwenden
- Zunächst habe ich die erforderlichen Abschnitte der Vorlage erstellt, ohne sie zu füllen. Es war einfach und dauerte nicht länger als 30 Minuten.
- Das Schwierigste war dann: Wir haben regelmäßige Treffen mit dem technischen Leiter vereinbart, bei denen wir begonnen haben, die Dokumentation unseres Systems zu analysieren. Beim ersten Treffen haben wir die aktuellen Seiten in drei Stapel unterteilt.
Wir haben alles, was irrelevant und unnötig ist, auf den ersten Stapel geschickt. Wir haben diese Seiten gelöscht oder an das Archiv gesendet.
Der zweite Stapel ist notwendig, aber irrelevant. Wir haben Seiten als irrelevant markiert, eine Aufgabe in Jira erstellt und diese Informationen dann entsprechend unserem Rückstand aktualisiert.
Der dritte Stapel ist der einfachste. Wenn alles klar ist, sind die Abschnitte relevant - wir haben sie einfach an die richtige Stelle verschoben.
Vor diesen Besprechungen waren Beschreibungen von Prozessen und Architekturen, Notizen von Testern und Entwicklern sowie Vorfälle im gesamten Raum verteilt. Es gab auch keine Homepage.
Für 6 Stunden Meetings haben wir ein hervorragendes Ergebnis erzielt. Aus dem Chaos haben wir Struktur und Ordnung gebildet. Jetzt können Sie verstehen, wo Sie die Beschreibung von Prozessen, Informationen zur Architektur und zu Vorfällen finden. Und vor allem haben wir jetzt eine Homepage. Hier wurde geschrieben, warum ein Auftragsabwicklungssystem benötigt wird und wer sein Stakeholder ist.
Unser großes System ist an fast allen Geschäftsbereichen beteiligt. Aber wir hatten vorher keinen eigenen Stakeholder. Während wir die Homepage machten, diskutierten wir mit dem CTO, mit wem wir Systemänderungen koordinieren sollten. So wurde ein Kollege ermittelt, der die Verbesserungen priorisierte. Nun sieht es nach einer lustigen Tatsache aus, dass die Erstellung der Homepage zur Entstehung eines Stakeholder geführt hat.
Wie wir die Vorlage verteilt haben
Ähnliche Ergebnisse zur Verwendung der Vorlage wurden von anderen Analysten erhalten, die sie in ihre eigenen Richtungen implementierten. Daher haben wir die meisten Systeme abgedeckt, die an vielen Integrationsprojekten aktiv beteiligt waren.
Wir hatten Teams, deren Systeme häufig an Integrationsprojekten beteiligt waren, aber es gab nicht genügend Beschreibungen darüber. In der Regel war eine Dokumentation erforderlich, sodass die Idee nicht verkauft werden musste.
Wir haben die erfolgreiche Erfahrung gezeigt, Vorlagen auf technische Leiter und Manager solcher Teams anzuwenden. Einige Teams haben anhand unseres Beispiels ihre Dokumentation selbst aufgeräumt, andere haben Analysten um Hilfe gebeten.
Feedback zur Vorlage
Unsere Vorlage ist keine obligatorische oder obligatorische Systembeschreibung. Kollegen nehmen die Vorlage als Grundlage, wenn sie sie benötigen, und bearbeiten sie entsprechend ihren Anforderungen. Beispielsweise übertragen sie den Austausch von Unterabschnitt zu Abschnitt, wenn das System hauptsächlich aus ihnen besteht.
Alle unsere Systeme unterscheiden sich in der Beschreibung, aber die allgemeine Struktur und die allgemeine Logik bleiben erhalten. Jetzt können wir leichter Informationen darüber finden, aus welchen Prozessen das System besteht, über die Systemarchitektur und so weiter.
Bei Lamoda teilen wir gerne Wissen. Wir haben große Integrationsprojekte, die dies motivieren. Wir senden Links zu aktuellen Systembeschreibungen, und Kollegen erhalten die erforderlichen Informationen ohne zusätzliche Fragen an bereits geladene technische Leads.
2 Jahre nach der Erstellung der Vorlage habe ich Kollegen interviewt und von der Mehrheit ein gutes Feedback erhalten. Sie verwenden die Vorlage und bearbeiten die Struktur nach Belieben.
Es gibt aber auch Leute, die denken, dass wir keine Dokumentation und keine Vorlage benötigen. Grundsätzlich ist dies die Argumentation der Teams jener Systeme, in denen es jetzt nicht dringend erforderlich ist, etwas zu dokumentieren.
Sie arbeiten an Systemen, die sich kaum ändern: Es gibt keine Integrationsprojekte, es besteht keine Notwendigkeit, andere Kollegen über diese Systeme zu informieren, und dementsprechend besteht kein Wunsch zu dokumentieren.
Ich denke, bevor Sie ein großes Projekt starten, werden unsere Kultur und die großen Unebenheiten Sie daran erinnern, die Hauptprozesse zu dokumentieren, und sie werden ihre Meinung ändern.
Ratschläge für Sie und diejenigen, die unseren Weg wiederholen möchten
- , , , , . , .
- . , . , .
- , , . : , , . . , .