So nahm ich noch ein anderes Buch auf der Softwareentwicklung auf und fing an zu lesen. Ich war nicht im Stande, es zu beenden, weil es mir solch ein Kopfweh gibt. Alle wenigen Seiten bekomme ich den unwiderstehlichen Drang, meine Stirn zu schlagen. An dieser Rate bin ich dabei, eine Gehirnerschütterung durch das Kapitel drei zu bekommen. Every few pages I get the irresistible urge to slap my forehead. At this rate, I'm going to get a concussion by chapter three.

Anyways, dieser Kerl geht über Voraussetzungen weiter: Wie richtige Voraussetzungsursache-Projekte zu nicht haben, über das Budget und hinter der Liste zu sein, wie Eigenschaft kriecht, zu schwer zu handhabender Projektliste und demoralisierten Entwicklern, yadda, yadda, yadda führt. Nein, wirklich? No, really?

Und seine Vorschrift ist, dass jemand die Voraussetzungen ausschreibt und veranlasst, dass alle Miteigentümer auf ihnen Schluss machen. Natürlich gibt es nicht nur eine Art der Voraussetzung - noooooo! - es gibt viele Art von Voraussetzungen. Sowie Benutzeranforderungen, es gibt Geschäftsvoraussetzungen und Designvoraussetzung und thingajig Voraussetzungen und.... Ich weiß nicht, aber viele viele bange Voraussetzungen und Mensch, wenn der Projektbetriebsleiter alle Voraussetzungen geschrieben bekommt und durch alle Miteigentümer Schluss machte, dann Halleluja, das wird EIN Projekt sein, das rechtzeitig und auf dem Budget fertig sein wird. Wenn nur jene dummen Projektbetriebsleiter schreiben konnten, dass ein guter Satz von Voraussetzungsdokumenten.... schlägt! - there are many kind of requirements. As well as user requirements, there are business requirements and design requirement and thingajig requirements and .... I don't know, but lots of lots of funky requirements and gosh, if the project manager gets all the requirements written up and signed off by all the stakeholders, then hallelujah, this will be the ONE project that will finish on-time and on-budget. If only those stupid project managers could write up a good set of requirement documents....thump!

Schade, das war mein Kopf, der den Schreibtisch schlägt. Ich denke, dass ich Bewusstsein seit ein paar Sekunden verlor.

Wollen o.k. wir versuchen, diesen Gesichtspunkt zu widerlegen, der scheint, herkömmlicher Verstand mit einer Ausnahme zu sein, wo gepanzerte schriftliche Voraussetzungen die Regel sind: Eingebettete Systeme. Grundsätzlich ist es wirklich hart, einen Span zu ändern, nachdem es entworfen worden ist. Duh. Basically, it's really hard to change a chip after it's been designed. Duh.

Für ziemlich viel ganze andere Softwareentwicklungsarbeit ist es eine gute Idee, eine Reihe einleitender Voraussetzungen niederzuschreiben. Und dann drucken Sie sie aus. Aber drucken Sie sie auf sehr weichem Papier aus, das im kleinsten Zimmer des Hauses verwendet werden kann. Weil in einer sehr kurzen Zeitspanne es das einzige Zimmer ist, wohin dieses Stück von Papier dabei ist, nützlich zu sein. But print them out on very soft paper that can be used in the smallest room of the house. Because in a very short period of time, that's the only room where that piece of paper is going to be useful.

Es gibt zwei Hauptgründe warum, ein offensichtlicher & ein feiner. Ich werde mit dem offensichtlichen anfangen: Wollen Wir vorgeben, dass Sie der Kunde sind. Sie haben einen Vertrag mit einem Softwareentwicklungshaus unterzeichnet, um ein elegantes Programm zu bauen, das etwas tut. Sie sind bereit gewesen, Geld zu bezahlen. In den meisten Fällen bezahlen Sie viel Geld. Sie haben Ihre Unterschrift auf ein Stück von Papier für etwas gestellt, was in der Gegenwart nicht besteht. Sie sind auch schmerzlich bewusst, dass, wenn dieses Stück der Software geschaffen wird, wenn es ist, den Erwartungen Ihrer Miteigentümer nicht entspricht, sind sie dabei, Ihnen darüber mitzuteilen. Und wie entsprechen Zeiten eine Softwareausgabe 100 % der Erwartungen des Kunden? Let's pretend you are the customer. You have signed a contract with a software development house to build a nifty program that does something. You have agreed to pay money. In most cases, you are paying a lot of money. You have put your signature on a piece of paper for something that doesn't exist in the present. You are also painfully aware that when this piece of software is created, if it's does not meet the expectations of your stakeholders, they are going to let you know about it. And how times does a software release meet 100% of the customer's expectations?

