Erstens: Willkommen zu diesem kleinen Ding, das ich gerne als "reales Leben" bezeichne.

Softwareentwickler sagen immer, dass vor Beginn eines Projekts alle Anforderungen anhand detaillierter Beschreibungen vollständig festgelegt werden sollten von Algorithmen zum Screening von Modellen, und sobald die Entwicklungsarbeit beginnt, sollten keine Änderungen mehr zulässig sein. Wenn das Produkt geliefert wird, werden wir natürlich alle Abweichungen von den schriftlichen Anforderungen beheben, aber es sind keine Änderungen zulässig, die eine Änderung der Anforderungen beinhalten.

Ja, dies würde dem Softwareentwickler das Leben erheblich erleichtern . Und es ist eine absurde Forderung.

Stellen Sie sich vor, Sie wollten ein Auto kaufen. Sie gehen also zum Autohändler und stellen fest, dass es sich nur um ein Büro mit einem Mann hinter einem Schreibtisch handelt. Er gibt Ihnen ein leeres Blatt Papier und sagt: "Schreiben Sie hier genau auf, was Sie in einem Auto wollen. Wir werden dann ein Auto finden, das diesen Anforderungen entspricht, und es Ihnen liefern. Sobald Sie das Papier unterschrieben haben, beginnen wir mit der Suche für ein Auto sind also zu diesem Zeitpunkt keine Änderungen zulässig. " "Aber", sagen Sie, "ich habe eine allgemeine Vorstellung davon, was ich will, aber ich möchte auf jeden Fall ein paar verschiedene Autos ausprobieren, sie zu Probefahrten mitnehmen ..." "Nein, tut mir leid", sagte er sagt: "Das ist nicht möglich. Schreiben Sie einfach auf, was Sie wollen, und wir besorgen Ihnen ein Auto, das diese Anforderungen erfüllt."

Nehmen wir nun an, Sie haben noch nie zuvor ein Auto gefahren. Wie würden Sie wissen, was Sie wollen, bevor Sie es versucht haben? Dinge, die auf dem Papier wie eine gute Idee erscheinen, funktionieren in der Praxis möglicherweise nicht so gut usw.

Ich würde mir keine Sorgen über vage Anforderungen machen, vorausgesetzt, alle Beteiligten verstehen, dass die Anforderungen vage sind, dass Sie müssen die Lücken füllen, und wenn sie die Entscheidungen sehen, die Sie getroffen haben, wird es einige Entscheidungen geben, die sie nicht mögen, und die Dinge müssen überarbeitet werden.

Wenn dies eine lockere und kooperative Umgebung ist, sollte es kein Problem geben. Sie produzieren etwas, bringen es zur Überprüfung, sie sagen Ihnen, was sie mögen und was nicht, Sie nehmen Änderungen vor, gehen vielleicht in vielen Zyklen vor. Ich habe viele, viele solche Projekte in meinem Leben gemacht. Oft muss der Benutzer die Software ausprobieren, um zu sehen, was in der Praxis funktioniert und was nicht.

Wenn der Chef oder der Kunde unangemessene Anforderungen stellen oder wenn Sie die Umgebung nicht kennen Dann müssen Sie die Dinge schriftlich festhalten, um sich zu schützen. Ich habe einige Projekte in meinem Leben gemacht, in denen der Chef oder der Kunde sagt: "Ich weiß nicht, was alle Anforderungen sind, Sie erfinden einfach etwas." Dann erfinde ich etwas und wenn ich es zurückbringe, schreien sie: "Was! Das wollte ich nicht! Was für ein Idiot bist du? Sicher war es offensichtlich, dass ..." und geben dann eine ganze Reihe von Anforderungen an das sie haben es noch nie erwähnt und das war mir überhaupt nicht klar. Schreiben Sie in einer solchen Umgebung - auch wenn Sie nicht schreien und drohen, Sie zu entlassen oder den Vertrag zu kündigen, vielleicht nur Ausdruck schwerer Enttäuschung und Frustration - in einer solchen Umgebung ein Papier, in dem beschrieben wird, was Sie tun möchten und Gib es ihnen zur Genehmigung zurück. Wenn Sie Glück haben, wird dies zu einer Diskussion über die tatsächlichen Anforderungen führen. Im schlimmsten Fall sagen sie "Ja, ja, was auch immer" und wischen es ab. Aber zumindest an diesem Punkt, wenn Sie dann mit der Software zurückkommen und sagen: "Das wollten wir nicht", können Sie das Dokument zurückbringen und sagen: "Oh, tut mir leid, das haben wir vereinbart Ich sollte es tun. Sehen Sie, es steht genau hier und Sie haben es genehmigt. " In einer freundlichen Umgebung sagen Sie dies auf freundliche Weise; In einer feindlichen Umgebung müssen Sie möglicherweise energischer sein. So oder so sagen Sie dann: "Okay, welche Änderungen an den Anforderungen möchten Sie vornehmen?" Schreiben Sie diese dann schriftlich und starten Sie einen weiteren Zyklus.

