it-swarm.com.de

Überzeugende "agile" Produktmanager vom Wert der Planung

Wurde vor einigen Monaten technischer Leiter eines Startups. Die Softwareentwicklung befindet sich im Organigramm unter Produkt.

Selbst nach Startstandards ist die Codebasis, die ich geerbt habe, schlecht. Beispiel: Das Entwicklerteam hat drei Wochen gebraucht, um den statischen Text in der Fußzeile der Site zu aktualisieren, und selbst dann haben sie nach 80% der Seiten aufgegeben. Durch das Aktualisieren der "wiederverwendbaren Komponente" der Fußzeile werden einige der Vorlagen beschädigt. Sie können nicht sagen, warum, obwohl sie seit Monaten mit dem Code arbeiten. Die ursprünglichen Auftragnehmer sind natürlich längst verschwunden und haben keine Dokumente zurückgelassen.

Ich habe mich eingekauft, um Dinge aufzuräumen, Dinge aufzuschreiben und technische Schulden abzubauen, aber natürlich zuerst müssen wir eine neue mittelgroße Funktion erstellen, die das Ganze einbezieht Stapel. Wir wissen, dass dies ein Schritt in Richtung anderer größerer Funktionen ist. Die Codebasis scheint voll von verlassenen, halbfertigen Funktionen zu sein, daher habe ich mich für einen der Entwickler angemeldet, um fünf Tage lang den Code zu erkunden und verschiedene Ansätze zu entwickeln, anstatt die erste Idee in jemandes Kopf zu verfolgen.

Am dritten von fünf Tagen bat der Produktmanager den Entwickler um Fortschritt - kurze Antwort, hier sind einige Ideen, die wir machen könnten, aber keine Ahnung haben, welche sind noch gut, da der Code ein Chaos ist, gab es am zweiten Tag einen Site-Ausfall, und er braucht mehr Zeit. An diesem Abend verschrottete der Manager den Spike und ersetzte ihn durch einen "Prototyp", basierend auf einer der Ideen. Dabei haben sie, der Produktmanager, vor Ort mehrere technische Entscheidungen getroffen und mich, den technischen Leiter, in den Schatten gestellt. Aufgrund dieses und anderer Vorfälle bin ich mir ziemlich sicher, dass der "Prototyp" schnell live gehen wird, nach einem kurzen "Sieht das für Sie in Ordnung aus?" Test auf dem Macbook des Entwicklers.

Ich bekomme das ganze "agile Startup" Ding. Ich habe die entspannte Einstellung zum Risiko und die Notwendigkeit, letzte Woche etwas irgendetwas in die Hände der Benutzer zu bekommen. Es macht mir nichts aus, wenn ich einen Rang habe.

Aber ... mir wurde ausdrücklich gesagt "Wir sind ein Startup, wir sind nicht in dieser Untersuchung ****" - "Forschung" wurde gesprochen, als wäre es ein schmutziges Wort. Ich schätze auch mehr, warum die Codebasis so ist, wie sie ist.

Alte Hasen werden feststellen, dass dies so aussieht, als ob Produkt schlecht ist, weil Prozesse schlecht sind; möglicherweise aus der org Kultur arm sein. In den Schützengräben gestanden, sieht dies wie der schlimmste Fall aus: "Agile Mittel machen es wieder gut, aus unseren Fehlern zu lernen ist etwas für Verlierer!" das habe ich gesehen.

Wie kann ich den Manager davon überzeugen, dass einige Planungen und Überlegungen wertvoll sind? Oder sollte ich mich vielleicht selbst davon überzeugen , dass dieses agile Startup so sein sollte?

9
gotrikoketri

Es gibt ein paar wichtige Punkte, die Sie aus dem Weg räumen sollten:

  • Agile! = Faule Entwicklung
  • Spikes und Prototypen sind keine austauschbaren Ideen
  • Nichts, was Sie oben beschrieben haben, wird von Agile oder Scrum vorgeschrieben

Bei Ihrer Frage, wie Sie Ihren Fall vertreten sollen, hängt es von ihrer tatsächlichen Motivation ab. Wenn sie die Auswirkungen ihrer Aktivitäten nicht verstehen, können Sie sich mit den Auswirkungen technischer Schulden auf die Fähigkeit befassen, schnell neue Funktionen bereitzustellen. Wenn sie andererseits einfach "wir sind agil" verwenden, um schlechte Entwicklungs- und Geschäftspraktiken zu vertuschen, gibt es kein Argument, das die Dinge ändern könnte, weil sie es bereits wissen und es ihnen egal ist. Jetzt habe ich viele von beiden gesehen, daher möchte ich Sie ermutigen, keine anzunehmen oder, wenn Sie müssen, die optimistische Option zu wählen, um zu beginnen.

