it-swarm-eu.dev

Umgang mit schlechten / unvollständigen / unklaren Spezifikationen?

Ich arbeite an einem Projekt, bei dem unser Entwicklerteam die Spezifikationen vom Geschäftsteil des Unternehmens erhält. Sowohl das Business Management als auch das IT Management erfordern Schätzungen und Terminprognosen, wie sie sollten.

Das Gute ist, dass Schätzungen hauptsächlich von den tatsächlichen Entwicklern vorgenommen werden, die die erforderlichen Funktionen ausführen können. Das Schlimme ist, dass die Spezifikationen normalerweise entweder zu einfach (es stellt sich heraus, dass Sie viele Fragezeichen über dem Kopf haben, weil viele Informationen zu fehlen scheinen) oder zu komplex (bis zu dem Punkt, an dem Sie können) sind nicht einmal visualisieren, wo alles in die App "passen" würde). Meistens ist der Geschäftsteil der Spezifikationen entweder unvollständig oder weiß nicht, was getan werden kann und was nicht (angesichts der zuvor implementierten Geschäftslogik).

Das Entwicklerteam erhält ungefähr einen Tag pro neuer Spezifikation, um eine Schätzung abzugeben, und wir versuchen, Unsicherheiten zu beseitigen, indem wir uns normalerweise mit demjenigen treffen, der die Spezifikation erstellt hat. In den meisten Fällen stellt sich heraus, dass Spezifikationsschreiber nicht wirklich alles durchdacht haben, und normalerweise geraten wir erst dann in Schwierigkeiten, wenn wir mit dem Entwerfen und Entwickeln beginnen, da viele der Spezifikationen Löcher zu haben scheinen.

Wie gehst du damit um? Sind Sie großzügig bei Schätzungen im Voraus?

44
eagerMoose

Wenn Sie während der Entwurfsphase Probleme finden, haben Sie wirklich ein Problem?

Stellen Sie sicher, dass diejenigen, die die Spezifikationen erstellen, nicht das Gefühl haben, alles im Voraus tun zu müssen. Sie können nicht an alles denken und wir auch nicht. Sie müssen auch wissen, dass sie nicht einfach einen All-Nighter für ein spezielles Dokument durchführen und dann mit dem Projekt fertig werden können. Diese Praxis führt auch dazu, dass sie alles hinzufügen, woran sie denken können, weil sie es möglicherweise brauchen, und wenn sie jetzt nicht fragen, werden sie es jemals bekommen. Sie müssen verfügbar sein, um ihre Anforderungen immer wieder zu überprüfen, zu testen und zu genehmigen.

Versuchen Sie nicht, die gesamte App auf einmal zu entwerfen oder zu erstellen. Jedes Projekt/jede App kann in Phasen, Teile, Module oder wie auch immer sie es nennen möchten unterteilt werden. Sie müssen nicht agil sein, wenn das nicht Ihr Ding ist. Beginnen Sie mit dem Teil "Benutzersicherheit" und gehen Sie von dort aus.

Nehmen Sie sich Zeit, sich mit diesen Leuten zusammenzusetzen und herauszufinden, was sie wirklich wollen. Ich würde gerne jemanden haben, der mir Spezifikationen gibt, mit denen ich das gesamte Projekt auf einmal erstellen kann. Aber was würde ich für die nächsten anderthalb Jahre tun?

13
JeffO

Ich benutze den Kegel der Unsicherheit Sprich mit lauter dröhnender Stimme

Grundsätzlich machen Sie die beste Schätzung, die Sie geben können, die Informationen, die Sie haben.
Sie weisen jedoch auch darauf hin, dass angesichts der Unbestimmtheit der Spezifikationen eine hohe Unsicherheit bei diesen Schätzungen besteht (Punktverwaltung vor Ort, damit sie sich über das Prinzip informieren können).

Wenn Sie sich dem Ziel nähern und die Spezifikationen verschärfen, können Sie Ihre Schätzung aktualisieren und die Unsicherheit verringern.

20
Martin York

Ja, ich bin großzügig in Bezug auf Schätzungen. Vergiss nicht Hofstadter-Gesetz

Hofstadter-Gesetz: Es dauert immer länger als erwartet, auch wenn Sie das Hofstadter-Gesetz berücksichtigen. Von Gödel, Escher, Bach: Ein ewiges goldenes Geflecht.

9
Brian Carlton

