↔️ 👩🏽‍🏭 👟 Comment éviter l'indignation de la programmation? Conseils d'intégration 🖐🏼 🤣 🙅🏽

Dans un article précédent sur les problèmes d'introduction de l'ERP dans les entreprises industrielles, à titre d'étude de cas, un des points a été mis en évidence «l'anarchie programmatique».

Nous avons un client dont les employés nous envoient maintenant des exigences douteuses, spécifient s'il s'agit d'une violation de la loi programmatique. Et certains ne le précisent pas, mais le créent.

Le sujet est pertinent et j'ai décidé d'écrire un article séparé à ce sujet.

Qu'Est-ce que c'est?

Quel genre de peintures votre imagination peint-elle lorsque vous entendez l'expression «non-respect programmatique»?

Un homme barbu avec un regard intelligent pensif frappe le chef comptable en larmes avec un volume de Knut, en disant: "Kopek, vous dites que vous n'êtes pas d'accord sur la facture? Le destinataire ne rentre pas dans la cellule? Maintenant, nous allons le tamponner avec un livre et tout ira bien! »

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

Ce phénomène est moins coloré que vous ne pouvez l'imaginer, mais plus terrible. En fin de compte, le chef comptable peut se calmer, essuyer les larmes et envoyer à un psychologue, les maîtres peuvent être déliés d'une chaise et envoyés au travail. Mais les courbes de publication dans InventTrans et l'inefficacité en raison d'erreurs de calcul dans l'architecture de la solution et d'améliorations inutiles, le psychologue ne corrigera pas la planification sommaire.

L'anarchie programmatique est une situation où, à la suite de la programmation, dont le but était de résoudre certains problèmes d'une entreprise, d'autres problèmes, souvent plus graves, pour les entreprises sont créés.

Permettez-moi de vous donner quelques exemples:

, , . - , .
. , , «» . . , , .

Je voulais nommer l'article «Chaos du programmeur. Intégrateur qui pleure », mais s'est rendu compte que personne ne se soucie de nos larmes. Mais des conseils pour éviter de telles situations peuvent être utiles.

Je vais essayer de définir les limites de mes recommandations à l'avance - nous parlons de:

programmeurs impliqués dans la mise en œuvre ou la maintenance de systèmes ERP. Je pense qu'ils ont des exigences légèrement différentes de celles, par exemple, des développeurs d'un nouveau produit ou d'une nouvelle technologie;
les programmeurs qui travaillent avec le client. Les développeurs intégrateurs sont moins enclins à «outrage».

Quelles sont donc les causes de ce phénomène et que peut-on y faire?

Réticence ou incapacité à regarder l'essence du processus

Je vois souvent cela avec des analystes et des programmeurs novices. Ils répondent simplement à la question que le client leur a posée. Ils n'y pensent pas - pourquoi a-t-il posé des questions à ce sujet, en a-t-il vraiment besoin? Au fil du temps, cela passe, mais au début, vous devez attraper et expliquer.

"Et pouvez-vous augmenter le nombre de décimales pour ce coefficient à 4?" - "Bien sûr". Mais rien que ce coefficient soit utilisé pour indexer le paramètre, qui a une précision de 1 décimale, et les valeurs ne dépassent pas 50? Toute précision de coefficient entrera dans l'arrondi. Alors peut-être qu'il vaut mieux ne pas faire ça?

«Ajoutez un nouveau champ de ce type à la référence de la nomenclature» - «Bien. La complexité de 15 minutes. " Alors, pourquoi avez-vous besoin de ce champ dans les nomenclatures? C'est une caractéristique qui varie d'une fête à l'autre. Peut-être vaut-il mieux ajouter ce champ au répertoire des soirées?

Un développeur dans ERP ne doit pas être simplement un implémenteur des changements que les utilisateurs apportent. Il doit comprendre la logique du système et agir en tant que protecteur contre toutes les absurdités. Pour ce faire, il serait bon de comprendre les processus métier au moins au niveau du bon sens et de pouvoir poser des questions inconfortables aux utilisateurs.

