Avertissement: Aujourd'hui, nous parlerons exclusivement des projets infructueux, nous ne nommerons donc pas les noms, les mots de passe et les présences.
Tous les cas d'échec de mon expérience et de celle de mon ami peuvent être divisés en trois types selon les sources des problèmes:
1. Collaboration avec les parties prenantes
La raison de nombreux problèmes du projet est que nous n'écoutons ni n'entendons le client. Ceci est particulièrement critique au tout début, lorsqu'il y a un risque de manquer la réponse à la question «Pourquoi le projet est-il lancé?
Cas 1
Nous avons été confrontés à une tâche simple: bloquer toutes les transactions financières possibles dans le cadre de contrats qui ne sont pas convenus au sein de l'entreprise. Nous avons calculé les effets et travaillé, comme il nous a semblé, tous les risques. Cependant, au cours de la discussion, l'utilisateur principal a fait valoir que cela ne fonctionnerait pas: «Nous aurons un processus de production». Cela ressemblait à une excuse, et le client principal a confirmé notre hypothèse et a insisté pour le faire.
Le X-day, selon les plans, nous avons lancé la fonctionnalité, et environ une heure et demie plus tard, notre client principal, de mauvaise humeur, a appelé et a demandé à tout annuler: «Ça ne marche pas!».
Comment était-ce nécessaire?Écoutez les préoccupations de l'utilisateur, qui connaît les spécificités de l'organisation de l'intérieur, et élaborez ces risques. Il y a toujours une possibilité de trouver des options qui conviennent à tout le monde.
Cas 2
C'était un client fonctionnel qui a parfaitement compris la tâche et le système que nous avions conçu. Mais nous n'avons pas pris en compte l'intérêt de la DSI dans la mise en œuvre de ce projet et y sommes arrivés assez tard: au stade de l'élaboration de l'architecture. J'ai dû réviser le projet et repousser la date limite de sa livraison. Nous avons perdu du temps, de l'argent et de la réputation en surestimant l'influence et les capacités du client fonctionnel et en sous-estimant les relations internes entre les divisions d'une grande entreprise.
Comment était-ce nécessaire? Impliquer toutes les parties prenantes dans le travail sur le projet dès le début et prendre en compte leurs intérêts, malgré les assurances du client.
Cas 3
Et c'était une affaire qui a failli échouer. Le client fonctionnel, représenté par le PDG, voulait changer la méthodologie de comptabilité analytique et, selon tous les calculs, l'effet des changements aurait dû être significatif. L'équipe du bloc financier était prête pour les changements et au moment où la tâche a atteint les analystes informatiques, la décision avait déjà été prise. Et ici, nous avons fait la bonne chose et demandé: Pourquoi? Comment cela fonctionnera-t-il? Qui soutiendra le processus? Comment avez-vous considéré l'effet?
En conséquence, l'effet a été recalculé en tenant compte des changements dans le système ERP et des coûts de maintenance du processus et de l'outil. Non seulement l'effet «disparu» dans l'argent, mais des risques supplémentaires ont également été découverts. Le projet était clos, et pour les employés du département d'automatisation interne, il était devenu une règle de poser des questions au départ, même si la tâche venait du PDG.
conclusions
- Cherchez toujours une raison, un but, un effet. Argumentez votre position. Comme le dit une de mes connaissances (un directeur de classe): «Écoutez, ne vendez pas ... Puis écoutez à nouveau ... et vendez seulement»;)
- Vivez un jour avec les utilisateurs directs du produit et apprenez à connaître leur routine en détail. Cela aidera à anticiper toutes les nuances possibles.
- Traitez tous les risques qui vous semblent importants, à vous, au client fonctionnel et à toute personne intéressée. Portez une attention particulière aux clients / utilisateurs les plus négatifs envers le projet. Ils savent clairement quelque chose! ;)
- Ne manquez pas un seul participant dans le processus. Il ne peut y avoir un seul participant au processus et le service informatique doit toujours être pris en compte!
2. Description des besoins
Le saint des saints pour tout analyste est une description des exigences. Considérons les erreurs dans ce domaine sur les deux autres cas.
Cas 1
Une des équipes de développement a reçu un projet nécessitant une révision. Le système est livré avec une documentation, où la description de la logique du système a été écrite à l'aide de requêtes SQL. Au moment où les travaux ont commencé, le système avait déjà été sérieusement repensé et les requêtes SQL n'étaient plus pertinentes. J'ai dû passer du temps à faire de la rétro-ingénierie pour comprendre la logique et la fonctionnalité du système.
Comment était-ce nécessaire? Revérifier la pertinence et la conformité des documents avec le niveau de développement du projet. Surtout lorsque vous le transmettez à d'autres développeurs.
Cas 2
C'était un projet intéressant pour automatiser tous les processus au sein de l'organisation. Le projet impliquait 5 systèmes de différentes classes, qui devaient être intégrés les uns aux autres pour que le processus se poursuive sans interruption. L'équipe a conçu l'architecture de la solution pendant environ deux mois, lorsque j'ai été connecté au projet.
Dans le processus de communication avec le client, je me suis rendu compte qu'il le voyait d'une manière, et les développeurs d'une autre. Ce sont les accords minimaux en termes de mots qui ont complètement changé le projet. Je devais partir du tout début et travailler toutes les exigences à partir de zéro: pourquoi? Quelle? Comment?
Comment était-ce nécessaire? Décrivez clairement non seulement les exigences pour la mise en œuvre des processus et sous-processus (comment cela fonctionnera), mais aussi à quoi ressemblera le résultat final.
conclusions
Souvent, les équipes ont peur des commentaires des clients et courent pour se développer lorsqu'elles entendent «bien, un peu comme ça». Nous pouvons supposer que vous avez trouvé un langage commun avec le client uniquement s'il a lui-même commencé à faire des ajustements de ses propres mains. Certaines personnes trouvent pratique de lire des textes, d'autres ont des diagrammes et d'autres encore mettent en place des interfaces. Cela vaut la peine de tout essayer jusqu'à ce que vous trouviez un langage commun, même si ce sera des «dessins sur des serviettes».
3. Développement d'une idée, d'un produit ou d'une solution
Ce sont des histoires sur la gestion des produits, quand l'idée inonde l'esprit, et tout le reste n'a pas d'importance.
Cas 1
Nous avions un excellent produit pour automatiser les tâches de routine au sein d'une organisation: de la saisie d'informations à la réponse aux questions des employés. Et tout était super: nous avons trouvé les premiers clients, compris le marché - il semblait qu'il y avait beaucoup d'argent - nous avons lancé quelques projets et les avons terminés avec succès. Et à ce moment-là, nous avons ouvert les yeux: personne n'a calculé le coût de prise en charge de la solution. Et il a effacé toutes les tentatives possibles de gagner de l'argent à zéro.
Comment était-ce nécessaire? Calculez soigneusement tous les aspects du projet: du développement au support de la solution.
Cas 2
Une autre histoire est celle où nous n'avons pas travaillé sur le marché. Une idée a été trouvée pour un bon produit qui n'avait pas de concurrents sur le marché, mais qui avait des clients. Au moins un, et il était prêt à payer et à investir. Nous nous sommes lancés dans ce projet et avons été confrontés à une absence totale de base théorique pour le développement de telles fonctionnalités, mais nous l'avons géré.
Et après être entrés sur le marché avec le produit, ils ont réalisé que ce n'était pas en vain qu'il n'y avait pas de concurrents. Beaucoup de gens négligent cette fonctionnalité malgré tous les effets qu'elle garantit.
Comment était-ce nécessaire? Réfléchissez aux raisons pour lesquelles il n'y a pas de concurrents dans un secteur de marché aussi rentable et allez au fond de la vérité.
Conclusions:
Vérifier la viabilité du projet dans le cadre non pas d'un client, mais de la compétitivité - en fonction de la situation actuelle du marché.
Culture de l'échec
Afin de surmonter les difficultés et de ne plus vous y retrouver, vous devez trouver une raison. Le plus souvent, cela réside dans la culture de l'échec qui est adoptée dans les organisations. Il existe deux mauvaises façons de réagir à l'échec dans les organisations:
- Condamnation / punition
Condamnant les erreurs, nous tuons l'initiative. Les employés ont peur d'être créatifs et ne prennent que des décisions sûres. Cela conduit à une stagnation dans l'entreprise.
Solution: définissez les limites des erreurs. Il est nécessaire d'allouer des ressources pour la manifestation des initiatives et de les vérifier aux points de contrôle. Eh bien, suivez le succès du projet selon des critères stricts convenus à l'avance. - Silence
Cette tactique conduit à répéter encore et encore les mêmes erreurs. Et cela conduit à son tour à la perte de la position de l'entreprise aux yeux des clients, des concurrents et du marché.
Solution: construire un système d'échange d'expériences entre collaborateurs. La discussion des solutions possibles aux échecs conduit finalement à une méthodologie qui aide à éviter ces erreurs.
Une réflexion raisonnable aide à se développer, mais ce n'est pas une raison pour s'entourer d'échec seulement. Recherchez l'équilibre, car apprendre des projets réussis est beaucoup plus agréable