19 mauvais conseils au responsable informatique de la banque ... ou une nappe chère

Aujourd'hui, mon manager a décidé de quitter la banque où je travaille, le transformant d'un employeur réputé en un endroit où tout le monde se disperse en à peine un an. Cet article est à la fois une lettre d'adieu à lui et une instruction aux autres «comment ne pas le faire».





  1. Rendre les processus de développement bureaucratiques afin qu'ils ne soient compréhensibles que par ceux qui les ont développés. En général, le temps qu'un programmeur passe sur les approbations, la correspondance, tente d'expliquer quelque chose à des personnes qui ne veulent tout simplement pas faire leur travail n'affecte en rien les résultats de son travail, car les délais pour les tâches sont en gras et toutes ces activités ne le sont pas. justification de leur violation.





  2. Lorsque vous postulez pour un emploi, mentez sur ce que le programmeur fera. Parlez de technologies ultramodernes et promettez que 70% du temps du programmeur sera consacré au développement. Il n'est pas du tout nécessaire de tenir des promesses, peu importe que vous y ayez en fait un héritage monolithique, dont une partie a été écrite au siècle dernier.





  3. Distribuez les tâches sur les technologies modernes et le développement uniquement aux programmeurs des départements voisins qui n'ont aucune idée de ce qui se passe dans votre système. Oui, vous avez bien entendu: les tâches de développement du système doivent être effectuées par des personnes peu familiarisées avec ce système. Les programmeurs de votre département ne doivent traiter que les bogues. Voltige - si vos programmeurs ratissent les écuries d'Augean pendant les heures de travail et écrivent un nouveau code le week-end. Eh bien, quoi, ils développent leurs compétences, pourquoi cela devrait-il se faire aux dépens de la banque?





  4. Lorsque vous modifiez les conditions de travail ("traduire à distance", introduire des horaires de travail stricts ou quelque chose comme ça) - ne vous inquiétez pas de prétendre que le programmeur a le droit de voter. Prétendez simplement que votre parole est suffisante pour tout changement. Si certains cadres déloyaux osent «être contre» - laissez entendre que des problèmes les attendent: «nous mettrons tous les mécontents sur un crayon». Merci de ne pas l'avoir planté. Si quelqu'un devient insolent au point de signaler directement l'incohérence juridique de vos actes, ignorez-le simplement: il semblera que vous n'avez pas daigné répondre, et il est peu probable que l'affaire soit portée devant les tribunaux.





  5. Si vous n'aimez pas un programmeur, renvoyez-le. Il est possible qu'un défaut se présente au bureau. Vous pouvez même au milieu d'une quarantaine de coronavirus.





  6. , - . , , , , . , , , - ,





  7. - : . .





  8. - " ". -? ? : , - : " - ".





  9. : - " ". " -". , ( ), .





  10. , : , , - - . .





  11. - , . , 15 , .





  12. - , . . - - . , .





  13. - . . , , .





  14. . . , .





  15. , 1 - . , , , . . - , . , . .





  16. : : , , . , , . .





  17. . ? ! , , . ? ? , : , .





  18. En savoir plus sur le temps de travail: il a été créé pour les bugs et l'analyse de cas controversés. Il est préférable de planifier les réunions d'organisation après la fin de la journée de travail, car sinon nous n'aurons pas le temps de publier la version. Que toutes les questions personnelles soient décidées en dehors des heures de travail. Vous savez mieux quand les heures de travail sont terminées.





  19. La loi au travail est votre parole. S'il y a d'autres morceaux de papier qui revendiquent ce nom fier (jours non ouvrables, code du travail, mesures de quarantaine), n'hésitez pas à l'ignorer. S'il n'est pas clair qui, et pas vous, établissez les règles - quel genre de patron êtes-vous?












All Articles