Cassez la boîte noire du développement logiciel

Si vous demandiez à un dirigeant d’une compagnie aérienne quelle était sa plus grande dépense il y a quelques décennies à peine, il vous aurait facilement répondu : carburéacteur. Ces jours-ci, vous auriez du mal à trouver un cadre dans n’importe quelle industrie qui ne répondrait pas avec, Software. Mais voici la différence : avec le carburéacteur, cet exécutif vous aurait dit qu’il pouvait voler x nombre de sièges-milles par gallon/litre de carburant (ou livres de carburant, si c’était technique). Avec le développement de logiciels, la dépense devient plus importante et beaucoup plus variable, mais le retour sur investissement est rarement clair. Au cours de la dernière décennie ou plus, le développement de logiciels a facilement pris sa place en tant que poste de dépenses à la croissance la plus rapide (et souvent la plus importante) dans pratiquement tous les secteurs. Toutes les entreprises ajoutent des expériences logicielles à ou autour de leurs produits, et elles ont besoin de personnes et d’outils pour créer, prendre en charge et optimiser en permanence ces expériences. Et cela coûte beaucoup d’argent.

Le problème est que le langage, les mesures et le monde dans lequel le développement de logiciels existe ne se traduisent pas en termes opérationnels ou financiers que les chefs d’entreprise peuvent facilement comprendre.

Nous avons investi X millions de dollars dans le développement de logiciels l’année dernière, pourrait dire un directeur financier. Et qu’avons-nous à montrer pour cela ?

Pendant ce temps, un leader technologique pourrait répondre avec, Faisons X déploiements par jour ! ou, Nous avons écrit X mille lignes de code !

Ils pourraient tout aussi bien parler des langues différentes parce que, concrètement, ils le sont.

Et le problème est que vous ne pouvez pas gérer ce que vous ne pouvez pas mesurer. Pour poursuivre notre thème de compagnie aérienne, le développement de logiciels continue d’être une boîte noire, cette source d’informations cachée à la vue de tous que les dirigeants financiers ne semblent pas pouvoir jeter un coup d’œil.

Pourquoi la boîte noire ?

Il est peu probable que les leaders technologiques soient délibérément insaisissables envers les chefs d’entreprise, il est plus probable qu’ils ne soient tout simplement pas alignés sur ce qu’ils doivent faire, fondamentalement, pour parler le même langage.

La question qui se pose est, en fait, ces investissements se transforment-ils en résultats commerciaux souhaités ? Mais la question à laquelle les leaders technologiques se sentent obligés de répondre est la suivante : que font vos employés toute la journée ?

Ce sont des questions qu’Agile et DevOps ne résolvent pas en traduisant les métriques Agile ou DevOps (également appelées métriques DORA) en métriques réelles et exploitables que les chefs d’entreprise doivent comprendre. Bien que ces métriques soient extrêmement utiles pour les équipes, les utiliser pour piloter l’entreprise est une erreur.

Mal alignés dans leurs objectifs et utilisant un langage différent, les chefs d’entreprise et les leaders technologiques se parlent alors que les coûts de développement de logiciels continuent d’augmenter.

Mais le coût du développement logiciel est trop élevé pour que les chefs d’entreprise continuent à tolérer cette boîte noire de coûts toujours plus élevés. C’est la responsabilité fiduciaire des dirigeants financiers de comprendre la valeur des investissements logiciels et de comprendre comment ils affectent les résultats de l’entreprise ou leurs emplois pourraient être en jeu.

Au cas où cela semblerait être une menace lointaine, ce n’est pas le cas : j’ai récemment vu un titre sur un dirigeant automobile éminent qui a perdu son emploi parce qu’il n’était pas en mesure d’obtenir les informations nécessaires sur ses coûts de développement de logiciels importants et sur les résultats de son entreprise. affectait la compétitivité de l’ensemble de leur entreprise.

Ça se passe. Et c’est à la fois aux chefs d’entreprise et aux chefs de file de la technologie de casser cette boîte noire et de commencer à parler le même langage.

La question suivante, bien sûr, est, comment ?

Comment combler le fossé de communication entre la technologie et les chefs d’entreprise

Pendant trop longtemps, les chefs d’entreprise se sont contentés des mesures d’activité fournies par les leaders technologiques, ils ont toléré ce manque de visibilité et ont trouvé d’autres moyens stratégiques pour justifier la hausse des coûts de développement logiciel. Peut-être se sont-ils demandé comment A mène à Bcomment une augmentation du financement pour le développement de logiciels pourrait entraîner une plus grande fidélisation de la clientèle ou l’utilisation d’applications, par exemple, mais ils n’ont pas eu de moyen tangible de se prouver, et encore moins aux investisseurs, si cela se produit réellement .