Der Prozess, den Sie beschreiben, ist eigentlich ganz normal. Das Problem ist, dass Geschäftstypen dazu neigen, Dinge als "Anforderungsphase", dann "Entwurfsphase" usw. zu betrachten. Wenn ein Team ein Produkt erstellt, benötigen Sie wirklich einen iterativen Ansatz. Einige Ideen, die ich gefunden habe, sind:

  • Definieren Sie die Hauptziele für die vorgeschlagenen Änderungen/neue App. Dies sind geschäftsbezogene Ziele wie "Reduzierung der Kosten für die Bearbeitung von Schadensfällen um 10%" oder "Marktforschung von unseren Satellitenbüros aus teilen, damit Produkte die Bedürfnisse unserer Kunden besser erfüllen". Es hilft, sich auf offene Anforderungen zu konzentrieren, um die tatsächlichen Bedürfnisse zu ermitteln.
  • Machen Sie Ihren ersten Swag (Seriously Wild-A ** Guess) für die schlechten Anforderungen, wie sie geschrieben wurden, aber dokumentieren Sie, was Sie angenommen haben, dass die Implementierung sein wird. Dies ist das Feedback, das die Geschäftsleute (und Ihr Kunde) benötigen, um sich zu verbessern und über diese Dinge nachzudenken. Sie verlassen sich für Sie auf Sie.
  • Wenn Sie die Wahl zwischen einer sehr langen und einer sehr kurzen Schätzung haben, gehen Sie immer lange. Es wird wahrscheinlich schockieren, wer Sie bittet, zu arbeiten, was eine gute Sache ist. Es wird euch beide zwingen zu diskutieren, wonach sie wirklich suchen.

Denken Sie daran, dass Ihre erste Schätzung nicht genau sein kann. Richten Sie Ihre Schätzungen auf angemessene Interpretationen der Anforderungen, die Sie erhalten, und dokumentieren Sie Ihre Annahmen/Interpretationen. Aufgrund der von Ihnen entdeckten Löcher werden mehr Anforderungen abgeleitet. Das ist normal.

6
Berin Loritsch

Schätzungen großzügig zu sein mag nett klingen, aber welches Problem löst es? Es wird die Spezifikation nicht verbessern, es wird die Planung nicht einfacher machen. Es heißt "es kann nicht viel schlimmer sein als X", im Gegensatz zu "es könnte Y sein". Die Wahrheit ist, dass du es nicht weißt. Finden Sie heraus, was Sie können.

Wenn die Geschäftsanalysten Entwickler früher einbeziehen müssen, teilen Sie dies ihnen mit. Ein schriftlicher Bericht ist nicht wirklich die beste Kommunikationsmethode. Wenn Sie einen Entwickler bei der Erfassung der anfänglichen Anforderungen und einen Geschäftsanalysten bei der Entwicklung und beim Testen unterstützen können, sind Ihre Ergebnisse besser.

Ich habe gerade den Kegel der Unsicherheit gelesen. Es ist gutes Zeug, aber es ist leicht, es falsch zu verstehen. Das Management kann sich das erste Bild ansehen und sagen: „Okay, wir haben die Geschäftsanforderungen, daher sollte Ihre Schätzung gemäß Ihrem Kegel zu 50% genau sein. Sag mir'. Das wird nicht helfen.

Auto-Analogie: Jemand fragt Sie, wie viel ein Auto kostet, und gibt Ihnen ein Papier mit seinen Anforderungen. Das Papier sagt, es sollte ungefähr 1200 kg wiegen, vier Räder und mindestens zwei Türen haben, aber vielleicht vier, sollte vier Personen Platz bieten, und gute Scheinwerfer sind wirklich wichtig. Die Farbe sollte grau sein (aber ist auch schwarz möglich?).

Sie können $ 25K sagen, und wenn sich später herausstellt, dass er einen brandneuen Range Rover will, sind Sie fertig. Das macht es nicht korrekter oder nützlicher zu sagen, dass es 100.000 US-Dollar kostet. Möglicherweise benötigt er nur einen gebrauchten (sorry, gebrauchten) Prius. Wenn Sie nicht die Zeit haben, herauszufinden, welche, werden Sie nie erfahren.

3
Jaap

In den meisten Fällen stellt sich heraus, dass Spezifikationsschreiber nicht wirklich alles durchdacht haben, und normalerweise geraten wir erst dann in Schwierigkeiten, wenn wir mit dem Entwerfen und Entwickeln beginnen, da viele der Spezifikationen Löcher zu haben scheinen.