Wenn der Chef oder Kunde unmögliche Bearbeitungszeiten erwartet und Sie beschuldigt, wenn unmögliche Anforderungen nicht erfüllt werden, ist es ehrlich gesagt an der Zeit, nach einem anderen Job oder einem anderen Kunden zu suchen. Oder wenn Sie diesen Job / Kunden dringend genug brauchen, saugen Sie ihn auf und nehmen den Missbrauch auf sich. (Ich habe gute Erinnerungen an die Zeit, als mein Chef mich fragte, wie lange es dauern würde, ein großes, komplexes System, das unser Unternehmen vor Jahren aufgebaut hatte, von einer alten Computersprache in eine modernere Sprache umzuwandeln. Ich begann, ein wenig laut nachzudenken Wir hatten eine solche Übersetzung für ein anderes Produkt gemacht, damit wir etwas Erfahrung hatten, aber niemand in der Firma war heute mit diesem Produkt vertraut, bla bla, und dann sagte er: "Ich brauche keine genaue Antwort, nur grob : zwei Tage? drei Tage? "Ich war verblüfft." Ähm, nein ", sagte ich." Die Frage ist, wie viele Monate. "Er ging murmelnd weg.)

Sie müssen zurückschieben. Holen Sie sich Zeit in ihren Kalendern. Fragen stellen. Frag viele Fragen. Stellen Sie so viele Fragen, dass sie Sie satt haben und Ihnen die Details geben, die Sie benötigen.

Wenn sie es nicht wissen, schlagen Sie spezifische Anforderungen vor und lassen Sie sich abmelden. Dokumentieren Sie ihre Antworten und senden Sie die Antworten zur Bestätigung an sie zurück. Das macht deutlich, dass die Ursache für Veränderungen und Verzögerungen darin besteht, dass sie ihre Meinung ändern und nicht Ihre Entwicklung.

Wenn sie sagen "Bauen Sie es auf Ihre Weise", meinen sie wirklich "etwas tun, was ich kann schau und ändere dich. " Es ist viel einfacher, Anforderungen zu überarbeiten und zu ändern, bevor sie implementiert werden.

Wenn die Kundenanforderungen sehr vage sind, sollten Sie im Allgemeinen aufschreiben, was Sie tun möchten (d. h. technische und funktionale Spezifikationen), und das Dokument validieren lassen . Auf diese Weise können Sie, wenn sie während des Projekts etwas ändern möchten, darauf hinweisen, dass dies nicht vereinbart wurde, und sie dafür belasten. Mindestens ebenso wichtig ist die Tatsache, dass sie dich nicht beschuldigen können, es "falsch" gemacht zu haben.

Wenn Ihr Projekt nicht zu weit fortgeschritten ist, würde ich trotzdem versuchen, dies zu erreichen. Es mag kurzfristig wie ein Zeitverlust erscheinen, aber es wird Sie von einer lebenslangen Implementierung von Änderungen abhalten.

Wenn Sie fast fertig sind (die endlose Liste der bevorstehenden Änderungen wird offensichtlich verworfen), ist das komplizierter. Hier geht es um Schadensbegrenzung. Lassen Sie dies vorzugsweise schriftlich von Ihrem Vorgesetzten anerkennen. Sie wollen kein Sündenbock sein, wenn das Projekt wirklich chaotisch wird.

Um es ganz klar auszudrücken, das scheint mir ein schlechtes Projektmanagement zu sein. Ich würde ein Gespräch mit dem Manager führen, um diese Situation in Zukunft zu vermeiden.

Marv, ich denke, die meisten dieser Antworten sind Kojen.

Dies ist nicht die Realität der Softwareentwicklung. Dies hat zur Folge, dass ein Software-Shop nicht gut genug verwaltet wird.

Anforderungen sind nicht die Antwort, da sich die Anforderungen ändern. Es ist irrelevant, ob die Leute, die sich abmelden, ihre Meinung ändern oder nie eine Vorstellung davon hatten, was sie wollten. Sogar das Unternehmen selbst kann Prioritäten ändern und die Anforderungen verschieben.

