Ce n'est un secret pour personne que les analystes sont l'une des professions les plus librement interprétées et aux multiples facettes. Et, malgré la présence de pas moins de deux normes professionnelles, chaque entreprise décrit individuellement l'éventail des tâches assignées au spécialiste occupant ce poste. Dans mon article, je veux partager mon expérience personnelle et vous dire quels rôles un analyste peut combiner au cours d'un projet ordinaire, quelles tâches clôturer, et aussi où développer si l'emploi principal du projet devient complètement ennuyeux.
J'espère que mon histoire vous aidera avec surprise à découvrir ce que vos frères ont en tête et à mettre en évidence les points de croissance et de développement possibles.
Clause de non-responsabilité
Tout ce qui sera discuté plus loin est une expérience purement personnelle dans un type d'activité très spécifique, consistant en le développement et la mise en œuvre de solutions personnalisées basées sur un système spécifique avec sa propre plateforme et langage de programmation.
De plus, cette activité est en outre limitée par les spécificités du système mis en œuvre, ainsi que par les technologies des fournisseurs internes qui agissent comme des normes locales.
Eh bien, comme une cerise sur le gâteau - cette activité est réalisée au profit de l'entreprise sanglante. Et quand je parle de l'entreprise sanglante, je veux dire des projets dans de très grandes entreprises - presque tout le pétrole et le gaz, les grandes banques, les industriels, le commerce de détail, etc.
En conséquence, l'analyste, qui sera discuté dans l'article, est une personne qui existe dans l'ensemble du paradigme susmentionné. De plus, c'est une personne très réelle et vivante, peu importe la forme sphérique d'un cheval dans le vide qu'il vous a semblé pendant la lecture.
Foreplay
En général, le sujet de l’autodétermination de l’analyste dans l’espace est assez explosif. Chaque fois que la question «qui sont ces maudits analystes à la fin» est soulevée dans les communautés professionnelles, les forums, les réunions, les conférences ou dans le chat des télégrammes, des holivars féroces commencent, au cours desquels certains analystes prouvent à d'autres analystes que chacun d'eux devrait et ne devrait pas faire.
Cela devient encore plus drôle (ou plus triste) lorsque divers eychars ou méthodologistes commencent à discuter de ce sujet.
Dans tous ces holivars, je préfère prendre position, dont l'essence réside dans un seul mot - la spécificité. En d'autres termes, chacun doit comprendre que l'ensemble des fonctions et tâches de l'analyste variera toujours considérablement en fonction de l'employeur final, du projet et de l'équipe.
Vous vous demandez peut-être - pourquoi ai-je soudain décidé de pouvoir en parler? Tout est simple. Il suffit de lister les rôles que je change tout au long de mon projet:
- analyste commercial;
- analyste de systèmes;
- Concepteur UI / UX;
- rédacteur technique;
- testeur;
- enseignant
- soutien.
Si nous parlons de projets de complexité et d'échelle accrues, avec une équipe de plusieurs analystes, parmi lesquels il peut y avoir des débutants, des rôles supplémentaires sont ajoutés:
- mentor;
- Responsable technique;
- Chef d'équipe.
Et dans toute cette variété de rôles, je travaille depuis près de huit ans.
Le marché
Mais commençons de loin. Ou plutôt, avec la situation qui s'est développée sur le marché en ce moment.
Si vous allez, par exemple, chez un chasseur de têtes et que vous introduisez le mot «analyste» dans la ligne de recherche, toute la richesse des fantasmes et des interprétations sur le sujet nous tombera dessus.
Bien sûr, les analystes ordinaires sont les plus courants. Sans aucune clarification, loin du péché. Dans la description de ces postes vacants, vous pouvez voir de nombreuses fonctions, tâches, responsabilités et exigences intéressantes pour les candidats.
Certains employeurs osent exprimer la catégorisation en analystes d'affaires et de systèmes dans leurs postes vacants et creusent ainsi pratiquement un trou pour eux-mêmes. Ils n'imaginent même pas combien d'analystes eux-mêmes ont été tués dans cette sanglante bataille.
La catégorie rationalisée et vaste des analystes informatiques est très populaire. Dans leur description, généralement, l'ensemble du domaine russe des expériences avec des responsabilités, limité, en fait, uniquement à la sphère informatique. Ces postes vacants me rappellent le plus les histoires de programmeurs tyzh qui sont régulièrement invités à réparer un aspirateur ou une bouilloire.
Honnêtement, ceux qui essaient au moins d'indiquer dans le titre ce qui devra être "analysé" exactement agissent. En conséquence, il existe des postes complètement différents du type «analyste SQL», «analyste des processus métier», «analyste des exigences», «analyste 1C», «analyste des ventes», «analyste marketing», etc. Cependant, cela ne sauve pas la différence de tâches, même dans les postes vacants avec deux noms identiques.
Normes
Il semblerait que le point de cette histoire aurait dû être fixé par des normes professionnelles, dont la tâche est précisément de fixer les objectifs d'une activité professionnelle particulière et de fournir une description exhaustive des fonctions de travail d'un spécialiste, les actions effectuées dans le cadre de leur mise en œuvre, ainsi que les connaissances requises et compétences.
Mais ça y était.
Bien sûr, vous devez être heureux que les normes existent toujours, bien qu'elles soient apparues relativement récemment. La norme pour les analystes de systèmes à l'automne aura cinq ans. Bien plus tard, la norme pour l'analyse commerciale a été resserrée - il n'a même pas un an.
Il est intéressant de noter que ces normes déclarent déjà la différence entre une entreprise et un analyste système au niveau des indicatifs professionnels: pour un analyste système, le code 06 est indiqué, et pour un analyste métier - 08. En d'autres termes, un analyste système est classé comme professionnel dans le domaine des «communications, information et communication technologie », et un analyste commercial - dans le domaine« finance et économie ». Et pas d'informatique pour vous.
Si nous passons aux objectifs de l'activité professionnelle, inscrits dans les normes, la différence deviendra encore plus évidente et divertissante. Un analyste système, puisqu'il est affecté au domaine informatique, est chargé de travailler avec des exigences en toute conscience, en mentionnant les logiciels, les systèmes automatisés, en général, tout ce que nous aimons. L'analyste d'affaires, à son tour, ne travaille pas avec les exigences, mais avec les besoins, mais son objectif est axé sur les changements dans l'organisation qui sont bénéfiques. Et, attention, pas un mot sur les systèmes ou les systèmes matériels et logiciels.
Dans le même temps, un grand nombre de personnes impliquées dans la création de divers types de produits logiciels ont une simple entrée «analyste commercial» dans leur classeur. Cependant, pourquoi aller loin, j'ai personnellement pendant huit ans qui que je sois appelé, remplissant les mêmes fonctions. Par conséquent, afin de ne pas être impliqué dans des conflits terminologiques, dans la suite de la narration, j'utiliserai néanmoins le mot le plus général et le plus neutre «analyste».
Missions
Passons aux détails.
Tout projet auquel notre analyste participe d'une manière ou d'une autre passe par 4 missions mondiales, appelons-les prévente, avant-projet, projet et mise en œuvre. Bien sûr, l'analyste peut ne pas participer à toutes les missions, mais se connecter isolément à chacune d'entre elles, mais puisque nous passons en mode super-héros, parlons en détail de chacune. Je ferai une réservation tout de suite; j'ai supprimé l'escorte en tant que mission de façon délibérée, car Je considère inapproprié de garder un spécialiste de haut niveau sur ces tâches.
Pré-vente
La première mission est bien sûr la prévente.
Il convient de noter que tous et pas toujours connecter les analystes à cette mission, compte tenu de la prévente du fief des vendeurs et des chefs de projet. Cependant, au fil du temps, les analystes ont pu prouver leur utilité et leur viabilité à ce stade.
Tout d'abord, l'analyste en prévente est bien sûr utile avec une expertise. De plus, à la fois sujet et système. Lorsqu'il voyage avec un vendeur pour des réunions et des démonstrations, l'analyste parle la même langue avec le sujet et aide le vendeur à dégager diverses situations associées au vocabulaire et à la terminologie professionnels caractéristiques. De plus, possédant une connaissance approfondie du système vendu et une vaste expérience de projet, l'analyste se concentre rapidement et plus précisément sur les possibilités de répondre aux souhaits du client, ainsi que de parler de manière convaincante de l'expérience existante dans la résolution de problèmes similaires.
Après une série de réunions réussies, l'analyste commence à travailler en vase clos avec le vendeur et part seul pour le client, réalisant une étude express des processus, des systèmes existants à remplacer, de l'infrastructure dans laquelle il sera nécessaire de s'intégrer, etc.
Les résultats de toutes ces activités sont les contours esquissés du futur projet, ainsi que les exigences techniques préliminaires, selon lesquelles il sera possible d'effectuer une première évaluation du temps, du travail et du coût des travaux.
Pré-conception
Une fois la vente terminée et les mesures organisationnelles pour signer le contrat et les danses rituelles pour initialiser le projet, l'analyste ne peut plus rester inactif, mais commencer les travaux préliminaires.
À ce stade, il peut déjà avoir à sa disposition de nombreuses informations pour la recherche: ce sont les résultats de l'analyse expresse, et les notes des réunions, et les TdR finaux auxquels l'équipe a souscrit, et, avec un peu de chance, un tas de diverses normes et réglementations des clients, dont les exigences devra être pris en compte dans la conception future. En d'autres termes, c'est une montagne de données non structurées qui doivent être traitées et formulées dans votre tête un concept pour une solution future.
Le plus souvent, cette mission est typique des projets de grande envergure avec une grande équipe. C'est en eux que l'analyste devient un expert technique et décide de ce que, au sens figuré, nous allons construire sur ce projet - un navire ou un avion. Il coordonne également l'équipe tout au long du projet, aidant à choisir les meilleures solutions techniques et substantielles, ainsi qu'à assurer la cohérence du système conçu.
Plongeant progressivement dans le contexte du futur projet, l'analyste dessine son cadre et détermine quelles composantes isolées conditionnellement peuvent y être divisées. Après quoi, déjà en collaboration avec le chef de projet, il répartit l'équipe entre les blocs alloués. Il est très important de prendre en compte les interconnexions des modules du futur système et de comprendre exactement quelle quantité de travail peut être allouée en toute sécurité à une unité indépendante.
Après avoir étudié toutes les informations actuellement disponibles, l'analyste construit le concept d'automatisation, où le squelette du futur système est coulé à grands coups. Ce sont ces décisions qui formeront la base de tous les travaux ultérieurs et définiront l'orientation des analystes pour résoudre leurs problèmes locaux sur des blocs indépendants. De plus, en plus du concept, les premiers diagrammes de processus, toujours de niveau supérieur, peuvent déjà apparaître. Le plus souvent, il s'agit, d'une certaine manière, d'un effet secondaire de l'immersion de l'analyste dans le projet - le résultat de l'analyse des informations disponibles. Mais à l'avenir, ces diagrammes pourront également être guidés par les analystes sur les blocs lorsqu'ils se rendront chez le Client pour une étude détaillée.
De plus, le concept est étroitement lié à l'architecture de la solution - ici, l'analyste interagit déjà avec le développeur principal, intégrant le futur système dans le paysage existant du client et identifiant les volumes d'intégration et de migration requis, à la fois en démarrage et en continu.
Dans le même temps, l'analyste se prépare non seulement pour le projet à venir, mais prépare également pour lui un groupe de travail du client - ces personnes qui deviendront les principales sources d'exigences pour le futur système à l'avenir. L'analyste tient des réunions avec le groupe de travail et présente une version encadrée du système, en accordant une attention particulière aux modules et fonctions qui seront affectés par la prochaine mise en œuvre. La tâche principale ici est de plonger le Client dans le contexte du système afin d'abaisser la barrière et d'atteindre une attitude plus informée face à la génération d'exigences. Dans les démonstrations, l'analyste «en direct» montre comment les éléments de savoirs traditionnels s'intègrent ou s'adapteront au système existant. Les tout premiers points d'ancrage des savoirs traditionnels et les besoins réels du client ont lieu ici.
Projet
Bien entendu, le travail principal commence directement sur le projet. C'est à ce stade que les rôles évoluent constamment.
Premièrement, l'analyste travaille en étroite collaboration avec le client en tant qu'analyste commercial. Dans le même temps, il peut soit se rendre occasionnellement à des réunions et des entretiens, soit même être sur le territoire du Client en mode plein temps. À ce stade, une étude approfondie des processus de l'entreprise est réalisée, les goulots d'étranglement et les besoins d'automatisation sont identifiés, des consultations sont proposées sur les solutions possibles aux problèmes rencontrés. De plus, ces décisions peuvent être non seulement systémiques, mais aussi administratives et organisationnelles. Sur la base des résultats de l'étude, des diagrammes détaillés et des descriptions des processus commerciaux «en l'état» et «à être» sont nés, avec toutes les subtilités et les options possibles pour le développement d'événements. En cours de route, les besoins pour les objets du futur système sont identifiés et collectés.
Lorsque les informations sont collectées, l'analyste métier est transformé en analyste système, plaçant les exigences du client dans les capacités d'un système particulier. À ce stade, la conception des modules du système est effectuée, tandis qu'un analyste expérimenté évalue de manière indépendante la faisabilité de la mise en œuvre d'une exigence particulière et recherche des moyens de contourner les limitations possibles de la plate-forme. Cependant, le manque d'expérience peut toujours être compensé par des consultations avec le développeur principal du projet.
Au même stade, l'analyste devient concepteur, concevant et dessinant les dispositions des futures interfaces système. Il est important de considérer non seulement la composante visuelle, mais aussi les postulats de base de l'UX, ainsi que la logique des processus auxquels les objets conçus participeront. Tous les formulaires d'écran devront tôt ou tard former une seule image logique et harmonieuse, et le système devra répondre également aux actions identiques de l'utilisateur.
Une étape distincte est la conception de toutes sortes d'intégrations et de migrations. Tout dépend de l'expérience de l'analyste et de ses compétences système. En général, l'analyste doit comprendre la place du système dans le paysage général et avoir une bonne idée de son interaction avec les autres systèmes du Client. Cette interaction doit être décrite au moins au niveau des entités qui se chevauchent, des règles pour les données transmises et de la cartographie des détails. La partie technique de la conception est généralement réalisée par le développeur.
Une fois toutes les solutions conçues, l'analyste devient rédacteur technique et rédige un grand et beau document qui fournit une description détaillée du futur système. Ce document comprend des schémas développés précédemment et des descriptions de processus et d'interfaces, avec une description détaillée de la logique appliquée des éléments, et d'autres descriptions des modifications qui doivent être effectuées dans le système afin de mettre en œuvre les solutions conçues. Ici, l'analyse est aidée par la structure vérifiée du document et des modèles prêts à l'emploi qui vous permettent de ne rien manquer.
Après avoir terminé la phase de documentation, le travail fondamental subit au moins deux revues - l'analyste principal et le développeur principal de l'équipe. Et si possible - également examen par des pairs externes par des collègues d'autres équipes et projets. Après examen, le document est envoyé pour approbation au Client. De plus, il ne tombe pas sur lui dans un Talmud incompréhensible de plusieurs pages, mais se présente d'abord sous la forme d'une présentation avec explications, chansons, danses et images drôles. De plus, l'analyste accompagne le processus d'approbation, répondant aux questions du client, corrigeant certaines formulations et, si nécessaire, des exigences et des solutions. Une fois l'approbation approuvée, le document est envoyé au développement.
En ce moment, notre analyste a un léger répit. Au cours du développement, il est, bien sûr, connecté au travail sur le projet, mais avec une charge sensiblement plus petite. Ses tâches sont principalement des réponses aux questions des développeurs et la mise à jour périodique des exigences avec le Client.
Une fois le développement terminé, l'analyste devient testeur et effectue un test long, réfléchi et rigoureux des solutions développées. Je noterai tout de suite que nous parlons de tests utilisateurs, mais cela ne veut pas dire que c'est superficiel. Chaque bouton est vérifié, chaque fenêtre, chaque branche d'itinéraire, tous les formulaires de rapport sont créés, tous les scripts sont lancés. Dans le même temps, les tests sont divisés en deux grandes étapes. La première étape consiste à vérifier les fonctions de base. Tout ici devrait fonctionner comme il est écrit dans la documentation, et comme si un utilisateur expérimenté et compétent était assis devant l'ordinateur. Une fois tous les scénarios d'utilisation positifs vérifiés, l'analyste commence à "casser" le système et à le tester du point de vue d'un utilisateur inexpérimenté qui est trop paresseux pour même lire les instructions. Je voudrais également attirer l'attention sur le fait qu'à ce stade, un affinement supplémentaire des exigences et la finalisation des décisions pourraient intervenir. Lorsque les tests sont enfin terminés, nous sommes prêts pour la prochaine mission.
Implémentation
A ce stade, l'analyste est impliqué dans le déploiement et la configuration du système sur les serveurs du Client. Dans un premier temps, un circuit de test est mis en place sur lequel le groupe de travail, en collaboration avec l'équipe du projet, effectuera le test final de la solution. Pour assurer ce test, l'analyste rédige des cas de test, en considérant les scénarios que le client devra mener afin de couvrir un maximum de fonctions pour une période de test limitée et convaincre le groupe de travail que tout fonctionne comme il se doit.
Bien sûr, la phase de test conduit à nouveau à un cycle de spécification des exigences, d'améliorations du système et de tests répétés, mais les souhaits inépuisables du client doivent être considérablement limités par le temps et le travail, en essayant de ne prendre que les moments les plus critiques au travail. La tâche principale est de mettre rapidement en service des utilisateurs en direct, peu importe à quel point cela peut paraître inhumain.
À ce stade, l'analyste se transforme en formateur, éduquant les utilisateurs ordinaires du futur système. La formation peut être dispensée de différentes manières: cours à temps plein avec travaux pratiques et certifications finales, séminaires, webinaires, vidéos, screencasts, etc. Les instructions utilisateur sont écrites en parallèle (bien qu'en général, leur développement commence au stade des tests internes).
, , , . , – , .
, , , . , , , .
, , .
Bonus-level
, , .
– . 3-4 . , , , , .
, , . , , .
– . . – .
– , , ..
, , - , , .
Epic-fail
, . . – overqualified.
. , , . , , .
, -. , , , . , . – , . . , .
, . – !