Die Verwendung von most ist falsch.

Es ist für Spezifikationsschreiber nicht möglich, alles durchzudenken. Zeitraum. Wenn sie alles durchdachten, würden sie wissen, wie viele Codezeilen zu schreiben sind und welche Codezeilen korrekt sind.

Da die Spezifikation falsch sein muss, können Sie nicht viel dagegen tun.

Das Problem ist das Problem.

Sowohl das Business Management als auch das IT Management erfordern Schätzungen und Terminprognosen, wie sie sollten.

Vielleicht nicht. Allgemeine Schätzungen und Fristen sind nicht die nützlichsten Dinge.

Daher die Entwicklung agiler Methoden.

Der Punkt ist dies. Alle auf Spezifikationen basierenden Schätzungen müssen fehlerhaft sein. Sie sind nur durch Glück richtig. Die Hälfte der Zeit ist die Schätzung weit unter und die Hälfte der Zeit ist die Schätzung weit über. Dies ist eine logische Folge des Versuchs, die Zukunft mit unvollständigen Informationen vorherzusagen.

Da es passieren muss, sollten Sie nicht in Schwierigkeiten geraten , wenn Sie sich irren. Du musst falsch liegen. Und Sie müssen konsequent und zufällig falsch liegen. Ansonsten fummeln Sie an den Zahlen herum.

2
S.Lott

Sie sollten dem Management erklären, dass bei vagen Spezifikationen ein geringes Vertrauen in die Schätzung besteht. d.h. Ihre Schätzung kann um 30% oder 40% oder 50% oder was auch immer Sie denken variieren. Wenn also etwas auf 2 Tage geschätzt wird, ist das tatsächlich ein Bereich von 2-3 Tagen.
Erstellen Sie dann ein Projektausgaberegister (kann sich in einem Wiki oder Jira usw. befinden). Erstellen Sie alle Ihre Fragen als Probleme und lassen Sie das Unternehmen Ihre Frage beantworten. Solange ein Problem ungelöst bleibt, bleibt die Schätzung ungewiss. Wenn möglich, lassen Sie sich von einem Business Analyst leiten, um dies zu erleichtern und bessere Anforderungen zu stellen. Lassen Sie Ihr Testteam die Spezifikationen überprüfen, da Testfälle anhand der Spezifikationen erstellt werden müssen. Oft kann ihre Beteiligung dazu führen, dass bessere Spezifikationen geschrieben werden. Melden Sie dem Management täglich/wöchentlich, wie viele ungelöste Probleme Sie haben. Je mehr gelöst wird, desto besser werden Ihre Schätzungen sein. Präsentieren Sie dem Management immer Metriken, da Zahlen sie zum objektiven Denken anregen und Sie ebenfalls auf eine solide Basis stellen.
Abhängig von der Größe des Projekts sollten Sie 1-4 Wochen für die Lösungsentwurfsphase einplanen, in der Sie die Hauptprobleme (sowohl die Anforderungen als auch die technischen) herausarbeiten. Haben Sie viele Workshops mit KMU aus Unternehmen und versuchen Sie, diese zu verstehen und Ihre Ansichten zu erläutern, um zu einer Schlussfolgerung zu gelangen. Erst wenn die wichtigsten Anwendungsfälle verstanden wurden und Ihre Schätzungen ein Vertrauen von etwa 80% erreichen, sollten Sie mit der Bauphase fortfahren.

1
softveda

Kommunikation hilft normalerweise, zumindest in einer gesunden Organisation.

Dies ist kein Wundermittel, aber ich habe versucht (und es hat in unserem Unternehmen funktioniert), Geschäftsleute davon zu überzeugen, das Problem zu erklären, anstatt sofort eine Lösung vorzuschlagen. Unsere Feature-Anfragen beginnen also mit einer Beschreibung des Problems oder des Ziels, das sie erreichen möchten.

Dann versucht ein Entwickler mit einigen Domänenkenntnissen, eine Lösung zu finden, während er sich mit jemandem auf der Geschäftsseite berät. Normalerweise liefert dieser Prozess mehrere alternative Lösungen mit Schätzungen.

