Bonne fête du programmeur! Aimez vos développeurs

Aujourd'hui est le jour du programmeur, le 256ème jour de l'année. Et nous avons décidé d'écrire un article non pas pour nos collègues développeurs, mais pour ceux qui sont à côté d'eux et avec nous. Pour ceux qui nous amènent à la chaleur blanche, cela nous fait bouillir la cervelle, se défouler et parler nerveusement de l'essence, de l'interface et des raisons du dépassement du délai. Pour vous, chers managers, hommes d'affaires, analystes, managers sans formation informatique et autres amis de bureau.

Si vous lisez le Habr, vous devrez probablement communiquer avec les programmeurs, leur demander de terminer le frontend ou le backend du site, de modifier le code d'analyse, de suspendre le fragment de code suivant dans l'en-tête du site, d'apporter des améliorations au logiciel client, et bien plus encore. Alors comment trouver un langage commun avec le développeur, pour ne pas se disputer? Nous en savons quelque chose.


Donc, tout de suite sur la liste.

Indiquez clairement vos besoins. Toujours: peu importe que vous demandiez de faire une petite sélection dans la base de données ou de préparer un projet logiciel sérieux pour le client. Il n'y a pas de description des tâches dans le formulaire «Faites-moi une carte d'événement en tant que profil VKontakte» (il y a beaucoup de programmeurs travaillant sur VKontakte, embauchez le même montant et faites-le), «Eh bien, vous faites tout, et je choisirai» (faire plusieurs options pour le programme coûte cher, vous Le PDG est d'accord?), «Faisons une telle balle» (c'est un ruban et des bibliothèques spéciales sont nécessaires pour sa mise en œuvre). Tout d'abord, vous devez comprendre ce que vous voulez recevoir, et c'est ce que le programmeur doit diffuser. Formulez les exigences en russe, sans le bureau et les déclarations pseudo-techniques - et oui, de préférence par écrit.

En parlant d'écriture. Il s'agit de la plus grande invention de l'histoire de l'humanité, aujourd'hui optimisée par ordinateur. N'hésitez pas à utiliser du papier dans une conversation avec le développeur:

• faire des croquis et des prototypes de ce que vous voulez voir (si c'est un programme ou une interface séparée) - aujourd'hui, il existe de nombreux outils pour cela
  
• utiliser des cartes mentales pour planifier le travail et créer un plan de projet
  
• décrire la fonctionnalité souhaitée aussi simple et détaillée que possible
  
• constituent le mandat (TOR).
  

Si cela vous semble une science compliquée, recherchez ce qu'un analyste de systèmes fait et ce qu'il utilise dans son travail - beaucoup peut être mis en service.

Vous n'avez pas besoin d'utiliser des diagrammes UML, des organigrammes et des pseudocodes si vous ne les possédez pas. Sur le chemin, il y avait plus d'un manager qui était fasciné par les diagrammes UML et y dessinait tout ce dont il avait besoin: du plan de réunion à la description de la campagne marketing. En effet, l'outil semble logique et pratique, cependant - une surprise - UML a été créé pour concevoir l'architecture logicielle, et chaque désignation n'est pas seulement une flèche ou un cercle, mais un composant très significatif. De plus, votre programmeur peut ne pas connaître UML et pour lui ce seront des blocs complètement dénués de sens.

La même histoire avec des diagrammes de blocs dans lesquels différentes formes de blocs existent non pas pour la beauté, mais avec un pseudo-code. Pas besoin d'écrire dans le style: " SI mois = avril, ALORS plaque signalétique champ 1 champ 2 champ 3 ". C'est tout simplement un non-sens illisible qui ne conquiert pas le service informatique, mais au mieux rit.

Répondez aux questions à temps. Tout le monde sait que les programmeurs sont des oisifs, ils sont assis et scient leur code, ils n'atteindront jamais les managers avec une centaine de tâches. Ok Mais quand même, quand vous menez un projet, vous en êtes responsable, et vous passez la tâche au programmeur, avez la conscience de répondre aux questions à temps. Pas besoin d'éviter les appels et les chats, de marquer les e-mails comme importants et de les placer dans un dossier séparé. Le programmeur passe du temps à interagir avec vous, il peut en avoir une simple à cause d'une question sans réponse - et c'est de votre faute. Veuillez être en contact pendant les heures de travail sur les problèmes que vous avez soulevés devant d'autres développeurs. Soit dit en passant, cela s'applique également aux clients tiers.

Et pourtant - si on vous demandait de voir ce qui s'est passé, évaluez le prototype ou testez la fonctionnalité pour savoir si elle répond à vos besoins, ne vous adressez pas à dix employés voisins et ne le faites pas ensemble. Vous augmentez donc considérablement le temps jusqu'à l'achèvement de la version finale.



Rubrique "Leurs manières". Comparez des requêtes similaires en russe et en anglais. Travail, amour, argent - tout est comme tout le monde. Mais surtout, comment voient-ils les utilisateurs?

Ne blâmez pas les développeurs pour tous les problèmes. "Le service informatique travaille sur le code depuis si longtemps", "Les informaticiens manquent d'une échéance", "Quelque chose que le programmeur a creusé dans les savoirs traditionnels depuis si longtemps" - est-ce familier? Il est facile de blâmer le problème sur une personne qui interagit avec la technologie - eh bien, quelque chose aurait pu mal se passer là aussi. Non, tenez un registre strict du temps, enregistrez le fait du transfert des tâches (vous pouvez le faire, par exemple, dans CRM ou sur le diagramme de Gantt), laissez chacun être responsable uniquement de son travail.

Autre extrême - en cas d'insatisfaction des clients, saupoudrez de cendres sur votre tête et criez: «Que faites-vous! Vous cherchez des critiques et traduisez sur vous! Nous perdons de l'argent et de la réputation! D'urgence! " La panique est facilement captée par les collègues et la direction, les nerfs du programmeur sont à la limite. Mais en fait, il s'avère que le port du client est tombé ou que la vitesse de connexion a chuté. Apprenez à ne pas blâmer mais à demander: «Vasya, Volga LLC a rencontré un problème: il n'y a pas de connexion à la base de données. Tu ne peux pas me dire ce qui pourrait être, où creuser? " Sentez-vous la différence?

N'insérez pas des idées du monde entier dans un projet de travail. Google a ajouté des filtres à la recherche, Yandex a activé Alice, Habr a lancé une nouvelle version mobile, Salesforce a activé l'intelligence artificielle, RegionSoft a publié CRM v.7 et maintenant vous vous précipitez le long du couloir afin d'offrir d'introduire ces technologies dans le projet de votre entreprise, car c'est ce qu'ils font Géants de l'informatique. Cependant, tout changement doit être introduit en termes de faisabilité, de pertinence et de retour sur investissement. Et si les améliorations ne profitent pas à l'utilisateur final et ne génèrent pas de profit, leur mise en œuvre deviendra une charge supplémentaire pour le développeur. Préparez une justification, des calculs, calculez le coût de l'introduction des fonctionnalités et seulement après cela, prenez la décision de commencer à discuter du problème.

N'évaluez pas la complexité d'un programmeur si vous n'êtes pas un chef d'équipe. "Nous avons besoin d'un module pour calculer le volume d'une boîte pour l'envoi d'un colis, voici une demi-journée de travail, asseyons-nous!" - Le marketing optimiste Masha appelle et se précipite pour boire du thé avant la troisième réunion. En même temps, Masha elle-même ne sait pas d'où elle tire un tel rythme. Le programmeur a des tâches de travail, des problèmes actuels, un traqueur de bogues le surplombe et un backlog clignote sur le côté, c'est donc entre eux qu'il cherchera du temps pour résoudre le problème. Et ce n'est pas un fait que le problème résolu en 15 lignes de code peut être résolu pendant l'ensemble de ces lignes - le temps prend le choix de l'algorithme, la recherche d'une solution, la sélection des bibliothèques, le débogage du code, les autotests, etc.

Mieux encore, si vous avez un règlement d'entreprise qui prescrit la procédure de demande de fin / déchargement / placement extraordinaires, etc. Dans ce cas, tout le monde se sentira en confiance et connaîtra les délais approximatifs pour résoudre le problème. Et oui, définissez des termes réels.



N'essayez pas d'influencer la pile des technologies de développement si vous ne développez rien vous-même. La situation est banale: le responsable se rend à la prochaine conférence intergalactique sur l'informatique, écoute les rapports et son cerveau coupe soudainement qu'il y a du bruit partout autour de Go, puis on lui a présenté un Gopher en peluche. Et maintenant, il se tient devant le département informatique, caressant le gopher trouvé et parle des avantages que Go a entendus et comment l'utiliser dans notre entreprise sanglante.

La réponse est simple. Les programmeurs sont très curieux et apprennent les langages de programmation, les SGBD, les nouveaux systèmes d'exploitation, les bibliothèques et les frameworks bien avant qu'un autre participant à la conférence n'en rédige un rapport. En même temps, ils ne sont pas seulement curieux, mais cherchent à voir si telle ou telle technologie peut s'intégrer pour faciliter le travail et renforcer la confiance dans le produit (car les programmeurs sont également extrêmement paresseux dans le bon sens du terme). Par conséquent, c'est à eux de décider quoi faire glisser sur la pile de développement et quoi laisser reposer jusqu'à des temps meilleurs et de nouvelles tâches. Et il est peu probable que vous les dépassiez dans ce domaine.

Faites attention à l'écriture , elle ne transmet pas d'intonation (cependant, cela s'applique à tous les collègues et aux autres en général). Si vous écrivez «Et faites-moi un déchargement dans une heure)))))))))))))))))» ou «Je ferais mieux de le mettre en œuvre, il me semble qu'il ralentit))))))))))))))) " , Les crochets ne vous sauveront pas - le message principal sera lu. Décrivez vos questions de travail de façon claire et sans émotion. Si vous avez aimé le travail, vous pouvez donner une barre de chocolat :-)



