🚪 🐌 👨‍💼 Geschäfts- und Systemanalytiker. Was du wissen musst ❓ 👂🏽 💖

Schöne Grüße! Mein Name ist Sergey und ich bin ein Business / System-Analyst. Ich arbeite seit ungefähr 8 Jahren in der IT-Branche, angefangen bei der Unterstützung beim Testen bis hin zur Analyse: sowohl im Geschäfts- als auch im Systembereich. Ich habe noch nicht getrennt als Unternehmen und als Systemanalyst gearbeitet.

Im Laufe meiner beruflichen Aktivitäten im Allgemeinen, einschließlich Praxis- und persönlicher Interviews und insbesondere Interviews mit potenziellen Kandidaten, wurde mir allmählich klar, welche Fähigkeiten der Markt vom Analysten erwartet. Habr hat lange Zeit keine neuen Artikel zu diesem Thema gesehen, deshalb habe ich beschlossen, das Material selbst vorzubereiten.

Für wen wird der Artikel meiner Meinung nach nützlich sein:

Anfängliche Geschäfts- / Systemanalysten;
Analysten, die ihren prof weiter pumpen wollen. Kompetenzen
Vielleicht Rekrutierungsmanager.

Ich muss sofort sagen, dass die folgenden Punkte meine subjektive Vision der Spezialisierung des Analytikers sind , die während der Praxis gebildet wurde. Wenn Ihr Unternehmen ein vollwertiges Scrum mit einem Produktbesitzer durchführt, der einen Meter von Ihnen entfernt sitzt und einem Designer und einem Architekten für das Team zugewiesen ist, sind einige der oben genannten Punkte möglicherweise nicht gefragt.

Dennoch werden zumindest all diese Fähigkeiten nicht überflüssig sein und den Analytiker in seinen Fragen noch kompetenter machen. Natürlich müssen Sie verstehen, dass ich nicht alle Fähigkeiten und Fertigkeiten des Analysten aufgelistet habe (dieselben Notationen, Geschäftsfähigkeiten, SQL usw.).

Geschäftsanalysen

Beseitigen Sie mehrdeutige Anforderungen in den frühesten Phasen

Wenn Sie mit einem Geschäftskunden sprechen, müssen Sie sich bewusst sein, dass sich seine Sprache erheblich von Ihrer unterscheiden kann. Eine Geschäftsanforderung kann so geäußert werden, dass mehrere Teilnehmer am Genehmigungsprozess ein unterschiedliches Verständnis dafür haben, was diese Anforderung bedeutet. Die Mehrdeutigkeit wird erzeugt, was für das Team in späteren Entwicklungsstadien sehr teuer ist.

Das Problem ist am akutesten, wenn es mehrere Geschäftskunden gibt, von denen jeder seine eigenen Anforderungen stellt. Zum Beispiel bei der Integration von zwei Systemen, von denen jedes einen eigenen Vertreter aus dem Unternehmen hat.

Fallstudie: Ein Monat Entwicklungszeit wurde für die Übertragung der Liste der Aktivitäten von Objekt Nr. 1 auf Objekt Nr. 2 aufgewendet. In der Phase der Abnahmetests wurde festgestellt, dass der Kunde eine völlig andere Funktionalität erwartete - Kopieren, nicht Übertragen von Aktivitäten. Bei der Überarbeitung der Funktionalität und der Detaillierung der Mehrdeutigkeit stimmte das IT-Team erstens mit dem Kunden über MVP überein und zweitens über die Notwendigkeit, mit der Wurzel des Geschäftsproblems zu arbeiten. Es wurde die Hypothese aufgestellt, dass die Kopierfunktionalität selbst nur aufgrund einer unzureichend implementierten Funktionalität zum Laden von Aktivitätsvorlagen erforderlich ist.

Haben Sie keine Angst, sich beim Kunden über die Anforderungen zu erkundigen

Ich bin auf Fälle gestoßen, in denen ich herausgefunden habe, wann die Entwicklungserklärung beschrieben wurde, ohne ein Geschäftsziel festzulegen: Was genau würde diese Fertigstellung dem Geschäft helfen? Welchen Schmerz wird diese Verfeinerung vom Geschäft lindern?

Oft führten solche zwecklosen Verbesserungen bereits in der Testphase zu unangenehmen Konsequenzen, als sowohl der Entwickler als auch der Tester nicht verstanden, warum wir diese Funktionalität entwickelt haben. Schlimmer noch, der Entwickler und der Tester erhielten keine Antworten vom Analysten, und wenn doch, kamen sie oft selbst auf den Analysten: Ziele, die der Analyst selbst formuliert hatte.