An diesem Punkt ist es Sache des Unternehmens, eine zu wählen, die auf den Kosten und der Vollständigkeit einer Lösung basiert. Auf diese Weise können Sie ihnen möglicherweise auch diese Methode verkaufen, da sie hier Optionen haben, nicht nur eine Reihe von Mandaten, sie annehmen oder lassen. Natürlich benötigt es auch mehr Ressourcen auf seiner Seite, aber wenn Sie Probleme mit Schätzungen und Spezifikationen haben, ist es eine Investition, die sich lohnt.

0
biziclop

Warum würden Sie eine Anforderungsspezifikation akzeptieren, die unvollständig ist, widersprüchliche Anforderungen enthält oder nicht durchführbar ist? Ich würde empfehlen, dass Ihr Prozess eine Möglichkeit enthält, die Spezifikation zu bewerten und zur Korrektur zurückzusenden, bevor Sie sie akzeptieren und Schätzungen abgeben.

0
oosterwal

Überzeugen das Management/den Kunden, dass es sich lohnt, in bessere Spezifikationen zu investieren. Versuchen Sie Leute mit Domain-Kenntnissen stärker einzubeziehen. Am Ende wird jeder davon profitieren.

0
FabianB

Beseitigen Sie die Spezifikationen.

Überzeugen Sie das Unternehmen, Agile (oder zumindest einen agilen Prozess) für ein Projekt auszuprobieren.

Schreiben Sie stattdessen Spezifikationen aus

  • treffen Sie sich mit den Geschäftsleuten, um Merkmale zu identifizieren
  • arbeiten Sie mit ihnen zusammen, um die minimalen Features/Funktionen zu identifizieren, die nützlich wären (auch wenn dies nur für eine interne Version gilt).
  • karte die Arbeit
  • legen Sie ein Datum für die Arbeit fest (je weniger Funktionen/Arbeiten vorhanden sind, desto einfacher sollte es sein, ein Datum genau zu schätzen).
  • arbeiten Sie mit Unternehmen zusammen, um Prioritäten zu setzen, stellen Sie sicher, dass sie die Möglichkeit haben, ihre Meinung über die Kartenbestellung zu ändern, und teilen Sie ihnen mit, wie sich dies auf das Datum auswirkt
  • mit jedem abgeschlossenen Feature haben Sie ein funktionierendes System, um sie anzuzeigen, und lassen Sie sie bei jeder Arbeit abmelden, wenn sie erledigt ist
  • veröffentlichung
  • spülen
  • wiederholen

Anzeigen Funktionen, sobald sie fertig sind. Früh und oft freigeben. Seien Sie transparent und reaktionsschnell. Ich habe festgestellt, dass dies zur Beseitigung sinnloser Fristen führen wird.

Für Architektur bearbeiten

Wer auch immer der Leiter ist, sollte ein Kick-off-Meeting haben, um den Entwicklern mitzuteilen, wie die Architektur aussehen soll. Die Führung ist auch wirklich die Person, die gebührende Sorgfalt walten lassen sollte, um sicherzustellen, dass alle Bedürfnisse erfüllt werden.

Wenn Sie zusätzliche Schritte in Ihrem Prozess benötigen, fügen Sie diese hinzu. Ein Prozess erleichtert dem Team die Erledigung von Aufgaben. Wenn etwas nicht funktioniert, ändern Sie es. Fügen Sie es hinzu, entfernen Sie es, ändern Sie es, um Ihre Bedürfnisse zu erfüllen. Wenn Sie sich besonders um die Sicherheit sorgen müssen, fügen Sie entsprechende Schritte hinzu.

0
dietbuddha

Denken Sie daran, dass jedes Mal, wenn die Spezifikation geändert wird, um neue Funktionen hinzuzufügen oder Fragen zu klären, es Zeit ist, die Schätzung erneut zu überprüfen. Es ist nicht so sehr so, dass unsere ursprüngliche Schätzung schlecht ist, wenn man bedenkt, was uns gesagt wurde, sondern dass wir nicht zurückschieben und nein sagen, wir brauchen dies, wenn mehr Details verfügbar gemacht werden. Wenn ich ein Bauunternehmer wäre, der ein Haus baut, und die Kosten anhand einer Lamiante-Arbeitsplatte schätzen würde und ein Monat später der Kunde eine Granit-Arbeitsplatte möchte, können Sie wetten, dass ich die Kostenschätzung mit ihm erneut prüfen würde. Wir lassen unsere Kunden mit schlechten Anforderungen davonkommen und schieben sie dann nicht zurück, wenn sich herausstellt, dass es viel mehr zu tun gibt, als ursprünglich vorgesehen.

0
HLGEM