Как хорошему разработчику не стать плохим менеджером - [41]

А в результате Алексей потратил время на решение задачи, плюс время на доведение менеджерского решения до работающего состояния, плюс время на исследование менеджерского решения, плюс время на убеждение менеджера и команды в том, что именно его решение нужно использовать.

То есть вместо ускорения работы Алексея получилось значительное замедление. Причём, например, заставлять Алексея тратить время на убеждение команды и менеджера в правильности принятого решения было совсем излишне. В этом и суть распределения ответственности. Если разработчик принимает решение, то заставлять его аргументировать излишне. Это если решение должен принять менеджер, то ему нужны доказательства, информация и прочее.

Собственно, из истории видно, почему менеджер не взял полностью решение задачи на себя. Он не мог довести его до конца. Из-за нехватки знаний, времени или и того, и того. Тем более странным является его поведение. Это больше похоже на какой-то прессинг разработчика.

Причём, здесь в высшей степени не важно, насколько хорошо Алексей сам подходил для решения задачи. Даже если действительно задача была простой “двухдневной”, а Алексей на неё тратил 2 недели из-за недостатка знаний. Ну и что? Менеджер может заменить разработчика или работать с тем, что есть. В конце концов, часто бывает, что тимлид работает с командой новичков. Там каждый(!) член его команды работает во много раз медленнее, чем он сам. Ну и что? Это нормально. Можно прокачивать свою команду, можно использовать их “как есть”. Но какой практический смысл в том, чтобы гнобить своих разработчиков? Это крайне непрофессионально.

Аналогичная картина видна и в продолжении истории. Какой смысл показывать недоверие всем оценкам? Зачем просить других членов команды подтверждать (или даже опровергать) оценки. Даже если есть какой-то Пётр, который может сделать какую-то задачу в два раза быстрее Алексея, то что из этого следует? “Я угадаю эту мелодию с трёх нот. – Угадывай!”

Смысл оценки в том, чтобы разработчик подписался на то, что он сделает задачу в срок. А то, что какой-то другой разработчик может сделать её в два-три-десять раз быстрее… Кому какая разница? Менеджер показывал своё недоверие Алексею, а значит и команде разработки в целом. Причём, команда подтверждала оценку Алексея, а менеджер выглядел совсем бледно.

Что делать в такой ситуации менеджеру? Прекратить показывать свои комплексы и неуверенность и начать управлять. Либо заменить разработчика, либо начать ему доверять, а не устраивать детский сад.

Что делать в такой ситуации Алексею? Я бы занял жёсткую позицию. Менеджер даёт свою реализацию задачи. Что он хочет, чтобы я с ней сделал? Изучил код? Это reverse engineering и пусть менеджер даёт согласие на эту трату времени. Либо пусть сидит и объясняет, как его код работает. Нужно принять решение по выбору кода, который идёт в прод? Отлично, решение принято, в прод идёт мой код. А, так нельзя, нужно сравнить решения? Тогда это исследовательская задача и пусть менеджер явно назначает такое задание, и принимает решение сам по результатам сравнения. При этом где-нибудь я бы эскалировал проблему менеджеру менеджера, так как явно он мешает работать.

А вот финал истории вполне закономерен. Менеджер потерял разработчика, причём не по своей инициативе. То есть и здесь у него всё пошло наперекосяк.

История про деньги заказчика

Услышал интересные рассуждения от опытного фрилансера:

И почему говорят, что чужие деньги не экономишь? Я давно понял, что проекты закрываются, когда у заказчика деньги кончаются. Поэтому я, чтобы без работы не остаться, экономлю деньги заказчика, как могу. Например, предлагаю немного код переписать, чтобы можно было сделать downgrade версии сервера и уменьшить цену лицензии. Или производительность оптимизирую, чтобы за хостинг заказчик меньше платил. Пусть лучше он эти деньги мне заплатит за разработку кода.

Спасибо, что дочитали эту книгу до конца. Я надеюсь, что эта книга принесла вам не только пользу, но и развлечение.

Возможно, вам хочется написать мне какую-то историю из вашей жизни. Или, может быть, вы хотите мне написать, с чем вы не согласны. Или вам хочется, чтобы в следующей книге я написал о чём-то важном. Пожалуйста, напишите мне об этом на мою почту [email protected], мне будет приятно.

До новых встреч!