👌🏾 🛶 🤰🏿 Startup innerhalb des Unternehmens 💊 👩‍❤️‍👩 🤾

Hallo, mein Name ist Andrey Vanin und ich entwickle und lanciere Brokerage- und Fintech-Produkte. Heute ist genau ein Jahr vergangen, seit ich bei BCS arbeite, wo wir in einem Team von acht Mitarbeitern das Projekt fintarget.ru entwickeln.

Im Folgenden finden Sie eine (nicht) große Geschichte darüber, wie Sie ein Startup in einem großen Unternehmen implementieren, auf den Markt bringen und nicht unter Tonnen von Memos und Genehmigungen ausbrennen.

Bild

Intro

Vergessen Sie alle agilen Manifeste und schaffen Sie eine komfortable Arbeitsumgebung, wenn Sie Ergebnisse erzielen möchten. Bei der Verwaltung hoffnungsloser Projekte treten nicht die Anwesenheit eines PlayStation-Büros und die obligatorischen Scrum-Rituale in den Vordergrund, sondern die Ambitionen und die persönliche Motivation des Teams.

Wenn Ihr Entwickler der Beste sein möchte, spielt er kein Airhockey und es ist ihm egal, ob es im Büro einen Ruheraum gibt (es gibt einen Spoiler). Wenn Ihr Projekt Respekt erlangen möchte, wird er lernen, auf dem Kopf zu gehen und jedes Problem zu lösen, sei es eine weitere unvorstellbare Aufgabe, einen kaputten Stuhl zu ersetzen, oder die Notwendigkeit, einen Prozess zu koordinieren, der nicht vorhanden ist.

Wenn der Front-End-Anbieter eine ausstehende Hypothek hat, bieten Sie ihm eine Auswahl an - entweder PS4 oder plus einen Bonus in Höhe des gleichen Betrags. Ihre Aufgabe ist es nicht, ein Kindermädchen im Projekt zu sein, sondern das Ergebnis so sicherzustellen, dass sowohl das Team als auch der Kunde zufrieden sind. Auch wenn es nicht möglich ist.

Auf die Plätze

Ich bin Anfang April 2019 in das Unternehmen eingetreten. Zwei Entwickler saßen im Büro, ein Kunde und ein halber Projektmanager, der noch nie zuvor an Entwicklungsprojekten beteiligt war. Wir mussten schnell ein System von Grund auf neu entwickeln, was sie drei- oder viermal zuvor versucht hatten, aber in fünf Jahren konnte niemand ein vernünftiges und benutzerfreundliches Produkt auf den Markt bringen.

Auf meinem Schreibtisch lag ein Ausdruck einer Präsentation von fünf Folien - wie alles gut wird, wie es aussehen wird, theoretische Architektur, wie viel Geld es bringen sollte und wie viel Geld es kosten wird. Und kein Wort über das Produkt, keine einzige Erwähnung verwandter Einheiten, kein einziger Prozess und kein Verständnis dafür, wie sich das alles entwickeln sollte.

Aber die Frist wurde angekündigt - im September zu veröffentlichen. Und wir setzten uns zur Arbeit.

Doppelzapfen

Bei der ersten Version des Produkts wurde eine interne Infrastruktur ohne eigene Front-End-Lösung erstellt. Es wurde davon ausgegangen, dass das Produkt im Regal der mobilen Anwendung präsentiert wird und meine beiden Entwickler nur das Backend und die Logistik des Informationsflusses unterstützen. Dieser Ansatz garantierte das Scheitern des Projekts bereits im Juni, da das Anwendungsteam in der parallelen Geschäftsrichtung erhebliche Änderungen durchlief und sein Rückstand bis zum Jahresende sehr neblig war. Und wir haben uns entschlossen, ein MVP-Produkt auf der aktuellen Web-Front des Unternehmens zu entwickeln. Dies war die erste Runde.

