Es ist kein Geheimnis, dass Analysten zu den am freiesten und vielfältigsten interpretierten Berufen gehören. Und trotz des Vorhandenseins von bis zu zwei professionellen Standards skizziert jedes Unternehmen individuell die Aufgabenbereiche, die dem Spezialisten zugewiesen sind, der diese Position innehat. In meinem Artikel möchte ich meine persönlichen Erfahrungen teilen und Ihnen sagen, welche Rollen ein Analyst während eines normalen Projekts kombinieren kann, welche Aufgaben zu schließen sind und wo er sich entwickeln muss, wenn die Hauptbeschäftigung des Projekts völlig langweilig wird.
Ich hoffe, dass meine Geschichte Ihnen mit Überraschung helfen wird, herauszufinden, was Ihre Brüder im Sinn haben, und auch mögliche Wachstums- und Entwicklungspunkte hervorzuheben.
Haftungsausschluss
Alles, was weiter besprochen wird, ist eine rein persönliche Erfahrung in einer ganz bestimmten Art von Aktivität, die in der Entwicklung und Implementierung von benutzerdefinierten Lösungen basiert, die auf einem bestimmten System mit eigener Plattform und Programmiersprache basieren.
Darüber hinaus wird diese Aktivität zusätzlich durch die Besonderheiten des implementierten Systems sowie durch interne Herstellertechnologien begrenzt, die als lokale Standards fungieren.
Nun, als Kirsche auf dem Kuchen - diese Aktivität wird zum Wohle des blutigen Unternehmens durchgeführt. Und wenn ich über das blutige Unternehmen spreche, meine ich Projekte in sehr großen Unternehmen - fast alle Öl- und Gasunternehmen, Großbanken, Industrielle, Einzelhändler usw.
Dementsprechend ist der Analytiker, der in dem Artikel erörtert wird, eine Person, die innerhalb des gesamten oben genannten Paradigmas existiert. Darüber hinaus ist dies eine sehr reale und lebendige Person, egal wie kugelförmig ein Pferd in einem Vakuum war, das es Ihnen während des Lesens erschien.
Vorspiel
Im Allgemeinen ist das Thema der Selbstbestimmung von Analytikern im Weltraum ziemlich explosiv. Jedes Mal, wenn die Frage „Wer sind diese verdammten Analysten am Ende?“ In Fachgemeinschaften, Foren, Meetings, Konferenzen oder im Telegramm-Chat gestellt wird, beginnen heftige Holivars, bei denen einige Analysten anderen Analysten beweisen, dass jeder von ihnen sollte und sollte nicht tun.
Es wird noch lustiger (oder trauriger), wenn verschiedene Augen oder Methodologen beginnen, dieses Thema zu diskutieren.
In all diesen Holivars ziehe ich es vor, eine Position einzunehmen, deren Wesen in einem einzigen Wort liegt - der Spezifität. Mit anderen Worten, jeder muss verstehen, dass die Funktionen und Aufgaben des Analysten je nach Arbeitgeber, Projekt und Team immer sehr unterschiedlich sind.
Vielleicht wundern Sie sich - warum habe ich plötzlich beschlossen, dass ich darüber sprechen könnte? Alles ist einfach. Es reicht aus, die Rollen aufzulisten, die ich während meines Projekts ändere:
- Geschäftsanalyst;
- Systemanalytiker;
- UI / UX-Designer;
- technischer Redakteur;
- Tester;
- Lehrer
- Unterstützung.
Wenn es sich um Projekte mit erhöhter Komplexität und Größe handelt, mit einem Team von mehreren Analysten, unter denen sich möglicherweise Anfänger befinden, werden zusätzliche Rollen hinzugefügt:
- Mentor;
- Technischer Leiter;
- Teamleiter.
Und in all diesen Rollen arbeite ich seit fast acht Jahren.
Der Markt
Beginnen wir jedoch von weitem. Oder besser gesagt, mit der Situation, die sich gerade auf dem Markt entwickelt hat.
Wenn Sie zum Beispiel zu einem Headhunter gehen und das Wort „Analyst“ in die Suchzeile eingeben, fällt uns der Reichtum an Fantasien und Interpretationen zu diesem Thema auf.
Natürlich sind gewöhnliche Analysten am häufigsten. Ohne jede Klärung weg von der Sünde. In der Beschreibung dieser offenen Stellen sehen Sie viele verschiedene interessante Funktionen, Aufgaben, Aufgaben und Anforderungen für Kandidaten.
Einige Arbeitgeber wagen es, in ihren offenen Stellen eine Kategorisierung in Geschäfts- und Systemanalysten vorzunehmen und damit praktisch ein Loch für sich selbst zu graben. Sie stellen sich nicht einmal vor, wie viele Analysten selbst in dieser blutigen Schlacht getötet wurden.
Die optimierte und umfangreiche Kategorie von IT-Analysten ist sehr beliebt. In ihrer Beschreibung beschränkte sich normalerweise das gesamte russische Experimentierfeld mit Verantwortlichkeiten tatsächlich nur auf den IT-Bereich. Diese offenen Stellen erinnern mich am meisten an Geschichten über Tyzh-Programmierer, die regelmäßig gebeten werden, einen Staubsauger oder einen Wasserkocher zu reparieren.
Ganz ehrlich, diejenigen, die zumindest versuchen, im Titel anzugeben, was genau "analysiert" werden muss, handeln. Infolgedessen gibt es völlig unterschiedliche Stellen vom Typ "SQL Analyst", "Geschäftsprozessanalyst", "Anforderungsanalyst", "1C-Analyst", "Verkaufsanalyst", "Marketinganalyst" usw. Dies erspart jedoch nicht den Unterschied bei den Aufgaben, selbst bei offenen Stellen mit zwei identischen Namen.
Standards
Es scheint, dass der Punkt in dieser Geschichte durch professionelle Standards festgelegt worden sein sollte, deren Aufgabe es ist, die Ziele einer bestimmten beruflichen Tätigkeit genau festzulegen und eine ausführliche Beschreibung der Arbeitsfunktionen eines Spezialisten, der im Rahmen ihrer Umsetzung durchgeführten Maßnahmen sowie des erforderlichen Wissens zu liefern und Fähigkeiten.
Aber da war es.
Natürlich müssen Sie froh sein, dass es noch Standards gibt, obwohl diese erst vor relativ kurzer Zeit erschienen sind. Der Standard für Systemanalytiker im Herbst wird fünf Jahre alt sein. Deutlich später wurde der Standard für Business Analytics verschärft - er war noch nicht einmal ein Jahr alt.
Es ist interessant, dass diese Standards bereits den Unterschied zwischen einem Unternehmen und einem Systemanalysten auf der Ebene der professionellen Vorwahlen erklären: Für einen Systemanalysten wird Code 06 angegeben, und für einen Geschäftsanalysten - 08. Mit anderen Worten, ein Systemanalytiker wird im Bereich „Kommunikation, Information und Kommunikation“ als Fachmann eingestuft Technologie “und ein Business Analyst - im Bereich„ Finanzen und Wirtschaft “. Und keine IT für Sie.
Wenn wir zu den in den Standards verankerten Zielen der beruflichen Tätigkeit übergehen, wird der Unterschied noch offensichtlicher und unterhaltsamer. Da der Systemanalytiker auf den IT-Bereich verwiesen wird, ist er damit beauftragt, mit gutem Gewissen mit Anforderungen zu arbeiten und Software, automatisierte Systeme und im Allgemeinen alles zu erwähnen, was wir lieben. Der Business Analyst wiederum arbeitet nicht mit Anforderungen, sondern mit Anforderungen, aber sein Ziel konzentriert sich auf Änderungen in der Organisation, die von Vorteil sind. Und wohlgemerkt kein Wort über Systeme oder Hardware- und Softwaresysteme.
Gleichzeitig haben eine große Anzahl von Personen, die an der Erstellung verschiedener Arten von Softwareprodukten beteiligt sind, einen einfachen Eintrag „Business Analyst“ in ihrer Arbeitsmappe. Aber warum weit gehen, ich persönlich habe acht Jahre lang, wer auch immer ich genannt wurde, die gleichen Funktionen ausgeführt. Um mich nicht auf terminologische Streitigkeiten einzulassen, werde ich in der weiteren Erzählung dennoch das allgemeinste und neutralste Wort „Analytiker“ verwenden.
Missionen
Kommen wir zu den Einzelheiten.
Jedes Projekt, an dem unser Analyst auf die eine oder andere Weise teilnimmt, durchläuft vier globale Missionen. Nennen wir sie Vorverkauf, Vorprojekt, Projekt und Implementierung. Natürlich kann der Analyst nicht an allen Missionen teilnehmen, sondern sich isoliert mit einer von ihnen verbinden. Da wir jedoch in den Superheldenmodus wechseln, lassen Sie uns detailliert auf jede Mission eingehen. Ich werde sofort eine Reservierung vornehmen und die Eskorte ganz bewusst als Mission entfernen, weil Ich halte es für unangemessen, einen hochrangigen Spezialisten für diese Aufgaben zu beauftragen.
Vorverkauf
Die erste Mission ist natürlich der Vorverkauf.
Es ist erwähnenswert, dass nicht alle und nicht immer Analysten mit dieser Mission verbunden sind, wenn man bedenkt, dass das Lehen von Verkäufern und Projektmanagern im Vorverkauf liegt. Im Laufe der Zeit konnten die Analysten jedoch ihre Nützlichkeit und Lebensfähigkeit in dieser Phase unter Beweis stellen.
Zuallererst ist der Analyst im Vorverkauf natürlich mit Fachwissen nützlich. Darüber hinaus sowohl Subjekt als auch System. Wenn Sie mit einem Verkäufer zu Besprechungen und Demonstrationen reisen, spricht der Analyst dieselbe Sprache mit dem Thema und hilft dem Verkäufer, verschiedene Situationen zu klären, die mit dem charakteristischen Fachvokabular und der Terminologie verbunden sind. Darüber hinaus konzentriert sich der Analyst mit tieferen Kenntnissen über das verkaufte System und umfassender Projekterfahrung schnell und genauer auf die Möglichkeiten, die Wünsche des Kunden zu erfüllen, und spricht überzeugend über die vorhandenen Erfahrungen bei der Lösung ähnlicher Probleme.
Nach einer Reihe erfolgreicher Besprechungen beginnt der Analyst, isoliert vom Verkäufer zu arbeiten, und geht selbstständig zum Kunden. Er führt eine Expressstudie über Prozesse, vorhandene Systeme, die ausgetauscht werden müssen, die Infrastruktur, in die integriert werden muss, usw. durch.
Das Ergebnis all dieser Aktivitäten sind die umrissenen Konturen des zukünftigen Projekts sowie vorläufige technische Anforderungen, anhand derer eine erste Bewertung von Zeit, Arbeit und Kosten der Arbeit vorgenommen werden kann.
Vorentwurf
Nachdem der Verkauf abgeschlossen ist und die organisatorischen Maßnahmen zur Vertragsunterzeichnung und die rituellen Tänze zur Initialisierung des Projekts beginnen, kann der Analyst nicht mehr untätig bleiben, sondern mit den Vorarbeiten beginnen.
Zu diesem Zeitpunkt verfügt er möglicherweise bereits über viele Informationen für die Forschung: Dies sind die Ergebnisse der Expressanalyse und der Notizen aus den Sitzungen sowie der endgültigen ToR, die das Team abonniert hat, und mit etwas Glück eine Reihe verschiedener Kundenstandards und -vorschriften, deren Anforderungen erfüllt sind müssen bei der zukünftigen Gestaltung berücksichtigt werden. Mit anderen Worten, es ist ein Berg unstrukturierter Daten, die verarbeitet und in Ihrem Kopf als Konzept für eine zukünftige Lösung formuliert werden müssen.
Meistens ist diese Mission typisch für Großprojekte mit einem großen Team. In ihnen wird der Analytiker zum technischen Experten und entscheidet, was wir im übertragenen Sinne auf diesem Projekt aufbauen werden - ein Schiff oder ein Flugzeug. Es koordiniert auch das Team während des gesamten Projekts und hilft bei der Auswahl der besten technischen und inhaltlichen Lösungen sowie bei der Gewährleistung der Konsistenz des entworfenen Systems.
Der Analyst taucht allmählich in den Kontext des zukünftigen Projekts ein, zeichnet seinen Rahmen und bestimmt, welche bedingt isolierten Komponenten in ihn unterteilt werden können. Danach verteilt er das Team bereits zusammen mit dem Projektmanager auf die zugewiesenen Blöcke. Es ist sehr wichtig, die Verbindungen der Module des zukünftigen Systems zu berücksichtigen und genau zu verstehen, wie viel Arbeit einer unabhängigen Einheit sicher zugewiesen werden kann.
Nachdem der Analyst alle derzeit verfügbaren Informationen untersucht hat, entwickelt er das Konzept der Automatisierung, bei dem das Grundgerüst des zukünftigen Systems mit großen Strichen gegossen wird. Es sind diese Entscheidungen, die die Grundlage aller weiteren Arbeiten bilden und die Richtung für Analysten festlegen, die ihre lokalen Probleme in unabhängigen Blöcken lösen. Zusätzlich zum Konzept werden möglicherweise bereits die ersten Prozessdiagramme angezeigt, die sich noch auf oberster Ebene befinden. Meistens ist dies in gewisser Weise ein Nebeneffekt des Eintauchens des Analytikers in das Projekt - das Ergebnis der Analyse der verfügbaren Informationen. In Zukunft können diese Diagramme jedoch auch von Analysten zu den Blöcken geführt werden, wenn sie für eine detaillierte Studie zum Kunden gehen.
Darüber hinaus ist das Konzept eng mit der Architektur der Lösung verbunden. Hier interagiert der Analyst bereits mit dem führenden Entwickler, integriert das zukünftige System in die bestehende Landschaft des Kunden und identifiziert die Volumina der erforderlichen Integration und Migration, sowohl beim Start als auch beim regulären Start.
Gleichzeitig bereitet sich der Analyst nicht nur auf das bevorstehende Projekt vor, sondern bereitet auch eine Arbeitsgruppe des Kunden darauf vor - jene Personen, die die Hauptanforderungsquellen für das zukünftige System werden. Der Analyst hält Besprechungen mit der Arbeitsgruppe ab und demonstriert eine Box-Version des Systems, wobei er besonders auf die Module und Funktionen achtet, die von der bevorstehenden Implementierung betroffen sein werden. Die Hauptaufgabe besteht darin, den Kunden in den Kontext des Systems einzutauchen, um die Barriere abzubauen und eine fundiertere Einstellung zur Generierung von Anforderungen zu erreichen. In Demonstrationen zeigt der Analyst „live“, wie TK-Elemente auf das vorhandene System passen oder passen werden. Hier finden die ersten Andockpunkte von TK und die tatsächlichen Bedürfnisse des Kunden statt.
Projekt
Die Hauptarbeit beginnt natürlich direkt am Projekt. In dieser Phase ändern sich die Rollen ständig.
Erstens arbeitet der Analyst als Business Analyst eng mit dem Kunden zusammen. Gleichzeitig kann er entweder gelegentlich zu Besprechungen und Interviews gehen oder sich sogar im Vollzeitmodus auf dem Gebiet des Kunden befinden. In dieser Phase wird eine eingehende Untersuchung der Unternehmensprozesse durchgeführt, Engpässe und Automatisierungsbedarf ermittelt und Konsultationen zu möglichen Lösungen für die gefundenen Probleme durchgeführt. Darüber hinaus können diese Entscheidungen nicht nur systemisch, sondern auch administrativ und organisatorisch sein. Basierend auf den Ergebnissen der Studie werden detaillierte Diagramme und Beschreibungen der Geschäftsprozesse „wie sie sind“ und „wie sie sind“ mit allen Feinheiten und möglichen Optionen für die Entwicklung von Ereignissen erstellt. Unterwegs werden Anforderungen an die Objekte des zukünftigen Systems identifiziert und gesammelt.
Wenn die Informationen gesammelt werden, wird der Geschäftsanalyst in einen Systemanalysten umgewandelt, wodurch die Anforderungen des Kunden in die Fähigkeiten eines bestimmten Systems gestellt werden. In dieser Phase wird das Design der Systemmodule durchgeführt, während ein erfahrener Analyst unabhängig die Machbarkeit der Implementierung einer bestimmten Anforderung bewertet und nach Möglichkeiten sucht, mögliche Plattformbeschränkungen zu umgehen. Der Mangel an Erfahrung kann jedoch immer durch Konsultationen mit dem Hauptentwickler des Projekts ausgeglichen werden.
Gleichzeitig wird der Analyst zum Designer, der Layouts zukünftiger Systemschnittstellen entwirft und zeichnet. Es ist wichtig, nicht nur die visuelle Komponente, sondern auch die Grundprinzipien von UX sowie die Logik der Prozesse zu berücksichtigen, an denen die entworfenen Objekte beteiligt sind. Alle Bildschirmformulare müssen früher oder später ein einziges logisches und harmonisches Bild bilden, und das System muss gleichermaßen auf identische Benutzeraktionen reagieren.
Eine separate Phase ist das Design aller Arten von Integrationen und Migrationen. Alles hängt von der Erfahrung des Analytikers und seinen Systemkompetenzen ab. Im Allgemeinen muss der Analyst den Platz des Systems in der allgemeinen Landschaft verstehen und eine gute Vorstellung von seiner Interaktion mit anderen Systemen des Kunden haben. Diese Interaktion sollte zumindest auf der Ebene überlappender Entitäten, Regeln für übertragene Daten und der Zuordnung von Details beschrieben werden. Der technische Teil des Entwurfs wird normalerweise vom Entwickler übernommen.
Nachdem alle Lösungen entworfen wurden, wird der Analyst zum technischen Redakteur und schreibt ein großes und schönes Dokument, das eine detaillierte Beschreibung des zukünftigen Systems enthält. Dieses Dokument enthält zuvor entwickelte Schemata und Beschreibungen von Prozessen und Schnittstellen mit einer detaillierten Beschreibung der angewandten Logik von Elementen sowie andere Beschreibungen von Änderungen, die im System durchgeführt werden müssen, um die entworfenen Lösungen zu implementieren. Hier wird die Analyse durch die überprüfte Struktur des Dokuments und vorgefertigte Vorlagen unterstützt, mit denen Sie nichts verpassen können.
Nach Abschluss der Dokumentationsphase werden die grundlegenden Arbeiten mindestens zwei Überprüfungen unterzogen - dem führenden Analysten und dem führenden Entwickler des Teams. Und wenn möglich - auch externes Peer Review durch Kollegen aus anderen Teams und Projekten. Nach Überprüfung wird das Dokument zur Genehmigung an den Kunden gesendet. Darüber hinaus fällt es ihm nicht in einem unverständlichen mehrseitigen Talmud auf, sondern wird zunächst in Form einer Präsentation mit Erklärungen, Liedern, Tänzen und lustigen Bildern gezeigt. Darüber hinaus begleitet der Analyst den Genehmigungsprozess, beantwortet die Fragen des Kunden, korrigiert bestimmte Formulierungen und gegebenenfalls Anforderungen und Lösungen. Nach erfolgreichem Abschluss der Genehmigung wird das Dokument an die Entwicklung gesendet.
In diesem Moment hat unser Analyst eine kurze Pause. Im Laufe der Entwicklung ist er natürlich mit der Arbeit am Projekt verbunden, jedoch mit einer deutlich geringeren Belastung. Seine Aufgaben sind hauptsächlich Antworten auf Fragen von Entwicklern und die regelmäßige Aktualisierung der Anforderungen beim Kunden.
Wenn die Entwicklung abgeschlossen ist, wird der Analyst zum Tester und nimmt eine lange, durchdachte und strenge Prüfung der entwickelten Lösungen vor. Ich werde sofort feststellen, dass es sich um Benutzertests handelt, dies bedeutet jedoch nicht, dass dies oberflächlich ist. Jede Schaltfläche wird aktiviert, jedes Fenster, jeder Routenzweig, alle Berichtsformulare werden erstellt, alle Skripte werden gestartet. Gleichzeitig ist das Testen in zwei große Phasen unterteilt. Der erste Schritt besteht darin, die Grundfunktionen zu überprüfen. Alles hier sollte so funktionieren, wie es in der Dokumentation geschrieben steht, und als ob ein erfahrener und sachkundiger Benutzer am Computer sitzen würde. Nachdem alle positiven Verwendungsszenarien überprüft wurden, beginnt der Analyst, das System zu „brechen“ und es aus der Sicht eines unerfahrenen Benutzers zu testen, der zu faul ist, um die Anweisungen überhaupt zu lesen. Ich möchte auch darauf hinweisen, dass zu diesem Zeitpunkt eine weitere Verfeinerung der Anforderungen und eine endgültige Entscheidung erfolgen kann. Wenn die Tests abgeschlossen sind, sind wir bereit für die nächste Mission.
Implementierung
Zu diesem Zeitpunkt ist der Analyst an der Bereitstellung und Konfiguration des Systems auf den Servern des Kunden beteiligt. Zunächst wird eine Testschaltung eingerichtet, auf der die Arbeitsgruppe zusammen mit dem Projektteam die endgültigen Tests der Lösung durchführt. Um diese Tests sicherzustellen, schreibt der Analyst Testfälle unter Berücksichtigung der Szenarien, die der Kunde durchführen muss, um das Maximum an Funktionen für einen begrenzten Testzeitraum abzudecken, und überzeugt die Arbeitsgruppe davon, dass alles ordnungsgemäß funktioniert.
Natürlich führt die Testphase erneut zu einem Zyklus von Spezifikation von Anforderungen, Systemverbesserungen und wiederholten Tests, aber die unerschöpflichen Wünsche des Kunden sollten durch Zeit und Arbeit erheblich eingeschränkt werden und versuchen, nur die kritischsten Momente in die Arbeit einzubeziehen. Die Hauptaufgabe besteht darin, Live-Benutzer schnell in Betrieb zu nehmen, egal wie unmenschlich sie klingen mögen.
In dieser Phase verwandelt sich der Analyst in einen Trainer, der normale Benutzer des zukünftigen Systems schult. Schulungen können auf verschiedene Arten durchgeführt werden: Vollzeitkurse mit praktischen Aufgaben und Abschlusszertifizierungen, Seminare, Webinare, Videos, Screencasts usw. Benutzeranweisungen werden parallel geschrieben (obwohl ihre Entwicklung im Allgemeinen in der Phase der internen Tests beginnt).
, , , . , – , .
, , , . , , , .
, , .
Bonus-level
, , .
– . 3-4 . , , , , .
, , . , , .
– . . – .
– , , ..
, , - , , .
Epic-fail
, . . – overqualified.
. , , . , , .
, -. , , , . , . – , . . , .
, . – !