In jedem unserer sechs Entwicklungsteams ist der Rückstand für etwa zwei Jahre geplant, wobei die fast unvermeidlichen Umgestaltungen, Korrekturen, Funktionen und Wunschliste-Produktologen berücksichtigt werden. Im Inneren kann alles nach Prioritäten verlaufen, und einige große Blöcke werden immer wichtiger. Jetzt werden sie entfernt und dort wird etwas Neues hinzugefügt. Aber es gibt immer ein Verständnis dafür, wo man in den kommenden Monaten graben kann.
Neben einer Reihe von Vorteilen weist ein solches System zwei offensichtliche Nachteile auf:
- Das ist kitschig langweilig, und Langeweile motiviert uns nicht, Code zu schreiben.
- Es häufen sich viele Hypothesen, die nach dem üblichen Verfahren irgendwo am Ende des Rückstands liegen, von denen jedoch jede ein schnelles Ergebnis liefern kann. Oder vielleicht auch nicht. Einige von ihnen sind interessant.
Im normalen Modus ist es schwierig, diese Hypothesen zu analysieren, da Sie die Interaktion eines Produktwissenschaftlers, einer Geschäftsperson (normalerweise eines Vorgesetzten) und einiger weiterer Personen aus anderen Entwicklungsteams benötigen. Das heißt, wenn Sie zwei freie Stunden haben, können Sie dies immer noch nicht tun. Und da wir oft Geld verdienen, indem wir den Weg im Geschäft zu neuen Schnittstellen und neuen Funktionen beschreiten, ist das Testen von Hypothesen das Leben.
Zuerst haben wir uns Zeit im Büro genommen und den gesamten Workflow durchgeführt. Es stellte sich heraus, dass Sie durchschnittliche Lösungen erhalten, wenn Sie so schnell wie möglich prüfen. Um die Qualität zu verbessern, müssen Sie aus der allgemeinen Routine ausbrechen.
Deshalb sind wir schon dreimal in eine fremde Stadt gereist und haben dort gearbeitet.
Warum wird das benötigt?
Wenn Sie bereits Beiträge darüber gelesen haben, wie wir
technische Schulden akkumulieren und was wir damit machen und was der
Entwickler über das Geschäft wissen muss, dann wissen Sie, dass wir von Zeit zu Zeit Dutzende von Hypothesen darüber haben, was zu tun. Etwa die Hälfte stammt von Entwicklern, teils von Geschichten aus anderen Abteilungen und von der Verlagerung von Erfahrungen auf sich selbst, teils von einem Produktwissenschaftler, Gründer oder einfach wegen der Mondphase.
Als nächstes bestimmen wir die Liste der Personen, die zur Lösung der meisten dieser Aufgaben benötigt werden. In der Regel handelt es sich dabei um ein bestimmtes Entwicklungsteam (Flugrichtungen, Eisenbahnen, Touren, Züge, Abenteuer oder Analysen), einen Infrastrukturingenieur, einige Mitarbeiter eines Unternehmens (für ein allgemeines Bild und eine Bewertung der finanziellen Konsistenz), einen Analysten für den Hin- und Hertransfer sowie Mitarbeiter anderer Teams .
Der grundlegende Prozess sah folgendermaßen aus: Nehmen Sie einen Vermarkter, Entwickler, Designer, Analysten und Leiter. Direkt im Büro arrangieren wir einmal pro Woche eine Diskussion über den Sprint über Hypothesen. Ein Tag wird zugewiesen, wenn nur an Hypothesen gearbeitet wird. Wenn die Lösung eines Problems in sechs Stunden abgeschlossen ist, wird sie unterbrochen und verlässt diesen Prozess. Die Aufgabe besteht darin, die schräge Beta in sechs Stunden zu starten. Zehn Hypothesen pro Woche werden für alle Teams getestet.
Dies funktioniert gut, aber die Einschränkungen, die Sie oben gesehen haben.
In einer vollwertigen Entwicklung wird davon ausgegangen, dass der Projektmanager nach den Ergebnissen der Beta zufrieden ist.
Wir haben uns mit dem Projektmanagement-Guru beraten, und mehrere verschiedene Personen sagten sofort, dass innerhalb des Unternehmens Spezialkräfte eingerichtet werden sollten, dh diejenigen, die speziell an der Förderung schneller Hypothesen beteiligt sind. Irgendwo nennt man das eine Entwicklungsgruppe, woanders. Der Punkt ist ein permanenter Hackathon für ein Team.
Es klingt logisch, aber nicht schnell umgesetzt: Es ist notwendig, Experten aus sechs verschiedenen Geschäftsbereichen zu sammeln und den Hauptteams die interessantesten zu entziehen, da alle Rosinen aus dem Brötchen von diesen "Spezialeinheiten" gepflückt werden.
"Special Forces" werden benötigt, denn wenn nicht 100% der Zeit des Entwicklers für die Lösung des Problems aufgewendet wird, wird es schlimmer. Nach Erfahrung zu urteilen. Das konnten wir aber nicht.
Wir nahmen TRIZ und schlugen vor, dass wir uns einen Teil der Zeit auf Hypothesen konzentrieren müssen, einen Teil der Zeit auf die Hauptarbeit „auf lange Sicht“. Was hindert uns daran, wie im Büro? Kontext, ständige Ablenkungen und Vorschriften, ständige Beschäftigung von Teammitgliedern und langes Feedback.
So kamen die Leute auf Hackathons. Sie entfernen alle Büroeinschränkungen und geben Zeit, sich zu konzentrieren. Nur ein Hackathon ist eine kostenlose freiwillige Geschichte, und es geht normalerweise um Training. Entwickler verbringen ihren Samstag, weil sie etwas Neues lernen können und nicht besser, um ihre Arbeit zu erledigen.
Aus diesem Grund haben wir beschlossen, ein Experiment durchzuführen und mit einem Team von 14 Personen nach Istanbul zu fahren.
Istanbul Experiment
Warum Istanbul? Wir brauchten eine Stadt, die den Lebensmittelanforderungen entsprach:
- Holen Sie sich schnell einen Flug ohne häufige Verspätungen (die andere Seite des Planeten passt nicht, Inseln mit unvorhersehbarem Wetter passen nicht).
- Der Zugang ist relativ günstig (Island ist normalerweise nicht geeignet).
- Die Stadt ist zu dieser Jahreszeit attraktiver als Moskau (nicht jeder verlässt gerne das Büro, um nur zu reisen, Omsk ist nicht geeignet, aber die Einwohner dieser Stadt werden mir vergeben).
- Es gibt viele interessante Dinge, für die Sie nicht weit reisen müssen (Norwegen ist nicht geeignet).
- Das Team will einstimmig in diese Stadt gehen.
Wir haben eine Liste geeigneter Städte erstellt und mit allen diskutiert. Es war wichtig, dass alles auf einmal überprüft wurde, und dies war keine schreckliche Pflicht.
Wir beschlossen, dass wir ein großes Treffen in Istanbul haben würden, um zwei freie Tage (bezahlt) zu bekommen, aber wir kaufen selbst Tickets. Diese Logik war für alle geeignet, da dies eine Gelegenheit ist, diese beiden freien Tage an Wochenenden anzudocken und Mitte des Jahres einen Kurzurlaub zu machen.
Nun, am Ende sind wir immer noch Menschen, die sich für Reisen begeistern.
Vor Ort mieteten sie ein großes Haus in der Nähe des Zentrums.
Wer hat das getan? Einer der Entwickler verbrachte seine persönliche Zeit damit, all dies zu organisieren. Ich bin mir nicht sicher, ob dies daran lag, dass er den Prozess des Geschäftsreisens studieren wollte (wir haben ihn gerade beworben) oder einfach daran, dass er allen helfen wollte.
Eine Woche lang warnten sie die
Küche, dass wir unterwegs Snacks brauchten, aber die Lebensmittelbelastung würde in den kommenden Tagen abnehmen.
Wir arbeiteten am Freitagmorgen wie üblich um 12:30 Uhr und gingen gegen 15 Uhr zum Flughafen - Abfahrt um 18 Uhr waren wir dort.
Wir kamen im Haus an, dort war bereits WLAN installiert, ich hatte Drucksachen dabei. Alle mit Firmen-Laptops. Wir aßen, saßen und diskutierten die wichtigsten Dinge. In der Tat war es eine Debatte darüber, was und wie in dem Produkt zu tun ist. Das heißt, wir haben entschieden, was in den Rückstand gelangen soll. Ich wollte „schnelle“ Hypothesen, das Schicksal und die Prioritäten langfristiger Aufgaben diskutieren.
Am nächsten Tag kamen wir zu diesem Format: Am Donnerstag erschien eine Liste problematischer Probleme (zusätzlich zu den bereits bekannten), sodass wir fast den ganzen Freitag darüber sprachen. Es wurden zwei Seiten gefunden: eine war für die Hypothese, die andere war dagegen. Dann arrangierten sie ein Duell, das alle anderen beurteilten. Das heißt, fast wie ein Prozess gegen Hypothesen: Der Staatsanwalt zieht für das, was Sie nicht tun müssen, und der Anwalt zieht für Erfolg und Freude. Zwar haben sie damals nicht daran gedacht, den Staatsanwalt und den Anwalt zu wechseln, und dies ist ein Standardverfahren in solchen Debatten.
Der Arbeitsplan war folgender: Wir wählen die schlechteste Zeit für Spaziergänge (in Istanbul ist dies die Mitte des Tages), wir setzen das Treffen dort ab. Morgen und Abend sind frei, aber wir essen zusammen zu Mittag, dies ist eine Gelegenheit zur Kommunikation. Auf dieser Reise haben einige Leute noch kleine Aufgaben erledigt, das heißt, sie konnten den üblichen Prozess nicht vollständig ausschalten. Andererseits würde ich nicht sagen, dass es eine beträchtliche Zeit gedauert hat.
Ein Beispiel für eine Einlaufhypothese
Die Busse haben kein gesetzlich zugelassenes elektronisches Ticket. Das macht uns unglaublich traurig, denn die Fahrgäste müssen das Formular entweder zu Hause oder auf einem Drucker am Busbahnhof ausdrucken (was manchmal zum Problem wird und manchmal gegen eine Gebühr banal ist). Die Russische Eisenbahn akzeptiert seit langem fast überall die elektronische Registrierung. Flugzeuge werden Ihnen am Flughafen ohne Fragen an den Terminals oder an der Rezeption gedruckt (und an einigen Stellen müssen Sie nicht drucken). Und in Bussen an einigen Orten noch die 70er Jahre der UdSSR.
In der Praxis gibt es progressive Stationen, die nur das Ticket vom Telefon anzeigen. Sie haben diese Daten immer noch in der Erklärung von ihrer Seite, und Sie müssen nur dort und im Dokument der Person nachsehen. Aber es gibt konservative Stationen und solche, gegen die nur "Baba Yaga" ist. Und alle Stationen haben ihre eigenen Formen solcher Formen.
Aus Sicht des Senders ist ein elektronisches Ticket eine Entwicklung. Die Sicherheit der Station erhöht sich, es ist bequemer für die Steuerung und den Fahrer, der Betrieb wird beschleunigt, Papier wird gespart, junge Leute stellen keine Fragen.
In einem Bus vergessen ein oder zwei Fahrgäste die Fahrkarten und werden auf jeden Fall aus den Stationsdaten wiederhergestellt. Aber an einigen Stellen finden sie sehr viel Schuld. Die Praxis hat gezeigt, dass ein Passagier, der anfängt, skandalös zu werden, ihn hereinlässt. Wenn er leise geht (meistens Rentner), müssen wir die Situation bereits verstehen.
Das erste, was wir getan haben, war, konservative Stationen zuzuweisen, und beim Kauf von Tickets machen wir dem Passagier eine separate Benachrichtigung, dass es notwendig ist, ein Ticket auszudrucken: Sie werden ohne dieses Ticket nicht zugelassen.
Dann beschlossen wir, eine „weiße Liste“ solcher Bushaltestellen zu erstellen, an denen die elektronische Registrierung funktioniert. Dreifacher Check: Passagierrückruf, Anruf unseres geheimen Kunden, direkte Frage an die Stationsleitung.
Wenn die Gesetzgebung in Bezug auf das Zulassen elektronischer Tickets hinter der Realität zurückbleibt, es jedoch eine Problemumgehung durch die Ticketwiederherstellung nach Angaben des Senders gibt, warum nicht automatisieren und Ihre eigene schnelle und bequeme Krücke herstellen?
Im Allgemeinen haben wir solche Stationen und markierte Tags auf der Site gefunden.
Die Überprüfung wird von Zeit zu Zeit wiederholt.
Dabei stellte sich heraus, dass es Stationen gibt, die selbst zu einem solchen System gekommen sind, aber den Passagieren nicht wirklich davon erzählt haben. Integratoren dazu gehen auch mit Freude.
Dann haben wir den Stationen, die eine solche Note haben, kleine Boni im System gegeben, so dass es einen wirtschaftlichen Anreiz dafür gibt.
Infolgedessen stellte sich heraus, dass wir schnell (naja, eigentlich nicht wir, aber sie selbst, insbesondere mit unserem Tool) einige Stationen und Carrier kombiniert haben, die bereits selbst eine elektronische Registrierung durchführen.
Das heißt, Sie können nicht nur sitzen und warten, bis alles gesetzlich vorgeschrieben ist, sondern auch herausfinden, wie dies programmgesteuert erfolgt. Und alle. Wir brauchten ein paar Entwickler, Manager, eine Person, die mit Partnern kommuniziert, und einen Designer.
Was ist das Ergebnis?
Verluste der ersten Erfahrung:
- Minus Tickets und Unterkunft.
Vorteile:
- Fast wie ein Urlaub mitten im Jahr.
- Für die nächsten sechs Monate entschieden sie alle Fragen auf einmal.
- Sie konnten gezielt mit dem Team kommunizieren. Aus irgendeinem Grund funktioniert das Büro nicht so.
- Schwer messbare Dinge auf der Ebene der Empfindungen: Die Beziehungen im Team haben sich verändert.
- Wir haben unser eigenes Produkt von außen betrachtet: Schließlich haben wir unsere Werkzeuge (und andere Teams) die ganze Zeit verwendet und uns einige Funktionen „on the fly“ ausgedacht.
- Sie fuhren einfach auf eine Reise, was für ein Unternehmen, das sich mit Reisen befasst, logisch ist.
- Die "älteren" Genossen lehrten die "Junees", rational zu denken, nicht nur in der Entwicklung, sondern auch in der Tagesplanung. Dies ist sehr unbedeutend, aber der Erfahrungsaustausch ist zu spüren.
- Sie konnten Remote-Entwickler in die Kommunikation einbeziehen, was normalerweise nicht ausreichte.
Nezhdanchiki:- Wir erfuhren, dass die beiden Mädchen katastrophale Probleme mit der Orientierung an der Region hatten: Sie waren verloren, wir fanden sie, ließen sie nie los. Dies störte die Arbeitssitzung fast.
- Der Entwickler, der die Organisation übernahm, zeigte eine Manifestation der situativen Führung. Nicht ganz erwartet, Eychar und Anführer waren überrascht.
- Wir haben herausgefunden, dass unsere Kollegin Misha coole Bilder macht. Er nahm die Kamera, nahm alles ab und präsentierte Papierabzüge. Auswendig.
Es ist sehr schwierig, auf Reisen zu synchronisieren, und dies ist noch kein Prozess geworden. Aber ich denke es wird, weil die Vorteile offensichtlich sind. Jetzt verwenden wir beide Ansätze: Wir verwenden die Zeit der Teams im Büro, um Hypothesen zu analysieren und gelegentlich zu verlassen. Abfahrten sind mehr erforderlich, um das Sehen und ungleiche Aufgaben zu bestimmen und im Büro „nicht zu stören“, um Hypothesen im persönlichen Hackathon-Modus einzubrechen.
In der ersten Iteration wurden sieben Hypothesen ausgewählt und getestet, von denen drei Ergebnisse zeigten. Zum Beispiel in Richtung Busse.
In der Dateneingabephase zeigten die Passagiere ein Schild mit der Aufschrift „Letzter Ticketkauf für diesen Flug vor N Minuten“. Auf der mobilen Version zeigte A / B + N% zum Umsatz, auf dem Desktop gibt es keine signifikanten Ergebnisse. Wir haben das Suchformular auf der mobilen Version der Seiten mit dem Zeitplan erweitert - als Ergebnis haben wir + NN% für den Umsatz erhalten. Wir erhalten Daten von Kunden, um diese zurückgeben zu können. Bei leeren Ausgaben begannen sie, Benutzer-E-Mails zu sammeln, um Busse zu senden. Wenn sie in die Richtung erscheinen, gibt es Hunderte von ihnen pro Woche. Basierend auf den Benutzerpräferenzen sammeln wir Angebote im Newsletter. Die Ergebnisse. Treffer: 91–93%. Verkäufe von denen, die den Brief geöffnet haben: + NN, 3% (signifikant). Aber! Die Leute fahren Busse in die gleichen Richtungen, was bedeutet, dass die Vorhersagen gleich sind. Bisher hat sich herausgestellt, dass die Mailings immer gleich sind. Wir werden überlegen, wie wir diversifizieren können.
Zu dieser Zeit gab es typische Aufgaben im Backlog, zum Beispiel eine solche Routine:
- Führen Sie zwei Integrationen mit Bushaltestellen aus.
- Aktualisieren Sie drei aktuelle Integrationen.
- Integrieren Sie litauische Busunternehmen.
- Machen Sie Konnektoren für Ihr Konto 16 Träger.
Im Allgemeinen funktioniert es, aber wir würden gerne Ihre Erfahrung hören, „isoliert“ vom Büro zu arbeiten und irgendwohin zu reisen, wenn Sie sie hätten.