Sie können fehlerfreie technische Spezifikationen schreiben, aber was nützt es, wenn Ihr Entwickler weint?

Ein kugelförmiger Produktbesitzer arbeitet in einer weit entfernten Galaxie. Er schreibt fließend Notizen auf eine Serviette und gibt sie still an die Entwickler weiter. Und bald erhält er ein fertiges Produkt, das seine Erwartungen zu 100% erfüllt. Auch wenn es sich bei diesem Produkt um einen komplexen plattformübergreifenden Service mit Blackjack und Anpassungsfähigkeit handelt.



Ist das in der Praxis möglich?



„Nein, Bruder, du kannst uns nichts vormachen! Das Mandat sollte lang und sorgfältig geschrieben werden “, sagen die grauhaarigen Senioren. "TK ist ernst!" - Die Juns mit dem gelben Mund wiederholen sie. "Meine Frau hat mich wegen eines kurzen technischen Auftrags verlassen", gibt ein erfahrener Business Analyst zu.



Lassen Sie mich nicht zustimmen.



Das Schreiben einer TK muss nicht zeitaufwändig sein. Darüber hinaus sind gute Leistungsbeschreibungen leichter zu schreiben als schlechte. Wenn Sie einige Tricks kennen, natürlich. Ich werde dir heute davon erzählen. Anstelle von Servietten empfehle ich jedoch weiterhin die Verwendung von Confluence .

Was ist falsch?

Ich schreibe seit über 11 Jahren Aufgaben für Entwickler. Darauf aufbauend wurden Anwendungen, Spiele, Webservices, CRM-Systeme, Trainingsplattformen und andere Produkte erstellt. In dieser Zeit bin ich in mehreren Schritten vom Schreiben von 200-seitigen Designdokumenten zum lakonischen Mandat übergegangen. Und natürlich füllte er alle möglichen Unebenheiten.



Jahr für Jahr habe ich in verschiedenen Unternehmen beobachtet, wie Produkt-, Spieledesigner und Vermarkter Aufgaben stellen. Und was sind die Konsequenzen der verschiedenen "Merkmale" der Gestaltung dieser Aufgaben? Wie sich der Start des Sprints um eine Woche verschiebt, um herauszufinden, was genau der Kunde will. Wie in einer Panik fixieren sie die Funktionalität, die gerade in das Produkt gegossen wurde. Wie schnell die App-Punktzahl aufgrund nicht erfasster Fälle sinkt. Wie der Umsatz sinkt und treue Nutzer gehen. Wie Entwickler ausbrennen, wenn sie an problematischen Aufgaben basteln müssen.



Ich hatte den Eindruck, dass zu viele von denen, die Entwicklungsaufgaben stellen, nicht wissen, wie man es gut macht . Und die Frage nach der Qualität von TK selbst steht nicht im Mittelpunkt der Aufmerksamkeit: Sie sagen, sie haben eine Aufgabe und Normen geschrieben, sie werden es nicht herausfinden, oder was? Darüber hinaus gibt es immer interessantere Dinge zu tun: neue Hypothesen diskutieren, Treffen, Kaffeepausen. Infolgedessen leidet jeder - Kunden, Entwickler und Unternehmen.

Beim Schreiben von TK gibt es zwei Extreme

Je größer das Produkt ist, an dem Sie arbeiten, desto höher sind die Kosten eines Fehlers und desto wichtiger ist die Qualität der technischen Spezifikation (danke, Kappe!). Daher sind beide Optionen nicht geeignet, wenn Sie etwas Ernsthafteres als eine Zielseite tun. Bei großen und wettbewerbsfähigen Produkten sollte das Schreiben von TK schnell, intelligent und rockig sein . Mal sehen, wie man dorthin kommt.

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. Die TK sollte dem Teamleiter gefallen.
   
   Dies bedeutet, dass keine besonderen Rituale und Erklärungen erforderlich sind, um auf die Entwicklung übertragen zu werden. Wenn beispielsweise ein Produkt den technischen Auftrag abgeschlossen hat und genau dort im Büro von einem Bus angefahren wurde, sollte dies ihn nicht daran hindern, den technischen Auftrag bestmöglich auszuführen.

Ist es schwierig, all diese Anforderungen zu erfüllen? Überhaupt nicht.



Im Gegenteil, wenn Sie sich an sie erinnern, werden Sie nicht in der Lage sein, ehrlich gesagt schlechte TK zu schreiben. Denn all diese Anforderungen beschränken sich nur auf eines: sich um die Menschen zu kümmern, die mit dieser TK interagieren.

Mein TK-Format

Dieses Format ist eine ziemlich lockere Mischung aus User Story + Definition von done .



