Salutations! Je m'appelle Sergey et je suis analyste commercial / systèmes. Je travaille dans l'industrie informatique depuis environ 8 ans, en commençant par la maintenance qui se poursuit dans les tests et en poursuivant avec l'analyse: à la fois commerciale et système. Je n'ai pas encore travaillé séparément en tant qu'entreprise et en tant qu'analyste système.Au cours de mes activités professionnelles en général, y compris la pratique et les entretiens personnels, et en particulier les entretiens avec des candidats potentiels, j'ai progressivement compris quelles compétences le marché attend de l'analyste. Habr n'a pas vu de nouveaux articles sur ce sujet depuis longtemps, j'ai donc décidé de préparer le matériel moi-même.Pour qui, à mon avis, l'article sera utile:- Analystes d'affaires / systèmes débutants;
- Les analystes qui veulent continuer à pomper leur prof. Compétences
- Peut-être des gestionnaires de recrutement.
Je dois dire tout de suite que les points ci-dessous sont ma vision subjective de la spécialisation de l'analyste , qui s'est formée pendant la pratique. Si votre entreprise dirige une mêlée à part entière avec un propriétaire de produit assis à un mètre de vous, avec un designer et un architecte affectés à l'équipe, certains des éléments ci-dessus peuvent ne pas être demandés.Néanmoins, au moins toutes ces compétences ne seront pas superflues et rendront l'analyste encore plus compétent dans ses questions. Bien sûr, vous devez comprendre que je n'ai pas énuméré toutes les compétences et les capacités de l'analyste (les mêmes notations, compétences commerciales, sql, etc.).Analyse commerciale
- Éliminez les exigences ambiguës dès les premières étapes
Lorsque vous parlez à un client professionnel, vous devez savoir que sa langue peut différer considérablement de la vôtre. Une exigence commerciale peut être exprimée de telle manière que plusieurs participants au processus d'approbation ont une compréhension différente de ce que signifie cette exigence. L'ambiguïté est générée, ce qui est très coûteux pour l'équipe dans les derniers stades de développement.Le problème est plus aigu lorsqu'il y a plusieurs clients commerciaux, chacun présentant ses propres exigences. Par exemple, lors de l'intégration de deux systèmes, chacun ayant son propre représentant de l'entreprise.Etude de cas: un mois de développement a été consacré à la fonctionnalité de transfert de la liste d'activités de l'objet n ° 1 à l'objet n ° 2. Au stade des tests d'acceptation, il a été découvert que le client s'attendait à une fonctionnalité complètement différente - la copie, pas le transfert d'activités. Dans le processus de refaire la fonctionnalité et de détailler l'ambiguïté, l'équipe informatique, d'une part, a convenu avec le client du MVP et, d'autre part, de la nécessité de travailler avec la racine du problème commercial. Il a été émis l'hypothèse que la fonctionnalité de copie elle-même n'est requise qu'en raison d'une fonctionnalité insuffisamment implémentée pour charger les modèles d'activité.
- N'ayez pas peur de vérifier avec le client les exigences de l'exigence
J'ai rencontré des cas lorsque je me suis rendu compte que l'énoncé de développement était décrit sans fixer d'objectif commercial: en quoi cet achèvement aiderait-il exactement l'entreprise? Quelle douleur ce raffinement soulagera-t-il des affaires?Souvent, de telles améliorations sans but ont conduit à des conséquences désagréables déjà au stade des tests, lorsque le développeur et le testeur ne comprenaient pas pourquoi nous avions conçu cette fonctionnalité. Pire encore, le développeur et le testeur n'ont pas reçu de réponses de l'analyste, et si c'est le cas, ils ont souvent trouvé l'analyste lui-même: des objectifs que l'analyste s'est fixés lui-même.
Notez les objectifs avec le client afin que tous les participants au processus comprennent à tout moment pourquoi ils font leur travail.- Exigez la présence de vos clients aux réunions d'affaires
En pratique, j'ai rencontré différents clients, dont certains n'étaient pas immédiatement prêts à inviter l'analyste à leurs réunions hors ligne. L'analyste devra également travailler avec cela: se mettre d'accord et montrer le résultat d'une collaboration bien coordonnée., — UX- — « », , . : , , windows-, . , .
De nombreux analystes, y compris moi-même, dans le processus de formulation des exigences, confrontés à une échéance stricte, ont utilisé la technique suivante: ils ont écrit une lettre aux participants du processus avec une échéance à laquelle la lettre devrait être répondue et les exigences convenues / des commentaires devraient être faits. Sinon, les exigences seront automatiquement reconnues comme convenu.Comme la pratique l'a montré, il n'y a rien de bon dans cette approche. Il est clair que, travaillant du côté du fournisseur et ayant un accord en main, vous devez recourir à de telles méthodes, mais essayez toujours d'éviter le consentement tacite, essayez de comprendre pourquoi les participants ne veulent pas vous donner une réponse tout de suite et résolvez le problème dès que possible.Il est préférable de documenter par écrit le fait que la réponse n'a pas été reçue de telle ou telle personne et vous voyez les risques suivants pour le projet dans ce document. Cependant, le processus de travail ne peut pas rester immobile, vous êtes donc obligé de poursuivre votre travail analytique, tandis que les risques précédemment définis doivent être clairs pour tous les participants au processus.Dans le processus de développement de l'intégration des deux systèmes, nous avons été confrontés à la formation d'exigences par le directeur couvrant les actions des utilisateurs dans les deux systèmes, mais le manque de coordination explicite de ces mêmes exigences de la part du chef immédiat de l'unité, dont les employés étaient des utilisateurs du système.
Comme il s'est avéré plus tard, le chef de la division ne comprenait pas du tout pourquoi toutes ces améliorations et comment elles permettraient d'optimiser les processus dans son domaine de responsabilité.
Souvent, les participants au processus d'approbation ont simplement peur d'apposer leur signature, car ils ne comprennent pas parfaitement certaines sections du processus opérationnel mis à jour. Votre tâche en tant qu'analyste commercial est d'éliminer ce malentendu.
- Présentez le sujet aux développeurs
Passez quelques heures, mais informez vos développeurs du client, des processus commerciaux actuels, de la douleur et des plans de développement. En règle générale, les développeurs bien motivés font non seulement parfaitement leur travail, comprenant pour qui ils écrivent le code, mais apportent également une précieuse contribution: ils offrent une optimisation, des solutions de contournement, sont plus disposés à poser des questions de clarification.Si nécessaire (et manque de mêlée), attirez le client vers une telle rencontre. En règle générale, les représentants des entreprises acceptent volontiers de telles initiatives.- Apprenez au client à répondre à la question «Quoi?» Plutôt que de formuler des exigences au format «Comment»
Le client ne doit pas formuler une exigence commerciale / utilisateur à partir de la position «Comment faire»: nous avons besoin d'un bouton sur cet écran pour générer un rapport; nous avons besoin d'un lien vers un système externe dans cette section; etc.Au stade de l'analyse initiale du processus, avant la conception elle-même, le client ne doit pas proposer de solution.Au lieu de cela, apprenez au client à formuler le problème, sa «douleur»: nous devons générer un rapport hebdomadaire, qui est complété manuellement par un employé et envoyé à la direction; dans le processus de travail avec le client, nous devons analyser des informations supplémentaires, et comme elles ne sont pas disponibles dans le système CRM, nous devons ouvrir un nouvel onglet dans le navigateur et vous connecter au système adjacent.Après avoir appris la douleur du client, vous, en tant que spécialiste, pouvez offrir des options pour optimiser le processus et son automatisation. Par exemple, envoyez automatiquement le rapport généré au courrier électronique de l'employé, enregistrez l'employé du travail manuel avec le rapport, en principe, téléchargez automatiquement les données d'un système adjacent vers CRM, etc.Dans de nombreux cas, cette approche sera confrontée à la réalité: délais et priorités. Mais vous, en tout cas, honnêtement essayé.
- Assurez-vous de diviser les utilisateurs en classes
Accepter les exigences de l'utilisateur du système, sans faute prendre en compte son rôle dans le processus métier. Dans la pratique, il y a souvent des cas où le chef de département définit les exigences de la fonction avec laquelle un employé ordinaire travaillera.Divisez les utilisateurs du système en rôles, et la fonctionnalité qui est affinée pour un rôle, ne "tache" pas sous un autre rôle.Une fois, dans le cadre du Système, nous avons implémenté l'affichage d'une liste de transactions avec les clients.
On a supposé que les gestionnaires et les employés ordinaires travailleraient avec la liste. Malheureusement, nous n'avons pas pu comprendre le client de la nécessité de diviser la partie UI de la révision en deux listes / écrans: une liste est pour le manager à des fins d'analyse et de contrôle, la seconde liste est pour le salarié dans le but d'effectuer des activités opérationnelles.
Le résultat a été un certain monstre, qui a ensuite dû être finalisé et finalisé.
Appliquez les meilleures pratiques de UX: élaborez des personnages - modèles d'utilisateurs. Convaincre le client de séparer les exigences de chaque personnage.- Utiliser activement le brainstorming analytique
C'est possible en tandem avec le deuxième analyste, c'est possible en tandem avec le designer UX. Dans le processus d'agression, essayez deux rôles: une personne génère d'abord beaucoup d'idées, réalisables et pas très, la seconde critique ces idées, les décompose, les écrit, les réfléchit; puis changez de rôle et faites le même travail.Comme le montre la pratique, cette approche accélérera considérablement le processus de compilation des exigences fonctionnelles et améliorera leur qualité. Mais il y a une difficulté à ce que les deux spécialistes soient dans le contexte de la tâche.- Si vous êtes coincé dans Waterfall, ne désespérez pas et avancez vers Scrum
Dans l'une des entreprises, littéralement en un an, notre équipe a réussi à transférer le processus d'introduction d'améliorations des cadres bien établis au niveau des managers à Waterfall à une sorte de Scrum. Oui, les délais «clairs» pour le carnet de commandes fortement taché, que le client exigeait constamment de l'équipe informatique, se retiraient, tandis que la rhétorique était progressivement atténuée grâce à des versions de deux semaines, des solutions MVP et une réponse rapide aux changements.- Ne diabolisez jamais le client.
Oui, il y a toutes sortes de clients. Il y a ceux qui sont littéralement furieux. Néanmoins, un analyste d'entreprise doit résoudre ce problème soit seul, soit avec la participation d'un gestionnaire et en aucun cas il ne doit sortir une «querelle de la hutte» - au sein de l'équipe.L'équipe doit être bien motivée pour travailler, et le rôle d'un analyste d'affaires dans le processus de formation de la motivation est l'un des éléments clés.Sérieusement. Lorsque dans le processus de communication avec le client, j'entends des interruptions verbales ridicules de mon collègue analytique, lorsque mon collègue analytique interrompt le client sans l'écouter jusqu'au bout, je veux l'envoyer à des cours de négociation ou d'éthique élémentaire.Essayez d'écouter l'interlocuteur et écoutez-le.- Débarrassez-vous des mots parasites
Essayez d'éviter les mots parasites et moins de «moo» dans les conversations. Au début, c'est difficile, mais, croyez-moi, il est doublement difficile pour le client d'écouter un tel analyste qui ne peut pas exprimer ses pensées clairement et clairement. Un parasite peut être affecté par un développeur, un concepteur, un testeur, mais pas par un analyste métier reliant l'équipe informatique à l'entreprise. :
- " ".
- ", : ".
Analyse système
- Lorsque vous définissez la tâche à l'avant et à l'arrière, essayez de décrire le diagramme de séquence
Ou, en russe, des diagrammes de séquence. Les diagrammes s'avéreront utiles même pas du point de vue du développement, mais du point de vue de la vérification de leurs propres exigences. Très souvent, lors de la description d'un flux de messages, j'ai identifié des «trous» dans mon propre processus. Par exemple, une API non pertinente.Pour «dessiner» rapidement une séquence de diagrammes, utilisez le plugin PlantUML pour Confluence. Il m'a semblé qu'il était plus rapide de taper du code que d'ajuster l'emplacement des blocs et des flèches avec des stylos. Mais chacun dans cette partie a sa propre expérience et ses propres préférences.
En termes d'analyse, l' éditeur Swagger vous permet de fermer vos propres trous dans les exigences. Quelque part, ils ont raté l'attribut, quelque part, ils ont oublié de créer une tâche dans JIRA pour finaliser la base de données. N'essayez pas de mémoriser la syntaxe Swagger, mais créez des modèles pour différents types d'API (répertoires, filtres, etc.) pour vous simplifier la vie à l'avenir.
- Utiliser activement l'outil de développement dans le navigateur cible pour analyser les demandes des clients et les réponses du serveur
Premièrement, pendant le processus d'acceptation initial, vous pouvez vérifier l'API que vous avez vous-même décrite. Parfois, il est plus rapide de vérifier certaines des améliorations par des demandes sortantes que par l'interface utilisateur, afin de comprendre la racine du problème à un stade précoce.En tant qu'analyste, vous aurez besoin de beaucoup moins de temps pour vérifier la mise en œuvre du développeur: données sortantes, données entrantes, résultat dans l'interface utilisateur.
Deuxièmement, vous pouvez vérifier la séquence d'appel correcte. Après tout, vous l'avez vous-même décrite dans le cadre du diagramme de séquence.Cette approche a permis à notre équipe d'apporter sans délai des améliorations assez délicates aux proms dans le cadre des sprints. :
- " JavaScript". JSON, , HTML, http / https, .
- . , . " . , , ". , , , .
en plus
Vous pourriez même l'aimer et vouloir évoluer vers l'analyse UX. Dans tous les cas, l'étude de la littérature et des outils de conception pertinents bénéficiera au moins du point de vue de la recherche d'un langage commun avec le concepteur UX de votre équipe.Souvent, ces exigences que vous, en tant qu'analyste, détaillez et notez, seront ensuite ajustées par le concepteur. Après tout, vous n'êtes pas seul, en fait, vous concevez l'expérience utilisateur.Pour être sur la même longueur d'onde, pratiquez votre analyse UX. Par exemple, pendant votre temps libre dans Sketch ou Figma, montrant de temps en temps le résultat à votre concepteur. Une telle expérience analytique ne sera jamais superflue. :
- " ".
- " ".
- ". ".
- ". ".
***Merci d'avoir lu l'article! Je serais reconnaissant, tout d'abord, pour les commentaires. Deuxièmement, pour des recommandations sur la littérature, les sources, les meilleures pratiques, l'expérience personnelle et les recommandations.