Schreiben Sie gemeinsam mit dem Kunden Ziele auf, damit absolut alle Teilnehmer des Prozesses jederzeit verstehen, warum sie ihre Arbeit machen.

Fordern Sie die Teilnahme Ihrer Kunden an Geschäftstreffen

In der Praxis bin ich auf verschiedene Kunden gestoßen, von denen einige nicht sofort bereit waren, den Analysten zu ihren Offline-Meetings einzuladen. Der Analyst muss auch damit arbeiten: um zuzustimmen und das Ergebnis einer gut koordinierten Zusammenarbeit zu zeigen.

, — UX- — « », , . : , , windows-, . , .

Viele Analysten, einschließlich meiner selbst, verwendeten bei der Formulierung von Anforderungen, die mit einer harten Frist konfrontiert waren, die folgende Technik: Sie schrieben den Teilnehmern des Prozesses einen Brief mit einer Frist, bis zu der der Brief beantwortet und die vereinbarten Anforderungen / Kommentare abgegeben werden sollten. Andernfalls werden die Anforderungen automatisch als vereinbart erkannt.

Wie die Praxis gezeigt hat, ist dieser Ansatz nichts Gutes. Es ist klar, dass Sie, wenn Sie auf der Seite des Anbieters arbeiten und eine Vereinbarung haben, auf solche Methoden zurückgreifen müssen, aber dennoch versuchen, eine stillschweigende Zustimmung zu vermeiden, zu verstehen, warum die Teilnehmer Ihnen jetzt keine Antwort geben möchten, und das Problem so schnell wie möglich lösen müssen.

Es ist besser, schriftlich zu dokumentieren, dass die Antwort von solchen und solchen Personen nicht erhalten wurde und Sie darin die folgenden Risiken für das Projekt sehen. Der Arbeitsprozess kann jedoch nicht zum Stillstand gebracht werden, weshalb Sie gezwungen sind, Ihre analytische Arbeit fortzusetzen, während zuvor identifizierte Risiken allen Teilnehmern des Prozesses klar sein sollten.

Bei der Entwicklung der Integration der beiden Systeme wurden wir vom Direktor mit der Bildung von Anforderungen konfrontiert, die die Aktionen der Benutzer in den beiden Systemen abdecken, jedoch mit der fehlenden expliziten Koordination dieser Anforderungen durch den unmittelbaren Leiter der Einheit, dessen Mitarbeiter Benutzer des Systems waren.

Wie sich später herausstellte, verstand der Abteilungsleiter überhaupt nicht, warum all diese Verbesserungen und wie sie dazu beitragen würden, die Prozesse in seinem Verantwortungsbereich zu optimieren.

Oft haben Teilnehmer am Genehmigungsprozess einfach Angst, ihre Unterschrift zu setzen, weil sie bestimmte Abschnitte des aktualisierten Geschäftsprozesses nicht vollständig verstehen. Ihre Aufgabe als Business Analyst ist es, dieses Missverständnis zu beseitigen.

Bild

Stellen Sie Entwicklern den Themenbereich vor

Verbringen Sie ein paar Stunden, aber informieren Sie Ihre Entwickler über den Kunden, aktuelle Geschäftsprozesse, Schmerzen und Entwicklungspläne. Gut motivierte Entwickler machen ihre Arbeit in der Regel nicht nur perfekt, verstehen, für wen sie den Code schreiben, sondern leisten auch einen wertvollen Beitrag: Sie bieten Optimierung, Problemumgehungen und sind eher bereit, klärende Fragen zu stellen.

Wenn nötig (und ohne Scrum), locken Sie den Kunden zu einem solchen Meeting. In der Regel stimmen Unternehmensvertreter solchen Initiativen bereitwillig zu.

Bringen Sie dem Kunden bei, die Frage „Was?“ Zu beantworten, anstatt Anforderungen im Format „Wie“ zu formulieren.

Der Kunde sollte keine Geschäfts- / Benutzeranforderung aus der Position "Gewusst wie" formulieren: Wir benötigen eine Schaltfläche auf diesem Bildschirm, um einen Bericht zu erstellen. In diesem Abschnitt benötigen wir einen Link zu einem externen System. usw.

In der Phase der anfänglichen Analyse des Prozesses sollte der Kunde vor dem eigentlichen Entwurf keine Lösung anbieten.

Bringen Sie dem Kunden stattdessen bei, das Problem, seinen „Schmerz“, zu formulieren: Wir müssen wöchentlich einen Bericht erstellen, der manuell von einem Mitarbeiter ergänzt und an das Management gesendet wird. Während der Arbeit mit dem Client müssen wir zusätzliche Informationen analysieren. Da diese im CRM-System nicht verfügbar sind, müssen wir eine neue Registerkarte im Browser öffnen und uns beim benachbarten System anmelden.