Nur eine Person scheint Agile vorgeschlagen zu haben. Das ist ein guter Anfang, aber Agile erfordert viel Buy-In von vielen Leuten, Leuten, die Hausaufgaben machen müssen. Natürlich arbeiten Sie nicht mit Leuten zusammen, die ihre Hausaufgaben nicht machen wollen.

Leihen Sie sich also bei Agile aus. Lassen Sie diese Stakeholder an Gesprächen teilnehmen, in denen Sie die Erstellung von Storys vorantreiben ( http://www.mountaingoatsoftware.com/agile/user-stories). Behalten Sie diese Definitionen in ihrer Sprache bei, damit keine Verwirrung darüber entsteht, worauf sie sich geeinigt haben, wenn sie 3 Monate später überprüft werden. Erwarten Sie Runden des Geschichtenerstellens, halten Sie sie zunächst auf hohem Niveau und teilen Sie sie im Laufe der Zeit in kleinere auf, wenn Sie dies benötigen. Kleinere Storys bedeuten feinere Arbeitsbereiche und helfen bei der Lösung lösbarer Probleme.

Mit einer Reihe von Storys, die klein genug sind, um bequeme Schätzungen abzugeben, können Sie unabhängig davon einen Zeitplan und eine Priorisierung für die Entwicklung Ihres Projekts festlegen wie viel Stakeholder helfen oder nicht helfen. Stellen Sie sicher, dass die Geschichten transparent gespeichert sind. Und wenn die Leute möchten, dass Sie nicht mehr "nach Geschichten arbeiten", dann zurückschieben.

Modelle, Vorschläge, PoCs, alles in Ordnung, aber selbst sie müssen von einem stammen Verständnis dafür, was Sie für Ihren Lebensunterhalt bauen werden. Ansonsten schießt es nur im Dunkeln und glaubt, dass man eines Tages einen Glückstreffer bekommt. Nehmen Sie das Problem bei den Hörnern und planen Sie das Projekt für sie, wenn sie es nicht selbst tun.

"Früh scheitern, häufig scheitern."

Wenn Sie minimale Anforderungen haben, erstellen Sie ein minimales System und zeigen Sie es dann. Demonstrieren Sie es und seine Funktionen auf dem ganzen Weg und fordern Sie Feedback an und erwarten Sie es, das Ihre Flugbahn verändert.

Ja, viele Entwickler wie Sie möchten eine makellose Spezifikation, woraufhin sie zum Turm gehen, und einige Zeit später tauchen Sie mit der richtigen Implementierung auf und sind bereit, das nächste Projekt zu erhalten.

Sie sind jedoch einer Firma und einem Team beigetreten, in denen Sie stattdessen mit minimalem Aufwand arbeiten müssen, ein bisschen joggen und zurückkommen mit Fragen und Demos und ein bisschen mehr joggen.

Dieser Prozess weist ein Element der Ineffizienz auf. Aber oft bestimmen es die geschäftlichen Anforderungen und Bedürfnisse. Wenn sie darauf warten würden, die perfekte Spezifikation zu erstellen, wäre das Projekt nicht rechtzeitig abgeschlossen und müsste trotzdem geändert werden, da niemand die Zukunft vorhersagen kann.

Die iterative Entwicklung ist möglicherweise nicht Ihre Sache. Aber wie Sie feststellen werden, ist es viel, viel häufiger als die perfekte Spezifikationsentwicklung.

Kommunikation, häufige Tests und Rückmeldungen von Benutzern / Kunden / Vorgesetzten und die Bereitschaft, mit den Schlägen zu rollen, werden zu großartigen Fähigkeiten zu haben, wenn Sie sie entwickeln.

Wenn Sie ein Projekt starten, wissen Sie am wenigsten, was Sie jemals darüber wissen werden. Die Verbraucher Ihres Projekts wissen auch das Wenigste, was sie jemals darüber erfahren werden.

Sie können Ihnen einen Pie-in-the-Sky geben. "Hier ist, was ich denke, dass es tun sollte, und hier ist, wie ich Ich möchte, dass es das tut ", aber die Chancen stehen gut, dass sie falsch sind, insbesondere im Detail.

Wenn Sie ein Design nehmen und einen mehr als zwei Monate dauernden Entwicklungsplan erstellen, um es zu implementieren, dann Geh und arbeite daran, du wirst diesem Plan mit ziemlicher Sicherheit nicht folgen. Teile werden schwieriger oder einfacher als Sie denken, andere Teile werden sinnlos sein, wenn Sie sie erreichen, und wenn Sie an dem Projekt arbeiten, werden Sie Fachwissen in diesem Projekt erwerben.

A. In der kommenden Woche haben Sie eine bessere Vorstellung vom Plan und viele Verbesserungen. In einem Monat werden Sie wahrscheinlich denken, Ihr Plan sei dumm.

Ihre Kunden / Chefs haben eine Vorstellung davon, was sie wollen. Sie sind keine Experten für das, was sie machen wollen: Im besten Fall sind sie Generalisten, die wissen, wie man ähnliche Probleme löst, aber der einzige Weg, ein Experte für die Erstellung einer Software zu werden, besteht darin, diese Software zu erstellen. Wenn sie diese Software bereits erstellt hätten, würden sie Sie nicht benötigen.

Ihre Aufgabe ist es, ein Experte für die Erstellung der Software zu werden. Was die Software anfänglich tut, wird vage sein. Sie wissen es nicht wirklich und du weißt es nicht wirklich. Also iterieren Sie: Sie erarbeiten, was Sie denken, dass sie wollen, Sie fragen sie, ob das vernünftig erscheint, Sie implementieren und stellen ihnen so schnell wie möglich etwas vor. Je nachdem, wer sie sind, polieren Sie verschiedene Teile und lassen andere Teile unvollendet.

Dann erhalten Sie Feedback. Sie werden einige Teile mögen, andere Teile für Müll halten und andere Teile für Zeitverschwendung halten. Du gehst los und änderst deine Software - vielleicht verschrottest du sogar die Arbeit und fängst von vorne an (weil jetzt dein Fachwissen beim Schreiben dieses ersten Teils viel besser geworden ist - du hast es einfach getan und du hast wahrscheinlich etwas daraus gelernt) und bekommst schneller zum selben Punkt - oder Sie optimieren es einfach und fügen hinzu, was ihnen gefällt, und ändern, was sie wollen.

Wenn Sie ihr Feedback erhalten, lassen Sie sie sagen, was das Wichtigste ist, was sie wollen verbessert. Lass es aufschreiben. Fragen Sie nach dem, was wichtiger ist (erhalten Sie es in einer geordneten Liste). Angenommen, Sie werden in ein oder zwei Tagen mit Prototypschätzungen zu ihnen zurückkehren. Erraten Sie, wie lange es dauern wird, bis die wenigen gewünschten Funktionen prototypisiert sind, und fragen Sie sie, ob sie in Ordnung sind, wenn ein Prototyp (NICHT eine fertige Version) in X Tagen (einschließlich Puffer für Fehler) einer der Top-Funktionen angezeigt wird 2 Dinge, die sie wollen.

Zeigen Sie ihnen dann Ihren Prototyp und fragen Sie sie, ob sie ihn fertig stellen oder aus der Lösung entfernen möchten. Je nachdem, wer sie sind, möchten Sie möglicherweise anhand des Verhaltens der App verdeutlichen, dass es sich um einen Prototyp handelt. Zu diesem Zeitpunkt sollten Sie eine gute Vorstellung davon haben, wie lange das Polieren des Prototyps dauern wird. Sie können weitere Änderungen anfordern, bevor sie es "fertigstellen", oder sie können verlangen, dass es poliert wird. Wenn sie nach weiteren Änderungen fragen, kehren Sie zu den vorherigen Prioritäten zurück.

Dies ist im Grunde genommen eine entwicklerorientierte Agilität, bei der Sie aktiv Geschäfte mit Ihren Verbrauchern / Vorgesetzten abschließen. Sie erhalten häufig Prototypen und werden häufig um Feedback gebeten. Sie müssen sicherstellen, dass jeder Prototyp entfernt werden kann und wird, wenn Sie nicht aufgefordert werden, ihn zu polieren, und dass er weiß, dass Ihre Prototypen den abgeschlossenen Funktionen nicht so nahe kommen.

Auf diese Weise Ihr Fachwissen beim Schreiben der Anwendung wächst und ihr Verständnis dafür, was sie wirklich wollen, wächst mit der Entwicklung der Anwendung.

Wenn Sie im Voraus nach einer vollständigen Spezifikation fragen, werden die Entscheidungen getroffen, bevor Sie wissen, was funktioniert und was nicht.

Ein Softwareteam benötigt nicht nur Entwickler, sondern auch Anforderungsingenieure, Tester und einige andere Rollen. Es ist durchaus möglich, dass in einem kleinen Team dieselbe Person viele Hüte gleichzeitig trägt. Beachten Sie jedoch, dass die Rolle eines Anforderungsingenieurs andere Fähigkeiten erfordert als die eines Entwicklers. Wenn Sie versuchen, Anforderungen blind zu erstellen, ohne den richtigen Weg zu kennen, sind Sie sehr ineffizient. Sie codieren im Grunde die falsche Anwendung in den meisten Entwicklungszeiten und werden dann frustriert, wenn Sie sie kratzen und erneut starten müssen.

Ich würde vorschlagen, dass Sie einige der Fähigkeiten erwerben, die ein Anforderungsingenieur benötigt. In Ihrem aktuellen Job werden Sie besser in den Aufgaben, mit denen Sie gesattelt wurden. In zukünftigen Jobs, in denen Anforderungsspezifikationen von einem engagierten Anforderungsingenieur oder durch einen Konsens innerhalb des Teams erstellt oder von einem Kunden zusammengeschustert werden können, werden Sie durch diese Fähigkeiten (die mit Ihrer reineren Entwicklerrolle in Verbindung stehen) wertvoller Teammitglied und ermöglicht Ihrem Team eine effizientere Zusammenarbeit aufgrund einer besseren Kommunikation mit Ihnen.

Der beste Einstieg ist ein umfassendes Lehrbuch. Mein persönlicher Favorit ist Ian Alexanders Discovering Requirements, ein sehr praktischer Text, dem Anfänger leicht folgen können. Die zweite Lesung auf Ihrer Liste kann Lauesens UI-Design für Ingenieure sein. Der Titel mag gealtert klingen, aber was Sie daraus lernen, ist jetzt unter dem Schlagwort UX bekannt, was heutzutage ein Plus in Ihrem Lebenslauf ist. Und nein, hier geht es nicht nur um die Benutzeroberfläche, sondern um alle Anforderungen, die für den Benutzer wahrnehmbar sind (einschließlich der Frage, welche Funktionen enthalten sein sollen).

Informieren Sie gleichzeitig Ihre Manager darüber, dass es sich um echte Arbeit handelt. Dies bedeutet, dass 1) wenn sie erwarten, dass Sie einen Job erledigen, für den eine Anforderungsanalyse im Wert von 10 Stunden erforderlich ist, Sie nur noch X-10 Stunden zum Codieren haben. Und 2) dass wie bei jedem anderen Prozess die Eingabe in die Ausgabe umgewandelt wird und Sie Zugriff auf die Eingabe erhalten müssen, bevor Sie eine Spezifikation erstellen können: In diesem Fall alle Informationen, die Sie über die zukünftige Verwendung der Anwendung erhalten können Sie arbeiten mit. Selbst der größte RE-Experte kann kein gutes Konzept erstellen, wenn er keinen Zugang zu echten Benutzern erhält. In den Büchern erfahren Sie, auf welche Quellen Sie zugreifen müssen. Versuchen Sie, so viel wie möglich davon abzudecken.