Die einfachste Lösung in dieser Situation besteht darin, den UX-Designer und Layout-Designer auszulagern, Bleistift-Layouts zu zeichnen, das Design zu erhalten und es der Entwicklung zu übergeben. Aber nur unabhängige Startups können. Wir sind ein Startup in einem großen Unternehmen, in dem der Designer nicht bar bezahlen kann, und alle Vorarbeiten müssen in Abstimmung mit Marketing und Anwälten erfolgen. Es war schwieriger, hat aber die Entwicklung des Kernels nicht gestoppt, also haben wir uns dem Marketing zugewandt.

Bild

Fast sofort trat das Problem der Schichtung des Gesamtbildes auf - das Marketing wusste nicht, was wir technisch machten, und die Entwickler verstanden nicht, wie alles hätte aussehen sollen. Vor den Maiferien öffneten wir zuerst den Zusammenfluss und setzten uns, um die Bildschirme zu beschreiben.

Bis Mitte Mai gab es nur in meinem Kopf und auf etwa fünfzig Seiten, auf denen die Algorithmen und Bildschirme beschrieben wurden, ein detailliertes Verständnis der Funktionsweise des Produkts. Es war ein großes Risiko (der Trick wurde von Profis gemacht! Nicht wiederholen - das ist gefährlich!), Aber gleichzeitig wusste jedes Mitglied des Teams, was zu tun war und wurde zwei Monate im Voraus mit Arbeit beladen.

Das Projekt rauchte, koordinierte die nächste Version der Architektur und die Interaktion der Systeme, der Teamleiter ging hinein und fing an, den Code auszuwählen, und der dritte Entwickler (der am selben Tag bei mir eingestellt wurde) verstand fast einen Monat lang die Integrationsmechanismen. Und das war der schwierigste Teil. Das Unternehmen verfügt über zwei Dutzend Systeme, von denen sechs integriert werden mussten.
Irgendwann wurde klar, dass der ernannte Teamleiter nicht in das Tempo des Teams passte und ersetzt werden musste. Der zweite Entwickler nahm seinen Platz ein, und für die freie Stelle nahmen wir einen Programmierer mit dem Hintergrund eines Kandidaten der Naturwissenschaften. Mit Blick auf die Zukunft werde ich sagen, dass es uns gerettet hat.

Fast sofort wurde jedoch klar, dass wir auch nicht in den internen Web-Schaltkreis passen können, und der Kunde stimmte zu diesem Zeitpunkt der einzigen Einsparungslösung zu - wir erstellen mit unserem Branding- und Support-Team eine eigene webbasierte Produktfront. Innerhalb der Abteilung haben wir hastig einen Wettbewerb um den Namen des Produkts angekündigt und uns letztendlich für die Option entschieden, die von Anfang an geäußert wurde, da es in meinem persönlichen Sparschwein eine gute Domain gab und es für jeden nichts Besseres gab, um abzustimmen und kreativ zu sein. So erschien die Marke fintarget.ru. Und das war die zweite wichtige Wendung.

Über das Team

Millionen von Büchern zum Entwicklungsmanagement bieten Ihnen Standardvorlagen für die Teamarbeit und Standardprozesse, wobei Sie vergessen, dass jedes Team einzigartig ist und einen individuellen Ansatz erfordert.

Viele Faktoren können die Arbeit und Kommunikation im Team beeinflussen: Alter, Familienstand und sogar Vorlieben in der Musik. Trotzdem achten die Produkte fast nie darauf und konzentrieren sich in der Regel auf Nebenfaktoren - die Lage und Größe des Tisches, die Jalousien an den Fenstern, Kopfhörer mit Belüftung und andere Kleinigkeiten, die "nicht nerven".

Die Sterne kamen zusammen und wir fanden eine Kette von Beziehungen, in denen jeder immer etwas anderes als Arbeit zu besprechen hatte. Und wenn Sie Kommunikation aufgebaut haben, können Sie ruhig mit der Rollenverteilung umgehen.

