A partir de demain, nous commençons à vivre d'une nouvelle manière. Nous aurons Scrum et il y aura du bonheur. Démocratie complète: pas de patron, l'équipe décide quoi faire, la bureaucratie est annulée, l'essentiel est de faire du bien au client.
Un entraîneur est venu et nous a enseigné les bases. Il a parlé du succès imminent, de l'efficacité et de l'orientation client, de la flexibilité et de l'importance sans précédent de l'implication d'un client dans le processus de développement, et des vaisseaux spatiaux labourant le Théâtre du Bolchoï.
Et bien. Attendez et voyez.
Nous commençons un nouveau projet. Eh bien, Dieu merci!
Et puis j'ai déjà couvert de mousse de m'asseoir au-dessus du code Legacy. Ma force n'est plus, je ne peux pas faire face à ce grand monstre de pâtes. J'ai en quelque sorte essayé de déplacer le bouton dans le formulaire de connexion, j'ai donc reçu des erreurs du module de messagerie. Pensez à l'endroit où se trouve la connexion ...
Ils nous ont présenté un nouvel employé, nous aurons un Product Owner ou, en russe, un représentant client. Je m'appelle Rita. Femme charmante. Aime parler.
Posez-lui une question simple, alors elle commence un discours pendant une demi-heure. Vous la regardez et pensez: "Euh, vous ne comprenez rien du tout!"
Cinq minutes plus tard, vous commencez à douter: "Non, c'est comme si on disait."
À la fin, vous vous rendez compte que vous n'avez pas reçu de réponse à votre question. Alors tu pars.
L'essentiel est de l'interrompre, il n'y a aucun moyen. En essayant de caler et de diriger le flux verbal dans la bonne direction, mais là où elle se sait coulée, elle raconte à nouveau les navires et le théâtre du Bolchoï.
Nous avions déjà peur de lui poser des questions, même simples. Vous pouvez obtenir une réponse, mais vous pouvez vous noyer dans l'océan verbal.
Oui, la bureaucratie est en effet devenue moins. Parce que tout le monde a marqué sur la documentation en général. Désormais, les informations sont transmises principalement par le bouche à oreille. Bien sûr, je comprends tout, nous sommes très agiles, mais pas dans la même mesure ...
Étant donné la tâche: développer dans la passerelle la capacité pour le client de recevoir des données pour afficher le graphique. Vous devez aller au service, obtenir les données brutes, les recompter et les donner au client. Il n'y a aucune spécification sur quoi et comment compter - personne ne sait. Il n'y a que le nom du graphique. Eh bien, comment dois-je faire cela, je me demande?
D'accord, j'ai cherché quelque chose dans nos anciens projets pour quelque chose de similaire, j'ai créé un modèle. Il n'y a aucune certitude que c'est ce qui est nécessaire, non. Étrange, mais personne ne s'en soucie vraiment. L'essentiel est que nous ayons introduit avec succès de nouvelles fonctionnalités lors d'un rallye de démonstration.
Je viens travailler aujourd'hui, là-bas, des testeuses ont entouré notre Scrum master Kolya, et elles demandent de leur expliquer comment fonctionne la nouvelle fonctionnalité. Kolya regarde le moniteur avec des yeux étonnés et marmonne quelque chose sur les modèles et sur l'évolution des exigences.
Vous pouvez comprendre Kolya: vous avez changé quelque chose il y a un mois, et il est difficile de se souvenir de quoi exactement, il n'y a pas de documentation. Mais les filles ne sont pas du sucre: on leur a demandé de tester quelque chose, je ne sais pas quoi.
Je les ai rencontrés dans le couloir une demi-heure plus tard: Kolya marchait, les filles le suivaient et tout le monde gloussait: "Nouveau modèle ... ancien modèle ... exigences des clients ...".
Les pauvres ...
Vous avez une demande de tirage pour un examen. Erreur lors de l'exportation du graphique: les proportions de la hauteur et de la largeur sont différentes de l'original. C'est étrange, car j'avais résolu ce problème une fois et pris soin de toutes les proportions ... Le problème a été résolu de manière originale: un collègue a simplement multiplié la hauteur par 1,25.
Je lui demande:
- Que signifie ce coefficient?
"Et ça," dit-il, "je l'ai ramassé." Maintenant, tout ira bien.
Quelle heure! Il a ramassé ... Et qu'arrivera-t-il avec l'exportation d'autres cartes? Ils ont commencé à comprendre, il s'est avéré que vous avez juste besoin de modifier légèrement la séquence des appels. Dans certains cas très rares, vos paramètres de canevas sont utilisés et vous devez recalculer les proportions après cela.
On a l'impression que parfois il est important que les gens rendent compte de leur travail par tous les moyens, et le résultat final ne les dérange pas vraiment ...
Aujourd'hui, Rita a déclaré qu'elle avait décidé d'utiliser le défilement infini lors de l'affichage d'une liste de documents. J'ai essayé de la convaincre que la situation du service REST est en constante évolution: certains utilisateurs ajoutent des documents, d'autres suppriment. En conséquence, soit des éléments supplémentaires apparaissent dans le formulaire, soit ils disparaissent, il est donc préférable d'utiliser la bonne vieillesse. Pour lequel on m'a dit qu'une telle situation est rare et que le défilement sans fin est à la mode et sexy, les utilisateurs seront heureux.
Etes-vous satisfait? Hmm ... Je serais contrarié si je trouvais que la liste ne correspond pas à l'état actuel ...
Je ne comprends pas comment il est possible de construire un bâtiment à partir de merde et de bâtons, sans fondation, en commençant en même temps sous quatre angles simultanément. Parfois, je pense que si les avions, les bateaux à vapeur et les gratte-ciel étaient conçus de la même manière que les logiciels modernes, les avions tombaient immédiatement, les navires étaient renversés et nos villes seraient en ruines. Il est clair que notre prix d'erreur est beaucoup plus bas. Au final, nous ne créons pas de logiciels médicaux ou spatiaux. Mais notre logiciel est compliqué, il utilise de nombreux microservices. Il faut faire attention à l'étude préliminaire des détails!
C'est bien que nous ne construisions pas d'avions ...
Il a regardé dans le département voisin et a senti du seuil que quelque chose n'allait pas. Tout le monde est assis, frappant furieusement sur les claviers, et dans l'air il y a une sorte de malheur général.
Soudain, leur maître de mêlée Vitya saute et comment crier à quelqu'un:
- Qu'est-ce que tu m'écris tous! Dites-le oralement!
Et puis ils ont percé. Tout à coup est devenu étourdi. Oralement. Le bruit est devenu extraordinaire.
Je restai debout une minute, toussa, tout le monde se tut et me fixa. Je me suis soudain sentie mal à l'aise.
Victor dit:
- Vous avez changé d'autorisation dans le service?
"Oui", je réponds, "changé." Désormais, les utilisateurs sans droits ne peuvent pas lire la ressource. Il est nécessaire d'utiliser une manière différente.
- Vous avez donc changé, - dit-il, - et maintenant l'application a cessé de fonctionner pour nous.
Il est resté silencieux pendant un moment et a ajouté:
- Vous avez tout fait correctement, c'est notre biseau. Mais nous, vous savez, devons déployer la version au bout de trois heures, et nous ne pouvons pas corriger l'erreur si rapidement.
Je voulais leur dire: «Bon sang, tu n'as jamais passé les tests, car la semaine est déjà passée!», Mais regarda leurs visages, se retourna et alla faire un rollback dans le service.
Le chef nous a réunis aujourd'hui et dit:
- Nous devons avoir une épopée. Nous voulons introduire l'apprentissage automatique pour personnaliser les résultats de la recherche.
Les gens, bien sûr, sont intéressés par ce que l'on veut dire et s'il existe une description du problème.
- Il n'y a pas encore de description complète, je vais vous jeter des liens vers ce qui est. Pensez pour l'instant, - réponses. Et à gauche.
Puis j'ai regardé la page par son lien: en-tête et deux paragraphes. Et comment pensez-vous que vous devriez commander, si ce n'est pas clair à quoi penser?
Que leur arrive-t-il, car il y avait du personnel technique, ils sont passés de simples développeurs, et maintenant c'est comme s'ils étaient dégénérés en clients. J'ai entendu quelque part que l'intelligence artificielle est à la mode et cool, et commençons une épopée. Ni tâche à concrétiser, ni spécification exacte à écrire, tout n'est que matière haute et vaisseaux spatiaux avec des théâtres ...
Je rencontre Vitya aujourd'hui dans le couloir et demande:
"Eh bien, avez-vous trouvé une erreur?" Un mois s'est écoulé. Il faudrait rétablir l'autorisation dans le service, sinon nous vivons avec un trou.
Vitya détourne le regard et dit:
- Non, pas encore trouvé. Il n'y a pas assez de temps du tout ...
Et bien voilà. Pendant un mois, les gens ne peuvent pas trouver un endroit où le mauvais point final est utilisé. Apparemment, ils ont déjà abandonné cela et sont engagés dans les affaires courantes. C'est étrange, car le programme utilise en fait des données incorrectes ...
Oui, ici notre nouvelle passerelle est devenue une boule de pâtes serrée, et il est déjà impossible de trouver les extrémités. Rapidement, nous avons réussi!
J'essaie de convaincre mes collègues de parler à mes supérieurs de la situation actuelle. De mon point de vue, le projet est dans un état déplorable: différentes équipes, résolvant leurs tâches, faisant des montages qui augmentent le chaos, l'entropie grandit. À chaque fois, résoudre des problèmes devient de plus en plus compliqué.
Les gars sont d'accord avec moi, mais mes initiatives sont cool. Et ils peuvent être compris: tout le monde a des tâches en cours qui doivent être résolues pendant le sprint. Ce n'est pas à philosopher, il faut faire les choses ...
J'avoue: j'ai inventé ce journal. Tous les personnages sont fictifs, les coïncidences sont aléatoires. Ce n'est qu'une blague.
Il arrive parfois que la direction perçoit Agile quelque peu vulgaire: il suffit de décrire légèrement la tâche, et une bonne équipe traitera seule tous les problèmes architecturaux et conceptuels. Souvent, ils oublient la nécessité d'une documentation approfondie, bien que l'utilisation d'Agile ne signifie pas du tout un rejet de la documentation.
Cependant, je ne voulais pas parler d'Agile ou de technologies de développement. Je veux spéculer sur la qualité du logiciel que nous créons et sur la façon dont les mauvaises décisions peuvent détruire ce logiciel.
Conflit d'intérêts
Vous êtes développeur. Le projet ou une partie du projet sur lequel vous travaillez est votre enfant préféré. Vous le créez et le nourrissez, vous voulez que vous ayez une création parfaite. Pour que vos collègues et utilisateurs puissent dire: "Oui, c'est cool!".
Mais vous travaillez pour l'entreprise qui vous a embauché. Les entreprises ne sont pas intéressées par vos ambitions. Le principal objectif d'une entreprise est le profit, et à juste titre. Vous êtes ici en même temps avec l'entreprise, car vous souhaitez que le plus de personnes possible utilisent votre projet?
Mais pour une raison ou une autre, une entreprise peut prendre des décisions qui violent l'harmonie de votre projet. Disons que vous devez resserrer quelque chose très rapidement, sinon le client partira. Il n'y a pas de temps pour résoudre correctement le problème.
Que faire?
Très probablement, vous devrez vous casser, en espérant que les béquilles actuelles pourront être retirées plus tard ...
Cependant, tout n'est pas si triste. À long terme, les entreprises sont votre allié dans la lutte pour la qualité, à moins, bien sûr, qu'il ne soit un ennemi de lui-même.
Cependant, j'ai dû trouver une telle approche que l'élaboration minutieuse des détails et de l'analyse peut parfois être négligée, car la satisfaction rapide et bon marché des clients est la plus importante. Le succès est-il possible dans ce cas?
Le succès est-il possible?
Le paradoxe est que de tels produits peuvent très bien réussir sur le plan commercial, du moins au premier stade. Les clients, bien sûr, sont ennuyés par de nombreuses lacunes et incohérences dans le système, mais, en général, le produit résout leurs problèmes.
Les clients sont satisfaits du niveau d'accompagnement: ils sont à l'écoute de leurs besoins et tentent de répondre rapidement aux nouveaux besoins. Certes, certains d'entre eux au fil du temps remarquent que le système devient de plus en plus incohérent et imprévisible dans le comportement, l'interface devient plus compliquée, il devient de plus en plus difficile de comprendre ce qui se passe à l'intérieur, comment résoudre correctement un problème particulier, il y a des problèmes de temps de réponse, etc. Mais cela se produit progressivement et au début imperceptiblement.
Personne ne soupçonne que le projet est condamné. Bientôt, il s'effondrera inévitablement de la sévérité de toutes les extensions qui lui sont attachées à la hâte.
Dans quelle mesure l'harmonie interne du produit est-elle liée à ses qualités de consommateur? Il arrive souvent que les développeurs soient dans un état d'horreur permanent face à l'état interne du système, alors que les clients sont apparemment satisfaits. Mais un vilain avion peut-il être bon? Et l'harmonie intérieure d'un produit ne doit-elle pas se refléter dans ses qualités de consommateur?
Ce n'est un secret pour personne que des intérieurs souvent obscènes sont cachés derrière une belle façade, et cela s'applique non seulement aux petites entreprises, mais aussi aux géants de l'industrie du logiciel. Voici juste un
exemple .
Les entreprises monstres peuvent se permettre d'embaucher des milliers de programmeurs pour soutenir le gigantesque plat de spaghetti que leur produit est devenu au fil des années et des décennies, mais pour les petites entreprises, c'est une façon de tuer. Et d'ailleurs, même pour les monstres, la faible qualité du code ne passe pas sans trace et se traduit par une augmentation exponentielle du temps de développement et de mise en œuvre pour chaque nouvelle fonctionnalité, une augmentation du coût du processus et une baisse constante de la qualité du support.
Quoi de plus important: la qualité des produits ou les compétences en vente?
Un produit de qualité, hélas, n'est pas une garantie de succès.
J'ai eu un cas concret où un programme hautement spécialisé qui fonctionnait bien en Russie devait être promu sur le marché européen. Le programme utilisait son propre format de données, et la conversion des données clients disponibles à l'époque n'était pas particulièrement difficile. Si nous parvenions à conclure des contrats, nous deviendrions monopolistes en Europe pendant un certain temps. Il semblerait que tout soit de notre côté: la demande sur le marché est grande, jusqu'à présent, personne ne peut offrir quelque chose de complet et de vraiment fonctionnel, sauf pour nous, le programme travaille déjà sur des centaines d'emplois en Russie, les clients russes réagissent positivement au produit.
Et donc, avons-nous réussi? Hélas, non. L'appel d'offres a été remporté par une entreprise européenne qui a déjà travaillé avec des clients dans d'autres domaines. À ce moment-là, ils n'étaient qu'au début du chemin que nous avions déjà parcouru, mais ont réussi à nous battre. Malheureusement, nous n'avions pas de bons spécialistes de la promotion et des ventes, et nous n'avons pas pu convaincre les gens de faire un choix en faveur de notre entreprise. Puis, après un certain temps, il a été très décevant de voir nos réalisations dans l'organisation de l'interface utilisateur dans leur nouveau produit ...
Mauvaises décisions
Un produit de haute qualité est un objectif stratégique, et une entreprise intelligente sera toujours du côté du développeur, en quête d'excellence. Mais maintenir l'harmonie interne du produit n'est pas facile. Avec le développement du produit, de nouvelles exigences nous viennent qui peuvent détruire l'harmonie originale des concepts. Les décisions qui sont prises dans ce cas jouent un rôle décisif dans le sort futur du produit.
Personne n'est à l'abri de mauvaises décisions. Si une décision stratégique est prise au stade de la conception, et au fil du temps, il devient clair qu'elle était erronée, cela conduit à la mort du projet. Mais souvent, de mauvaises décisions sont prises pendant le développement lorsque de nouvelles fonctionnalités sont ajoutées. Tout dépend, d'une part, de la globalité des décisions prises, c'est-à-dire du degré de leur influence sur le système dans son ensemble, et d'autre part, du nombre de mauvaises décisions. Lorsque le nombre de mauvaises décisions et le degré de leur influence dépassent un certain seuil, une longue et douloureuse agonie commence.
Je voudrais partager avec vous quelques exemples de mauvaises décisions tirées de ma propre expérience. Bien entendu, ces exemples ne prétendent en aucun cas à l'étendue académique et à la systématisation.
Règles laxistes
Parfois, il nous semble que pour la commodité de l'utilisateur, les règles doivent être flexibles.
Par exemple, votre système fonctionne avec différents types de hiérarchies créées par les utilisateurs. Vous décidez que pour l'un des types, la clé de nœud est unique uniquement au niveau et non dans toute la hiérarchie. Cela semble pratique car l'utilisateur charge la hiérarchie en niveaux.
Conséquences: maintenant, les programmeurs de partout dans le code devront se charger de préparer la clé composite, ce qui entraînera souvent des erreurs. Si les utilisateurs ont accès aux sites par clé, ce sera également un casse-tête pour eux.
Il pourrait être utile d'envisager des règles plus strictes et d'exiger l'unicité d'une clé dans toute la hiérarchie. Cela profitera aux développeurs et aux utilisateurs.
Violation des règles
Vous avez une hiérarchie complexe d'objets créés par l'utilisateur. Chaque objet contient la propriété Name, qui est la clé, et le titre avec du texte arbitraire. Il existe un ensemble de règles formelles pour un nom, par exemple, le nom ne doit pas contenir d'espaces ni de caractères spéciaux. À un certain point, la tâche se pose de générer automatiquement des objets d'un type à partir d'un autre. Le nom doit être basé sur le titre et être reconnaissable. Vous décidez d'enfreindre les règles et d'utiliser Title comme nom: il vous semble que ce sera plus pratique pour les utilisateurs.
Préparez-vous aux problèmes de votre système qui se produiront dans des endroits inattendus.
Paramètres de complexité
Vous entrez des paramètres qui ne sont valables que sous certaines conditions. Lorsque certaines installations fonctionnent à condition que d'autres soient incluses, il s'agit d'une situation assez courante. Mais si vous avez une hiérarchie complexe d'attitudes, dont certaines fonctionnent lorsque d'autres sont activées, et celles-ci, à leur tour, sont conditionnelles, c'est le chemin du chaos. L'expérience montre que dans ce cas, personne n'est prêt à prédire comment le changement dans une installation particulière affectera le comportement: ni les utilisateurs, ni les développeurs. Le système de paramètres doit être clair, aussi évident que possible et soigneusement pensé. Vous devez vous efforcer de réduire les dépendances de certains paramètres sur d'autres.
Manque d'analyse du problème
Votre système permet à l'utilisateur de créer des rapports basés sur DSL. Il a été décidé dans un premier temps que DSL contenait toutes les propriétés du rapport. Après un certain temps, l'un des clients vous demande d'ajouter la possibilité de stocker une partie des installations séparément - cela est nécessaire pour résoudre certains problèmes internes du client. Lancer une tâche dans «Ajouter des paramètres externes» de Jira sans d'abord analyser le problème est une erreur. Tout d'abord, il est nécessaire de répondre à la question: pourquoi était-elle nécessaire? Il peut s'avérer que le client souhaite simplement masquer une partie des paramètres pour certains utilisateurs. Peut-être devriez-vous envisager de diviser DSL en parties avec l'autorisation de ces parties? La décision n'est pas si rapide, mais peut-être stratégiquement correcte.
Décisions politiques
Parfois, les décisions sont prises pour des raisons d'organisation. Par exemple, certaines ressources sont stockées dans un microservice spécialement conçu à cet effet. Plusieurs types de ressources similaires sont requis. Une équipe est impliquée dans le service et de nouveaux types de ressources sont nécessaires pour d'autres. Afin de partager la responsabilité, la décision est prise d'ajouter de nouveaux types non pas au service d'origine, mais aux services gérés par d'autres équipes.
Le problème est que le service a non seulement stocké des données, mais a également fourni une autorisation. Maintenant, vous devez en quelque sorte prendre soin de réutiliser le code. Mais ce n'est pas l'essentiel. L'essentiel est qu'il ne soit désormais plus évident de savoir quel service utiliser pour obtenir les données nécessaires.
La preuve interne de la construction d'un système est sacrifiée à des motifs organisationnels ou politiques.Conclusion
En tant que développeur, je veux être fier des résultats de mon travail. Pour moi, la beauté intérieure, l'élégance et l'harmonie du projet sont importantes. Mais la demande n'est pas moins importante. Je ne veux pas travailler pour le panier, je veux que le plus de personnes possible utilisent le produit et soient satisfaites. Je comprends que parfois, il faut faire les frais et gâcher un peu l'harmonie intérieure pour satisfaire les intérêts des clients individuels. Mais je suis convaincu que derrière la belle façade il ne doit y avoir aucune honte, les intérieurs laids vont tôt ou tard grimper à l'extérieur, peu importe s'il s'agit d'une confusion externe dans les concepts, ou d'un temps de réponse toujours plus long aux problèmes des clients.La beauté et l'harmonie du produit sont les plus importantes. Oui, nous sommes parfois obligés de faire des compromis dans l'intérêt des entreprises et sommes prêts à brouiller la clarté des approches dans l'intérêt d'un client particulier, surtout s'il s'agit d'un client très important, mais c'est une pente glissante.Plus d'une fois, j'ai dû observer l'extinction progressive et la mort de projets lorsque les gens n'ont pas pris la peine d'étudier attentivement les détails et ont introduit sans réfléchir de nouvelles fonctionnalités, sans se soucier des incohérences du produit et sans prêter attention à l'émergence de connexions nouvelles et inutiles entre les modules. Cela conduit toujours à la confusion, quand il devient de plus en plus difficile de corriger l'erreur la plus simple, car il n'y a aucune certitude que cette correction n'aura pas un effet inattendu sur des composants et des parties complètement étrangers du système.Je souhaite souhaiter une longue vie à vos projets!