Nachdem Sie den Schmerz des Kunden gelernt haben, können Sie als Spezialist Optionen zur Optimierung des Prozesses und seiner Automatisierung anbieten. Senden Sie beispielsweise den generierten Bericht automatisch an die E-Mail des Mitarbeiters, speichern Sie den Mitarbeiter vor manueller Arbeit mit dem Bericht, laden Sie im Prinzip automatisch Daten von einem benachbarten System in CRM herunter und so weiter.

In vielen Fällen wird dieser Ansatz der Realität gerecht: Fristen und Prioritäten. Aber Sie haben es auf jeden Fall ehrlich versucht.

Bild

Teilen Sie die Benutzer unbedingt in Klassen ein

Das Akzeptieren von Anforderungen durch den Benutzer des Systems berücksichtigt unbedingt seine Rolle im Geschäftsprozess. In der Praxis gibt es häufig Fälle, in denen der Abteilungsleiter die Anforderungen für die Funktion bildet, mit der ein gewöhnlicher Mitarbeiter arbeiten wird.

Teilen Sie die Benutzer des Systems in Rollen ein, und die für eine Rolle geschärften Funktionen "verschmieren" nicht unter einer anderen Rolle.

Einmal haben wir im Rahmen des Systems eine Liste von Transaktionen mit Kunden implementiert.

Es wurde angenommen, dass sowohl Manager als auch normale Mitarbeiter mit der Liste arbeiten würden. Leider konnten wir vom Kunden nicht verstehen, dass der UI-Teil der Revision in zwei Listen / Bildschirme unterteilt werden muss: Eine Liste ist für den Manager zum Zwecke der Analyse und Kontrolle bestimmt, die zweite Liste ist für den Mitarbeiter zum Zwecke der Durchführung operativer Aktivitäten.

Das Ergebnis war ein bestimmtes Monster, das anschließend finalisiert und finalisiert werden musste.

Wenden Sie Best Practices von UX an: Erarbeiten Sie Zeichen - Benutzermodelle. Überzeugen Sie den Kunden, die Anforderungen für jeden Charakter zu trennen.

Verwenden Sie aktiv analytisches Brainstorming

Dies ist zusammen mit dem zweiten Analysten möglich, zusammen mit dem UX-Designer. Probieren Sie im Angriffsprozess zwei Rollen aus: Eine Person generiert zuerst viele Ideen, machbar und nicht sehr, die zweite - kritisiert diese Ideen, zerlegt sie, schreibt sie auf, überlegt sie; Wechseln Sie dann die Rollen und erledigen Sie den gleichen Job.

Wie die Praxis zeigt, wird dieser Ansatz den Prozess der Erstellung funktionaler Anforderungen erheblich beschleunigen und deren Qualität verbessern. Es ist jedoch schwierig, dass beide Spezialisten im Kontext der Aufgabe stehen sollten.

Wenn Sie im Wasserfall festsitzen, verzweifeln Sie nicht und bewegen Sie sich in Richtung Scrum

In einem der Unternehmen gelang es unserem Team buchstäblich innerhalb eines Jahres, den Prozess der Einführung von Verbesserungen von den auf Managementebene etablierten Managern auf Waterfall auf eine Art Scrum zu übertragen. Ja, die „klaren“ Fristen für den stark verschmierten Rückstand, den der Kunde ständig vom IT-Team forderte, zogen sich zurück, während die Rhetorik durch zweiwöchige Veröffentlichungen, MVP-Lösungen und eine schnelle Reaktion auf Änderungen schrittweise gemildert wurde.

Dämonisiere niemals den Kunden.

Ja, es gibt alle Arten von Kunden. Es gibt diejenigen, die buchstäblich wütend sind. Trotzdem muss ein Business Analyst dieses Problem entweder alleine oder unter Einbeziehung eines Managers lösen und sollte auf keinen Fall einen „Streit aus der Hütte“ führen - im Team.

Das Team sollte gut motiviert sein, um zu arbeiten, und die Rolle eines Geschäftsanalysten bei der Motivationsbildung ist einer der Schlüssel.

Nicht unterbrechen

Ernsthaft. Wenn ich gerade mit dem Kunden kommuniziere, höre ich absurde verbale Beilagen von meinem analytischen Kollegen. Wenn mein analytischer Kollege den Kunden unterbricht, ohne ihm bis zum Ende zuzuhören, möchte ich ihn zu Kursen über Verhandlung oder elementare Ethik schicken.

Versuchen Sie, dem Gesprächspartner zuzuhören und ihn zu hören.

