Fristen an sich sind keine schlechte Sache, würde ich sogar sagen, irgendwo gut. Persönlich erweist sich meine Arbeit als produktiver, wenn ich mich mental auf einen bestimmten Zeitrahmen konzentriere und wenn ein Projekt überhaupt keinen Zeitrahmen hat, kann es letztendlich schaden. Die Hauptsache hier ist, realistisch zu denken und ein Gleichgewicht zu halten.
Die Frist muss begründet sein. "Weil weil" ist keine Rechtfertigung. Dies ist eine schlechte Zeiteinstellungspraxis, die sowohl Unternehmen als auch Entwickler betrifft. Ich hatte das Glück, dass die meisten Unternehmen, für die ich gearbeitet habe, nicht die Angewohnheit hatten, Termine zu wählen. Aber es gab Ausnahmen. Ich möchte in diesem Artikel als Beispiel auf eine solche Situation eingehen.
Ich habe damals bei einem Startup gearbeitet; Unser Front-End-Team bestand aus drei Personen, und es gab auch ein Back-End-Team der gleichen Größe. Wir arbeiteten an einer aktualisierten Version der mobilen Anwendung und mussten die Veröffentlichung vor einem klar gekennzeichneten Tag erfüllen. Ein Problem: Dieser Tag wurde willkürlich entweder von einem einfachen Direktor oder von einem technischen ohne Grund für eine solche Entscheidung gewählt.
Nun, das ist nicht ganz ohne Begründung - bei der Auswahl eines Tages wurde die ungefähre Dauer der von den Entwicklern angegebenen Arbeit berücksichtigt. Wenn Sie mit Code oder mit den Leuten arbeiten, die ihn schreiben, verstehen Sie wahrscheinlich bereits, wo das Problem liegt. Die ungefähren Daten sind immer ungefähr, das heißt, sie unterscheiden sich sehr von dem, was tatsächlich herauskommt. Und es geht nicht um die Inkompetenz der Entwickler, es ist einfach unglaublich schwierig, den Arbeitsaufwand für ein gesamtes Projekt abzuschätzen. Es gibt viele Dinge, die Fristen verschieben können und die nicht vorherzusagen sind.
Auf die eine oder andere Weise war unsere grobe Schätzung das Ergebnis zweitägiger Besprechungen: zuerst eine allgemeine Übersicht über neue Funktionen, dann eine detaillierte Analyse der einzelnen Funktionen, dann eine noch detailliertere Analyse ... Schließlich für jede Arbeitsphase Wir haben die Anzahl der Stunden geschätzt, erneut überprüft, mit dem UX- und UI-Design korreliert, alles zusammengestellt, einige Stunden darüber geworfen - und das war die Frist für die Arbeit.
Sie denken jetzt wahrscheinlich: Nun, da ihre UX- und UI-Designs bereits fertig sind und noch mehr Stunden in Reserve sind, sollte dann wahrscheinlich alles gut gehen? In den meisten Fällen sind die Bedingungen beim Einstellen der Daten schlechter. Nun, im Allgemeinen nein. Nichts ging gut.
Die Dauer der Arbeit wurde auf drei bis vier Wochen festgelegt - nicht zu viel Zeit, wenn wir mit einem kleinen Team über die Veröffentlichung eines neuen Produkts sprechen. Natürlich waren wir nach den ersten zwei Wochen bereits hinter dem Zeitplan zurück. Nicht weil sie langsam arbeiteten oder einige Stunden an dem Projekt verbrachten, sondern weil immer alles schief geht.
Das Backend befasste sich mit der Implementierung der API für die Anwendung, als sich plötzlich herausstellte, dass das System nicht normal mit einem einfachen Add-On interagieren konnte. Dies bedeutet, dass das bereits vorbereitete API-Fragment unter Berücksichtigung dieser Umstände neu geschrieben werden musste Konto. Es dauerte zwei außerplanmäßige Tage, um den Endpunkt fertigzustellen.
Aufgrund dieser kleinen Änderung begann die API etwas anders zu funktionieren als in der Diskussionsphase vorgesehen, was dazu führte, dass einzelne Teile der Anwendung neu geschrieben werden mussten - eine Arbeit für mehrere Stunden. Ein solches Umschreiben ist in mobilen Apps aller Größen üblich und sollte niemanden überraschen. Aber wir haben eine enge Frist. Und jetzt können wir nicht passen.
Also was kannst du tun? Am nächsten Tag wurde uns gesagt, wir müssten vier zusätzliche Stunden arbeiten, um wieder weiterzukommen. Vier Stunden zusätzlich zu einem typischen achtstündigen Arbeitstag. Ja, wir wurden natürlich gefüttert, aber in solchen zwölfstündigen Schichten gibt es nichts Nützliches für das Gehirn und kann es nicht sein. Trotzdem haben wir es geschafft, den Zeitplan einzuhalten und einzuhalten.
Eine Woche später wurde die Anwendung veröffentlicht. Wir waren froh, dass jemand ein paar Cupcakes zum Feiern mitgebracht hatte, und fünf Minuten später saßen bereits alle an den Monitoren und taten so, als wäre nichts passiert.
Das Update enthielt nichts so Wichtiges, das die Notwendigkeit einer Veröffentlichung an diesem bestimmten Datum und nicht einen Tag später begründen würde. Keiner der Benutzer wusste, dass eine neue Version vorbereitet wurde, niemand (weder Kunden noch Investoren) machte Pläne basierend auf einem Datum. Ja, die Funktionen sind nützlich, aber würde sich jemand schlechter fühlen, wenn sie einen Tag später veröffentlicht würden? Würde es überhaupt jemanden betreffen?
Aber die Entwickler waren betroffen. Hier und da schütteten die Leute ihr Missfallen miteinander aus; Die Beziehung zwischen dem Team und dem Management war eindeutig verdorben. Und dies ist kein Einzelfall, dies geschah oft, während ich dort arbeitete - mit einer Häufigkeit von ungefähr einmal alle paar Monate.
Und was ist die Schlussfolgerung aus all dem? Zu jeder Zeit ganz aufgeben? Na klar natürlich nicht. Wie am Anfang des Artikels erwähnt, sind Fristen tatsächlich nützlich, und ich selbst finde es einfacher, mit ihnen zu arbeiten. Sie sollten jedoch als Richtlinien und nicht als starre Verpflichtungen verstanden werden. Wenn das Produkt einige Tage später herauskommt, sollte es nicht als das Ende der Welt betrachtet werden. Was bringt es, Entwickler unnötig unter Druck zu setzen? Oder glauben Sie, dass die Qualität des Codes nicht unter solchen Märschen leidet?
Als wir nach einem Arbeitstag am späten Abend unter dem Banner höherer Gewalt zusätzliche Stunden trainierten, war die allgemeine Stimmung: "Also müssen wir es so schnell wie möglich beenden." Oft wurden alle Arten von Krückenlösungen eingeführt, die eine Weile funktionieren und dann ein Refactoring erfordern. In einigen Fällen wurde das entsprechende Refactoring sofort geplant, in anderen Fällen wurde es sicher vergessen. Und es kam vor, dass die Entwickler selbst nicht wirklich merkten, dass sie etwas Krücken machten, weil sie müde waren und nach Hause wollten.
Wenn es um Refactoring geht (wo es überhaupt hingekommen ist), ist es wahrscheinlich eher eine Ressource als höhere Gewalt. In Codestücken, die in Eile geschrieben wurden, tauchten Fehler auf. Da die App bereits veröffentlicht wurde, ging sie allen besonders auf die Nerven.
Nach meinen Schätzungen (ich habe keine Statistiken gesammelt, kann also nicht bürgen) war diese Verarbeitung nur kurzfristig sinnvoll. Ja, wir haben die Anwendung pünktlich veröffentlicht. Und die nächste Veröffentlichung musste bereits verschoben werden, da viel umgeschrieben wurde. Die Entwickler waren unglücklich (und Sie haben es erraten, sie haben aktiv aufgehört), die Atmosphäre im Team wurde angespannt. Und wir berücksichtigen immer noch nicht die Folgen der Fehler, auf die Benutzer nach der Veröffentlichung gestoßen sind.
Wie brauchst du es
Wenn Sie möchten, dass alles effizient erledigt wird, geraten Sie nicht in Fieber, hören Sie den Entwicklern zu und verfolgen Sie den Fortschritt. Wenn das Team nicht passt und es keinen Grund zur Dringlichkeit gibt, verschieben Sie die Frist! Nicht willkürlich, aber für die Zeit, die zum gegenwärtigen Zeitpunkt nicht ausreicht. Ermutigen Sie Entwickler, mögliche Ursachen für Verzögerungen und Risiken zu kommunizieren. Wenn jemand etwas sieht, das eindeutig nicht in den allgemeinen Zeitplan passt, lohnt es sich, die Aufmerksamkeit der geplanten Person auf sich zu ziehen, damit er die Möglichkeit hat, die geschätzten Daten zu korrigieren.
Hast du alles vorher gemacht? In einer solchen Situation gewinnt nur jeder. Das Testen kann ordnungsgemäß durchgeführt werden und bietet Entwicklern die Möglichkeit, die Codebasis zu verbessern. Wenn Sie Entwickler sind oder mit Entwicklern für die Arbeit kommunizieren, wissen Sie selbst: Es gibt immer Stellen im Code, die Sie festigen möchten. Manchmal dauert es nur eine Stunde und manchmal mehrere Tage. Es ist besser, keine Zeit damit zu verschwenden, den Code besser und genauer zu machen - wie wir alle bestätigen können, gibt es genug Mängel in Anwendungen, die keiner der Benutzer zu schätzen wissen wird.