Ich denke, es kommt darauf an, Kunden und Management zu schulen.

Änderungen werden teurer, je weiter das Projekt fortgeschritten ist.

Sie können nahezu jedes Lehrbuch zur Softwareentwicklung konsultieren, um die "relativen Kosten für die Behebung von Fehlern im Software-Lebenszyklusdiagramm" zu ermitteln. Grundsätzlich heißt es, je weiter Sie im Projekt sind, desto mehr kostet es, eine Änderung vorzunehmen. Warum sollten Sie Probleme in der Planungsphase nicht beheben, wann immer Sie können?

Code Complete erwähnt, dass der Großteil der Kosten eines Projekts in der Codierung liegt - wenn nötig Um dies mehrmals zu wiederholen, können die Kosten Ihres Projekts leicht außer Kontrolle geraten.

Planen Sie gerade genug für die Komplexität des Projekts.

Es gibt verschiedene Metaphern, die für das Software-Engineering geeignet sind. Mein persönlicher Favorit ist der Hochbau. Im Gegensatz zum Bauen muss der Planungsaufwand nicht erschöpfend sein - er muss nur für die Komplexität des Produkts ausreichen.

• Wenn das Projekt trivial ist (wie eine Hundehütte) ), dann können Sie den Builder bitten, "es einfach zu erstellen, wir können es später ändern", und das ist in Ordnung. Das Ändern ist einfach.

