Je travaille en tant que chef de projet pour Live Typing. L'année dernière, nous avons écrit dans notre blog d'entreprise que si le délai venait à tomber, l'essentiel n'est pas d'en faire une surprise et d'avertir le client. Mais plus nous travaillons, plus nous nous rendons compte que des délais pires que brisés ne peuvent être que des clients et des équipes complexes et émotionnels épuisés sous leur pression.
Les entreprises qui ont acquis quelques clients réguliers au cours des travaux, savent filtrer les prospects suspects même au stade du premier appel et peuvent se le permettre. Hélas, les jeunes studios en quête d'expérience et de revenus ne peuvent hélas pas se passer de tels clients.
Avant d'entrer dans le top 10 des différentes notes de l'industrie,
Live Typing a travaillé avec un client qui a tellement démotivé l'équipe que les gens ont commencé à quitter l'entreprise. Pour les raisons que je vais aborder ci-dessous, nous avons de nouveau convenu avec le client. Craignant une nouvelle crise dans les relations, j'ai développé une tactique de gestion spéciale pour garder l'équipe saine et sauve. Après tout, trouver un développeur sympa est difficile, et former et adapter un nouvel employé coûte plus cher que de garder un ancien. De plus, les spécificités de l'externalisation sont telles qu'après ce projet, les développeurs prendront le suivant, et il est important qu'ils le fassent avec des cerveaux qui n'ont pas été complètement fustigés.
À propos de la façon dont je l'ai fait, lisez l'article.
Pour des raisons évidentes, j'appellerai simplement le client «client». Même sur le projet, avec une coopération répétée, nous, à l'intérieur de l'équipe, n'avons rien appelé d'autre. Pourquoi? À ce sujet ci-dessous.
Contexte
Il y a deux ans, un projet nous est venu. Avant de nous rejoindre, environ cinq équipes y ont travaillé et il a accumulé un code hérité décent.
Les relations du client avec les équipes précédentes étaient loin de celles de son partenaire, alors avec lui, il a décidé de prendre automatiquement une position offensive et de se clôturer avec un mur de méfiance.
Pour accélérer la communication et le développement, le premier chef de projet a rendu le chat dans Slack commun pour le client et l'équipe - l'application n'a pas été développée par nous et a soulevé beaucoup de questions qui devaient être rapidement adressées au client. Dans la plupart des cas, cette méthodologie accélère le transfert d'informations entre les membres de l'équipe, mais notre client ne s'est pas refusé la possibilité de faire des commentaires impolis, que ce soit dans le chat ou dans un cadre personnel à une personne spécifique.
Le client s'est tourné vers des personnalités, ce qui a entraîné des conflits ouverts, et son nom a même été entendu par ceux qui n'étaient pas impliqués. En conséquence, l'entreprise a perdu au moins un employé qui ne pouvait pas supporter cette attitude, et plusieurs autres sont partis après quelques mois. Les raisons formelles du départ semblaient différentes, mais nous savons quelque chose.
Lorsque le client a manqué d'argent, nous avons rompu. L'argent, il convient de le noter, est allé, y compris la prise en charge du code hérité et le développement de fonctionnalités pour le plaisir de la fonctionnalité.
Le client est revenu plus tard. Il nous a convaincus qu'il souhaitait développer l'application à partir de zéro, abandonner le code obsolète, réduire les fonctionnalités et communiquer dans un style différent. Nous l'avons accepté, mais après un certain temps, l'histoire a commencé à se répéter.
Le client ne faisait pas confiance à nos notes et offres. Il avait sa propre idée du fonctionnement du produit. Nous savions également comment faire, mais le client n'a pas perçu les arguments et au lieu d'un partenaire ayant une expertise dans le développement d'applications, il n'a vu en nous que les mains qui transforment sa liste de souhaits en vie. Nous ne connaissons pas les raisons pour lesquelles le client se met dans une telle position et ne spéculerons pas.
La situation se réchauffait. Rappelant comment les événements se sont développés dans le passé, nous avons priorisé dans un ordre inhabituel pour nous: tout d'abord, vous devez sauver l'équipe, puis seulement clôturer le projet avec succès et, si possible, fidéliser la clientèle.
Tactiques de protection pour les clients complexes
Voyons maintenant les techniques qui nous ont aidés à atteindre notre objectif, les erreurs que vous ne devez pas répéter et les conclusions que vous pouvez utiliser dans votre travail.
Expliquez la valeur du design
Ainsi, le projet est parti de zéro. Dans le cadre de cette décision, une proposition a été faite de faire du MVP et de payer notre travail selon le modèle de prix fixe. Cela semblait logique, car s'il n'y a pas de code de quelqu'un d'autre, alors il n'y a aucun risque.
L'inconvénient du prix fixe en tant que modèle de paiement est qu'il prive le projet de flexibilité: pendant que la fonctionnalité est mise en œuvre, ce que les parties ont convenu dans la tâche technique, le marché peut changer et le résultat du travail ne résoudra plus les problèmes réels des utilisateurs. Il est possible de développer des MVP à un prix fixe uniquement si vous avez minutieusement testé toutes les hypothèses, conçu les spécifications techniques et rédigé la documentation détaillée. Notre client a simplement négligé le design, ou plutôt, l'a pris sur lui.
L'histoire avec le choix d'un service pour les chats est indicative. Le client a lui-même étudié les solutions techniques possibles et nous a proposé plusieurs services: "Quel est le meilleur?" Nous avons choisi le service A car il convenait au projet sur un ensemble de méthodes API, et du point de vue du développement et de l'intégration c'était mieux que le service B. Nous n'avons pas conçu le service pour travailler avec notre infrastructure et n'avons vérifié rien d'autre que ces critères formels: ni stabilité , pas de vitesse de réponse, rien - il n'y avait pas de budget. Le chat a fini par répondre plus lentement qu'il ne le pouvait s'il avait le temps de vérifier.
Ne tombez pas dans les manipulations dans l'esprit de «Si vous en avez besoin pour accomplir une tâche, faites-le gratuitement! Vous devez bien le faire! »S'il y en a: l'essence du développement de l'externalisation est de résoudre les problèmes des clients pour l'argent du client.
L'analyste doit concevoir. Il possède les connaissances qui lui permettent de comprendre et d'exprimer clairement ce dont le client a besoin au final, et de construire une architecture système commune: quels services seront dans le produit, s'il y a intégration avec des systèmes tiers, comment les requêtes vont-elles entre les services, où les informations sont stockées, comment il est livré, etc. Cela est nécessaire, premièrement, pour que le produit du client fonctionne rapidement et de manière fiable, et deuxièmement, pour vous conseiller sur ce que vous pouvez économiser et ce qui ne vaut pas la peine.
Faites en sorte que MVP soit le même pour tous
Ce que MVP signifiait pour nous:
- nous nous accordons sur les fonctionnalités de base de l'application et polissons à l'idéal uniquement les fonctionnalités qui s'y rapportent. D'autres fonctionnalités devraient fonctionner de manière à ce que vous ne souhaitiez pas fermer l'application;
- nous faisons un minimum de fonctionnalités nécessaires pour résoudre un problème commercial, et aucune zone d'administration conçue;
- nous reportons la personnalisation à plus tard, c'est-à-dire que nous utilisons des composants dans la conception qui peuvent être réutilisés sur plusieurs écrans, refusons les éléments de mise en page complexes et simplifions la conception si nécessaire.
Mais les clients MVP ont des interprétations différentes. Qu'est-ce que cela a signifié pour le nôtre:
- fonctionnalité minimale pour un minimum d'argent.
À l'avenir, il s'est en quelque sorte trouvé qu'il restait «un minimum d'argent» et la position «nous savons comment le faire, alors faites ce que nous disons» a été ajoutée.
Une telle position menace un partenariat normal. La menace ne peut être supprimée que par la conception et une tâche fonctionnelle, qui définit tout ce que l'application devrait être en mesure de faire. Y a-t-il de nouvelles exigences et suggestions non engagées? Reportez-vous à la loi fédérale et proposez de gagner du temps. Il s'agit peut-être de formalisme et non de souci du client, mais c'est juste par rapport à votre entreprise.
Encore une fois: MVP est combiné avec fix quand il y a du design. Nous ne l’avions pas, mais vous devriez l’avoir.
Laissez les développeurs discuter avec vous
Et ne travaillez jamais avec une conception non engagée du client, comment nous avons travaillé.
Les développeurs sont le plus souvent liés: dès que la tâche est définie, ils le feront. Mais sur des projets à budget limité, la mise en œuvre de chaque tâche potentiellement complexe doit être remise en cause afin de la plier et de respecter le délai.
La source de ces tâches était de façon inattendue la conception avec laquelle le concepteur côté client a traité. Nos développeurs ont été informés que s'ils demandaient des corrections, elles seraient soumises rapidement, nous avons donc commencé à travailler non pas avec la version statique du design, mais dans l'éditeur Figma, où ce design a été créé. Les développeurs ont donné une évaluation et se sont mis au travail.
Et puis, un par un dans la conception, des éléments ont commencé à apparaître qui n'étaient pas à l'origine - cela pouvait être vu à partir de la sauvegarde, que j'ai faite juste au cas où. Mais avant de commencer le développement, il est impossible de vérifier si un élément particulier de la conception a changé - du moins parce que le développeur prend les tâches dans un ordre pratique pour lui-même.
Identifier les incohérences a aidé cette même liberté d'expression. Le développeur pourrait venir vers moi et faire appel non seulement aux éléments qui ne peuvent pas être rapidement constitués, mais aussi aux éléments qui sont dans la conception du client - cela est compréhensible, car le concepteur lui-même les a secrètement introduits là-bas, mais pas dans notre copie. Ces éléments n'ont pas été inclus dans l'évaluation, ce qui signifie que nous ne devons pas les traiter à nos frais.
Dans le monde du développement sain, le prix fixe ne permet pas d'augmenter la quantité de travail et de changer les conditions en déplacement.
Éloignez le client de l'équipe
La dernière fois que nous avons connecté directement les développeurs et le client - il y a des équipes où l'on pense que le gestionnaire doit d'abord surveiller les conditions et le budget, et ne pas servir de transmetteur des exigences du client.
Il s'agit d'une excellente méthodologie avec ses avantages: la réaction de chaque partie est plus rapide, l'équipe comprend mieux la tâche commerciale, son autorité grandit et le gestionnaire ne meurt pas en tant qu'émetteur. Mais sachant que le client peut devenir personnel, je l'ai isolé de l'équipe. Seul le client, gestionnaire de compte et chef de projet, c'est-à-dire moi, est resté dans le chat.
Qu'est-ce que cela nous a apporté? J'ai modéré la communication et n'ai pas permis à des relations personnelles d'empoisonner la routine de travail. Dans les moments où le client a critiqué l'équipe à leur manière, j'ai répondu que nous prendrions des mesures et punirions l'employé. Les observations montrent que pour rassurer certains clients, il suffit de sacrifier quelqu'un de l'équipe même pour le plaisir, donc l'employé a continué à travailler calmement et ne savait même pas qu'il avait été puni.
Si vous pensez que le client est agité, n'amenez pas l'équipe avec lui au moins pendant un certain temps, jusqu'à ce que vous soyez convaincu du contraire.
Reformuler le feedback du client à l'équipe
Dans une atmosphère de méfiance et de critique constantes, l'équipe ne parvient plus à traiter les commentaires sous la forme dans laquelle ils arrivent, et le client commence à penser que l'équipe ne vient travailler qu'avec de mauvaises intentions - et les incarne.
Que faire de ce manager? L'édition cosmétique ne ferait pas de mal: j'ai supprimé l'évaluation de la personnalité du feedback, ne laissant que le libellé de l'erreur sans perte de sens. Et comme vous ne recevez aucun éloge de la part du client, je n'ai pas oublié de donner à l'équipe mes propres commentaires - pour les tâches qui n'ont pas soulevé de questions, ce qui signifie qu'elles ont été bien exécutées du point de vue du client.
C'était:
«L'application ne fonctionne pas de paiement. Quelles mains as-tu faites? "C'est devenu:
«Les gars, l'application a quelque chose à payer, le client demande à le comprendre, voici les captures d'écran. Et avec les animations qui ont pris du retard il y a une semaine, tout allait bien. »Ne vous précipitez pas pour obtenir des bugs
La saisie de bogues dans le gestionnaire de tâches dès qu'ils ont été reçus du client est due à l'inexpérience. Armé d'un œil critique, le gestionnaire permettra d'économiser des heures de développeurs et un testeur. En parlant simplement au client ou en demandant de lire les actions qui ont conduit à l'erreur et d'enregistrer la vidéo, vous pouvez comprendre que le bogue n'est pas une priorité ou est apparu parce que le client faisait quelque chose de mal - et maintenant, vous n'avez plus besoin de le modifier. J'ai donc trié un quart des bogues entrants, et une autre partie était liée au service de support de service intégré - il y avait suffisamment de SDK tiers sur le projet.
Ne mentionnez pas le nom du client
Peut-être la perspicacité la plus importante. Selon l’ancien souvenir d’une partie de l’équipe, exprimer le nom d’un client a provoqué une attitude partiale envers toute remarque de sa part, quelle que soit sa pertinence. Et j'ai proposé d'appeler le client juste le client, ce qui a réduit le négatif. Il semble que tout le monde comprenne de qui il parle, mais croyez-moi - cette nuance a amélioré l'écologie du projet.
Conclusion
Pour plus de clarté, j'ai décidé de réduire tout ce qui précède à un tableau sur le principe «Comment ne pas faire et comment le faire».
Mais nos conseils vous seront utiles au minimum si la personne chargée de travailler avec les clients entrants dans votre entreprise, ou le gestionnaire de compte révèle des défauts de client au stade de la négociation.
Voici quelques points importants auxquels nous prêtons maintenant attention:
- Ce que le client dit de l'entrepreneur précédent, s'il l'était. S'il parle négativement de lui, il est possible qu'il ne perçoive aucune opinion autre que la sienne et qu'il impose ses décisions.
- Le client a-t-il de l'expérience en informatique? Pour un client expérimenté, le processus de développement soulève moins de questions.
- Qu'il négocie pour chaque cent ou non. Plus le client désire payer moins, plus il soutient volontiers et obstinément.
J'espère que cet article sera utile à quelqu'un. Et si vous étiez déjà à ma place, dites-nous comment vous avez résolu des clients aussi difficiles.