Aujourd'hui, je vais parler du fonctionnement du conseil informatique sur l'exemple du Big Data, partager mon expérience personnelle, comment je suis entré dans ce domaine et des études de cas, ainsi que donner des conseils sur qui et pourquoi devrait s'essayer dans le conseil.
Je suis diplômé du département de mécanique et de mathématiques de l'Université nationale VN Kharkiv Karazina a obtenu le poste DataArt de Java Trainee et y a travaillé pendant les 6 prochaines années. Ma carrière s'est développée rapidement en raison du fait que l'amour s'est réuni pour résoudre des puzzles complexes, mon désir inné d'apprendre, de trouver constamment quelque chose de nouveau pour moi et une équipe de méga-professionnels. Une fois, j'ai été attiré par un projet IoT interne, où nous, avec d'autres passionnés, avons compris comment connecter des capteurs à un microcontrôleur, où stocker (et surtout, est-ce nécessaire?) Cette énorme quantité de données, comment les traiter plus tard et comment les suivre en temps réel l'état du système, prévoir les pannes, où et comment l'héberger, etc. Nous sommes donc rapidement arrivés aux questions et aux tâches de BigData.
Cela a donné une forte impulsion à mon développement et m'a permis de travailler dans plus de 15 projets IoT et BigData, de participer régulièrement à des préventes, de prendre la parole lors de conférences et de cours éducatifs. Pendant cette période, ma position est passée de développeur principal à architecte de Big Data. Au début, c'était intéressant, mais au fil du temps, cela s'est transformé en une routine pour moi. Dans la plupart des cas, je suis allé sur le projet, le premier ou les deux premiers mois, il a été très actif, j'ai établi des processus, la communication avec le client et réfléchi à l'architecture, et ensuite je suis devenu l'un d'entre eux. plomb, PM, analyste d'affaires et bien d'autres)) Après six mois, tout s'est transformé en une journée sans fin de marmotte.
Par conséquent, à la recherche d'une nouvelle expérience et de nouveaux défis, je suis passé à SoftServe. Après presque un an, je peux partager mon expérience et ma vision du fonctionnement de tout ici.
Voyons d'abord comment fonctionne le processus de consultation. En effet, la plupart des employés informatiques sont impliqués dans le projet quand il y a déjà un contrat, un budget, un manager, et il est relativement clair quoi, quand et avec quelle équipe vous devez faire. Peu de gens se demandent comment, en principe, de nouveaux projets entrent dans l'entreprise et ce qui lui arrive au stade initial.
En effet, dans la vie de chaque projet, on distingue les phases suivantes:
- Préventes
- Découverte
- PoC / MVP
- Implémentation
- Le soutien
Phase de découverte - c'est le conseil même pour lequel nous sommes tous ici. Dès la signature du contrat, une personne du groupe conseil se rend chez le client. Idéalement, un analyste d'entreprise avec un designer UX le rejoint (je conseille aux personnes intéressées par la méthodologie de lire l'approche Design Thinking, dont j'ai déjà expérimenté plus d'une fois l'efficacité dans ma propre pratique). Dans un idéal idéal, il y a aussi un responsable de mission, qui s'occupe de toutes les questions d'organisation du processus, et un spécialiste de profil étroit.
- Sur place - en communication réelle avec le client, nous collectons autant d'informations que possible;
- Hors site - en collaboration avec l'équipe, nous analysons tout ce que nous avons réussi à déterrer, à concevoir le système, à prescrire les risques et le plan de mise en œuvre.
En sortie, ce groupe fournit au client un document qui contient:
- Description de haut niveau de l'état actuel du système;
- Scénarios d'utilisation d'un futur produit;
- Pilotes architecturaux et commerciaux prioritaires;
- Exigences concernant le volume de données, la vitesse de traitement, le délai admissible;
- Une vision architecturale reflétant toutes les exigences précédentes;
- La pile technologique sélectionnée (dont le choix est basé sur une analyse de compromis des options de mise en œuvre possibles dans le contexte des exigences du système);
- Estimation et carnet de commandes (liste des tâches) pour le prochain vase, plan de développement;
- Risques et moyens possibles de les éviter.
Si tout se passe bien et que le client signe la phase suivante, alors l'architecte travaille sur ce projet depuis un certain temps (le plus souvent à temps partiel). Jusqu'à ce que le processus soit établi, l'étendue des travaux est claire et le client est satisfait. Si tout le monde ici est heureux et veut continuer la coopération, alors la preuve de concept (PoC), le produit minimum viable (MVP) et la mise en œuvre et le support supplémentaires suivent.
Il semblerait que tout ce processus soit clair, structuré et compréhensible. Mais en pratique, tout n'est pas si simple. Examinons les scénarios possibles.
Ici, un client potentiel vient à nous. L'équipe commerciale effectue les premiers appels / rallyes afin de comprendre quel type de problème doit être résolu et se tourne vers des spécialistes plus étroits. Si le projet nécessite une connaissance de la pile de Big Data, alors le client potentiel vient à mon groupe.
L'étape suivante consiste à comprendre le niveau de difficulté de la tâche et à déterminer quels experts sont nécessaires. Il existe plusieurs options.
Le client ne sait pas du tout ce qu'il veut
Le plus souvent, cela se produit avec de grandes entreprises adultes qui comprennent qu'elles perdent de l'argent, mais ne comprennent pas pourquoi. Ou ils comprennent, mais n'ont aucune idée de comment résoudre ce problème.
D'après ma propre expérience, je peux dire que souvent dans une telle situation, vous devez d'abord résoudre des problèmes commerciaux, puis seulement la technologie. Vous devez être préparé au fait que ce n'est pas facile et des parties intéressées peuvent apparaître qui tenteront de vous entraîner dans leurs jeux politiques.
Par exemple, l'un des CTO que j'ai eu la chance de connaître m'a conduit une fois à un rassemblement stratégique pour discuter de l'achat d'une licence pour un produit populaire. La raison officielle de ma comparution n'était qu'une connaissance. Le conseil d'administration a été ravi de l'accord à venir et a fait l'éloge de leurs futurs partenaires. En tant que personne honnête et réfléchie, j'ai posé quelques questions de fond sur la façon dont ils vont s'intégrer. Il n'y a pas eu de réponse, mais l'accord a été annulé. En quittant la salle de réunion, j'ai demandé au CTO même si j'étais allé trop loin avec mes questions et si j'aurais dû me lancer dans tout cela. A quoi le "cardinal secret" a répondu: "Tout est super, je vous y ai amené pour ça."
Comment éviter cela? Non, c'est de la consultation. Il faut y être préparé, dans lequel la connaissance personnelle de la psychologie, des collègues plus expérimentés et une expérience personnelle m'aident, bien sûr.
Le client a une vision du produit final, mais il a besoin de notre expertise pour s'assurer qu'il a raison.
Probablement l'option la plus rentable en termes de coûts de temps. Beaucoup moins d'efforts seront consacrés à la recherche d'un problème, la communication avec un client sera beaucoup plus productive, pour laquelle votre opinion fait toujours autorité.
Cependant, il y a des pièges. Pour l'un de nos clients du secteur financier Discovery, la phase a été conçue pour 4 semaines, 2 semaines sur site et hors site. Le client pendant 2 semaines sur place n'a pas dit un mot qu'il avait déjà sa propre vision de l'architecture. Il y a eu une discussion sur certaines choses conceptuelles, mais il n'y a jamais eu de conversation sur une pile technologique. Et au milieu de la 4e semaine du projet, alors que nous avions déjà accumulé une tonne de matériel, collecté, priorisé et reflété les principales exigences dans la solution finale, lors de la présentation de l'architecture, le client commence à ressentir et dire que nous ne l'avons pas entendu. Il s'est avéré que notre tâche n'était pas tant de trouver quelque chose de nouveau que de deviner ce qui était déjà dans la tête de notre principal intervenant. Merci à mon grand patron qui était sur cet appel et a rapidement compris dans quelle direction le vent soufflait. Quelques mots-clés et le client sont à nouveau satisfaits et pour les jours restants, nous changeons complètement le concept, reflétons toutes les exigences et les risques, mais déjà dans l'architecture convenue avec le client.
Comment éviter cela? Validez, validez et validez à nouveau vos décisions avec le client, le plus tôt et le plus souvent, le mieux. Il vaut mieux dire plusieurs fois en parties ce que tout le monde a déjà compris que 4 semaines plus tard pour la première fois pour montrer l'architecture finale. Et cela concerne non seulement l'architecture, mais aussi l'approche de Discovery dans son ensemble.
Le client a une vision très précise et détaillée du produit, de vous il n'a besoin que d'une exécution
D'une part, c'est pratique. Pas besoin de connaître les exigences, de jouer avec la documentation, d'aller au client, au final. Prenez et faites. Mais souvent, cela ne fonctionne pas de cette façon. Dès les premiers jours, il devient clair que la vision du client est loin d'être idéale, car loin de tous les risques et exigences ont été pris en compte, les estimations sont clairement sous-estimées, et il est extrêmement difficile de transmettre cette idée, car le client est fermement confiant dans sa décision.
Comment se comporter dans cette situation? À mon avis, vous devez d'abord évaluer la rentabilité du projet par rapport aux ressources de l'équipe que vous devrez y consacrer. Après tout, de tels projets n'apportent pas toujours beaucoup de profits et vous devez y consacrer beaucoup d'énergie. Si nous décidons d'entreprendre ce commentaire, j'essaie de transmettre au client l'idée que nous, en tant que consultants expérimentés qui ont mis en œuvre de nombreux projets, nous efforçons d'utiliser notre expérience pour trouver la solution la plus rationnelle à son problème, et pas seulement de mettre en œuvre aveuglément l'idée proposée. J'informe également que la partie obligatoire de notre travail est de l'avertir de tous les risques possibles et, si nécessaire, de faire des recommandations sur la façon de les éviter. Autrement dit, vous devez gagner en crédibilité et vous assurer que le client commence à vous écouter.
Vous devez toujours pouvoir écouter et entendre à la fois le client et les collègues du projet. Après tout, les défis auxquels nous sommes confrontés sont souvent de nature non technique.
En résumé, je peux dire que le conseil s'adresse à ceux qui ne sont pas assis et n'ont pas peur d'essayer quelque chose de nouveau. Si vous travaillez sur le même projet depuis plus d'un an, le travail vous ennuie, mais la peur de changer quelque chose est obsédante - essayez de prendre un peu plus de responsabilités. Payer un cours pédagogique, réfléchir et proposer une optimisation au client, lui transmettre sa valeur, le vendre. Prenez quelque chose de nouveau, sortez de votre zone de confort. N'oubliez pas qu'il n'y a pas de mauvaise expérience, et même l'échec apporte une leçon, ce qui signifie qu'il nous rend meilleurs. Si l'expérience réussit, alors la peur disparaîtra et vous serez rempli de fierté et d'un désir d'aller de l'avant, de faire encore mieux et plus. En ce moment, vous pouvez venir en toute sécurité chez nous!