• Wenn Sie ein Haus bauen, bitten Sie normalerweise einen Architekten, zuerst Pläne zu erstellen. Der Bauherr und der Architekt vereinbaren einen Entwurf bevor das Haus gebaut wird. Wenn die Pläne akzeptiert werden, kann der Builder beginnen. Sie können den Bauherrn immer noch bitten, es einfach zu machen, aber er muss vor dem Start einen groben Plan entwerfen, und es kostet Sie viel mehr, wenn er ihn reparieren muss.

• Wenn Sie ein Bürogebäude bauen, verwenden Sie besser einen Architekten, da es sonst zusammenbricht. Wenn es einem unglaublich erfahrenen Bauunternehmer gelingt, ein Bürogebäude ohne Plan zu bauen, ist es entweder immens teuer oder völlig unmöglich, ihn zu bitten, einen Untergeschoss hinzuzufügen, weil Sie das Parken vergessen haben.

Sie benötigen keine vollständige und vollständige Spezifikation, bevor Sie beginnen. Sie brauchen nur genug, um zu überprüfen, ob der Client das im Sinn hat, was Sie im Sinn haben.

Sie können nicht schneller bauen als Sie planen können

Clients wenden sich manchmal gegen diese Planung zu lange brauchen. Meine Antwort darauf lautet: "Sie möchten, dass wir dies schneller bauen, als wir es planen könnten? Die Planung ist schneller, einfacher und billiger als das Bauen. Wenn Sie also nicht glauben, dass wir dies in drei Monaten planen können, können wir es definitiv." Erstellen Sie es nicht in drei Monaten. "