Es war das Ergebnis einer langjährigen Evolution: Jedes Mal, wenn ich ein systematisches Problem sah, änderte ich das Format meiner TK, damit dieses Problem in Zukunft nicht mehr auftritt. Das Ergebnis ist ein lakonisches und optisch sauberes Format, das selbst Junes leicht erkennen können. Außerdem erfüllt es die oben beschriebenen Anforderungen.



So sieht eine typische Geschichte in meiner TK aus:







Und egal wie groß und komplex das Produkt ist, das wir entwickeln, jede TK wird aus solch einfachen Geschichten bestehen (ihre Anzahl wird nur wachsen).





Wichtig: Storys sollten nicht zu große Funktionen (z. B. mehrere Bildschirme) oder zu kleine Funktionen (z. B. eine Schaltfläche) beschreiben. In der Regel ist eine Geschichte eine Funktion oder ein Produktmechaniker. Beispielsweise kann eine Story die Registrierung eines neuen Benutzers vollständig beschreiben. Um eine Aufgabe für das Layout einer neuen Landing Page festzulegen, reicht mir in der Regel auch eine Story.



Wenn die technische Spezifikation groß und bedeutsam ist, schreibe ich vor der Liste der Geschichten kurz: Warum wir das tun und welche Ergebnisse wir erzielen wollen . Nur damit Entwickler ein großes Bild haben.

Im Allgemeinen stellt sich so etwas heraus:

Beispiel

Okay, um zu verstehen, wie das funktioniert - lassen Sie uns ein Produkt in solche Geschichten aufteilen. Zum Beispiel haben wir beschlossen, eine Anwendung namens "Neural Boot" zu erstellen. Darin führt das neuronale Netzwerk vertrauliche Gespräche mit Produkten, die keinen Tag hatten (und keine Freunde haben).



Der Einfachheit halber gehen wir davon aus, dass wir bereits über ein trainiertes neuronales Netzwerk verfügen und eine Schnittstelle dafür in Form einer Anwendung erstellen müssen.



Wahrscheinlich wird die TK aus folgenden Zeilen bestehen:

1. Benutzerberechtigung
2. Benutzerprofil
3. Bildschirm der Kommunikation mit einem Neuroboot
4. Bildschirm "Neuroboot-Katalog"
5. Profil- und Einstellungsbildschirm
6. Zahlungs-Popup
7. Analytics-Verbindung

Es bleibt, jede Geschichte (im obigen Format) zu malen und an die Entwicklung zu senden. Ich habe dir gesagt, es wäre einfach.

---

Tricky Life Hacks

Es gibt eine Reihe von Techniken, mit denen ich jeden Tag an einem Produkt arbeiten kann. Hier sind diejenigen, die sich auf das Schreiben von Leistungsbeschreibungen beziehen.

Life Hack # 1: Detail iterativ

Jetzt schreibe ich überhaupt keine technischen Spezifikationen mehr - sie selbst erscheinen im Hintergrund im Arbeitsprozess. Wenn eine neue Aufgabe erscheint, finde ich sofort heraus: Welche Unteraufgaben werden dazu benötigt? Und dann korrigiere ich jede Unteraufgabe im Story-Format (nur der Name, Details werden später bekannt gegeben).



Somit habe ich sofort ein allgemeines Mandat parat. Es bleibt nur insoweit detailliert, als es möglich sein wird, den technischen Auftrag für die Entwicklung zu vergeben.



Die Detaillierung geht auch in den Hintergrund: Während ich recherchiere und über die Details nachdenke, mache ich mir sofort Notizen in den entsprechenden Zeilen. Anstelle von Design füge ich Prototypen von NinjaMock ein .



Dieser Ansatz beschleunigt die Arbeit erheblich. Außerdem können Sie das große Ganze nicht verpassen und sich nicht im Voraus mit den Details befassen.

Life Hack # 2: Nicht mit Genies arbeiten

Es gab so einen alten Film, in dem der Geist die Wünsche auf die beschissenste Weise erfüllte.



Natürlich wird ein vernünftiger Entwickler nicht speziell nach einer Möglichkeit suchen, Schaden zuzufügen. Aber manchmal ist es den Leuten egal, woran sie arbeiten. Dann erledigen sie die Aufgabe "wie geschrieben" und untersuchen nicht wirklich, warum sie benötigt wird. Dies führt regelmäßig zu großen und kleinen Dateien. Nun ja, die Produktion hat sich eingestellt ... aber niemand hat in die Aufgabe geschrieben, was überprüft werden muss - ob eine solche Implementierung alles andere kaputt macht.



