Unsere BAs (Business Analysts) haben die lästige Angewohnheit, uns eher Systemanforderungen als Geschäftsanforderungen zu liefern. Oft wissen sie nicht einmal, was die geschäftlichen Anforderungen sind.
Es macht mich wütend, weil ich eine Liste von Anforderungen sehe, die an die Art und Weise gebunden ist, wie sie implementiert werden soll, und nicht an das Problem, das gelöst werden soll.
Ein sehr erfundenes Beispiel wäre: „Das System sollte dem Kunden eine Bestellbestätigung per E-Mail senden.“ statt "Der Kunde muss darüber informiert werden, dass die Bestellung bestätigt wurde."
Zugegeben, in diesem Fall wird es wahrscheinlich eine E-Mail sein. Es besteht jedoch die Möglichkeit, dass wir eine geschäftliche Entscheidung treffen, um sympathischer zu sein, und Bestellungen mit Telefonanrufen nachverfolgen möchten, um zu überprüfen, ob sie alles gefunden haben, wonach sie gesucht haben, usw.
Andere Beispiele sind heimtückischer. Ich arbeitete mit etwas, das die Umverteilung der Verteilung auf verschiedene Standorte basierend auf den Verkäufen handhabte. Die Bestellung wird zunächst aufgegeben, indem ein Betrag von X $ an Geschäft X, ein Betrag von $ Y an Geschäft Y und ein Betrag von $ Z an Geschäft Z gesendet wird. Allerdings sind seit der Erstbestellung 6 Monate vergangen, und wir sehen, dass Geschäft Z jetzt Geschäft Y übertrifft , deren Verkäufe gesunken sind. Wir wollen die Ware, die wir verteilen, zwischen den Filialen tauschen. Die mir gegebenen Geschäftsregeln waren sehr eng an die Implementierung gebunden, und in vielen Fällen, in denen X->Y, Y->Z und Z->X keine Vertauschungen auftreten würden, obwohl unsere Augen sehen können, dass wir buchstäblich gerecht sind Waren zwischen den Läden hin- und herschieben.
Also habe ich einen neuen Ansatz vorgeschlagen, die Bestellungen in eine Warteschlange zu stellen, sie zu sortieren, die Geschäfte nach Verkäufen zu sortieren und dann die Listen auf diese Weise neu abzugleichen. Sicherstellen, dass die meistverkauften Geschäfte die größten Bestellungen erhalten.
Da ich die Geschäftsregel jedoch nicht wirklich kenne und nur den Mischalgorithmus kenne, der mir falsch erscheint, muss ich zur Behebung zurück zu den Benutzern gehen und die Geschäftsregeln abrufen ... was hätte getan werden sollen der erste Ort.
Was ich frage, ist, gibt es einen Trick, um gute Anforderungen zu sammeln, die auf Geschäftsregeln basieren? Wie kann ich die BAs dazu bringen, dies zu tun, wenn sie es noch nicht sind? Es fällt mir schwer, den Unterschied zwischen Geschäfts- und Systemregeln zu erklären ... und sie verstehen es eindeutig nicht. Wie kann ich sie erziehen und ihre Fähigkeiten verbessern?
Ändern Sie das Format. Traditionelle funktionale Anforderungen sind ziemlich fehlerhaft und konzentrieren sich jahrzehntelang auf das „Was“ und nicht auf das „Warum“ oder das „Wer“.
User Storys und User Persona-basierte Anforderungen konzentrieren sich auf das „Wer“ und das „Warum“. Während Agile heute der offensichtlichste Benutzer davon ist, ist es kein neues Konzept. Ich habe zum ersten Mal von diesem Konzept durch eine Produktmanagement-Methodik aus dem Aufruf „Building a Market Focused Organization“ aus den 1990er Jahren erfahren.
Nehmen Sie die US-Banken in den 70er und 80er Jahren. In ihren Bemühungen, in der Zeit nach der Deregulierung wettbewerbsfähiger zu werden, wandten sie sich an ihre Kunden. Sie begannen nicht damit, was zu tun war, sie begannen damit, den Kunden Fragen zu stellen. Dann sahen sie sich an, was die Kunden sagten: "Längere Öffnungszeiten, mehr Kassierer." und fragte, wie sie das lösen könnten (ohne die $ für längere Arbeitszeiten und mehr Kassierer auszugeben). Der Ausläufer sollte eine Technologie nutzen, die es seit Mitte der 60er Jahre gab, die aber als Gadget ohne echten Markt gelitten hatte. Und so kamen Geldautomaten vorbei.
Verwenden Sie also User Personas und User Stories. Mike Cohn hat zwei sehr gute Bücher zu diesem Thema veröffentlicht, die ich sehr empfehlen kann.
Ich habe kürzlich einen zweiteiligen Blog über die Verwendung agiler Praktiken auf der Ebene der Produktanforderungen erstellt, um brauchbare Anforderungen voranzutreiben. Bei Interesse ist mein Blog in meinem Profil verlinkt. Suchen Sie nach den Blogs „Garbage in, Gorilla out“ und „How much is that gorilla in the window“.
Was tun Sie, um sicherzustellen, dass Sie die gewünschten Anforderungen erfüllen?
Ich habe mehrere Jahre als BA in einem großen Unternehmen praktiziert. Ich werde Ihnen sagen, dass dies kein ungewöhnliches Problem ist, das Sie haben. Ich kann Ihnen auch sagen, dass es nur behoben wird, wenn Sie und die BA auf derselben Seite stehen.
Ja, der BA soll die Anforderungen in einer Weise dokumentieren, die vom Entwicklerteam leicht konsumiert werden kann. Das Entwicklerteam soll Code produzieren, der funktioniert und keine Supportanrufe (die Sie nicht annehmen müssen) verursacht.
In jedem Fall ist das Einholen von Anforderungen nur ein Teil der Arbeit eines BA. Der andere Teil besteht darin, die NICHT-technischen Führungskräfte zu gewinnen, die das Scheckbuch führen, das Sie beide dafür bezahlt, Anforderungen zu stellen, die sinnvoll sind und sich nicht jede Woche ändern. Ich kann Ihnen versprechen, dass sie Ihr Problem überhaupt nicht verstehen.
Wenn Sie anfangen, nach Arbeit zu suchen, bei der der BA ein Rockstar sein wird, werden Sie in Ihrer Karriere nach einer Menge Arbeit suchen.
Warum nicht mit dem BA auf die Seite gehen. Nach der Arbeit, auf einen Kaffee oder was auch immer, und helfen Sie ihnen, Ihre Bedürfnisse zu verstehen. Bringen Sie ihnen bei, die Fragen so zu stellen, dass sie die Anforderungen so erfassen, dass Sie effizient konsumieren können. Es ist eine Win-Win-Situation für Sie beide.
Oh, und ich habe programmiert, bevor ich BA wurde, und tue es heute noch, also weiß ich, warum Ihre Anforderungen sauber sein müssen.
Sie sind sich nicht sicher, ob Sie die Möglichkeit, die Zeit und die Ressourcen hätten, bestehende Anforderungen abzulehnen und sie basierend auf einer eher geschäftlichen Perspektive neu schreiben zu lassen.
Wenn Sie die Möglichkeit haben, versuchen Sie, mit dem zuständigen Manager zusammenzuarbeiten und eine Vorlage für ein Geschäftsanfrage- / Änderungsanfrageformular (je nach Art der Maßnahme) für zukünftige Anforderungen zu erstellen. Diese Vorlage sollte alle relevanten Informationen wie Name des Anforderers, Daten, erforderliche Spezifikationen und Erwartungen des Endbenutzers enthalten. Sie können beliebig viele Felder hinzufügen, um die für Sie geeigneten Informationen zu sammeln.
Versuchen Sie, seine Aufmerksamkeit auf die Abschnitte „ Endverbrauch “ oder „ Geschäftserwartung “ zu lenken, in denen der Analyst das erwartete Ergebnis kurz beschreiben muss. Bitten Sie diesen Manager, das Format mit Ihnen abzustimmen (damit er in Zukunft eine Ablehnung nicht als etwas Persönliches betrachtet) und geben Sie Beispiele für gewünschte Eingaben in der Vorlage an, damit er sie nur überschreiben muss.
Wenn sie ihre Anfragen per E-Mail senden und das ordnungsgemäß ausgefüllte Formular anhängen, erhalten Sie zumindest einen robusten Mechanismus, der es Ihnen ermöglicht, jede Anfrage, die die vereinbarten Kriterien nicht erfüllt, direkt abzulehnen.
Denken Sie nur daran, dass die Verbesserung nicht von einem Tag auf den anderen eintritt und Sie mit ihnen zusammenarbeiten müssen, damit sie Ihnen die richtigen Informationen liefern, aber ihnen eine praktikable Lösung zu bieten, wird Ihnen helfen, Ihr Ziel zu erreichen.
Ich habe einen Artikel zum Dokumentieren von Geschäftsanforderungen gefunden, der zusätzliche Einblicke enthält:
Es gibt keinen Trick. Eine Anforderung mit dem passenden Wortlaut auf der richtigen Abstraktionsebene zu schreiben, ohne die Lösung einzubeziehen, erfordert ein wenig Geschick, Analyse und Überlegung. Das soll der BA für dich tun. Das Konzept zu verstehen ist einfach, es tatsächlich zu schreiben ist etwas schwieriger. Wenn Ihr Mitarbeiter in dieser Rolle das Konzept nicht einmal verstehen kann, dann haben Sie die falsche(n) Person(en). Werfen Sie einen Blick auf Ihre Wissens-/Fähigkeitsanforderungen, die Sie für diese Rolle haben, schreiben Sie sie um und suchen Sie dann nach neuen Talenten. Die Suche nach einem "Trick" ist ein Nichtstarter.
EDIT: Ich könnte dafür sein, die Arbeit zurückzuziehen. In einem Prozess wird der nächste Schritt durch die Ausgabe des vorherigen Schritts ausgelöst. Der vorherige Schritt hat ein Abschlusskriterium, das besagt, dass die Arbeit hier abgeschlossen ist. In ähnlicher Weise hat der nächste Schritt Eintrittskriterien, anhand derer die Eingaben aus dem vorherigen Schritt getestet werden, um sicherzustellen, dass sie einsatzbereit sind. Wenn es fehlschlägt, wird es zurückgewiesen und der nachfolgende Schritt startet nicht.
Die Arbeit der BA zurückzuziehen, wird wahrscheinlich ein wenig Aufruhr in Ihrer Organisation verursachen, aber es ist ein Symptom für ein Problem in Ihrem Prozess und möglicherweise der schnellste Weg, wenn auch politisch riskant, es endgültig zu beheben, z. B. BA ersetzt.
Mit gutem Beispiel vorangehen. Machen Sie entweder selbst ein paar gute, um sie zu teilen, oder engagieren Sie einen Rockstar. Sie müssen auch herausfinden, warum diese Leute fehlen. Viele BAs machen den Job, weil sie ihr Geschäft lieben. Andere machen es, weil sie nicht technisch genug zum Programmieren sind. Die letztere Gruppe konzentriert sich eher auf das Wie als auf das Was oder Warum, weil sie es nicht besser wissen.
Ich konzentriere mich darauf, so unparteiisch wie möglich zu sein, und biete zwei Standpunkte an:
Aus Sicht des Business Analysten: Wie bereits erwähnt, muss er sich auf das WAS konzentrieren . Wenn er WIE sagt , ist die Anforderung (aus geschäftlicher Sicht) nicht optimal. Da gibt es die Definition optimaler Anforderungen (aus BABoK ): Sie sollen zusammenhängend, vollständig, widerspruchsfrei, korrekt, durchführbar, modifizierbar, eindeutig und überprüfbar sein. Sie können es verwenden, um Lücken in den Anforderungen zu finden.
Aus Sicht der IT-Abteilung: Die Kernaufgabe der IT ist es , den Anforderungen entsprechend zu bauen . Wenn die BA mit dem Unternehmen bestätigt hat, dass das „System dem Kunden eine Auftragsbestätigung per E-Mail senden soll“ und es zwischen den Teilen vereinbart wird, gibt es nichts anderes, was die IT tun kann (noch muss!). Das Geschäft akzeptierte die Mail-Lösung.
Nun zum Kommunikationsfluss: Wenn die BA der Kanal zwischen IT und Business ist, dann:
Im ersten Fall glaube ich fest daran, dass diese Frage nicht gestellt wurde. Wenn wir letzteres für selbstverständlich halten, haben wir Rollen miteinander verflochten: BA versucht, die Arbeit des Funktionsanalytikers zu erledigen, und auch umgekehrt. Wer weiß ... vielleicht hat Ihr BA eine ähnliche Frage in einem BA-Forum gestellt (mein IT-Leiter hört nicht auf, verschiedene Ansichten zu den von mir entdeckten Problemen anzubieten).
Erfolg!
Was ich frage, ist, gibt es einen Trick, um gute Anforderungen zu sammeln, die auf Geschäftsregeln basieren?
Wenn es einen einzigen Trick gibt, ist es, sich zunächst ausreichend darüber im Klaren zu sein, wem das Projekt helfen soll. Wer (oder was) profitiert von einem erfolgreichen Ausgang Ihres Projekts? Dies wird manchmal als Stakeholder-Analyse oder Stakeholder-Mapping bezeichnet . Meiner Erfahrung nach hat ein typisches IT-Projekt zwischen 20 und 40 Stakeholder, die alle ein direktes oder indirektes Interesse an dem Projekt haben. Aber natürlich sind einige wichtiger als andere, um das Projekt glücklich zu machen! Hinweis: Direkte „Anwender“ der Software sind nur einer davon und mit ziemlicher Sicherheit nicht der wichtigste (z. B. ihre Chefs?).
Sobald Sie ein Modell der Stakeholder erstellt haben, können Sie sich nacheinander auf jeden einzelnen konzentrieren und fragen: "Was tun sie?" und ganz entscheidend: „Was an dem, was sie tun, muss verbessert werden?“. Dokumentieren Sie „wie sie tun, was sie jetzt tun“, um Hintergrundinformationen zu erhalten, und halten Sie auf jeden Fall alle Ideen fest, die sie haben könnten, um Dinge zu verbessern. ABER halten Sie diese in Ihren Spezifikationen getrennt und getrennt.
Wie kann ich die BAs dazu bringen, dies zu tun, wenn sie es noch nicht sind?
Eine bewährte Technik, um eine ausreichende Qualität von Projektartefakten in Nicht-Software-Engineering-Disziplinen sicherzustellen, ist die Verwendung von Inspektionstechniken, die mit Eingangs-/Ausgangskriterien gekoppelt sind. Sie können der Fertigungseinheit keine technische Zeichnung eines Flugzeugflügels geben, es sei denn, Sie wissen, dass sie ein ausreichendes Maß an objektiver „Korrektheit“ aufweist (z. B. weniger als ein potenzieller schwerwiegender Fehler pro Zeichnungsseite).
Einige Praktiker wendeten diese Techniken ab den 1960er Jahren auf Software an ( siehe zum Beispiel dieses Buch für eine Sammlung früherer Arbeiten). Ich empfehle Gilbs „Agile SQC“-Sampling - basierte Messtechnik. Es wird Ihnen billig und objektiv sagen, wie viele "Hauptfehler" (auch bekannt als "potenzielle Fehler") es pro von Ihren BAs erstellter Spezifikationsseite geben könnte. Sie können sich dann als Organisation darauf einigen, dass es wirtschaftlich nicht akzeptabel ist, Anforderungsspezifikationen an ein Entwicklungsteam weiterzugeben, die ein bestimmtes Fehlerniveau überschreiten (z. B. „10 pro Seite mit 300 Wörtern“). Es kann wirklich helfen, Egos und Emotionen aus dem Prozess herauszunehmen.
Wie kann ich sie erziehen und ihre Fähigkeiten verbessern?
Ein wunderbarer Nebeneffekt der Verwendung von Agile SQC im Laufe der Zeit, wenn es richtig gemacht wird, ist, dass es sich selbst verbessert.
Aus dem Gilb Agile SQC-Papier :
„Langfristig besteht die effektivste praktische Lösung darin, Agile SQC als Teil des Unternehmensprozesses zu übernehmen und vor allem sicherzustellen, dass jeder einzelne Verfasser von Spezifikationen die Fehlerdichtekriterien (und die daraus resultierende „No Exit“-Konsequenz) ernst nimmt. Sie werden es dann tun lernen, die Regeln zu befolgen, und reduzieren dadurch ihre persönliche Fehlerinjektionsrate. Im Durchschnitt sollte die persönliche Fehlerinjektionsrate nach jeder Erfahrung mit der Verwendung des (agile) SQC-Prozesses um etwa 50 % sinken."
SBWorks
CaffGeek
Thiago Cardoso