Wenn Sie frühzeitig planen, sind Missverständnisse billig und leicht zu beheben. Wenn Sie dies nicht tun, ist es schwieriger, Probleme später zu beheben.

Der agile Weg

Agile verfolgt einen ganz anderen Ansatz.

• Anstatt den Wasserfall-Ansatz einmal zu wählen, teilen Sie das Projekt in Iterationen von jeweils ein oder zwei Wochen auf.

• Sie führen noch Planungs- und Anforderungsklärungen durch , aber weniger davon, und Sie tun dies einmal pro Iteration.

• Sie erhalten zu jeder Iteration viele Benutzer-Rückmeldungen.

• Sie nehmen die einfachsten Änderungen an der Software vor, die die neue unterstützen kann Anforderungen, bevor Sie sie dem Benutzer präsentieren

• Sie führen viele TDD-Vorgänge durch, um sicherzustellen, dass Sie mit Ihrem ständigen Refactoring keine Probleme haben.

Tod durch eine Million Veränderungen

Es gibt eine Art Benutzer, der gerne eine Menge kleiner Anpassungen vornimmt. "Diese Schriftart sollte etwas größer sein." "Diese Schriftart sollte etwas kleiner sein." "Mach das eine andere Farbe." "Anstelle der vollkommen guten Sache, die wir hier haben, können wir sie in etwas anderes ändern."

Wenn dies der Fall ist, ist mein Vorschlag, dass Sie den Kunden dazu bringen, sich zuerst auf die Kernfunktionalität zu konzentrieren. sich zuerst auf größere Veränderungen zu konzentrieren. Sie sollten sie auch bitten, die Anforderung zu formulieren, die die kleine Änderung erfüllt.

Es kann durchaus sein, dass hinter der Anfrage eine wichtige Anforderung steht, von der Sie einfach nichts wissen. Wenn dies der Fall ist, verstehen Sie die Notwendigkeit und prüfen Sie, ob Sie etwas vorschlagen können, das die Anforderung besser erfüllt.

Oft ist die Anforderung "allgemeine Benutzerfreundlichkeit". Die Antwort auf "allgemeine Benutzerfreundlichkeit" sind fast immer Benutzertests. Wohlgemerkt keine Client-Tests, sondern Benutzertests von etwa sechs Personen, die das System tatsächlich verwenden.

Wenn Sie nicht die Anforderungen erhalten, die Sie zum Starten eines Projekts benötigen, müssen Sie alle Anforderungen aufschreiben und diese so schnell wie möglich angeben. Teilen Sie ihnen die genauen Anforderungen mit, die Sie benötigen, und vor allem, welche Sie daran hindern, das Projekt abzuschließen.

Während Sie dies tun, codieren Sie so viel wie möglich mit dem, was Sie können werden am Anfang angegeben. Ich kann das nicht genug betonen. Arbeiten Sie weiter an dem, was Sie erhalten haben , bis Sie nicht mehr können. Lassen Sie sie wissen, wenn Sie einen Punkt erreicht haben, an dem Sie nicht vorbeikommen können, da noch keine Anforderungen festgelegt wurden.

Es kann einen legitimen Grund geben, warum Ihre Chefs Ihnen nicht die Spezifikationen gegeben haben, die Sie benötigen. Möglicherweise muss ein Modell erstellt werden, um zu sehen, wie es zuerst funktioniert. Möglicherweise haben sie keine sie noch, weil Ihre Benutzer / Geschäftsanalysten ihre Füße auf die genauen Metriken ziehen, denen Sie folgen müssen. Was auch immer der Grund sein mag, auch wenn es ein schlechter Grund ist, Sie sollten immer noch so viel Arbeit wie möglich erledigen.

