Développement de produits lorsque vous n’avez pas la bonne expertise technologique


Il y a quelques mois, on m’a confié la tâche de livrer un produit utilisant une technologie avec laquelle notre entreprise n’avait jamais travaillé et que notre équipe n’avait jamais rencontrée. Ma première pensée a été que c’était très risqué et qu’il y avait peu de chances de succès. Mais ma deuxième pensée a été: “OK, si je ne sais pas, cela signifie que je devrais trouver quelqu’un qui Est-ce que savoir et leur demander de l’aide. ” J’ai donc commencé le voyage que je voudrais maintenant partager avec vous.

Notre tâche était de fournir une extension à notre produit de base dans une technologie dans laquelle mon équipe actuelle n’avait aucune expertise. Nos équipes sont formidables. Ils sont intelligents, travailleurs et très professionnels, mais lorsque le délai demandé n’est qu’à deux mois et nécessite de nouvelles compétences technologiques, il n’est pas réaliste de s’attendre à ce qu’ils réussissent.

Tout au long de cet article, j’utiliserai l’implémentation d’une application de shopping mobile pour une plateforme de commerce électronique en marque blanche comme exemple de développement de produit lorsque vous n’avez pas d’expertise dans la technologie.

Développer en interne ou trouver une expertise externe?

Il y a quelques aspects qui doivent être pris en compte lors de la décision de développer une expertise en interne ou de rechercher à l’extérieur les compétences nécessaires.

1. Pertinence pour le cœur de métier

La nouvelle technologie peut apporter des améliorations importantes au produit, mais elle peut également être loin du cœur de métier ou concerner uniquement un segment spécifique de vos clients. Peut-être que la technologie est une niche et que vous souhaitez simplement tester le marché pour voir comment il réagit avant d’investir des ressources importantes ou de recruter de nouveaux membres de l’équipe.

2. Courbe d’apprentissage

L’apprentissage des nouvelles technologies prend du temps, beaucoup plus de temps que prévu. Vous devrez non seulement investir dans l’apprentissage de la technologie, mais vous devrez également sélectionner votre approche, comprendre les meilleures pratiques, trier vos licences, configurer l’infrastructure informatique (même pour la technologie liée au cloud). Et lorsque vous commencez sur cette voie, vous ne pouvez jamais être certain de l’effort requis, et cela vous prendra probablement plus de temps que quelqu’un qui a implémenté des fonctionnalités similaires une douzaine de fois auparavant. Dans notre exemple de commerce électronique, l’apprentissage du développement de plates-formes mobiles peut nécessiter un investissement de temps, ainsi que le recrutement de développeurs experts dans les technologies et les pratiques pertinentes, ainsi que l’adaptation de la technologie déjà présente dans l’entreprise.

3. Délais

Mon équipe commerciale veut que tous les nouveaux produits soient livrés hier, toujours. Je suis sûr que votre équipe commerciale le fait aussi. Les délais sont donc très importants. Dans les cas où la technologie est nouvelle, il est très difficile de s’engager dans un délai raisonnable, car tout le monde (naturellement) commence à ajouter des tampons en raison du manque de connaissances de la technologie. Habituellement, les responsables du développement n’aiment pas mettre trop de gens à travailler sur une nouvelle technologie à la fois, et si l’une de ces quelques personnes part en vacances de ski au milieu, il est difficile de trouver un remplaçant.

Le seul choix évident pour moi était de sélectionner une équipe ayant une expertise dans la technologie, puis de les aider à comprendre l’entreprise. Je pensais que si nous avions un grand propriétaire de produit qui comprend quoi devrait être fait, et les grands développeurs qui connaissent Comment cela devrait être fait, alors nous serions en bonne position – mais nous avons constaté que ce n’est pas entièrement vrai. Une bonne équipe est une équipe qui ne fait pas que compléter les connaissances d’une autre équipe – elle doit aussi chevauchement il. L’équipe produit doit connaître les limites techniques et les développeurs doivent comprendre les flux liés à l’entreprise et comment ils s’influencent mutuellement. Ainsi, lorsque le propriétaire du produit ne connaît pas les limites de la technologie et que les développeurs ne comprennent pas parfaitement l’entreprise, vous devez être prêt à relever un défi. Si vous suivez l’approche consistant à faire appel à des ingénieurs externes possédant les compétences requises, gardez à l’esprit qu’il y aura toujours quelque chose que l’équipe de développement ne comprend pas ou ne vous a pas expliqué, et que vous devez trouver ces choses qui fonctionnent. à travers eux ensemble.

Histoires d’utilisateurs

Afin de surmonter ce défi, je suggère d’utiliser les deux approches suivantes. L’un d’eux consiste à créer un document PRD classique qui peut être utilisé pour la définition des exigences et la base pour d’autres énoncés de travail et d’estimation. La deuxième façon consiste à créer des user stories, que vous connaissez peut-être à partir de méthodologies agiles.

