De nombreuses circonstances peuvent être des catalyseurs pour créer des logiciels médiocres: les outils utilisés, la qualité de la communication en équipe, les qualités personnelles des développeurs, les méthodologies, etc. Et il y a une chose parmi eux qui est à l'origine de presque tout le monde: les problèmes imaginaires.
La plupart des logiciels complexes ou zagabovannoy n'étaient pas prévus pour être complexes et, encore plus, zagabovannoy. Il a simplement été créé pour exécuter non pas les tâches qui étaient à la base du plan initial.
Histoire du podcast
Imaginons que vous enregistrez un podcast populaire et que vous envisagez à un moment donné de créer votre propre site - enfin, vous savez, avec des informations sur votre podcast, des enregistrements de numéros précédents, des articles et peut-être de la publicité. En fait, combien pouvez-vous partager les bénéfices avec certains éditeurs externes?
Vous décidez donc d'embaucher des personnes qui réaliseront ce site pour vous. Vous écrivez des exigences absolument claires pour eux:
- Chargement rapide du site en Amérique du Nord
- Prise en charge du téléchargement des versions antérieures des podcasts et de la diffusion en direct des contenus actuels
- La diffusion ne doit pas tomber ni geler pendant les 15 premières minutes pour 99,99% des utilisateurs. Jamais souhaitable, mais quand même.
- Intégration avec Google Adwords (et à l'avenir, éventuellement avec des analogues)
- Intégration avec les diffusions Facebook, car là vous passez vos diffusions. Si vous pouvez créer une solution alternative qui vous permettra de diffuser plus facilement - encore mieux.
Vous donnez ces exigences aux développeurs et, peut-être, communiquez un peu avec eux. 2 mois passent. Ils vous montrent une démo et vous êtes couvert de taches rouges. Il devient clair que vous venez de jeter 15 000 $ dans l'abîme. Ce qu'ils vous ont montré est complètement inacceptable de n'importe quel côté, juste un tas d'ordures. Vous voulez récupérer votre argent, mais le train est déjà parti.
Se mettre en colère à la vue d'un site démontré est très simple. À la première ouverture, tout s'est figé. Ensuite, cela a semblé fonctionner et vous avez demandé comment changer le type de publicité qui sera affichée sur le site. Ils vous ont montré une interface Twist-and-Bike pour cela, ce qui est tout simplement irréaliste à maîtriser par vous-même. Les flux Facebook sont lents. Tout est terrible.
Mais l'équipe de développement ne comprend pas pourquoi vous êtes contrarié. De leur point de vue, ils ont accompli un exploit, ayant fabriqué un produit aussi complexe en seulement 2 mois. Ils ont mis tout son talent en lui, toute leur âme. Jugez par vous-même des merveilleuses fonctionnalités qu'ils y ont ajoutées:
- Système de recommandation incroyable
- Algorithme de reconnaissance vocale qui affiche les sous-titres sous votre diffusion EN TEMPS RÉEL !!!
- La page principale du site se charge en 200 ms partout dans le monde
- Le protocole de diffusion et le client sont écrits à partir de zéro, et Facebook a été ajouté par un plugin. Vous pouvez ajouter des plugins pour d'autres plateformes à tout moment!
- Il est possible de s'intégrer à 20 plateformes publicitaires différentes
Vous voyez déjà quel est le problème, non? Vous avez demandé un produit très spécifique et hautement spécialisé avec quelques fonctionnalités supplémentaires dont vous avez besoin. L'équipe de développement l'a entendu différemment. Pour eux, tous vos "souhaitables", "plus pratiques" et "à l'avenir" se sont transformés en une tâche passionnante pour développer un produit commun, extensible, évolutif et complété de proportions énormes, au cours de la mise en œuvre duquel vous pouvez résoudre héroïquement un tas de problèmes intéressants. Eh bien, et, bien sûr, il n'y a rien à distraire par des bagatelles telles que le polissage et la mise à l'idéal des fonctionnalités de base du produit - nous avons quelle échelle, nous n'avons pas le temps de l'échanger maintenant!
Un autre problème est que vous n'avez probablement pas communiqué directement avec les développeurs directs du système. Vous avez joué un téléphone gâté: vous avez parlé avec un vendeur qui a confié des tâches à un membre de la direction de son entreprise, y a rédigé des spécifications commerciales, les a confiées au chef de projet, il a rédigé des spécifications techniques et les a données au chef d'équipe, qui les a réparties en tâches et remis aux développeurs. Eh bien, chacun des développeurs a également compris et réalisé ses tâches dans le contexte de sa compréhension.
Mécanisme d'évitement de la réalité
Les problèmes imaginaires sont plus intéressants à résoudre que les vrais. Des gens très intelligents jouent à des jeux complexes, résolvent des problèmes mathématiques, écrivent des livres sur des sujets abstraits - gratuitement ou presque gratuitement. Dans le même temps, le programmeur de classe moyenne pour une application mobile assez standard vous coûtera très cher. Ce n'est pas parce qu'un programmeur moyen est plus difficile à trouver qu'un génie. En effet, il est facile et agréable d'effectuer des tâches intéressantes, mais pas une routine.
La plupart des programmeurs veulent travailler sur des tâches intéressantes et en avoir pour leur argent. C'est difficile à réaliser. Bien sûr, vous pouvez spéculer sur ce qu'est un «problème intéressant», mais pour la plupart des développeurs, c'est quelque chose qui est très proche de la frontière du domaine des problèmes théoriquement résolubles. Quelque chose de difficile à réaliser, mais possible.
Donnez à une personne rationnelle de nombreuses tâches routinières et non automatisées, et tôt ou tard vous l'amènerez à la poignée. Le cerveau humain, cependant, après des millions d'années d'évolution, a développé plusieurs astuces différentes pour se maintenir dans un état adéquat. Alors que les victimes de la violence peuvent s'échapper dans le monde de leurs fantasmes, innocemment vouées à des années de développement d'entreprise ou de freelance sur le Web trouvent le salut pour résoudre des problèmes imaginaires.
Le nombre et la complexité des problèmes inventés sont fonction du niveau d'imagination du programmeur et de la complexité de ses tâches réelles. Il convient de noter que cette approche elle-même n'est pas propre aux développeurs de logiciels. Les gestionnaires, les vendeurs, les RH, le support, les avocats et les comptables trouvent leurs propres moyens uniques de créer et de surmonter héroïquement des problèmes inexistants. Ils s'impliquent dans des décisions qui dépassent leur compétence, s'expriment lors de réunions où leur présence est une pure formalité, etc. Ils surestiment également l'ampleur des problèmes et leur rôle dans leur résolution («Notre nouvelle application Doggy Diary devrait être compatible à 101% avec le RGPD dès le premier jour! Nous avons hâte que le client se plaigne!»). Ils gonflent le personnel pour donner l'impression de l'importance du travail de leur équipe, puis traitent les problèmes de croissance, de mise à l'échelle et de logistique (et il y aura toujours de tels problèmes dans une grande équipe).
Beaucoup de développeurs sont intelligents, mais bon nombre de leurs tâches sont plutôt stupides. Cette contradiction oblige les gens intelligents à imaginer d'autres, bien qu'ils n'existent pas dans la réalité, mais des tâches intéressantes.
Architecture de téléphone gâtée
Parfois, les problèmes imaginaires ne sont pas le résultat des fantasmes de développeurs ennuyés. Parfois, c'est le résultat d'un "téléphone cassé".
Je travaille parfois en freelance. Quand je viens de commencer, je ne pouvais pas me permettre de trier les clients. Cela signifiait la nécessité de prendre tout le monde dans une rangée et d'observer dans toutes les couleurs les manifestations les plus diverses des déviations de la psyché humaine. J'ai vu des chaînes de centaines de lettres au sujet de détails de prototype complètement immatériels. J'ai vu des gens changer absolument chaque paragraphe de la spécification chaque semaine. J'ai eu des clients qui, pour des projets de sites banals, ont demandé l'opportunité de sortir immédiatement avec eux à l'ICO ou de leur lier l'intelligence artificielle.
Il y avait des clients assez sensés qui manquaient cependant de connaissances (ou de vocabulaire?) Pour exprimer toutes leurs exigences dans des formulations compréhensibles. Ce n'est pas en soi un problème. Une partie du travail des développeurs de logiciels est précisément la collecte des exigences et la rédaction des spécifications. C'est ce pour quoi nous sommes payés, y compris l'argent, et ce travail peut même être fait plus ou moins normalement si vous avez un accès normal au client et suffisamment de temps. Le problème est que parfois cet accès ne l'est pas et qu'il existe plusieurs intermédiaires entre vous.
La plupart des entreprises aiment avoir des «vendeurs» dans des postes séparés. Ce sont des personnes spéciales qui recherchent des clients potentiels, discutent avec eux des tâches, des délais et des prix. Ce sont ces personnes qui peuvent trouver le plus utile et poser le plus de questions. Mais ce ne sont pas les gens qui vont écrire ce projet. Entre les vendeurs et les programmeurs, il y a 2, 3, 4 couches ou plus de gestionnaires, d'architectes, d'analystes et de chefs d'équipe de niveau intermédiaire et inférieur. Oui, il peut s'agir de personnes très qualifiées. Mais encore - ce sont des couches supplémentaires. Peu importe à quel point ils essaient, les informations qui les traversent changeront. Quelqu'un rejettera quelque chose (à son avis) qui est sans importance, un autre clarifiera quelque chose d'indéterminé, mais (à son avis) évident, le troisième remplacera la formulation stupide par le terme correct (comme il en est sûr) - et maintenant la tâche initiale ne peut plus être reconnue. Un vendeur peut lancer une phrase au client comme "mais pour 39 999 nous pouvons le faire sur la blockchain aussi". Si le client mord, l'équipe de développement devra creuser la cervelle à deux niveaux ci-dessous, mais comment cela peut-il être fait sur la blockchain. Mais il est déjà vendu et payé, nous le ferons.
Ainsi, le problème d'origine est perdu dans la spéculation et la réflexion. Il y a des trous entre les nouveaux problèmes inventés (s'ils n'y étaient même pas encore) et il y a des gens qui veulent les combler de leurs propres problèmes imaginaires et de leurs solutions brillantes. Parce que c'est toujours la liberté, pas la routine.
Complexité artificielle et sélection naturelle
Il y a souvent un côté encore plus sombre. Inventer des problèmes imaginaires et des méthodes pour les résoudre peut devenir le moteur de la croissance de l'entreprise et, à l'avenir, peut-être son activité principale, la partie la plus importante de son existence, qui ne peut être abandonnée.
«Les personnes sélectionnées pour résoudre des problèmes complexes n'ont aucune raison de résoudre des problèmes simples» - Taleb
Avez-vous entendu parler des trois meilleurs ingénieurs qui ont soudainement découvert que la banque en ligne est, en général, une chose assez simple? Ils ont créé un logiciel simple et donc sans problème, utilisé les techniques et langages de programmation appropriés, puis transféré toutes les banques principales sur leur plateforme.
Non, n'a pas entendu? C'est parce que ce n'était pas le cas. Mais ce qui s'est passé est et sera - des équipes distinctes de milliers de programmeurs travaillant pour différentes banques et pendant environ six mois, capables d'utiliser toute l'équipe pour mettre en œuvre une fonctionnalité telle que la «transaction de restauration». C'est comme ça que les logiciels bancaires sont écrits, oui.
Et ce n'est bien sûr pas parce que déplacer un nombre d'une colonne à une autre est si difficile, non. Ce n'est pas difficile. Ici, indexez l'intégralité d'Internet, puis affichez les résultats de recherche pertinents en une fraction de seconde - c'est difficile. Cependant, quelques gars du garage l'ont fait. Et pour l'annulation de la transaction, 1000 personnes et six mois sont nécessaires.
Le problème ici est que l'écosystème bancaire est incroyablement bon dans sa tâche principale - soutenir l'écosystème bancaire. Les roues tournent, les papiers bruissent et demain tout sera comme hier. Tout a de l'inertie. Et si nous travaillons sur un problème imaginaire depuis 5 ans, nous y travaillerons également demain.
«Il est difficile de faire comprendre quelque chose à une personne si elle reçoit son salaire pour ne pas le comprendre.» - Upton Sinclair
Et tout le monde continue de travailler sur des tâches fictives, car s'ils s'arrêtent un instant et regardent les vraies, il deviendra clair que tout leur système est en panne. Soudainement, il se peut que Vasya, assis dans ce coin, surveille l'état de la batterie de serveurs interne depuis 10 ans, la migration de laquelle vers AWS s'est déroulée avec succès il y a 5 ans. Soudain, il s'avère que tout le travail de Masha consiste à envoyer les rapports de Dasha à quelqu'un. Une telle prise de conscience est très difficile et les gens essaient inconsciemment d'éviter les situations dans lesquelles ils peuvent être accidentellement créés.
Et nous continuons à résoudre des problèmes imaginaires.