„... und der Lotterie-Computer, der hauptsächlich etwas durcheinander gebracht hat, ist einer von allen, anstatt sich zu entschuldigen und Ausreden zu machen, nicht nur
gab den Fehler zu, war aber eindeutig stolz darauf.
"Ich bin gemacht", kündigte der Computer an, "mit minimalen Toleranzen." Ich soll komplexe und genaue Operationen ausführen, die nicht mehr als zulassen
ein Fehler für fünf Milliarden Aktionen.
"Na und?" Der Angestellte fragte.
- Die Schlussfolgerung ist klar: Ich wurde auf einen Fehler programmiert und habe getan, wofür ich programmiert wurde. Sie müssen sich an die Herren erinnern, die für das Auto
Der Fehler ist ethisch, ja, ausschließlich ethisch. Eine ideale Maschine ist unmöglich, und jeder Versuch, eine solche Maschine zu erschaffen, wäre Gotteslästerung ... "
Robert Sheckley, "Koordinaten der Wunder" (1968)
Hallo allerseits. Mein Name ist Svyatoslav Shcherbatyuk, ich arbeite mit dem Dnipro-Büro von EPAM in der Rolle des Lead Business Analyst. Ich bin vor mehr als vier Jahren aus dem Bereich der rechtlichen Unterstützung von Investitionsprojekten in diesen Beruf gekommen, an dem ich seit zehn Jahren beteiligt bin.
Die Frage nach der Rolle eines Business Analysten in einem Projekt wird heute hinreichend detailliert betrachtet: Es ist bekannt, welche Eigenschaften er haben sollte, wie er besser Karriere machen kann, welche Fähigkeiten er entwickeln muss. Es reicht aus, eine Google-Suche zu verwenden, um angemessene Antworten zu finden.
In diesem Artikel schlage ich vor, die häufigsten Fehler zu berücksichtigen, die die meisten unerfahrenen Geschäftsanalysten machen. Vielleicht werden die Dinge, die diskutiert werden, für Sie offensichtlich sein, aber glauben Sie mir: Dieser Artikel basiert auf in der Praxis gesammeltem Material, und solche Fehler finden sich regelmäßig in der Arbeit selbst erfahrener Geschäftsanalysten.
Also in Ordnung
1. Englische Sprache . Eines der wichtigsten und wichtigsten ist die unzureichende Beachtung des Englischniveaus. Bei Interviews stößt man häufig auf Kandidaten mit hohem Fachwissen und beeindruckender Berufserfahrung, aber schwachem Englisch. Es ist zu beachten, dass die meisten IT-Unternehmen und -Projekte auf ausländische Kunden ausgerichtet sind. Der Bedarf an freiem Englisch wird durch den Ort des Business Analysts an der Schnittstelle von Produkt und Engineering-Team (die Rolle und der Ort von VA im Scrum-Team ist ein Thema für einen separaten heiligen Krieg) und die Aufgaben, denen es gegenübersteht (effektive Kommunikation zwischen diesen Teams), bestimmt.
Ein besonderer Aspekt des Sprachproblems ist der professionelle Slang, der von Arbeitgebern, Kunden und Teammitgliedern beachtet wird. Die Aufgabe eines Business Analyst ist es, eine effektive Kommunikation herzustellen. Dies ist nur möglich, wenn Sie mit allen Teammitgliedern dieselbe Sprache sprechen. Darüber hinaus wird die überwiegende Mehrheit der Fachliteratur und Schulungen in englischer Sprache angeboten. Ohne Fremdsprachenkenntnisse ist eine vollständige berufliche Weiterentwicklung in der Regel nicht möglich.
2. Befolgen Sie blind den Rahmen. Aus der Frage der effektiven Kommunikation folgt ein weiterer schwerwiegender Fehler, den Anfänger begangen haben - die dogmatische Verfolgung der Ansätze des gewählten Rahmens. Es muss berücksichtigt werden, dass die IT eine sich dynamisch entwickelnde Branche ist und das Erfolgsgeheimnis in der Fähigkeit besteht, sich an sich schnell ändernde Umstände anzupassen.
Sie können dem Team so viel sagen, wie Sie möchten: „Wir arbeiten nach dem klassischen Scrum / Lean / Kanban-Prinzip“. Wenn die Aufgaben und Prozesse für sie jedoch unklar sind oder mehr Zeit und Ressourcen in Anspruch nehmen als bei einem anderen Ansatz als im Lehrbuch, hat dies keinen Sinn . In diesem Fall wäre es unprofessionell zu sagen, "dies ist ein schlechtes Team, sie folgen nicht meinem idealen Ansatz zur Methodik falsch." Die Aufgabe eines Geschäftsanalysten besteht darin, verschiedene Ansätze zu untersuchen und den für ein bestimmtes Team in einem bestimmten Projekt effektivsten auszuwählen. Ich stelle fest, dass ich während meiner Praxis kein einziges Projekt mit absolut „buchmäßigen“ Prozessen gesehen habe.
3. Ignorieren der Kultur und Unternehmensrichtlinien des Kunden. Abschließend sei auf die Bedeutung einer effektiven Kommunikation für einen Unternehmensanalysten hingewiesen. Bei der Planung ihrer Arbeit müssen die Unternehmenskultur und die Unternehmensrichtlinien des Kunden berücksichtigt werden.
Trotz der gewissen Offensichtlichkeit dieses Problems und der Tatsache, dass es bereits viele Probleme gelöst hat, wird der kulturelle Aspekt der Interaktion mit dem Kunden von einigen Geschäftsanalysten nicht gebührend berücksichtigt. In Verbindung mit unzureichenden Englischkenntnissen kann dieser Punkt jedoch dazu führen, dass ein Kunde einen Geschäftsanalysten als "unhöflich, nicht höflich" empfindet. Dies wirkt sich negativ auf die Arbeit von VA in einem der wichtigsten Aspekte aus - der Interaktion mit Stakeholdern.
So ist es zum Beispiel besser, nicht zu vergessen, dass Vertreter asiatischer Kulturen nicht immer direkt Nein sagen können, und wenn Sie mit Amerikanern oder Kanadiern arbeiten, sollten Sie 5 Minuten damit verbringen, über den Erfolg ihrer lokalen Sportmannschaft zu sprechen. Die Tatsache, dass Vertreter der osteuropäischen, slawischen Kultur von Vertretern der westlichen Kultur häufig als unhöflich empfunden werden, habe ich wiederholt gehört (zum Beispiel verwenden die Menschen das „Kannst du“ anstelle des milderen „Könntest du“ und vergessen, „Bitte“ hinzuzufügen). Bei einem der Projekte fragte der Stakeholder direkt, warum das Team ihn so sehr hasste. Am Ende stellte sich heraus, dass die Schwierigkeit in den unterschiedlichen Kulturen und unzureichenden Englischkenntnissen liegt.
Es ist wichtig zu verstehen, dass ein solcher Fehler für einen Geschäftsanalysten inakzeptabel ist, da die Wahrscheinlichkeit, Einzelheiten herauszufinden, die der Kunde aus irgendeinem Grund nicht direkt erwähnt, von der Qualität seiner Kommunikation mit dem Kunden abhängt.
So verbessern Sie die Kommunikationsfähigkeiten Ihrer Kunden:
- Ergänzen Sie den Wortschatz mit Feinheiten und Synonymen.
- Bedingungen lernen;
- Arbeite an der Aussprache
- Lernen Sie die Regeln für die Verwendung der Artikel "a" und "the".
Weitere praktische Tipps finden Sie in diesem
Artikel .
4. Ignorieren von Änderungen in der Kundendomäne Bei der direkten Projektarbeit kann einer der Fehler der Abbruch des Studiums der Domain Domain und der Besonderheiten des Geschäfts des Kunden sein. Es gibt Situationen, in denen selbst erfahrene Business Analysten, die lange an dem Projekt gearbeitet haben, die Frage nicht beantworten konnten, wie genau ihr Produkt in relativ einfachen Szenarien funktioniert. Der Verlust des Interesses an Trends und Trends im Domain-Bereich und ein Stillstand bei der Untersuchung des Kundengeschäfts können dem Projekt einen Streich spielen, insbesondere in dynamischen, sich schnell verändernden Geschäftsbereichen. Fast alle Experten erwähnen die Notwendigkeit, sich ständig mit dem Geschäft des Kunden auseinanderzusetzen, wenn es um die Vor- und Nachteile des Business-Analytics-Berufs geht.
5. Fehlende Roadmap. Eine der schwerwiegenden Schwierigkeiten kann das Fehlen grundlegender Dokumente wie Vision und Roadmap für das Projekt sein, die auf Kundenverkaufsplänen basieren. Vielleicht ist dieses Thema für große Projekte wichtiger und gehört zum Verantwortungsbereich von Produktmanagern, aber ein Business Analyst kann und sollte in jedem Fall den Prozess der Erstellung solcher Dokumente initiieren und erleichtern. Wenn VA sich in Richtung Produktmanagement weiterentwickeln will, ist dies eine Überlegung wert.
Als Beispiel aus meiner persönlichen Erfahrung kann ich die Situation nennen, in der die VA-Gruppe ein Roadmap-Projekt zur weiteren Prüfung und Genehmigung durch das Produktmanagementteam entwickelt hat. Insbesondere Fachleute analysierten die Funktionalität der Anwendungen potenzieller Wettbewerber, die Verkaufspläne des Unternehmens für das nächste Jahr, die Pläne für die Entwicklung entsprechender Module sowie die Rückstandsgeschichten, die aus irgendeinem Grund von den Produktmanagern vor langer Zeit abgelehnt wurden. Basierend auf all diesen Nachforschungen wurde die Roadmap geboren, die von den Kunden genehmigt wurde.
6. Es gibt keinen Kommunikationsplan und keine Stakeholder Map. Wenn Sie sich mit den Details der Arbeit eines Geschäftsanalysten befassen, können die Anfänger das Fehlen eines Kommunikationsplans und einer Stakeholder-Matrix als Fehler bezeichnen. Sie sollten den Kunden daran gewöhnen, regelmäßige Besprechungen abzuhalten, und sich selbst -, um im Voraus eine Liste von Themen zur Diskussion vorzubereiten. Häufige Absagen von Anrufen aufgrund fehlender Themen oder eines fehlenden konstruktiven Dialogs können dazu führen, dass die Stakeholder im entscheidenden Moment einfach nicht zu einer scheinbar geplanten Besprechung kommen. In einem Schlüsselmoment mag er ihnen nicht ganz wichtig und dringend erscheinen.
Bei der Planung der Kommunikation ist es wichtig, nicht nur das Wesentliche des Problems zu berücksichtigen, sondern auch, wie es formuliert ist. Es kommt oft vor, dass die Antwort des Kunden auch von der Frage abhängt. Dies ist äußerst wichtig, wenn ein Geschäftsanalyst als Vertreter des ausführenden Teams die Entscheidungen des Entwicklungsteams verteidigen muss, insbesondere während der Benutzerakzeptanzprüfung und der Übergabe der Arbeit an den Kunden. Um eine funktionierende Matrix aus Einfluss und Interesse aufzubauen, können wir die Stakeholder in vier Quadranten aufteilen. Ein gutes praktisches Beispiel finden Sie in diesem Artikel auf
dou.ua.7. Vereinbarungen sind nicht festgelegt. In Fortsetzung kann man einen solchen Fehler feststellen, wie das Fehlen von Sitzungsnotizen, die aus den Ergebnissen der Kommunikation mit den Interessengruppen zusammengestellt wurden. Das Schreiben von Besprechungsnotizen ist eine hervorragende Form der Teamverteidigung, insbesondere bei dynamischen Projekten mit hoher Mobilität der Manager.
Ich musste mich mit Situationen auseinandersetzen, in denen der Kunde nach einer Weile die getroffenen Vereinbarungen vergaß oder im Zusammenhang mit dem Wechsel des Produktteams solche Vereinbarungen verloren gingen und wir den Kunden davon überzeugen mussten, dass bestimmte Änderungen, beispielsweise im Freigabeplan, keine Fehleinschätzung waren. aber ein echtes Geschäft.
8. Fehlende Sichtbarkeit. Es lohnt sich, das Format der täglichen Aufstände zu beachten. Es ist äußerst wichtig, dass der Kunde ein ausreichendes Maß an Transparenz besitzt und weiß, wo und wie effizient sein Geld ausgegeben wurde. Anfängliche Business Analysten (obwohl oft nicht nur sie) schaffen es nicht immer, dem Kunden kurz und informativ zu erklären, was getan wurde.
Denken Sie daran, dass der Kunde nicht gerne wissen möchte, dass beispielsweise die gesamte letzte Woche eines der Teammitglieder im Blocker war und nichts getan hat. Ich habe Situationen erlebt, in denen ein Kunde mit der Begründung, dass jemand von etwas blockiert wurde, gefragt hat: „Und was haben Sie persönlich getan, um den Blocker zu überwinden / was haben Sie getan, während Sie blockiert wurden?“. Nutzen Sie die Zeit, in der Sie sich im Blocker befinden, um vorhandene Prozesse im Projekt zu verbessern. Glücklicherweise gibt es eine Menge solcher Arbeiten (insbesondere bei neuen Projekten). Und wenn Sie dem Kunden von erledigten Aufgaben erzählen, gehen Sie von einer proaktiven Haltung aus und überlegen Sie, mit welchen Gegenproblemen Sie rechnen können.
9. Es wird zu viel Zeit für Teile aufgewendet. Als Fehler für Anfänger kann man in seiner Beschreibung eine übermäßige Fokussierung auf die Details des Tickets und / oder die Kompliziertheit der Implementierung betonen. Bei langfristigen Projekten muss berücksichtigt werden, dass sich die Implementierungsdetails mit dem Übergang zu einer neuen Technologie ändern können, während das Geschäft des Kunden gleich bleibt. Falsch vorbereitete Akzeptanzkriterien mit vielen Implementierungsdetails (z. B. Beschreibung bestimmter Methoden oder Anforderungs- / Antwort-APIs) führen dazu, dass das Produkt-Backlog neu geschrieben werden muss.
Andernfalls weicht das tatsächliche Verhalten des Systems aus Sicht der Regressionstests von den bestehenden Anforderungen ab: Es ist technisch erforderlich, ein Fehlerticket zu starten, der Rückstand wird "veraltet" (dh die Beschreibung des Systemzustands wird irrelevant). Gleichzeitig gibt es keine formalen Gründe für das Umschreiben von Anforderungen, wenn sich die Geschäftsprozesse des Kunden nicht geändert haben.
10. Sie haben keine Vision für das gesamte Projekt. Ein typischer Fehler für große, langfristige Projekte kann auch ein mangelndes Verständnis des „Gesamtbildes“, Verknüpfungen mit anderen Elementen des Ökosystems und ein Mangel an „Hubschrauberblick“ sein.
Wenn Sie die Verbindungen Ihres Moduls mit anderen Modulen kennen und wissen, wie sich ein verbundenes System entwickelt, können Sie Ihr eigenes Produkt korrekt und rechtzeitig entwickeln, ohne die Details der Implementierung zu verschleiern. Darüber hinaus können Sie auf diese Weise die Anforderungen an das Schreiben erheblich verbessern. In solchen Fällen hilft es sehr gut, ein Kontextdiagramm zu
erstellen .
11. Du gehst vom Gegenteil aus. Mit der vorherigen ist der Fehler verbunden, Anforderungen „vom Gegenteil“ zu schreiben - das sollte das System nicht tun. Das Ergebnis ist ein Bedarfsstau, aus dem hervorgeht, was das System nicht tun wird, aber was es tun wird. Dies kann daran liegen, dass der Fokus auf das Geschäft des Kunden verloren geht. Es muss daran erinnert werden, dass VA zunächst direkt darüber nachdenkt, was das System tut, um die Geschäftsanforderungen des Kunden zu erfüllen.
12. Falsche Beurteilung. Der häufigste Fehler, den ein unerfahrener Business Analyst vermeiden kann, ist jedoch, den Umfang der Projektaufgaben sowie ihre fachlichen Fähigkeiten zu unterschätzen oder zu überschätzen. Dies sind zwei Extreme desselben Phänomens, die natürlich auf mangelnde Erfahrung und mangelndes Verständnis des tatsächlichen Niveaus der eigenen Fähigkeiten zurückzuführen sind.
Der vielleicht effektivste Rat wäre, sich vor nichts zu fürchten, aber auch einige Zeit nicht im Namen des Teams zu bürgen und vor dem Kunden / den Stakeholdern zu arbeiten. Schritt für Schritt werden alle Aktionen ausgeführt, die von einem neuen Business Analytics-Projekt erwartet werden. Vergessen Sie nicht, dass dasselbe BABOK den gesamten von Ihnen benötigten Aktionsplan enthält. Es ist normal, dass zu Beginn des Projekts nichts klar ist.
Denken Sie daran, dass das Hauptwerkzeug von Business Intelligence die Kommunikation ist. Auch wenn nichts bekannt ist, ist die Identifizierung von Stakeholdern ein guter Anfang, um das Projektziel und das Geschäft des Kunden herauszufinden und erste Kontext- und Workflowdiagramme zu erstellen, die Antworten auf alle Fragen des Projekts geben. Erfahrene Kollegen, die bereits länger mit diesem Kunden oder Projekt zusammengearbeitet haben, helfen Ihnen dabei, falsche Kundenerwartungen an das Produkt zu vermeiden.
13. Angst vor Fehlern. Er lähmt und anstatt zu handeln und das Projekt anzupassen, beginnt der unerfahrene Business Analyst lange Zeit, sich auf das Handeln vorzubereiten: Schreiben Sie sorgfältig Briefe an den Kunden und konzentrieren Sie sich darauf, Randfallszenarien zu beschreiben, bei denen es unwahrscheinlich ist, dass sie in den ersten Phasen des Projekts ablaufen im Allgemeinen vernachlässigt. Es ist in Ordnung, Fehler zu machen: Sowohl bei Agile als auch bei Scrum geht es darum, Fehler schnell zu machen und genauso schnell auf Fehler zu reagieren.
Ich wünsche allen Newcomern von VA, dass sie keine Angst vor Fehlern haben und mutig vorankommen. Viel glück