Technische Schulden

Die Art und Weise, wie ich den größten Erfolg bei der Argumentation für technische Schulden gesehen habe, ist folgende:

Sie haben X Zeit in einem Sprint. Nehmen wir an, 40% Ihrer Zeit entfallen auf die Verwaltung Ihrer technischen Schulden und 60% auf neue Funktionen. Wenn wir in der Entwicklung großartig sind, wächst dieser Haufen vielleicht leicht. Lassen Sie uns eine Nummer auswählen und sie vielleicht 1-2% pro Sprint nennen. In einem Startup müssen wir uns jedoch schnell drehen und viel Zeit haben wir versehentlich eine Menge technischer Schulden, so dass selbst ein gutes Startup-Team in einem Sprint weitere 5-10% verursachen kann. Wenn Sie nicht versuchen, gut zu arbeiten, kann es natürlich viel schneller aufgebaut werden. Wenn Sie diese technischen Schulden nicht bereinigen, baut sie sich einfach auf. Bald dauert eine Änderung, die ein oder zwei Tage dauern sollte, 3 Wochen (kommt Ihnen bekannt vor)?

An diesem Punkt können Sie sich als hilfreich oder als Curmudgeon herausstellen, und es hängt wirklich davon ab, ob Sie sich in sie einfühlen. Es wäre großartig, wenn Sie einfach anhalten und alte Probleme beheben könnten, aber die Organisation wird dies wahrscheinlich nicht tun. Lassen Sie uns also eine neue Lösung finden. Erstens müssen Sie aufhören, so schnell technische Schulden zu machen. Effektive Qualitätsmaßnahmen, einschließlich Komponententests, Codestandards und Codeüberprüfungen, sind von entscheidender Bedeutung. Dann müssen Sie damit beginnen, die bereits entstandenen Schulden zu begleichen. Vielleicht kann das Unternehmen die Code-Bereinigung freitags mit Eis aufnehmen. Durch die Ausrichtung auf Bereiche, in denen die Entwicklung der meisten neuen Funktionen durchgeführt werden muss, wird auch gezeigt, wie sich eine sauberere Codebasis mit einer schnelleren Bereitstellung von Funktionen amortisiert.

Planung/Analyse

In Ihrer Frage scheinen Sie technische Schulden und Analysen in Einklang zu bringen. Falls es nützlich ist, müssen Sie sie möglicherweise auch verkaufen. Dazu ist es wichtig zu verstehen, dass es komplizierte und komplexe Probleme gibt. Bei einem komplizierten Problem kann ein Experte das Problem in kurzer Zeit analysieren und eine gute Lösung finden. Die beste Datenstruktur zum Speichern von Einträgen aus einem bekannten Formular ist ein gutes Beispiel dafür. Bei komplexen Problemen gibt es viele unbekannte Faktoren oder die Art und Weise, wie sich die verschiedenen Faktoren gegenseitig beeinflussen, ist schwer vorherzusagen. Dies erfordert Experimente und Beobachtungsergebnisse. Keine Analyse führt Sie zur Antwort. Sie müssen dort einsteigen und etwas ausprobieren. Es ist wichtig zu wissen, welche Art von Problem Sie lösen.

Dies unterscheidet sich auch deutlich von der iterativen Entwicklung, bei der es eher darum geht, Teile des Problems zu lösen, als ein ganzes großes Problem auf einmal anzugehen.

Hoffe das hilft. Viel Glück und ich hoffe, die Leute, mit denen Sie zusammenarbeiten, sind sich der Auswirkungen ihrer Handlungen einfach nicht bewusst.

11
Daniel

Sie können nicht, weil es keinen Wert für sie in der Planung gibt.

Die PMs erhalten eine Gutschrift für die termingerechte und budgetgerechte Fertigstellung von Projekten, nicht dafür, wie gut das Produkt funktioniert.

Sie können sie dazu bringen, weitere Anforderungen hinzuzufügen, bevor die Arbeit beginnt. zB "funktioniert auf einem PC".

Es sind die differenzierteren Anforderungen, die zu guten Programmierpraktiken führen. Nicht "Qualität" oder "es richtig machen"

Es hört sich so an, als ob Sie Anforderungen wie "Funktioniert mit dem Vorlagensystem" und "Bereitstellungen ohne Ausfallzeit" benötigen, um einen Teil des Refactorings voranzutreiben, das Sie durchführen möchten.

Wenn Sie die richtigen Anforderungen erfüllen können, wird das Korrigieren des Codes zum Projekt und die PMs arbeiten für Sie und nicht gegen Sie.

4
Ewan

"Wie kann ich überzeugen ..." Fragen setzen voraus, dass Sie Recht haben und der Produktmanager Unrecht hat. Aus der Formulierung Ihrer Frage geht nicht hervor, dass Sie große Anstrengungen unternommen haben, um die Argumentation des Produktmanagers zu verstehen. Bedenken Sie jedoch, dass der Produktmanager möglicherweise ein größeres Bild hat. Als Entwickler und technischer Leiter ist es Ihre Pflicht, die geschäftlichen Einschränkungen zu verstehen, unter denen Sie tätig sind.

Während Sie die Geschichte erklärten, sparte der Produktmanager zwei Tage Recherche, indem er eine schnelle Entscheidung traf. Sie geben auch an, dass Sie "die Notwendigkeit verstehen, letzte Woche etwas in die Hände der Benutzer zu bekommen". Angesichts dieser Voraussetzungen scheint der Produktmanager den richtigen Anruf getätigt zu haben.

Angesichts der Tatsache, dass Sie haben Buy-In, um einige Ressourcen für die Bereinigung zu verwenden, scheint es, dass das Management do versteht, dass solche schnellen und schmutzigen Lösungen einen Kompromiss aufweisen . Was möchten Sie sie überzeugen? Dass Sie immer drei Tage für Forschung aufwenden sollten, unabhängig von der Kritikalität des zu entwickelnden Fixes oder Features?

Die Markteinführungszeit kann für ein Startup von entscheidender Bedeutung sein. Nehmen wir an, ein Tech-Startup befindet sich an einem kritischen Punkt. Wenn Sie das Benutzerwachstum einen Monat lang fortsetzen, erhalten Sie erhebliche Neuinvestitionen. Wenn das Wachstum stagniert, muss das Geschäft geschlossen werden. Unter solchen Umständen akzeptiert ein Startup bereitwillig technische Schulden - Sie optimieren die schnelle Bereitstellung von Funktionen auf Kosten der langfristigen Wartbarkeit. Wenn das Geschäft geschlossen wird, ist die Frage der langfristigen Wartbarkeit umstritten. Wenn es erfolgreich wird, können Sie mehr Entwickler einstellen, um das Chaos zu beseitigen.

Ich denke, das erste, was Sie tun sollten, ist, mit dem Produktmanager zu sprechen, um die Einschränkungen und Prioritäten, unter denen Sie arbeiten, besser zu verstehen.

2
JacquesB

Schau genau hin:

(enter image description here

Dort! Ein Bild sagt mehr als tausend Worte, sagen sie nicht? Nehmen Sie dieses Diagramm nicht zum Nennwert, es ist nur eine Illustration, sondern von sehr spezifischen Dingen .

  • Der erste Fall (Linie, die am unteren Rand des gestreiften Bereichs verläuft) stellt den Fall dar, in dem Sie sorgfältig beginnen, geeignete Muster und Praktiken anwenden, die erforderliche Zeit für die Vorausplanung und das Entwerfen aufwenden. Sie vermeiden technische Schulden, indem Sie zusätzlich wenig Zeit aufwenden, um sie "bei der Geburt" abzuzahlen, damit Sie nicht " Zinsen " ansammeln.

  • Der zweite Fall (Linie am oberen Rand des gestreiften Bereichs) stellt den Fall dar, in dem Sie beginnen nachlässig unter viel Druck, so dass Sie jetzt Ergebnisse und später aufräumen müssen. In diesem Fall können Sie, egal wie erfahren Sie und Ihr Team sind, nur die Zinsen für die technischen Schulden niedrig halten. Aber es sammelt sich im Laufe der Zeit an.

Ich konzentriere mich auf diese Fälle, weil Sie unter den zweiten Fall zu fallen scheinen. Ich würde sogar sagen, dass dies ein eher typischer "Deal" mit Startups ist. Entweder nehmen Sie sich Zeit (und Ressourcen), um zu glänzen, oder Sie erzielen schnell Ergebnisse und zahlen später dafür (aber zumindest haben Sie noch Ihren Job).

Der Punkt ist so einfach wie folgt: Wenn any Startpunkt gegeben ist, gibt es in der Zukunft einen kritischen Moment, von dem aus Sie ab diesem Zeitpunkt Fangen Sie an zu leiden, dass ernsthaft Ihre Produktivität beeinträchtigt hat, indem Sie "Forschung" ignoriert haben (wirklich ein Schlagwort, wenn Sie sich nur die Zeit nehmen, Ihre technischen Schulden zu reduzieren oder sie die ganze Zeit zu vermeiden). Dementsprechend werden Sie natürlich, während Sie "Forschung" ignorieren, für eine Weile mehr Arbeit erledigen, aber diese Zeit ist nicht ewig. Diese Tatsache wird durch den orange-y-gestreiften Bereich in der obigen Tabelle dargestellt.

Egal wie hart man seinen Kopf gegen eine Wand schlägt, an dieser Tatsache führt kein Weg vorbei. Technische Schulden akkumulieren Zinsen . Ein Problem, dessen Behebung x Stunden dauert, dauert y> = x Stunden, um es später mit dem "> "viel wahrscheinlicher sein und der Unterschied wächst mit der Zeit.

Alles, was zu tun ist, ist, ernsthafte Überlegungen anzustellen, ob diese kritische Zeit in der Zukunft näher ist oder nicht, als einige äußerst wichtige Frist) . Wenn Sie Ihre zukünftige Produktivität beeinträchtigen möchten, müssen Sie sehr gut auf $ haben, um dies zu tun! Denken Sie zum Beispiel etwas in der Art eines Alles-oder-Nichts-Deals.

Denken Sie daran, dass das Ignorieren von Forschung manchmal das " weise " sein kann. Beispielsweise benötigt Ihr Unternehmen möglicherweise Ressourcen, die voraussichtlich vor t-kritisch , aber definitiv nicht später, verfügbar sein werden. Schmerzhafter Aufholprozess ist also oft besser als gar kein Unternehmen.

Dies ist natürlich das schwierige Problem, mit dem die Manager umgehen müssen, also ist es ihre Aufgabe, aber sie müssen die Fakten sehr gut verstehen. Wenn Sie ein wenig darüber nachdenken, können Sie möglicherweise einige tatsächliche Zahlen annähern und mit Ihrem Manager über diese Zahlen darüber diskutieren, wie Sie vorgehen sind jenseits dieses kritischen Zeitpunkts und Sie bereiten sich ständig darauf vor, die Produktivität immer weiter zu senken.

Wenn sich Ihr Manager Zeit nimmt, um zumindest auf das zu achten, was Sie sagen/zeigen, kann ein eingängiges Diagramm den Punkt weitaus besser verstehen als jede Menge gesprochener Wörter.

Aktualisieren

Aufgrund einiger Kommentare, die neue Fragen aufwerfen, muss festgestellt werden, dass die obige Tabelle nur eine (n zu) vereinfachende Annäherung ist. Das Schätzen der ungefähren Position dieses t-kritischen Augenblicks ist ein sehr schwieriges Problem, aber nicht das Problem, das wir normalerweise zu lösen versuchen (dies ist nach dem Prinzip der Einzelverantwortung a Problem des Managements). Was wir anstreben sollten , ist zu wissen, auf welcher Seite der Zeitachse wir uns in Bezug auf diesen Moment zu einem bestimmten Zeitpunkt befinden.

Außerdem stellt dieses Diagramm einfach dar, was das Management wissen muss: "Wenn wir die Untersuchung **** ignorieren, recherchieren (und alle anderen Schlüsselwörter, die nur Aliase für den richtigen Code Housekeeping sind), wir wird nie so gut wie wir hätte sein können, wenn wir am Anfang nur ein bisschen mehr Zeit verbracht hätten ". Wenn eines der Ambitionen/Ziele/Notwendigkeiten des Unternehmens ein hochflexibles und leistungsstarkes Tech-Team ist, kann es angesichts der aktuellen Codebasis/des aktuellen Produktstatus genauso gut früher fallen gelassen werden, anstatt mehr Ressourcen für einen verlorenen Fall zu verschwenden.