Par conséquent, si l'un des utilisateurs ne vous a jamais adressé de plaintes concernant l'impudence d'un programmeur qui a refusé de mettre en œuvre sa liste de souhaits, ce développeur devrait y regarder de plus près. Peut-être qu'il fait juste ce qu'ils disent. Et cela se termine rarement par quelque chose de bien.

Manque d'endurance dans la lutte contre l'envie de tout quitter à l'ancienne

C'est le cas lorsque le désordre du programmeur n'est pas créé par les développeurs, mais avec leur connivence.

Tout produit sérieux comporte non seulement un ensemble de certaines fonctions, mais aussi une idéologie, des meilleures pratiques. Et les gens veulent travailler à l'ancienne. Et ils ont fait pression sur le programmeur pour lui donner cette opportunité. Et s'il ne pouvait pas prouver que cela ne devait pas être fait, alors tout pourrait malheureusement se terminer.

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

Que peut-on faire avec ça? Pour commencer, ne subordonnez pas le programmeur aux services économiques. Il doit travailler dans une autre unité et avoir une certaine indépendance par rapport à la gestion des services dont le travail est automatisé.

Ce serait bien d'ajouter un maillon à cette chaîne: toute amélioration sérieuse devrait être approuvée non seulement par l'entrepreneur, mais aussi par quelqu'un qui comprend les affaires de l'entreprise dans son ensemble et qui a le pouvoir. Une telle personne peut certainement dire: "Non".

L'habitude de résoudre tous les problèmes par programmation

L'amour de l'automatisation mène au progrès, mais nuit parfois. J'ai vu comment, au lieu de demander aux gens d'entrer manuellement des données dans le système, cette entrée a été automatisée. Automatisé, en oubliant certains détails ou fonctionnalités qui auraient nécessairement été remarqués, discutés et très probablement corrigés avec une saisie manuelle. Et donc - tout le monde est sûr qu'il n'y a pas d'erreurs, mais après un certain temps, les conséquences se manifestent en masse, ce qui est déjà beaucoup plus difficile à corriger que la cause première.

, , . , , , . . , . , , . : .

Par conséquent, lorsqu'un programmeur est invité à écrire un script pour corriger 200 erreurs survenues en raison du fait que les utilisateurs ne fonctionnaient pas conformément aux instructions, il ne devrait pas se précipiter tête baissée dans le clavier. Nous devons estimer le temps qu'il faut pour corriger une erreur manuellement, et si le temps pour corriger manuellement toutes les erreurs ne dépasse pas la complexité de l'écriture d'un script d'un ordre de grandeur, amener les utilisateurs à corriger ces erreurs par eux-mêmes: il y a plus de chances qu'ils fonctionnent selon les instructions à l'avenir. Cela devrait être introduit en règle générale, accroché au mur près du programmateur afin qu'il puisse pousser tous les visiteurs dans ce morceau de papier.

De plus, pour une raison quelconque, nous pensons que si les gens sont libérés du travail de routine en raison de l'automatisation, ils feront quelque chose d'utile: ils commenceront à proposer des idées pour améliorer les processus commerciaux, optimiser les rapports et former des collègues moins expérimentés. Mais très probablement, ils auront tout simplement plus de temps pour le thé, les pauses fumeurs et Internet au travail. Alors ça vaut le coup?

Confiance en soi

Il existe une fonctionnalité qui ne doit pas être modifiée. Dans Axapt, il s'agit, par exemple, de la planification générale. Dans ma mémoire, nous ne l'avons touché que 2 fois. Et à chaque fois, il n'était pas intégré dans le code, mais une sorte de «tache» - des fonctions qui étaient exécutées avant ou après la planification consolidée. Et même ainsi, je me souviens de ces améliorations avec envie.

Il y a des endroits moins évidents où il ne faut pas grimper. Et un excellent moyen de distinguer un programmeur expérimenté d'un débutant est de proposer d'affiner une telle fonctionnalité: une expérimentée sera surprise et refusera, peut conseiller d'optimiser le processus métier, et le débutant dira: "Allez."