In der Phase des Debuggens von Teamprozessen haben wir ein derart hybrides Schema erstellt, dass es in keine der vorhandenen Vorlagen passt.

Zuerst haben wir den Analysten verlassen. Absolut. Die Rolle des Analysten wird zwischen dem Teamleiter und dem Product Owner verteilt, und die Details der Prozesse werden während des Testens des Service modernisiert und festgelegt. Dies ist die kontinuierliche Verbesserung des Produkts, über das die Befürworter von Edge gerne sprechen.

ZweitensWir haben die Grenze zwischen den Befugnissen des Produktmanagers in der Person des Kunden und des Produktbesitzers aufgehoben. Zwei Mitarbeiter üben online zwei Rollen aus, ohne die Autorität einzuschränken und ohne Angst vor Verantwortung bei der Entscheidungsfindung zu haben. Es war besonders interessant, Entwickler zu beobachten, die sahen, wie der Eigentümer und Manager heiser über CJM oder das Seitenlayout diskutierten. Dies hat übrigens die Beteiligung des Teams stark beeinflusst.

Drittens haben wir in der Kernel-Entwicklungsphase Sprints mit einem harten Rückstand vollständig aufgegeben und einen iterativen Ansatz verwendet, der auf der Verfeinerung und Hinzufügung von Funktionen während der Entwicklung basiert. Erinnern Sie sich, wie JPEG-Bilder zu Beginn des Jahrhunderts in den Browser geladen wurden? So haben wir den Produktkern entwickelt.

Viertenshaben wir (zwangsweise) die Funktionalität der Entwickler streng abgegrenzt. Für jeden Sektor wurde ein separater Microservice-Entwickler zugewiesen, der nur für sein Segment verantwortlich war. Wir haben fünf solcher Segmente im Projekt: Integration in interne Systeme, Integration in Austauschsysteme, Kernel-Produktalgorithmen, OpenAPI und Front.

Und fünftens waren alle Ressourcen des Projektmanagers unserer Abteilung, die wir hatten, ausschließlich darauf ausgerichtet, externe Teams zu verwalten, die für die Fertigstellung der Systeme verantwortlich sind, in die wir integrieren müssen, und alle Verfahren zur Koordination und Integration eines Startups in die Infrastruktur des Unternehmens zu implementieren.

Dieser Projektheld verbrachte drei Monate lang mehr als eineinhalbhundert verschiedene Dienstleistungen, beschrieb und dokumentierte ein Dutzend neuer Prozesse und war es, der in der Praxis die populäre Theorie der Unmöglichkeit widerlegte, Startups in großen Unternehmen zu gründen.

Dieser Ansatz ermöglichte es uns, den Aufgabenpool zu planen, alle Anforderungen für MVP festzulegen und insgesamt, als klar wurde, dass der Mechanismus funktionierte, ging ich als Oouner fast ruhig in den Urlaub. Es war Juli, und wie in einem berühmten Projektmanagement-Roman geschrieben steht, muss man nur zuschauen, wenn alle Prozesse definiert sind, Aufgaben und Fristen bekannt sind.

Am ersten August hatten wir den Kernel des Systems zusammengestellt, fast alle Vorbereitungsarbeiten wurden durchgeführt, die Beta-Version von OpenAPI wurde zusammengestellt, die Front wurde gezeichnet und erstellt, und es blieb noch eine Woche, um die Algorithmen zu polieren und auf das Front-End zu warten, das "nur" alles sammeln sollte Dies ist ein funktionierender MVP.

Ereignisbäume

Es ist möglich, die Infrastruktur des Startprojekts in einer geschlossenen Testschleife so oft zu sammeln, wie Sie möchten, aber das Projekt wird ohne die Integration in die Schlüsselsysteme des Unternehmens niemals gestartet. Dies ist das Hauptproblem der Arbeit von Startups in Unternehmen: Mehr als 80% der Projekte sterben, ohne die Möglichkeit zu finden, alle Unternehmensanforderungen und -vorschriften zu integrieren und einzuhalten.