Jetzt nach dem Unterzeichnen eines Stückes von Papier dafür, was viele in Ihrer Organisation als einen obszönen Betrag des Geldes denken, vergeht eine bestimmte Zeitspanne, und Sie veranlassen, dass ein anderes Stück von Papier mit einem Titel liest feststellend, dass es ein Design/Benutzer case/business/whatever Voraussetzungsdokument ist. Sie lesen das Dokument durch. Es sieht o.k. aus. Es gibt einen Raum für Ihre Unterschrift. Vielleicht unterzeichnen Sie es. Vielleicht senden Sie eine E-Mail zurück sagend, dass Sie ein Stück von Papier für soundsovielte Millionen von Dollars unterzeichneten, und es das einzige Stück von Papier ist, muss jemals unterzeichnen. Aber wollen wir vorgeben, dass Sie auf den Voraussetzungen der Doktor Schluss machen. Bedeutet das, dass Sie, der Kunde, das Recht aufgegeben haben, sich jemals in Verbindung zu setzen, kommunizieren oder nörgeln, die Entwicklung tun sich mit neuen Eigenschaften und/oder Voraussetzungen zusammen? It looks okay. There's a space for your signature. Maybe you sign it. Maybe you send back an e-mail saying you signed a piece of paper for umpteenth millions of dollars, and that's the only piece of paper need to sign, ever. But let's pretend you sign off on the requirements doc. Does this mean that you, the customer, have given up the right to ever contact, communicate or nag the development team with new features and/or requirements?

Nein. Nie. Jemals. Es gibt keinen Kunden, der jemals von jeher bestanden hat, der die Entwicklung für neue Eigenschaften direkt bis zum Moment der Ausgabe und danach nicht ständig belästigen wird. Kommen. Verwendet. Dazu. Es. Ever. There is no customer that has ever existed since the beginning of time that will not continually pester the development for new features right up to the moment of release and after. Get. Used. To. It.

So ist die Lehre für jeden Projektbetriebsleiter nicht, verbringen zu viel Zeit beim Zeichnen der Voraussetzung die Doktoren. Sicher, schlagen Sie sie schnell dröhnend, und ich meine schlagen sie dröhnend, aber wenn, Wunder von Wundern, der Kunde einen o.k. und ein Schluss gemachtes Dokument zurücksendet, denken Sie nicht sogar, dass Ihr Job beendet wird. Der Spaß hat gerade angefangen. The fun has just started.

Das bringt meinen zweiten Punkt über das Fallen in die Falle der Dokumentieren-Voraussetzungen herauf: Das Bekommen aller Voraussetzungen ist superhart. In den meisten Fällen ist es unmöglich. Nicht sogar können der Kunde, und der Kunde des Kunden, Ihnen 100 % der Voraussetzungen geben. In most cases, it's impossible. Not even the customer, and the customer of the customer, can give you 100% of the requirements.

Schau mal, es ist dem Gehen zum Fanclub von Julia Roberts und Ausspruch ähnlich: "Wir wollen eine Liebesgeschichte mit Julia und Brad Pitt machen. Sie verlieben sich, sie kämpfen & Bruch, und dann machen sie sich zurecht und verlieben sich wieder. Am Ende des Films, jedes im Publikum, weil der Film so wunderbar war. Hier ist die Schrift des Films. Können Sie uns versichern, dass nach dem Sehen dieses Films Sie nach Ihrem Taschentuch greifen werden?" They fall in love, they fight & break-up, and then they make up and fall in love again. At the end of the movie, everybody in the audience because the movie was so wonderful. Here is the script of the movie. Can you assure us that after seeing this movie, you'll reach for your hankie?"

Lassen Sie mich ein Beispiel von der echten Welt nachzählen (Ich habe einige der Details geändert, um den Unschuldigen zu schützen): Einer des Kunden von Creo hatte etwas Drucktechnologie, die mit einem Softwaregefolge entwickelt am Anfang der 1990er Jahre lief. Creo hat eine Vorpressesoftware entwickelt ungefähr ein Jahrzehnt später, der gewaltig höher ist. Jedoch gab es einige einzigartige Eigenschaften, die erforderlich waren, um entwickelt und zum Softwaregefolge von Creo hinzugefügt zu werden. Creo has some pre-press software developed about a decade later that is vastly superior. However, there were some unique features that were needed to be developed and added to Creo's software suite.

