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