Ich werde nicht über Outsourcing sagen, aber dieser Ansatz ist im Produkt nicht akzeptabel. Ein guter Entwickler baut einen Tempel und legt nicht nur Ziegel. Das heißt, er sieht das große Ganze und vertieft sich in das, was passiert. Solche Leute bieten oft alternative Lösungen an und warnen selbst vor Fallstricken.



Wenn Sie also möchten, dass Ihre TK bestmöglich durchgeführt wird, müssen Sie manchmal nicht die TK, sondern die Entwicklungskultur im Team verbessern. Im Allgemeinen ist dies die Aufgabe eines PM, aber das Produkt kann auch die Situation beeinflussen. Vor allem, wenn das Team ihm vertraut (zum Beispiel dank seiner durchdachten und gut gestalteten technischen Spezifikationen).

Lifehack # 3: Trennen Sie TK von der Dokumentation

Das Mandat beantwortet die Frage "Was ist zu tun?" Und die Dokumentation - zur Frage "Wie wird es gemacht / wie funktioniert es?" Die TK wird vor der Implementierung der Aufgabe geschrieben, und die Dokumentation wird danach geschrieben.



Wenn ich den Schrank neu anordnen muss, schreibe ich eine Aufgabe im Sinne von „von hier neu anordnen -> hier“. Aber ich werde nicht den architektonischen Plan des Hauses zeichnen, in dem sich ein Kleiderschrank befindet.



Manchmal gibt es die Meinung, dass TK so geschrieben werden sollte, dass es sozusagen gleichzeitig eine Dokumentation ist . Dies ist eine schädliche Theorie. Die vollständige Dokumentation funktioniert immer noch nicht, da nicht im Voraus bekannt ist, wie genau die Leistungsbeschreibung umgesetzt wird. Darüber hinaus benötigen Entwickler Handlungsspielraum, den die Dokumentation nicht bietet. Und die Hauptsache ist, eine solche TK um ein Vielfaches länger zu schreiben, und es wird sich als umständlich herausstellen.



Es gibt verschiedene Produkte und verschiedene Startups. Jemand kann überhaupt auf Dokumentation verzichten. Wenn Sie dennoch Dokumentation benötigen, sollten Sie einen Juni beauftragen, der die Funktionalität nach der Implementierung ausführlich beschreibt . Sie benötigen keine besonderen Fähigkeiten, um die vorhandenen Funktionen zu beschreiben, aber Sie sparen Zeit und Nerven für geschickte Mitarbeiter - Produktentwickler und Entwickler.

Life Hack # 4: Programmieren lernen

Eine rein empirische Beobachtung: Produkte, die programmieren können, können Aufgaben besser formulieren. Darüber hinaus ist es nicht erforderlich, ein leitender Backend-Operator zu werden. Es reicht aus, jede Programmiersprache zu beherrschen und die Essenz des algorithmischen Denkens zu verstehen.



Zu einer Zeit programmierte ich immer noch unkontrolliert auf dem chthonischen Spektrum , und in meinen Studienjahren musste ich sogar Treiber in Assembler schreiben. Das heißt, ich bin mit dem Programmieren aus erster Hand vertraut - und dies hilft natürlich dabei, eine gemeinsame Sprache mit Entwicklern zu finden.

Life Hack # 5: Viel nachdenken, ein wenig schreiben

Die größten Probleme treten immer bei Aufgaben auf, die der Kunde selbst nicht vollständig versteht. Zum Beispiel benötigt er einen neuen Bericht im Administrationsbereich, aber er versteht nicht ganz, wie dieser Bericht erstellt wird. Sie Programmierer werden es herausfinden. Nein, so funktioniert es nicht.



Der einzige Weg, ein gutes Problem zu schreiben, das richtig gemacht wird, ist zu verstehen. Verstehen Sie das Problem im Idealfall so gut, dass Sie es selbst erledigen können ... wenn Sie wissen, wie man programmiert.



Aber wenn Sie es herausgefunden haben, müssen Sie nicht alle Informationen in der TK speichern. Es ist nur ein tiefes Verständnis der Aufgabe, das es Ihnen ermöglicht, unnötige Dinge zu verwerfen und nur das zu schreiben, was wichtig ist.

---

PS TK ist ein Mittel, kein Zweck. Daher ist manchmal die beste TK ihre Abwesenheit. Eines Tages werde ich Ihnen erzählen, wie ich einige Produkte ohne technische Spezifikation auf den Markt gebracht habe.



PPS Wenn Sie beim Schreiben ein eigenes Format für Leistungsbeschreibungen oder Life-Hacks haben, teilen Sie dies bitte in den Kommentaren mit.