Auf dieser Grundlage könnte der Dialog folgendermaßen aussehen:

  • Sehen Sie diese erste Zeile hoch oben, "Spitzenproduktivität mit Forschung"? Dort werden wir wahrscheinlich nie in der Nähe sein.
  • Siehe diese zweite Zeile unten, "Spitzenproduktivität ohne Forschung"? Hier werden wir bestenfalls sein, das heißt, wenn wir Glück haben . Versuchen Sie nicht, dies in metrischen Einheiten zu messen, da die vertikale Skala um mehrere Größenordnungen verkleinert wird!
  • Wenn das Überleben des Unternehmens davon abhängt, " lebensfähig " über der unteren Zeile zu sein, sollten wir es jetzt einfach abbrechen, da wir kann, um Ressourcen zu sparen und verschiedene Karrieremöglichkeiten in Betracht zu ziehen.
  • So wie wir uns gerade bewegen, sind wir past t-kritisch , also um sogar zu sein) fähig um irgendwann in der Zukunft über die 2. Linie zu klettern, müssen wir arbeiten sehr hart bis zuerst die virtuellen Arbeitsgewinne , die durch den orange gestreiften Bereich dargestellt werden, zurückzahlen, und dann sich bemühen, die gewonnene Produktivität langsam zu übersetzen Vorteile für eine Menge Arbeit, die groß genug ist, um zu liefern.

  • Beachten Sie, dass mit "virtuellen Arbeitsgewinnen" gemeint ist, dass mehr Arbeit dann wie das Stehlen dieser Arbeit aus der Zukunft war. Können Sie sich vorstellen, wie viel besser unser Leben wäre, wenn wir jeden Tag zusätzliche 10 Minuten produktive Zeit hätten? Wenn wir in unserer Unterwäsche arbeiten, erhalten wir diese 10 Minuten zusätzliche Produktivität. Genau das wurde getan. Sich nicht zu verkleiden ist kein guter Weg, um Zeit bei Ihrer Arbeit zu sparen , ich hoffe, Sie folgen der Analogie und der Metapher.

  • Übrigens reicht es nicht aus, ausreichend produktiv zu sein, man muss auch den Arbeitsaufwand berücksichtigen ausgeführt werden wurden jederzeit durchgeführt. Dies wird durch Fristen dargestellt! Entweder verschieben Sie die nächsten geplanten Fristen, um Zeit für die Wiederherstellung zu erhalten, oder wir gehen alle nach Hause ... natürlich nicht jetzt, aber in einigen Fristen, wenn Sie eine Frist einhalten, ist eine Produktivität erforderlich, die weit über der zweiten Frist liegt Diagramm ... das, das wir niemals erreichen werden, wenn wir so weitermachen ...

2
Vector Zita

Bei Agile besteht die Idee darin, zu planen und dabei sauber zu machen. Wenn ich eine Woche Zeit habe, um eine Funktion für eine unordentliche Codebasis zu planen, läuft der Prozess ungefähr so ​​ab:

  • Verbringen Sie einen Morgen mit meinen Kollegen beim Brainstorming von groben Ideen und beim Whiteboarding.
  • Verbringen Sie den Nachmittag damit, den ersten Schritt in die vielversprechendste Idee zu machen. Wenn es sich um neue Technologien handelt, bedeutet dies eine Art Hallo-Welt. Ich versuche nicht wirklich, die Hauptaufgabe hier zu erfüllen. Ich versuche herauszufinden, was mich davon abhält, die Hauptaufgabe zu erfüllen.
  • An diesem Punkt bin ich oft zuerst auf schlecht strukturierten Code gestoßen. Ich verbringe ein oder zwei Tage damit, es aufzuräumen und Tests zu verbessern, nur in dem Bereich, den ich direkt ändern muss, um die Funktion hinzuzufügen.
  • Verbringen Sie einen Morgen damit, die Funktion erneut hinzuzufügen. Treffen Sie eine grundlegendere Straßensperre und entscheiden Sie sich für Plan B, den ich am Montag erarbeitet habe.
  • Da sich die Funktion im selben allgemeinen Bereich befindet, ist die Bereinigung, die ich am Dienstag durchgeführt habe, immer noch hilfreich, aber der neue Ansatz erfordert eine zusätzliche Bereinigung in einem etwas anderen Bereich. Verbringen Sie den Nachmittag mit weiteren Aufräumarbeiten.
  • Jetzt ist der Code, den ich ändern muss, in einem viel besseren Zustand. Ich verstehe es tiefer. Ich habe ein paar verschiedene Ansätze ausprobiert. Ich kann dem Produktmanagement besser erklären, warum bestimmte Ansätze nicht durchführbar sind. Mit kürzeren Bereinigungs-/Codezyklen kann ich viel schneller Fortschritte machen.

Der Reinigungscode lautet wie Sie bewegen sich schnell. Durch die Arbeit im Code lernen Programmierer, was funktioniert. Das heißt nicht, dass Sie nicht planen. Dies bedeutet, dass Sie Ihre Planungs-/Ausführungs-/Bereinigungszyklen in der Größenordnung von Stunden anstelle von Wochen durchführen.

1
Karl Bielefeldt