Planen Sie, dass das Management für den Kunden aus der Zentrale Mitte die Vereinigten Staaten koordiniert wurde, wohingegen die Drucktechnologie an der Pflanzenseite in der Nähe von der Westküste beruhte. Ich flog unten zum Werk, um mit dem Softwaregefolge von Creo und Festnahme-Voraussetzungen zu protzen. Tat die Präsentation, flog zurück nach Vancouver. Ein paar Wochen später bekommen wir die diplomatische Nachricht von der Zentrale, dass vielleicht alle Voraussetzungen nicht gewonnen worden sind. So fliege ich unten wieder. Ich veranlasse auch, das Softwaregefolge von Creo auf einem Server und verladen zur Pflanzenseite als ein loaner laden zu lassen. Dieses Mal, während der Präsentation, haben sie ihren Überbenutzer, ihren Systemverwalter verfügbar. Ich bin glücklich, dass der Kunde klug genug ist, um ihre Benutzer zur Präsentation herauszubekommen, um das Gefolge zu kritisieren. Der Überbenutzer geht tief auf mir. Das bedeutet, dass sie unten bohrt, verdunkeln viele Niveaus zu einigen wirklich (zu mir), aber wichtig (für sie) Geschäftsvoraussetzung, die nicht in unserem Softwaregefolge ist. Ich versprach, auf jenen Eigenschaften mit einigen von den SMEs von Creo zu folgen (Gegenstand-Experten), wenn ich zum Büro zurückkomme. Did the presentation, flew back to Vancouver. A couple of weeks later, we get the diplomatic message from head office that perhaps all the requirements have not been captured. So I fly down again. I also arrange to have Creo's software suite loaded on a server and shipped to the plant site as a loaner. This time, during the presentation, they have their super-user, their system administrator on hand. I am lucky that the customer is smart enough to get their users out to the presentation to critique the suite. The super-user goes deep on me. That means she drills down many levels to some really obscure (to me) but important (for them) business requirement that is not in our software suite. I promised to follow up on those features with some of Creo's SMEs (subject matter experts) when I get back to the office.

Inzwischen kommt der Server mit der Software von Creo vor Ort mit einem lokalen Feldrips an, um zu tun, installieren und einleitende Ausbildung. Ich treffe auch Vorkehrungen, dass ein Trainer mit einem Vor-Ort-Besuch im Kunden eine Woche später nachstößt. Ich weise den Trainer vorein, um zuzusehen & für irgendwelche neuen Voraussetzungen zu berichten. Sechs Wochen später sende ich einen anderen Trainer. Ungefähr fünf Monate sind seit meinem ersten Besuch im Kundengefolge gegangen. Schließlich ist der Überbenutzer im Stande, die Voraussetzungen zu artikulieren, dass das Werk dem Vertreter von Creo braucht, der auch ein SME in diesem besonderen Subthema ist. So ließen wir die Voraussetzungen gewinnen und wir sie der Entwicklungsmannschaft weitergeben und wir die Nachricht zurück bekommen, dass keine der Voraussetzungen unmöglich ist zu erfüllen, wird man ungefähr drei Monate brauchen, um in die folgende Steigung zu rollen. Ende der Geschichte. I pre-brief the trainer to watch & report for any new requirements. Six weeks later, I send another trainer. About five months have passed since my first visit to the customer suite. Finally, the super-user is able to articulate the requirements that the plant needs to the Creo representative who is also a SME in that particular sub-topic. So we get the requirements captured and we pass them on to the development team and we get the message back that none of the requirements are impossible to fulfill, it will take about three months to roll into the next upgrade. End of story.

Bemerken Sie jetzt, dass in diesem Fall studieren:
1. Der Kunde war hoch entwickelt, verstehend, dass wir den Überbenutzer viel Zeit mussten verbringen lassen, mit unserer Software spielend, so konnte sie entdecken, was vermisst wurde.
2. Wir hatten viel Zeit. Das Bekommen der richtigen Voraussetzungen nahm fünf Monate. Das Codieren der Voraussetzungen nahm zwei Wochen (die Verwaltungslast, neue Steigungen ins Softwaregefolge zu rollen, das seit den anderen 2.5 Monaten erklärt ist). Coding the requirements took two weeks (the administrative load of rolling new upgrades into the software suite accounted for the other 2.5 months).
3. Das war eine Modifizierung eines vorher existierenden Softwaregefolges. Wir boten dem Kunden ein "leeres Stück von Papier nicht.""
4. Das Geschäft war wert genug, um einen loaner Server mit der Software zum Werk zu senden UND insgesamt fünf getrennte Besuche im Werk (zwei Reisen durch den Projektbetriebsleiter, ein durch einen lokalen Vertreter, und zwei durch Trainer) zu haben.

Schließlich der Punkt dieses Aufsatzes ist, dass das Bekommen von Voraussetzungen in der echten Welt nicht so viel ein Punkt der Dokumentation, aber ein wiederholender Prozess mit dem Kunden ist, der durch den Lebenszyklus des Entwicklungsprozesses (und darüber hinaus) weitergeht.
Ich bin wird versuchen, das Buch zu beenden, das ich lese, wenn man sich nur zukünftigen Arbeitgebern als Schriftart (des herkömmlichen) Verstands vorstellt. Aber wirklich, wenn die Wälder mit Projektbetriebsleitern voll sind, die denken, dass sie hausfrei sind, sobald dokumentieren sie die Voraussetzungen eines Projektes am Anfang des Entwicklungszyklus, dann ist es kein Wunder, dass viele von ihnen shredded nach ein paar Jahren im Geschäft bekommen.

Markiert als: 166, 186, 83 186, 83