Die Anforderungserfassung wird unterbrochen, wenn die Zeit für die Anforderungserfassung zu lang ist

Ich mache ein kleines Projekt. Benutzer können nur einen Teil der Anforderungen bereitstellen. Der Zeitraum der Erfassung der Benutzeranforderungen dauerte zwei Monate. Aber es scheint, dass wir für die restlichen Anforderungen keine Informationen erhalten werden.

Soll das Projekt in zwei Phasen aufgeteilt werden? Eine Phase, um das System für die bestehende Anforderung zu starten. Die zweite Phase könnte die „Reset-Anforderung“ sein und die zweite Anforderung starten, wenn der Benutzer denkt, dass die „Reset-Anforderung“ fertig ist.

Ist dies üblich, wenn Bedarfe für einen bestimmten Zeitraum nicht erhoben werden können?

Antworten (3)

Unabhängig davon, ob Sie ein großes oder ein kleines Projekt durchführen, sollte Ihr Ansatz in etwa so aussehen:

  • Finden Sie heraus, was die Benutzer wollen (sprechen Sie zum Beispiel mit ihnen)

  • Bauen Sie eine kleinste Version davon (z. B. keine Benutzerverwaltung, nur mit Dummy-Daten usw.) und fragen Sie nach ihrer Meinung

  • Wenn es ihnen gefallen hat, beginnen Sie mit der Verbesserung der Funktionalität (fügen Sie hinzu, was Sie brauchen, um es produktionsreif zu machen).

  • Wenn sie sie nicht fragen, warum und was es besser machen könnte

Wiederholen, bis "Projekt" fertig ist.

PS Sie werden nie vollständige Anforderungen haben, bevor Sie Ihren Benutzern nicht mehrmals etwas gezeigt haben. Aus diesem Grund ist es im Allgemeinen keine gute Idee, die „Anforderungsphase“ länger als ein oder zwei Wochen zu haben, bevor Sie mit dem Bau beginnen. Und mindestens 50 % der Anforderungen, die Sie von den Benutzern zum Start erhalten, werden sich ändern. Der Prozentsatz kann auch über 100 liegen (was bedeutet, dass sich auch die geänderten Anforderungen ändern werden)

Ja. Das System wird mit den bestehenden Anforderungen entwickelt. Tatsächlich löschen Benutzer die Reset-Anforderung nicht, sodass sie zu lange ansteht.
Außerdem hat sich herausgestellt, dass es bei der agilen Methodik ziemlich schwierig ist, die Kosten zu bewerten, da sich die Anforderungen ändern können.
@BenCheng das liegt nicht an der agilen Methodik; agile macht es nur transparenter, dass es passiert.

Sie werden nie alle Informationen für Anforderungen haben, also ...

Für dieses kleine Projekt können Sie vorschlagen, die beste Lösung zu entwickeln, die Sie mit den verfügbaren Ressourcen (Informationen, Budget und Zeit) erstellen können. Wenn sich die Situation weiterentwickelt, ändern sich auch Ihre Optionen.

Wenn dies keine Option ist, werden Sie möglicherweise zum Scheitern verurteilt.

Wie kann ich für den Kunden Gebühren erheben, wenn die Anforderung nicht gut erfasst werden kann?

Ist dies üblich, wenn Bedarfe für einen bestimmten Zeitraum nicht erhoben werden können?

Es könnte jedoch passieren, dass Sie etwas erraten oder ignorieren, wenn Sie etwas nicht wissen. Wenn diese Sache für den Benutzer wichtig ist, werden sie wahrscheinlich nicht glücklich sein, es sei denn, Ihre Vermutung war richtig! Menschen, die ein bestimmtes Geschäft gut kennen, können aufgrund früherer Erfahrungen manchmal kleinere Details erraten. Auch dies funktioniert möglicherweise nicht immer. Beispielsweise hat jede Bank ihre eigene Richtlinie, wenn sie einen neuen Kunden für ein Darlehen bewertet. Wenn Sie die Regeln überspringen oder die Kriterien einer anderen Bank verwenden, hilft dies nicht.