Afin de comprendre et de quantifier les coûts de développement de logiciels, nous devons commencer à exiger davantage de nos leaders technologiques : travailler avec eux pour établir des objectifs réalistes et des résultats clés (OKR), et les tenir responsables des mesures commerciales qui se rapportent réellement aux résultats. Cela signifie insister sur les résultats commerciaux et ne pas accepter les mesures d’activité à leur place.

Des produits à fonds stables, pas des projets

Voici une pilule difficile à avaler pour la finance : lorsqu’il s’agit de fournir des expériences client logicielles, il ne s’agit pas d’optimiser les coûts. C’est beaucoup plus nuancé que X dollars en égale X dollars en sorties. Le financement par projets peut aider à rendre les chiffres nets, mais il ne reflète pas la réalité de l’entreprise.

Le financement par projet a également tendance à maintenir les chefs de projet dans une mentalité de centre de coûts : il donne l’impression que toutes les ressources sont fongibles ; comme si le travail et les personnes qui l’exécutent étaient interchangeables.

L’un des objectifs d’Agile est de maximiser la valeur pour le client. Mais lorsque nous finançons par projet, nous arrêtons souvent de financer un travail en le déclarant terminé avant qu’il ne commence réellement à générer de la valeur. Nous avons cette fausse date de fin qui ne reflète pas la fin réelle de la valeur que nous avons financée pour créer.

Au lieu de cela, les organisations financières devraient passer au financement stable des produits : financer un résultat et donner aux équipes la possibilité d’arrêter, de modifier ou d’étendre leur travail pour atteindre les résultats commerciaux du produit.

Il s’agit d’un changement qu’une grande banque britannique a connu ces dernières années, passant de la gestion de portefeuille traditionnelle à une gestion de portefeuille allégée, y compris le passage à des projets à financement stable. Vous pouvez en savoir plus sur la façon dont NatWest Group (anciennement Royal Bank of Scotland) a opéré ce changement dans ce webinaire.

Visualisez le flux de valeur avec les mesures de flux

Enfin, nous devons cesser de traiter la collecte de mesures technologiques et de mesures commerciales comme deux efforts distincts et non liés. Agile et DevOps sont excellents pour accélérer le débit de votre développement logiciel, mais les mesures de vanité sur la rapidité avec laquelle les équipes livrent ne suffisent pas à justifier l’investissement croissant et matériel dans le développement logiciel.

Les responsables financiers ont la possibilité d’être le Babelfish entre les leaders technologiques et les chefs d’entreprise. Comme mentionné ci-dessus, une façon d’encourager une communication plus claire entre les équipes consiste à utiliser les OKR pour lier naturellement les objectifs de développement logiciel à des résultats commerciaux tangibles. Plus nous nous entraînons à établir des liens entre la technologie et les mesures commerciales, plus nous nous rapprochons de l’ouverture définitive de cette boîte noire insaisissable.

Un élément clé de cela consiste à communiquer différemment les métriques opérationnelles : développer un ensemble de métriques de base pour suivre le flux de valeur commerciale dans la livraison de logiciels et fournir un mécanisme qui corrèle l’investissement dans le flux pour chaque flux de valeur de produits avec les résultats commerciaux pour cette valeur. flux.

Visualiser le flux de valeur dans un processus de développement logiciel n’est peut-être pas aussi facile que de regarder le flux de valeur dans un atelier de fabrication, mais cela ne signifie pas que c’est impossible. Grâce au grand nombre d’outils de données et de visualisation à notre disposition, il est possible de rendre les produits logiciels et leurs flux de valeur aussi visibles que les lignes de production.

Le Flow Framework, créé par le Dr Mik Kersten, relève le défi crucial de briser la boîte noire du développement de logiciels et de combler le fossé entre l’entreprise et la technologie pour optimiser le flux de valeur commerciale vers les clients.

Cassez la boîte noire avec la gestion des flux de valeur

La boîte noire du développement logiciel est, à la base, un problème de communication. C’est à la fois aux chefs d’entreprise et aux chefs de file de la technologie de combler ce fossé de communication. Les chefs d’entreprise doivent exiger davantage des leaders technologiques et insister pour traduire l’activité en mesures commerciales. Les leaders technologiques doivent s’entraîner à lier leurs efforts à des résultats commerciaux tangibles pour aider à justifier leurs dépenses croissantes.

Bien sûr, il est utile d’avoir des outils spécialement conçus pour faciliter cette visibilité et cette communication.