Befreien Sie sich von Parasitenwörtern

Vermeiden Sie parasitäre Wörter und weniger „Moo“ in Gesprächen. Anfangs ist es schwierig, aber glauben Sie mir, es ist doppelt schwierig für den Kunden, einem solchen Analysten zuzuhören, der seine Gedanken nicht klar und deutlich ausdrücken kann. Ein Parasit kann von einem Entwickler, Designer, Tester, aber nicht von einem Geschäftsanalysten betroffen sein, der das IT-Team mit dem Geschäft verbindet.

 :
-   "    ".
-   ", :    ".

Systemanalyse

Versuchen Sie, das Sequenzdiagramm zu beschreiben, wenn Sie die Aufgabe auf Vorder- und Rückseite einstellen

Oder auf Russisch Sequenzdiagramme. Die Diagramme werden sich auch nicht unter dem Gesichtspunkt der Entwicklung als nützlich erweisen, sondern unter dem Gesichtspunkt der Überprüfung ihrer eigenen Anforderungen. Sehr oft habe ich bei der Beschreibung eines Nachrichtenflusses „Lücken“ in meinem eigenen Prozess identifiziert. Zum Beispiel eine irrelevante API.

Verwenden Sie das PlantUML-Plugin für Confluence, um schnell eine Folge von Diagrammen zu „zeichnen“. Es schien mir, dass es schneller ist , Code einzugeben, als die Position von Blöcken und Pfeilen mit Stiften anzupassen. Aber jeder in diesem Teil hat seine eigenen Erfahrungen und Vorlieben.

Bild

Lerne Swagger Editor

In Bezug auf die Analyse können Sie mit dem Swagger-Editor Ihre eigenen Lücken in den Anforderungen schließen. Irgendwo haben sie das Attribut übersehen, irgendwo haben sie vergessen, eine Aufgabe in JIRA zu erstellen, um die Datenbank fertigzustellen. Versuchen Sie nicht, sich die Swagger-Syntax zu merken, sondern erstellen Sie Vorlagen für verschiedene Arten von APIs (Verzeichnisse, Filter usw.), um Ihr zukünftiges Leben zu vereinfachen.

Bild

Verwenden Sie das Entwicklertool im Zielbrowser aktiv, um Clientanforderungen und -antworten vom Server zu analysieren

Zunächst können Sie während des ersten Akzeptanzprozesses die von Ihnen selbst beschriebene API überprüfen. Manchmal ist es schneller, einige der Verbesserungen anhand ausgehender Anforderungen zu überprüfen als anhand der Benutzeroberfläche, um die Ursache des Problems frühzeitig zu erkennen.

Als Analyst benötigen Sie viel weniger Zeit, um die Implementierung des Entwicklers zu überprüfen: ausgehende Daten, eingehende Daten, das Ergebnis in der Benutzeroberfläche.

Zweitens können Sie die richtige Anruffolge überprüfen. Schließlich haben Sie es selbst im Rahmen des Sequenzdiagramms beschrieben.

Dieser Ansatz ermöglichte es unserem Team, im Rahmen der Sprints ohne Verzögerung recht knifflige Verbesserungen an den Proms vorzunehmen.

 :
-   " JavaScript".   JSON, , HTML, http / https,   .
- . , .  " . , , ".      ,  ,   ,   .

Außerdem

Tauchen Sie ein in die UX

Vielleicht gefällt es Ihnen sogar und Sie möchten sich in Richtung UX Analytics weiterentwickeln. In jedem Fall wird das Studium der relevanten Literatur und Design-Tools zumindest unter dem Gesichtspunkt von der Suche nach einer gemeinsamen Sprache mit dem UX-Designer Ihres Teams profitieren.

Oft werden die Anforderungen, die Sie als Analyst detaillieren und aufschreiben, anschließend vom Designer angepasst. Schließlich sind Sie nicht allein, sondern gestalten die Benutzererfahrung.

Um auf der gleichen Wellenlänge zu sein, üben Sie Ihre UX-Analyse. Zum Beispiel in Ihrer Freizeit in Sketch oder Figma, um Ihrem Designer von Zeit zu Zeit das Ergebnis zu zeigen. Eine solche Analyseerfahrung wird niemals überflüssig sein.

 :
-   "  ".
-   "   ".
-   ".   ".
-   ".   ".

***

Danke, dass du den Artikel gelesen hast! Ich wäre zum einen für das Feedback dankbar. Zweitens für Empfehlungen zu Literatur, Quellen, Best Practices, persönlichen Erfahrungen und Empfehlungen.

Geschäfts- und Systemanalytiker. Was du wissen musst

Geschäftsanalysen

Systemanalyse

Außerdem

More articles: