Алексей ушёл думать. Он решил докопаться до сути и погрузился в исследование решения Игоря. Почему оно проще и быстрее? Вскоре Алексей выяснил, что менеджер вместо работы с базой использовал заранее приготовленные файлики JSON с нужными данными и показывал только первые 1000 записей. Поэтому и производительность была нормальной. Когда эти хаки убрали, решение менеджера стало тормозить так же.
Алексей убедил команду, что надо в продакшене использовать его решение, так как оно соответствует изначальным требованиям. А чуть позже он смог и решить проблему с производительностью. Причём, решение было крайне нетривиальным и завязанным на конкретные структуры данных.
На этом история не закончилась. После этого менеджер оспаривал любую оценку Алексея, заявляя, что всё должно быть проще и быстрее. Менеджер просил других разработчиков сказать свою оценку, чтобы проверить оценку Алексея. Иногда это были даже разработчики из других проектов. Все они, кстати, подтверждали оценки Алексея, но это не помогало.
В результате Алексей решил, что для него будет лучше сменить компанию. А для себя вынес, что нет хуже ситуации, когда не понимаешь мотивов своего менеджера.
Анализ
Мне в первый момент показалось, что Алексей рассказывает про какого-то безумного менеджера, который полностью потерял вменяемость из-за чего-то и творит беспредел. Но при вдумчивом вглядывании я понял, что видел много подобного поведения. Поэтому стоит проанализировать ситуацию детальней.
Самое интересный вопрос тут, это зачем менеджер полез в код? Он хотел ускорить работу разработчика? Зачем тогда он делал это втайне, и почему не взял ответственность на себя? Менеджер (а скорее тимлид) может перевести на себя какую-то задачу, если видит, что разработчик не сделает её. Но тогда нужно делать это полноценно, по процессу, доведя задачу до конца.
А в результате Алексей потратил время на решение задачи, плюс время на доведение менеджерского решения до работающего состояния, плюс время на исследование менеджерского решения, плюс время на убеждение менеджера и команды в том, что именно его решение нужно использовать.
То есть вместо ускорения работы Алексея получилось значительное замедление. Причём, например, заставлять Алексея тратить время на убеждение команды и менеджера в правильности принятого решения было совсем излишне. В этом и суть распределения ответственности. Если разработчик принимает решение, то заставлять его аргументировать излишне. Это если решение должен принять менеджер, то ему нужны доказательства, информация и прочее.
Собственно, из истории видно, почему менеджер не взял полностью решение задачи на себя. Он не мог довести его до конца. Из-за нехватки знаний, времени или и того, и того. Тем более странным является его поведение. Это больше похоже на какой-то прессинг разработчика.
Причём, здесь в высшей степени не важно, насколько хорошо Алексей сам подходил для решения задачи. Даже если действительно задача была простой “двухдневной”, а Алексей на неё тратил 2 недели из-за недостатка знаний. Ну и что? Менеджер может заменить разработчика или работать с тем, что есть. В конце концов, часто бывает, что тимлид работает с командой новичков. Там каждый(!) член его команды работает во много раз медленнее, чем он сам. Ну и что? Это нормально. Можно прокачивать свою команду, можно использовать их “как есть”. Но какой практический смысл в том, чтобы гнобить своих разработчиков? Это крайне непрофессионально.
Аналогичная картина видна и в продолжении истории. Какой смысл показывать недоверие всем оценкам? Зачем просить других членов команды подтверждать (или даже опровергать) оценки. Даже если есть какой-то Пётр, который может сделать какую-то задачу в два раза быстрее Алексея, то что из этого следует? “Я угадаю эту мелодию с трёх нот. – Угадывай!”
Смысл оценки в том, чтобы разработчик подписался на то, что он сделает задачу в срок. А то, что какой-то другой разработчик может сделать её в два-три-десять раз быстрее… Кому какая разница? Менеджер показывал своё недоверие Алексею, а значит и команде разработки в целом. Причём, команда подтверждала оценку Алексея, а менеджер выглядел совсем бледно.
Что делать в такой ситуации менеджеру? Прекратить показывать свои комплексы и неуверенность и начать управлять. Либо заменить разработчика, либо начать ему доверять, а не устраивать детский сад.
Что делать в такой ситуации Алексею? Я бы занял жёсткую позицию. Менеджер даёт свою реализацию задачи. Что он хочет, чтобы я с ней сделал? Изучил код? Это reverse engineering и пусть менеджер даёт согласие на эту трату времени. Либо пусть сидит и объясняет, как его код работает. Нужно принять решение по выбору кода, который идёт в прод? Отлично, решение принято, в прод идёт мой код. А, так нельзя, нужно сравнить решения? Тогда это исследовательская задача и пусть менеджер явно назначает такое задание, и принимает решение сам по результатам сравнения. При этом где-нибудь я бы эскалировал проблему менеджеру менеджера, так как явно он мешает работать.
А вот финал истории вполне закономерен. Менеджер потерял разработчика, причём не по своей инициативе. То есть и здесь у него всё пошло наперекосяк.
История про деньги заказчика
Услышал интересные рассуждения от опытного фрилансера:
И почему говорят, что чужие деньги не экономишь? Я давно понял, что проекты закрываются, когда у заказчика деньги кончаются. Поэтому я, чтобы без работы не остаться, экономлю деньги заказчика, как могу. Например, предлагаю немного код переписать, чтобы можно было сделать downgrade версии сервера и уменьшить цену лицензии. Или производительность оптимизирую, чтобы за хостинг заказчик меньше платил. Пусть лучше он эти деньги мне заплатит за разработку кода.
Спасибо, что дочитали эту книгу до конца. Я надеюсь, что эта книга принесла вам не только пользу, но и развлечение.
Возможно, вам хочется написать мне какую-то историю из вашей жизни. Или, может быть, вы хотите мне написать, с чем вы не согласны. Или вам хочется, чтобы в следующей книге я написал о чём-то важном. Пожалуйста, напишите мне об этом на мою почту [email protected], мне будет приятно.
До новых встреч!