Im Maklergeschäft gibt es mehrere solcher Systeme: Handels- und Buchhaltungssysteme, Integrationsbusse, CRM, einen Katalog von Diensten und ein Dutzend weitere Systeme und Mechanismen, die von Informationssicherheitsdiensten sehr streng reguliert und überwacht werden.
Integration ohne Übertreibung war der schwerwiegendste Test für das Projekt und das Team, und wir mussten insgesamt etwa drei Mannmonate Arbeit daran töten.

Eine Schlüsselrolle in diesem Prozess spielte die Regel „Zuerst alle Regeln brechen“. Wir haben mehrere parallele Integrationsszenarien gleichzeitig initiiert - von den offiziellsten (über den Projektpass, die Koordination der Architektur, die Erstellung einer Testschaltung und die Übertragung aller Anweisungen für die Freigaberichtlinie und den Support) bis zu den inoffiziellsten -, die wir in der Kampfschaltung entwickeln, von außen geschlossen und das System selbst testen Maklerkonten.

Die Details dieser Geschichte verdienen einen separaten Artikel, aber der Schlüssel, der erreicht wurde, besteht aus mehreren Punkten:

. « – – crm– – – – », , ,
- « - », « » .
Der Testansatz „Preprod“ hat die Beteiligung von Entwicklern erheblich erhöht, es ermöglicht, UX in der Praxis zu testen, bevor das Produkt an die Außenwelt freigegeben wird, und vor allem für das Projekt den korrekten Betrieb der Systemalgorithmen auf realen Markt- und Kundendaten zu debuggen.

Und das Wichtigste: Berücksichtigen Sie niemals Zeitverschwendung bei parallelen Prozessen während der Integration. Wie bei Werbebudgets wissen Sie immer noch nie, welche Hälfte des Budgets Sie vergeblich ausgegeben haben. Erstellen Sie einfach einen Baum mit Optionen und starten Sie die Prozesse: Einige Zweige verschwinden von selbst als hoffnungslos, andere verschmelzen zu einem, und wenn einer von ihnen Sie zum Ergebnis führt, ist dies nur Ihr Championpfad. Da in einem anderen Projekt dasselbe Szenario möglicherweise nicht funktioniert.

Bild

Was ist das Ergebnis

Das funktionierende MVP des Projekts wurde Ende August zusammengestellt. Parallel dazu wurde eine Version des Emulators für die Akkreditierung des Programms bei NAUFOR implementiert und 150 Seiten unterstützender Dokumentation für die Registrierung von Software geschrieben. Die ersten echten Transaktionen auf dem System zu den freudigen Schreien des Teams fanden am 31. August statt. Gesetzliche Änderungen an Unternehmensdokumenten und Kundenbestimmungen traten am 1. September in Kraft. Bevor das System akkreditiert wurde, hatten wir Zeit, die Schnittstellen zu debuggen und zu lecken.

In MVP hatten wir weder Währungskonten noch Futures oder sogar ein eigenes Brokerage-Konto, aber die Schlüsselaufgabe war erledigt - die Infrastruktur wurde implementiert, das Preprod wurde zu einem Produkt, der Kundenservice wurde implementiert.

Am 17. September wurde die Fintarget-Software in das Register der akkreditierten Auto-Follow-Programme aufgenommen, und schon am nächsten Tag sahen wir die ersten Kunden, die sich mit dem System verbanden. Es gab noch viel Arbeit, um die Funktionalität zu erweitern und den MVP in den Zustand eines vollwertigen und autarken Produkts zu versetzen, aber dies ist eine völlig andere und weniger interessante Geschichte: Veröffentlichungen, Sprints, Rückstände und endlose Kundenanalysen.