Analyste d'affaires et analyste de systèmes en TI. Tri des notes

Problème


Certains de mes amis, collègues, managers, eycharov, représentants du "business" dans leur tête ont créé une confusion entre les types d'analystes. Le concept d '«analyste» est utilisé pour des professions complètement différentes - analyste d'affaires (BA), analyste de systèmes (SA), analyste de données, analyste UX, analyste de la sécurité de l'information, analyste des processus d'affaires et 5 à 10 autres, tous ces espèces ont beaucoup de différences. Maintenant sur les deux spécifiques, les plus confus, mais très différents dans les réalités informatiques nationales.



Qui bénéficiera de cet article:
ÀComment
Analyste et collègues— , , . — , , .

: xml- , -.
HR, , . «, ».

: java, .
Cibler la sélection et la distribution des ressources qui sont prêtes à effectuer une combinaison spécifique de responsabilités professionnelles, améliorer la communication au sein des équipes. 

Exemple: Pour un poste qui requiert un maximum de communication et de flexibilité, un «technicien» est sélectionné sans vouloir développer de telles compétences.

En général, «Du bonheur pour tous, pour rien»

Hypothèses


Cet article en dit plus sur l'informatique.

La valeur "distillée" des poteaux est considérée. Dans la vie réelle, en particulier dans les équipes qui développent des compétences en forme de T (modèle de développement des compétences d'un employé dans des professions connexes), c'est plus compliqué et déroutant, mais si votre analyste n'est pas Janus aux multiples facettes, la transition entre différentes responsabilités n'est pas une tâche facile.

Partie principale


En communiquant avec BA et CA d'entreprises et de projets de différentes tailles, j'ai vu une discorde dans les concepts qui crée la controverse. Comme cela se produit généralement, le manque de terminologie généralement acceptée interfère avec la répartition des tâches et des responsabilités dans le projet entre ceux qui sont en mesure de les remplir avec la plus grande efficacité. Afin de faire appel à une source objective dans ces litiges, j'ai décidé de chercher des avis sur le net.

Je partage les résultats de mes recherches.

L'analyse commerciale et l'analyse système en informatique sont des ensembles de pratiques, de méthodes et de tâches qui simplifient le développement des systèmes d'information nécessaires pour atteindre les objectifs commerciaux des organisations. La confusion entre ces deux concepts existe non seulement dans l'environnement domestique, donc:

https://en.wikipedia.org/wiki/Systems_analyst :

Un analyste de systèmes est généralement confiné à un système attribué ou donné et travaille souvent en collaboration avec un analyste d'entreprise. Ces rôles, bien qu'ayant un certain chevauchement, ne sont pas les mêmes.

En tant que sources pouvant établir une «ligne de démarcation» entre le SA et le BA, j'ai essayé d'utiliser les codes de connaissances du BA, la littérature professionnelle généralement acceptée, les documents réglementaires et les articles sur diverses ressources. Je n'ai pas pu trouver une division clairement articulée. Et c'est pourquoi:

  • , , — , . « », ( ), . 
  • ( / . ., BABOK, ., PMI Guide to business analysis . .), . , - -, . , . . -, « , , , , . , , , , - ». . PMI IIBA «system analyst» , «business analyst» .
  • ( ) , . , — . — , , , . — , , , , , .

Dans cette situation, j'offre ma vision, basée sur l'expérience des entreprises informatiques russes à la fois de la part du client et de la part de l'entrepreneur dans le développement de systèmes d'information. Cette approche a aidé le travail de l'auteur Alan Vongsavanh, qui a étudié la littérature et les résultats de plusieurs entretiens et a rassemblé une liste des compétences de base qui constituent la part du lion des activités de routine du BA et du CA (la majeure partie du temps de travail):


* Les sources étrangères utilisent les termes les plus appropriés «axé sur la technologie» et «axé sur les entreprises».

Où:
Identification des exigencesle processus de détermination des exigences à partir de diverses sources au moyen d'entrevues, de séminaires, d'analyses de tâches, de flux de travail et de documents et d'autres méthodes
Connaissance des affaires, , -
.
-
 ,
 
,
( )
connaître les technologies, la programmation, la création et la configuration de bases de données et d'autres aspects techniques, normes et règles de conception de solutions

Ensemble, ces actions vous permettent de former un cycle complet d'analyse des exigences, en l'apportant du client au développeur, et ensuite - en amenant le produit fini de l'équipe de développement au client. Une telle interaction tombe facilement sur les cadres, par exemple, voici à quoi cela ressemble dans le modèle V, le modèle en cascade ou les méthodologies flexibles:





Pourquoi une telle séparation


Les compétences requises par BA et CA sont similaires au plus haut niveau, mais le diable est dans les détails. Un analyste système a besoin de compétences techniques beaucoup plus pratiques pour une activité à part entière, il est beaucoup plus proche d'un groupe de spécialistes techniques et devrait mieux comprendre leur langue (sans cela, il est difficile de se faire respecter dans l'équipe, ce qui signifie qu'il est impossible de transmettre votre vision). BA in IT est plus configuré pour communiquer avec l'entreprise, sa tâche est de déterminer le besoin (douleur), de trouver, de formuler et de proposer une solution au problème du client d'entreprise utilisant des systèmes informatiques, de «vendre» cette solution en quelque sorte. La proximité et la compréhension de l'utilisateur aident le BA à hiérarchiser plus efficacement les tâches, à décrire les exigences et les limites non fonctionnelles dans un cas particulier.

De plus, BA a des exigences excessives inhérentes au système, il pense aux objectifs commerciaux et ne devrait pas être limité par les capacités de la technologie, ce qui est inacceptable pour une CA. Parfois, ces exigences BA excessives aident à trouver des solutions vraiment révolutionnaires.

Il y a cependant des limites. Pour BA, il s'agit de la portée d'un domaine ou d'une industrie étudiée (par exemple: une connaissance approfondie des règles bancaires), pour BA, il s'agit d'une technologie et d'un système (par exemple: une expérience exceptionnelle avec les produits Oracle). Ces restrictions peuvent être un obstacle à la transition entre équipes, projets et entreprises, mais peuvent être rapidement éliminées si souhaité et avec l'aide de collègues.

Presque toujours, l'analyste de l'équipe joue plus ou moins les deux rôles (par conséquent, je voudrais éviter les disputes sur la combinaison «et nous avons BA aussi un virologue»). Dans certains cas, les analystes peuvent ne pas être nécessaires; dans certains cas, un spécialiste peut remplir pleinement les deux rôles. Cela ne viole pas les règles, mais indique une combinaison de rôles, le niveau de maturité et la valeur d'un spécialiste particulier. Dans le cas d'un employé expérimenté, cela est tout à fait normal, mais le poste vacant de BA junior avec une connaissance de SQL, JS et API sur un site bien connu semble étrange.

https://en.wikipedia.org/wiki/Systems_analyst :

Certains professionnels dévoués possèdent des connaissances pratiques dans les deux domaines (analyse des affaires et des systèmes) et parviennent à combiner avec succès ces deux professions, brouillant efficacement la frontière entre analyste commercial et analyste de systèmes.

Exemple abstrait:


Ivan - BA entreprise "Entrepreneur".
Eva est analyste système chez Executor.
L'entreprise "Client" a besoin d'une révision majeure du système existant. 

Dans cette situation, les tâches d'Ivan (BA): identifier les exigences fonctionnelles et non fonctionnelles du client et du contractant, éliminer les contradictions entre les parties intéressées afin de déterminer une solution acceptable, créer des prototypes, interagir avec le client pendant le processus de développement, effectuer une démonstration et l'acceptation des travaux. Faire tout cela avec Eve.

Tâches d'Eve (SA): pour concevoir la révision de manière optimale, décrire son impact sur le système, les limites et les améliorations possibles, créer une spécification, décomposer et transférer les tâches au développement, et surveiller leur achèvement en temps opportun conformément aux exigences. Pour faire tout cela avec Ivan.

Au lieu de la sortie


De chaque fer, on peut entendre qu'avec le temps, la complexité des problèmes métier et de leurs solutions informatiques augmente de façon exponentielle. Parallèlement à cela, la pile technologique se développe de manière intensive et extensive, en largeur et en profondeur. Le choix de la bonne composition des technologies peut fournir des avantages concurrentiels révolutionnaires, mais cela peut aussi être destructeur, souvent le choix est fait pour les années à venir, plaçant les développeurs dans un cadre étroit. 

La situation actuelle nécessite que les analystes informatiques (1) aient une connaissance approfondie du domaine d'activité, des caractéristiques des processus internes, de l'environnement extérieur et des tendances, (2) au moins une connaissance approfondie des technologies, souvent leur utilisation pratique.

Vous pouvez être un idéaliste, rechercher un génie et lui demander une compréhension approfondie de divers domaines de connaissance, sinon polaires. Vous pouvez descendre sur terre et comprendre qu'une telle dualité de tâches est susceptible de conduire à un fakap dans les deux sens. Assis sur deux chaises n'est pas une bonne pratique. 

Si la complexité du projet nécessite un BA et CA, vous devez d'abord formuler le concept du niveau de connaissances commerciales et des fonctionnalités techniques d'un spécialiste et le traduire en une stratégie publiée de vacance, d'entrevue et de test. On veut toujours «une taille unique», mais nous vivons dans la vraie vie, où cela compliquera plus probablement la recherche et augmentera le prix pour attirer un «multi-outil».

Aux collègues qui se sont retrouvés ou envisagent de travailler en BA ou en CA, je vous conseille de suivre la même procédure et de comprendre honnêtement par vous-même si vous voulez (1) rechercher le grain de vérité dans des algorithmes et une logique souvent défiants, une entreprise en constante évolution ou (2) rechercher et concevoir un complexe systèmes déroutants mais intéressants. Cela contribuera à raccourcir le chemin vers le pic sélectionné et à réduire l'inconfort d'être à sa place dans la poursuite d'une «belle position». 

annexe



Eh bien, Glavred, est-ce maintenant plus clair? =)

All Articles