Pour les histoires plus compliquées, j’ai trouvé bon d’ajouter une section qui soit une illustration pratique de l’histoire. Cette section contient des instructions pas à pas pour examen par l’équipe lors des réunions hebdomadaires, et les développeurs peuvent parcourir un scénario et comprendre comment vous prévoyez de tester le produit. Nous avons choisi cette approche user-story pour les raisons suivantes:

1. Souplesse

Une liste d’histoires d’utilisateurs peut servir de carnet de commandes pour que l’équipe puisse sélectionner des tâches, mais en tant que propriétaire du produit, vous définissez les priorités. Vous devez obtenir des estimations de l’effort pour le développement selon vos besoins, plutôt que tel que le développeur le comprend. Vous décomposant votre PRD dans les histoires, vous pouvez également demander à l’équipe externe de fournir des estimations d’effort basées sur votre compréhension de la fonctionnalité. Cela signifie que vous économiserez beaucoup de temps lorsque vous négociez la portée du projet.

Imaginons que nous ayons des fonctionnalités de vente croisée et de vente incitative dans notre plateforme de commerce électronique. De notre point de vue, c’est le même composant qui présente différentes listes d’éléments en fonction de ce que l’utilisateur a sélectionné sur l’écran principal. Les développeurs externes peuvent considérer cela comme deux tâches – la vente croisée et la vente incitative – et supposer que cela nécessite deux efforts de développement. Mais nous pouvons définir cette fonctionnalité comme l’histoire utilisateur de la vente croisée et up-selling, avec des composants potentiellement identiques, activé à l’aide d’un ensemble de paramètres différent selon le scénario.

2. Acceptation

Vous définissez comment vous testez, ce qui crée le cadre d’une compréhension commune. Les critères d’acceptation et l’illustration pratique permettent aux développeurs d’effectuer eux-mêmes des tests avant de vous livrer le résultat. Au cours de nos réunions hebdomadaires, nous avons démontré la manière dont nous avons effectué les tests d’acceptation, et l’équipe de développement a pu se préparer pour les futures réunions sur cette base.

Voici une illustration pratique simple de notre plate-forme de commerce électronique: “Connectez-vous à la plate-forme, sélectionnez un élément dans la page principale, sélectionnez un élément dans le composant de vente incitative et accédez à la page de paiement.” Cette illustration pratique implique que la sélection de deux composants différents est importante pour nous, et nous allons le tester lors de la réunion hebdomadaire.

3. Aspects technologiques

Cette liste d’histoires d’utilisateurs vous permettra également d’en apprendre davantage sur la technologie. Imaginez que vous avez trois histoires dans votre carnet de commandes. Pour autant que vous puissiez en juger, les deux premiers nécessitent un effort similaire et le troisième est beaucoup plus important, mais l’effort requis de l’équipe est incompatible avec votre compréhension, par exemple le premier et le troisième sont un effort égal, et la seconde est extrêmement élevé.

Cela peut être dû au fait que la technologie fonctionne d’une manière différente de votre compréhension, ou que l’équipe ne vous a pas bien compris. Dans notre exemple de commerce électronique, la vente croisée et la vente incitative peuvent être considérées comme un composant relativement simple, car il affiche simplement une liste de trois articles en résolution standard. Cependant, le rendu des éléments dans l’application mobile doit être adapté à chaque résolution prise en charge de l’appareil et nécessitera probablement des efforts supplémentaires.

Nous avons constaté que cette liste d’histoires était un moyen efficace de communiquer avec les développeurs et de clarifier nos intentions. Le seul inconvénient que nous avons trouvé avec une telle approche était le manque d’image complète pour l’équipe de développement. Chaque user story décrit une fonctionnalité distincte (ou au moins un workflow séparé), et le manque de connexion entre les stories signifiait que l’équipe de développement avait du mal à comprendre comment tous les composants devraient interagir. Ils l’ont trouvé très utile lorsque, en plus de la liste des histoires, nous avons fourni des diagrammes de séquence et des descriptions de flux.

En résumé, ce fut une expérience incroyable pour moi dont j’ai beaucoup appris. Gardez à l’esprit qu’une communication claire avec l’équipe de développement est toujours de la plus haute importance – d’autant plus lorsqu’elle est en train d’en apprendre davantage sur votre entreprise et que vous êtes en train d’apprendre une nouvelle technologie. Les récits d’utilisateurs peuvent constituer une excellente base pour une telle communication, mais gardez également à l’esprit que la documentation complémentaire doit être fournie pour former une image complète dans l’esprit des développeurs.





Source

  • Partager cet article

Laisser un commentaire