Ich stelle mir vor, ich w�re der User von dem System. Also habe ich das Problem, dass ich nunmal selbst ungenaue Daten hab. Das bl�de System will es aber ganz genau wissen. Was ist mein erster (und wahrscheinlich auch letzter) Gedanke? Wer beschissen werden will, wird beschissen. Das ist genau das Thema, mit dem ich tagt�glich k�mpfe. K�nnte Romane erz�hlen zu welcher Kreativit�t der Mensch f�hig ist.
Am anderen Ende sitzt ein armseliger Programmierer, der sich mit der Aufgabe konfrontiert sieht nebul�se oder schlicht dumme Vorgaben so umzuwandeln dass die Kiste, die ja nur ganz genau das macht was man ihr sagt, auch versteht und tut. �ber das Konfliktpotential in der Situation k�nnte ich auch ein paar Jahre Lebenserfahrung beitragen. Ich habe f�r mich nur eine saubere L�sung auf das Problem gefunden: glasklares Prozess Management. Alles andere macht entweder die Nutzer sauer oder den Auftraggeber. In beiden F�llen kriegt der Programmier die alleinige Schuld und wundert sich wom�glich warum er die meisten �berstunden macht und am Ende als der gr��te Idiot dasteht. Am konkreten Beispiel: Technisch gibt es eine Reihe von M�glichkeiten. Ich kann dem Benutzer sehr wohl eine Palette an Eingabem�glichkeiten zur Verf�gung stellen. Es sollte kein Problem sein eine Freitexteingabe wie "morgen", "n�chstes Jahr", "q3" etc. zu interpretieren bzw. notfalls f�r die 5 Ausnahmen pro Jahr bei Benutzer zur�ckzufragen "wie hast Du es gemeint". Genauso sollte es kein Problem sein einen Eintrag freizulassen. Oder 1.1.2100 einzutragen um anzudeuten "so genau wissen wir es auch noch nicht". Wie geht es dann weiter? Ich schreibe ein kleines Management summary. Was mir hilft ist das SPIN Modell. Beispiel Situation Arbeitsgruppe X macht jene T�tigkeit und ben�tigt zur Verbesserung ihrer Produktivit�t ein xyz Tool. Zur Planung von ... ist es erforderlich, dass Berichte vorliegen, die .... aussagen. Problem Projektende Daten k�nnen nicht zuverl�ssig vorausgesagt werden. Die geforderte Berichtsfunktionalit�t macht es notwendig dass die Applikation eine Standardannahme treffen muss. Die konkrete Auspr�gung dieser Standardannahme ist nicht definiert / nicht abgestimmt / [jeder hat eine andere Meinung dazu] Implication Ein Nicht-L�sen des beschriebenen Knotens f�hrt dazu, dass die Applikation nicht on time, [on budget], [mit geforderter Funktionalit�t] fertiggestellt werden kann Need Eine Entscheidung dar�ber wie verfahren werden soll. Bis hierhin sollte es reichen, um die Betroffenen (die Kunden) f�r das Problem einzukaufen. An der Stelle kommt dann Kleverle Programmierer um die Ecke und macht zwei kreative Vorschl�ge (ruhig ein bischen aus der �blichen Denke rausgehen) mit jeweiligen Vor- und Nachteil. Hier im Beispiel: langes Programm, das vieles selbst interpretiert. Pro: easy user experience. Cons: erh�hte Kosten/Zeit, versp�teter Fertigstellungstermin. Oder ich zwinge den User genaue Angaben zu machen, wobei 3 im Jahre im voraus eine g�ltige Vorgabe ist. Pro: Einhaltung Termin und Budget Cons: der User muss mehr Zeit aufwenden (kostet auch Geld). Am Ende steht die Frage sollen wir a oder b machen? Wobei hier zus�tzlich ein Mittelweg auch denkbar w�re. Damit ist das Problem zu 100% dort wo es hingeh�rt. Die Auftraggeber haben Input auf der Basis die sie verstehen (Geld und Zeit - der Rest ist eh meist unrelevant). Der Programmierer ist aus dem Schneider, denn zaubern kann er auch nicht. Aber ein bischen Arbeit macht das schon. -- Viele Gr��e Hubert Daubmeier | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