Ici, une chose peut être conseillée: embaucher des personnes expérimentées qui, déjà auprès d'autres clients ou sur d'autres projets, ont eu toutes les bosses qui, en principe, pouvaient être comblées.

Absence de réglementation de développement

Lorsque nous prenons un projet en charge, l'un des premiers documents que nous demandons au client est la réglementation de développement qui décrit l'environnement de développement, les règles de dénomination des objets, les interdictions et les restrictions. Le plus étrange, c'est que parfois cela n'arrive pas. Et c'est un signe certain - il y aura une corbeille dans le code: à partir du manque classique de commentaires et se terminant par des situations où des valeurs spécifiques des répertoires pour différentes branches de l'algorithme ont été écrites directement dans le texte. Et la corbeille dans le code est la première étape des problèmes avec l'entreprise.

Par conséquent, ne parlez pas du fait que «la programmation est un art. Ce n'est pas réglementé "," mais qu'en est-il de l'agilité? " et c'est tout. Si vous développez, alors il devrait y avoir un règlement. Et ce n'est pas 3 points:

le développement est effectué sur l'application dev;
le test est effectué sur l'application de test;
Le code doit avoir des commentaires.

Cela devrait être un document à part entière de dix pages avec des sections:

Conditions requises pour les applications de développement.
Conditions requises pour rédiger l'énoncé du problème.
Conditions requises pour écrire du code.
Exigences de test.
Exigences de migration entre les applications.

En règle générale, l'intégralité du hardcode est effectué selon le principe «Faisons-le vite, puis faisons-le normalement». Cela se fait rapidement, puis on l'oublie ... Et quand il y a un document signé qui dit que cela ne peut pas être fait, vous pouvez toujours le fouiller et dire à l'utilisateur: "Cela ne fonctionnera pas rapidement, il m'est interdit de travailler comme ça. Désolé, Alevtina Svetozarovna, je serais ravi de commenter tous les chèques directement sur le travailleur, mais ils me licencieront. "

Solitude et manque de contrôle

Un programmeur solitaire est mauvais. Il devrait toujours y avoir quelqu'un qui dit: "Eh bien, qu'avez-vous fait, un imbécile?" - Sinon, le développeur se détend, oublie les règles, oublie la responsabilité. C'est là que le hardcode commence, les décisions architecturales douteuses, les erreurs affectant l'entreprise.

D'une manière intelligente, cela s'appelle une «révision de code» et c'est quelque chose qui devrait toujours aller de pair avec les réglementations de développement. Après chaque révision, avant de la tester, il convient de vérifier la conformité du code avec les réglementations de développement et les meilleures pratiques. Un examen du code permettra:

contrôler la qualité du développement;
former des programmeurs moins expérimentés.

Par conséquent, les développeurs doivent être au moins 3 pièces (deux seront toujours d'accord pour dire que vous ne pouvez rien faire, un tiers au système réduira considérablement le risque de collusion). Et ils doivent travailler selon des réglementations internes, dont l'un des points clés est la révision obligatoire du code.

Conclusion

Ainsi, afin de réduire les probabilités de "non-conformité programmatique", il est nécessaire de former votre propre service de développement interne selon les règles suivantes:

Ce doit être une équipe d'au moins 3 personnes.
Au moins une de ces équipes devrait avoir de l'expérience dans la mise en œuvre ou la maintenance d'un système ERP, ce devrait être son n-ième projet, où n> 3.
Le département de développement devrait idéalement rapporter directement au PDG.
Les utilisateurs finaux doivent parfois se plaindre que les programmeurs refusent de mettre en œuvre certaines de leurs exigences.
Même pour un si petit département, des réglementations doivent être élaborées, dont la violation doit être sanctionnée.

Naturellement, c'est ma vision. On peut faire valoir que, pour chacun de ces points, je peux même donner des contre-exemples de mon expérience lorsque l'exigence n'était pas remplie, mais tout était parfait. Mais ces recommandations peuvent être utilisées comme point de départ pour la formation de leurs principes de lutte contre l'illégalité programmatique.

Comment éviter l'indignation de la programmation? Conseils d'intégration