Manchmal ändern sich Anforderungen , und Sie können nichts dagegen tun.

Willkommen in der Softwareindustrie.

Es gehört zu Ihrem Job , solche Dinge zu erledigen. Viele der Antworten geben Ihnen einige spezifischere Ideen, wie.

Es ist Teil Ihres Jobs , flexibel zu sein. Um Code zu erstellen, der gepatcht ist, ja, aber in erster Linie verständlich. Und reparabel, wie Sie gehen. Ihr Job

Es ist Teil Ihres Jobs , Pie-in-the-Sky-Anfragen anzuhören, Codierungen vorzunehmen und jemanden sagen zu lassen, dass dies nicht der Fall ist Weg zum Code, Code wie sie wollen, was nicht funktioniert. Dann gehen Sie zurück und machen Sie es so, wie es funktioniert. Teil Ihres Jobs

Ich denke, das einzige Chaos, das nicht wirklich Teil Ihres Jobs ist, ist die Beschwerde, dass dies ineffizient ist. Sie können es erwähnen, denke ich, oder Sie können versuchen, es zu binden, wenn die Dinge später und später werden, können Sie bestimmte Dinge vorschlagen, aber das wird wahrscheinlich nicht wirklich funktionieren.

Auch hier wird es Teil Ihres Jobs sein , um mit dem Durcheinander fertig zu werden. Und sei nett. Und sag, ok, Boss, wenn das Ganze in den Müllcontainer geworfen wird. Und sagen Sie, ok Chef, wenn das Ganze aus dem Müllcontainer gezogen, mit Müll bedeckt und überarbeitet werden muss.

Teil des Jobs. Wenn es Ihnen nicht wirklich gefällt, empfehlen wir Ihnen, eine eigene Firma zu gründen, ein paar leicht arrogante Programmierer einzustellen und zu versuchen, Ihnen Dienstleistungen und Produkte zu verkaufen und Gehaltsabrechnungen zu machen, während Ihre weinerlichen Mitarbeiter sagen, es ist ein gepatchter Chef, es ist nicht schön Code-Chef. Also ...

Ich denke, eine andere Sache ist, dass Leute, die oft Geschäfte machen, absolut nie Zeit für viele Besprechungen mit Ihnen haben. Wenn Sie Ihren Job machen können, werden Sie in der Lage sein, einige Dinge zu antizipieren, die Dinge zu reparieren, die Sie nicht können, und alles selbst zu tun.

Wie bereits in anderen Antworten erwähnt, benötigen Ihre "Kunden" (diejenigen, die die von Ihnen erstellte Lösung angefordert haben) etwas, das sie mit ihren Anforderungen vergleichen können, um diese Anforderungen vollständig zu erforschen und zu verstehen (das Reifenkicken beim Autokauf) Analogie). Aus diesem Grund haben sie keine vollständigen Spezifikationen bereitgestellt und Änderungen angefordert, nachdem Ihre Lösung Gestalt angenommen hat.

Wenn der "Kunde" sich dessen bewusst ist, werden Sie möglicherweise ausdrücklich aufgefordert, einen Prototyp zu erstellen und entwickeln Sie eine solide Spezifikation basierend auf dem, was der Prototyp enthüllte. Sie können jedoch denselben Weg gehen, ohne dass dies jemandem (Ihnen oder dem Kunden) ausdrücklich bewusst ist. Das Problem tritt auf, wenn Sie bei Lieferung eines Prototyps zitieren, bei dem Ihr Kunde erwartet hat, dass Ihr Angebot für das fertige Produkt gilt.

In "The Mythical Man-Month" wird über a diskutiert "Pilot" -System. Im Wesentlichen einmal ein System erstellen (das weggeworfen wird), um alles zu lernen, was erforderlich ist, um das System erneut zu erstellen, richtig und wie oft es absichtlich passiert oder nicht. Möglicherweise stehen Sie kurz vor der Fertigstellung Ihres "Pilot" -Systems, und die "echte" Lösung muss noch gestartet werden.

