Par souci de productivité, les développeurs doivent apprendre à dire "non"

Celui qui a inventé le mantra ' Le client a toujours raison ' n'a jamais essayé d'entreprendre des tâches de développement pour des clients avec des idées grandioses, mais aucun arrière-plan technique.

De nos jours, chaque société peut être une société de logiciels mais tout le monde ne sait pas comment gérer efficacement les projets de développement de logiciels. Mais donnez-leur l'option, et ils vont certainement essayer.

Dans mes différents rôles en tant que développeur, chef de projet et maintenant PDG ont appris qu'essayer de trop se plier à tous les besoins, souhaits et caprices de vos clients, limite votre capacité à résoudre correctement vos problèmes de travail –

Voici trois raisons pour lesquelles vous obtiendrez les meilleurs résultats pour vos clients. pour les projets de développement, vous devez apprendre à dire non:

1. Pas tous les clients sont un bon ajustement pour votre équipe

Récemment, un client potentiel m'a dit qu'ils n'étaient pas à l'aise de payer à l'avance. Je leur ai offert la chance de partir sans frais à ce stade, expliquant que « nous offrons des logiciels personnalisés, pas des processus personnalisés .»

Finalement, ils ne se sont pas inscrits. Même si ce n'était pas le meilleur résultat financier, c'était le meilleur résultat pour mon équipe et mon entreprise.

Mon manque de flexibilité sur ce sujet ne devait pas être difficile, c'est parce que nous avons développé des processus éprouvés, et que nous ne pouvons tout simplement pas adapter pour chaque client si nous voulons rester évolutif et rentable.

Cette question concernait les paiements, mais la même chose s'applique à tous les aspects de nos activités. Si les clients veulent travailler de la meilleure façon possible pour leur projet, ils doivent aussi être en adéquation avec nous.

Un rapport de Forrester prévoit qu'en 2018, les employeurs pourraient finir par payer jusqu'à 20% de plus que les salaires du marché pour les développeurs seniors et autres talents en demande. Au milieu d'une «pénurie de talents techniques», il est relativement facile de trouver de nouveaux clients, mais il est beaucoup plus difficile d'attirer les meilleurs développeurs.

Demander aux clients d'accepter nos conditions nous aide à gérer des projets, mais cela montre également à nos développeurs que nous apprécions leur travail plus qu'un salaire d'un client difficile. Mon entreprise peut survivre quelques mois sans nouveaux clients, mais si tous mes développeurs expérimentés quittent, nous sommes foutus.

2. Les clients paient pour que vous soyez un expert, pas un «homme-oui»

Beaucoup de dirigeants sont poussés à dire «oui» à tout, par peur de perdre des clients ou de recevoir de mauvaises critiques . Cependant, le risque de ces situations est beaucoup plus élevé si vous acceptez de faire des choses qui sont trop loin des zones de confort de votre équipe.

Vous n'allez pas dans un restaurant italien étoilé au Michelin, et vous vous plaignez ensuite parce que les chefs ne vous feront pas un curry indien. Vous pourriez cependant, s'ils essayent de vous faire quelque chose dont ils ne sont pas les meilleurs au monde, et cela ne répond pas à vos attentes.

En tant que tel, mon équipe et moi sommes très clairs sur les services que nous offrons, et ceux que nous n'avons pas. Nous travaillons uniquement avec: PHP, Laravel, JavaScript, Vue.js, Node, Ionic et Electron. Ces technologies sont modernes, matures et nous permettent de construire et de développer rapidement des produits.

Les clients paient pour vos services parce que vous pouvez faire quelque chose de mieux – et plus rapidement – que par eux-mêmes. Un problème auquel nous nous heurtons régulièrement est que les clients empilent des fonctions ou intégrations supplémentaires qu'ils croient nécessaires pour atteindre leurs objectifs. Dans ces situations, il est de notre devoir de repousser et de démontrer comment nous pouvons fournir des résultats de la manière la plus simple et la plus conviviale possible.

Un autre problème courant est que les clients veulent attendre qu'un produit soit parfait avant d'engager une base d'utilisateurs. Cela ne fonctionne pas pour nous. Nous construisons des logiciels en utilisant un processus agile éprouvé, et nous encourageons les clients à utiliser les logiciels le plus possible et le plus tôt possible pour pouvoir tester, trouver des problèmes et améliorer les fonctions.

Avant que les méthodologies Lean ne deviennent populaires, il était beaucoup trop courant pour les entreprises de passer jusqu'à trois ans sur des projets de développement [19659006]mais de réaliser que les méthodes finies devenaient populaires. produit n'a pas réellement atteint leurs objectifs. Je crois que lorsque vous utilisez des sprints, il n'y a pas de raison que vous ne puissiez pas avoir un logiciel fonctionnel dans les trois mois. Mais l'exécution de sprints efficaces exige que nos clients soient impliqués dans le processus du début à la fin.

Alors que mon équipe et moi-même sommes résolveurs de problèmes, nous refusons de travailler avec des clients qui veulent nous remettre un briefing, disparaître, puis s'attendre à un produit fini (tah-dah!). Au lieu de cela, nous travaillons en étroite collaboration avec nos clients dans un processus de développement rapide et itératif.

Je crois que la communication et la collaboration sont la pierre angulaire des projets de développement efficaces, et n'attribuons que des équipes de développeurs chevronnés à des clients, qui devraient être disponibles à la fin de chaque sprint.

Research montre que les paires de développeurs ont tendance à considérer plus d'options de conception que les programmeurs en solo, et produisent par conséquent des produits finaux plus simples et plus faciles à maintenir, avec moins de problèmes de conception et de bugs.

En même temps, il y a trop de participation des clients. Les clients de microgestion distraient les équipes de développement et peuvent ralentir un projet au rythme d'une escargot. Pour cette raison, nous offrons des mises à jour bihebdomadaires à la fin de chaque sprint, et n'offrons qu'un gestionnaire de compte ou un chef de projet comme point de contact pour garder un client à distance durant le moment critique des sprints, tout en ajoutant un futur essentiel. tâches à l'arriéré.

À la fin de la journée, les clients ont choisi de travailler avec vous parce qu'ils ne veulent pas embaucher et gérer eux-mêmes des développeurs. Si vous leur permettez de pousser vos projets de développement dans n'importe quelle direction, vous allez à l'encontre du but de tout l'accord. Donc, même si aucun client ne veut entendre NON trop souvent, si vous voulez offrir le meilleur service, vous devez prendre les choses en main et savoir quand mettre votre pied à terre.