Après la demande «pourquoi les programmeurs russes sont-ils si bons», ils sont partis pour être fiers

N'imposez pas vos méthodes de communication. Aujourd'hui, chacun sur un PC et un téléphone portable en état de marche dispose d'une douzaine d'outils de communication: Télégramme, Skype, SMS, téléphone, Viber, mail, Slack, Jira ... Et chacun d'eux a son propre cercle de tâches et d'abonnés. Par conséquent, si le programmeur demande que le week-end n'écrive que dans le panier, définisse des tâches uniquement dans Jira et appelle uniquement sur Skype, il a une bonne raison à cela: il sait avec certitude qu'il n'oubliera pas de faire le travail associé à ces contacts. Mais votre SMS «Commencez lundi le rapport sur les paiements du premier semestre» sera perdu dans les fils de discussion de la campagne du dimanche. Par conséquent, il est préférable d'écrire à ce sujet dans les programmes de travail et de ne pas vous considérer comme exceptionnel et le plus efficace dans la communication et la définition des tâches. Croyez-moi, ce n'est pas difficile.

Si vous travaillez avec des programmeurs et créez des programmes pour des clients externes, fournissez une version. Autrement dit, au moment où le programme est prêt et lancé dans la production, vous devez avoir tout le matériel promotionnel, les visuels, les présentations, les accords, etc. C'est le respect du travail du développeur - parce que dans une telle entreprise, il remplit la fonction d'une unité de production. Si vous avez personnalisé les programmeurs, ils ont tout fait à temps et la sortie est reportée de trois mois, c'est un excellent démotivateur et dévalue l'équipe en tant que telle. Il y a rarement un programmeur qui ne se soucie pas de ce qui arrivera à son programme à l'avenir et ne s'intéresse pas à la façon dont il se comporte sur le marché et avec les clients.





Domestic Yandex a une vision complètement différente des choses: même Ada Lovelace est classée parmi les programmeurs 1C, et dans les meilleurs postes vacants se trouvent Assembler et Delphi (le cas échéant, nous avons recherché dans un navigateur anonyme). Mais l'essentiel est qu'il y a 256 jours - et c'est aujourd'hui :-)

Apprenez des programmeurs et apprenez la terminologie. Une personne qui sait programmer, pense systématiquement et logiquement, sait prioriser, voit l'essence des choses et connaît parfaitement le sujet (non, eh bien, en l'honneur des vacances, vous pouvez exagérer un peu!). Il a beaucoup à apprendre - d'autant plus que vous travaillez dans le domaine informatique, vous avez besoin d'une bonne maîtrise de l'appareil conceptuel et du vocabulaire professionnel. Communiquez au travail, clarifiez les questions controversées, demandez, souvenez-vous des termes et de leurs définitions - cela n'interférera certainement pas avec votre carrière. Mais la compréhension avec un programmeur sera certainement meilleure.

Au moins, vous n'écrirez pas sur le portail d'entreprise «Happy Programmer's Day», mais vous pouvez écrire quelque chose comme ceci:

«Les gars! Bonne fête du programmeur! C'est formidable qu'il y ait vous qui commettez le code à temps, refactorisez et rendez notre logiciel encore plus rapide et plus intuitif, collectez les builds à temps et exécutez-les en production. Je vous souhaite des commits réussis, des bibliothèques fiables, des cadres pratiques et nous, des utilisateurs adéquats. Vous faites du monde du présent un petit avenir. Et nous vous aimons! "

Eh bien, avez-vous appris notre petite leçon? Maintenant, félicitations à vos développeurs.

Bonnes vacances, amis! Team RegionSoft Developer Studio , développeurs de puissants CRM et autres logiciels pour les entreprises, qui connaissent beaucoup la communication entre les utilisateurs et les programmeurs

---

Notre chaîne Telegram

Nous saluons la principale chaîne de Nizhny Novgorod à propos des événements informatiques et de leur site Web it52.info . Allez aux événements, soyez dans le sujet.