Vielleicht können Sie an dieser Stelle am besten jede Änderungsanforderung dokumentieren - genau so, wie Sie es verstehen die Anforderung und Ihr Angebot, was erforderlich ist, um es zu liefern - und seien Sie ehrlich. Beginnen Sie nicht mit Arbeiten, die länger als ein paar Stunden dauern und nur mündlich vereinbart werden. Schreiben Sie es auf - selbst eine informelle E-Mail ist besser als nichts. Möglicherweise müssen Sie sich vor "das habe ich nicht gefragt" und "Sie haben mir nicht gesagt, dass es so lange dauern würde" schützen müssen. Es könnte politisch schlecht sein, Ihrem Chef einfach zu sagen, dass er aufhören soll, nach Änderungen zu fragen. Lassen Sie die wachsende Zahl der zitierten Änderungsbeschreibungen für Sie darüber sprechen, wie die Dinge dort angekommen sind, wo sie sich befinden, und wie Sie Ihre ehrlichen und bestmöglichen Anstrengungen unternommen haben, um den Anforderungen Ihrer "Kunden" nachzukommen.

Alternativ können Sie ein Diagramm oder einen Schaltplan erstellen, der Ihrer Meinung nach den Kunden entspricht. Wenn sie ein Programm mit Gleichungslösern wünschen, können Sie einen Schaltplan (Benutzeroberfläche und alle) eines Programms erstellen, in dem dem Benutzer ein Menü angezeigt wird, und dann eine Taste drücken, um einen Gleichungslöser auszuwählen. Die Gleichung wird dann in ein Textfeld eingegeben, und der Benutzer drückt eine andere Schaltfläche, um das Programm anzuweisen, die Gleichung zu lösen.

Bitte tun Sie sich auch einen Gefallen und erhalten Sie die schriftliche Antwort des Kunden. Stellen Sie sich das als eine Möglichkeit vor, Ihren Hintern zu bedecken, wenn der Kunde später sagt: "Das wollte ich nicht."

Kommunikation ist der beste Weg, um Ihr Problem zu lösen. Stellen Sie Fragen, die Sie satt haben und die Details liefern, die Sie benötigen. Wenn sie es nicht wissen, schlagen Sie selbst Anforderungen vor. Dokumentieren Sie die gegebenen Antworten und senden Sie sie zur Bestätigung zurück. Auf diese Weise machen Sie deutlich, dass die Ursache für Verzögerungen oder Änderungen in einer Änderung ihrer Meinung liegt. Wenn Mgt. Sagen Sie "Bauen Sie es auf Ihre eigene Weise". Das bedeutet "Tun Sie etwas, das ich betrachten und ändern kann." Theoretisch schlägt die Softwareentwicklung vor, dass vor Beginn eines Projekts alle Anforderungen vollständig geklärt werden sollten, von detaillierten Beschreibungen der Algorithmen bis hin zu Bildschirmmodellen. Wenn das Produkt geliefert wird, werden wir natürlich alle Abweichungen von den schriftlichen Anforderungen beheben, aber Änderungen, die eine Änderung der Anforderungen beinhalten, sind nicht zulässig. Ja, dies würde dem Softwareentwickler das Leben erheblich erleichtern. Ich würde mir keine Sorgen um vage Anforderungen machen, vorausgesetzt, alle Beteiligten verstehen, dass die Anforderungen vage sind, dass Sie die Lücken füllen müssen und dass es einige Entscheidungen geben wird, wenn sie die von Ihnen getroffenen Entscheidungen sehen dass sie nicht mögen und die Dinge überarbeitet werden müssen. Unangemessene Anforderungen, die vom Chef / Management oder vom Kunden gestellt werden, müssen schriftlich erfolgen, um sich zu schützen. Wenn der Chef / das Management oder der Kunde unmögliche Bearbeitungszeiten erwartet und Sie beschuldigt, wenn unmögliche Anforderungen nicht erfüllt werden, ist es ehrlich gesagt an der Zeit, nach einem anderen Job oder einem anderen Kunden zu suchen.

Geben Sie Ihrem Chef die minimale und schnellste Interpretation der wenigen Anforderungen, die er an Sie gestellt hat, und präsentieren Sie sie schnell als abgeschlossenes Geschäft.

Zukünftige unklare Änderungswünsche sollten in Frage gestellt werden, um deutlich zu machen, dass die Änderung vorliegt kam aus dem Nichts, wo Sie gebeten wurden, Ihr eigenes Ding zu schreiben, und jetzt wird es willkürlich geändert. Fragen Sie nach konkreteren Gründen für jede Änderung, damit Sie Ihre eigenen Anforderungen entdecken und Ihrem Chef mitteilen können, dass er es ablehnt, Ihnen zu erlauben, Ihr eigenes Ding zu machen und es als sein Versagen zu betrachten.

Wenn, wie auch immer In einer guten Beziehung zu Ihrem Chef gibt er Ihnen möglicherweise die Chance zu glänzen - fragen Sie ihn nach den Mitteln, um Ihre eigenen Anforderungen zu entdecken, sich zu bewerben und zu liefern!