Wenn Sie nicht alle Anforderungen erfüllen können, liegt dies entweder daran, dass die Benutzer nicht wissen, wie sie Ihre Fragen beantworten sollen, oder daran, dass Ihr Team nicht in der Lage ist, die richtigen Fragen zu stellen. In jedem Fall wäre das Projekt gefährdet. Bestimmte Anforderungen können wie von Ihnen vorgeschlagen in einer zukünftigen Version schrittweise eingeführt werden. Dies kann jedoch in einigen Fällen riskant sein. Beispielsweise erfordert das Fehlen einer Viele-zu-Viele-Beziehung zwischen zwei Tabellen in einem Projekt, das eine relationale Datenbank verwendet, Arbeiten an der Datenbank und möglicherweise eine Änderung der GUI. Ein praktischer Ansatz ist:

  1. Identifizieren Sie, was fehlt.
  2. Stellen Sie fest, warum es nicht abgeschlossen wurde.
  3. Wenn das Problem in Ihrem Team liegt, beheben Sie es.
  4. Wenn das Problem das Benutzerteam ist, identifizieren Sie das Risiko und die möglichen damit verbundenen Kosten klar. Fragen Sie vielleicht nach einer Änderung im Benutzerteam. Verwenden Sie Eskalationsverfahren, um die großen Fische darauf aufmerksam zu machen.
  5. Wenn Sie Annahmen treffen, dokumentieren Sie diese Annahmen sorgfältig.
  6. Lassen Sie sich den gesamten Analyseaufwand abnehmen – die guten und die schlechten Teile der Analyse.
  7. Denken Sie immer daran, dass eine unvollständige oder schlechte Analyse jedes Projekt leicht töten kann.

Dies kann relevant sein: Umgang mit unvollständigen Anforderungen

Da es sich bei dem Projekt um ein Festpreisprojekt handelt, erhöhen Anforderungsänderungen oder unklare Anforderungen meine Projektkosten. Ich möchte das Wechselgeld oder die verbrauchte Zeit in Rechnung stellen, aber ich kann meinen Kunden unglücklich machen.
@Keine Änderung. Da die Anforderung nicht vollständig erfasst wird, ist es sehr schwierig, eine Genehmigung für den Analyseaufwand zu erhalten.
Es tut mir leid, sagen zu müssen, dass Sie sich auf Festpreisprojekte einlassen sollten, es sei denn, Sie kennen den Kunden gut oder wissen, dass Sie die Superkräfte haben, das Unbekannte zu tun. Viele große Unternehmen verlieren bei solchen Projekten. Es ist seltsam, dass Ihr Kunde die Anforderungen nicht erfüllt.
Dies liegt daran, dass der Benutzer die Anforderungen nicht kennt. Sie sind nur eine Arbeitseinheit und haben kein vollständiges Bild des Geschäftsablaufs. Manchmal haben sie viele seltsame Ideen, können aber keine Anforderungen sein. Außerdem können andere Faktoren dazu führen, dass sie keine Anforderungen stellen möchten. Sie wollen zum Beispiel keine neuen Dinge lernen.
Softwareentwicklungsprojekte sollten also nicht zum Festpreis abgerechnet werden?
Festpreisprojekte bringen den Anbieter der Software automatisch vom ersten Tag an in eine schlechte Situation. Entwicklung sollte eine geteilte Verantwortung sein, eine Teamarbeit, kein Rechtsgeschäft. In Ihrem Fall schlage ich vor, dass Sie das Projekt auf die Bereiche ausdehnen, in denen die Anforderungen erfüllt sind. Wenn der Anwender nicht lernen will oder die Anforderungen ständig ändert, dann kann man im Festpreisvertrag nicht gewinnen.
Da ich weiß, dass die meisten Outsourcing-Projekte Festpreise wären, wie gehen sie mit dieser Situation um?
Sie handhaben die Situation, indem sie in Projekte einsteigen, in denen sie gute Geschäftserfahrung haben, und sich durch einen Vertrag absichern, der besagt, dass der Kunde kooperieren muss. Denken Sie daran, dass der Kunde nicht nur die Leute sind, die Sie jeden Tag treffen, der Kunde umfasst auch die Chefs des Unternehmens, diese Leute wollen das bekommen, wofür sie bezahlen, also ist es in ihrem Interesse, zu erfahren, was Sie liefern und das zu lösen Probleme für Sie, damit Sie es schaffen können. Sie sollten auf Ihrer Seite berücksichtigt werden.
Bedeutet das, dass bei einem Festpreisprojekt das Risiko sorgfältig abgeschätzt und einkalkuliert werden sollte?
Bevor Sie etwas unternehmen, müssen Sie die Risiken bewerten und einen Plan erstellen, der zeigt, wie Sie mit diesen Risiken umgehen wollen. Normalerweise können Sie Teile dieses Plans mit dem Kunden besprechen. Kein Projekt ist risikofrei.
Die Anforderungserfassung wird unterbrochen, wenn die Zeit für die Anforderungserfassung zu lang ist
AntwortenHierDatenschutz-Bestimmungen1y, 0v