Иллюзии ТЛ + ПМ + ПО

1. Тимлид: «я знаю, как правильно делать — не учите меня жить!»

Зачастую тимлид — действительно очень умный и опытный человек. И если какое-то техническое решение или инициатива кажутся ему неправильными — он легко объяснит, почему оно неправильное. Если вообще не берётся объяснять — то, наверное, человек находится не на своём месте.

Часто бывает, что при выборе между двумя техническими подходами у каждого есть как плюсы, так и минусы. И нормально, например, говорить: «с этим вот подходом у меня больше опыта, поэтому у нас будет меньше рисков». А не ставить команду перед фактом без объяснения причин. Не надо бояться уронить свой авторитет. Надо бояться уронить доверие к себе.

2. Тимлид: «я вынужден подтирать за этими криворукими, работать по вечерам и даже ночами».

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

Во-первых, маскируется проблема. Вместо того, чтобы видеть, как растёт технический долг и принимать осознанное решение с ним справляться — Продакт или Проджект видит, что всё хорошо: команда справляется, скорость высокая. Можно накидывать ещё функциональности. А Тимлид, вместо того, чтобы говорить о техническом долге — молча устраняет его по ночам. Но технический долг всё равно будет расти.

Во-вторых, Тимлид увеличивает риски. Он с таким режимом работы выгорит к чертям собачьим, выйдет в окно, — и что тогда будет с проектом? Продакшин ляжет, и некому будет в сжатые сроки исправить проблему. Но Тимлид, вместо того, чтобы создавать таски под исправление технического долга и списывать туда время — молча овертаймит. И предупредить его выгорание просто некому.

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

В-четвёртых, Тимлид не даёт своей команде развиваться и становиться лучше. Когда на один небольшой коммит, сделанный за полчаса левой пяткой, тебе приходится устранять технический долг часа четыре — это, знаете ли, отрезвляет. И даёт очень мощный стимул к развитию — чтобы, во-первых, научиться писать хорошо, а во-вторых ответственнее относиться к качеству. Но вместо этого тимлид плачет ночами, а кодеры весело педалят код, ни о чём не задумываясь.

Корень проблемы в том, что Тимлид думает на уровне Кода, хотя должен думать на уровне Команды. Тимлиду надо организовать работу Команды так, чтобы Код получался хорошим — а не тянуть всё на себе.

3. Тимлид настаивает на том, что качество кода важнее сроков выпуска.

Да, бывает, что требования к качеству действительно высоки, и сделать «хуже чем надо» — нельзя. Даже ГОСТы на это есть, хоть и не всегда. Но вот делать «лучше чем надо» — тоже нельзя. Работающий продукт важнее качественного кода. В продуктовке это правило работает почти в 100% случаев.

Заковыка в том, что только Тимлид обычно может знать — сколько это «столько, сколько нужно». И если он при этом думает ТОЛЬКО о качестве, не поднимая голову над уровнем кода, на уровень проекта и продукта — то он будет тянуть одеяло в сторону качества, даже в ущерб конечному результату. Потому что конечный результат у написания кода — это код. У реализации проекта — завершённый проект. У продуктовой разработки — работающий продукт. И хороший Тимлид должен помнить обо всех уровнях этого слоёного пирога.

В целом — Тимлид работает на уровне Команды. Код — лишь часть его зоны ответственности. И эффективно работать на уровне Команды он может, только если заглядывает на уровни выше.

4. Проджект говорит, что ему не на кого положиться в команде.

Мол, либо не умеют работать, либо не хотят. Ну, что можно сказать — человек явно не на своём месте. Именно Проджект отвечает за то, чтобы люди в команде умели и хотели работать. Или думать головой.

Возможно, Тимлид недостаточно хорошо помогает к работе — и это проблема как Тимлида, так и Проджекта. Возможно, команда выгорела и демотивировалась на предыдущем проекте — и это проблема Проджекта. Возможно, сам Проджект строит работу и отношения в команде так, что никто не хочет работать. И это — тоже его проблема.

5. Проджект думает, что сроки важнее качества продукта.

Начинается поторапливание, напряжение сил, горящие сраки — и падает качество сначала кода, а потом продукта. Да, это — очень разные вещи. Плохой код может работать без ошибок и продукт при этом может быть качественным. Плохой продукт может быть написан великолепно — но будет при этом плохим, даже если ошибок нигде нет.

Но ни о том, ни о другом наш Проджект не думает. У него — сроки, и их надо соблюдать. Для него они неизменны, и он всех загоняет в рамки этих сроков.

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

6. А иногда бывает, что Проджект вообще не думает о сроках проекта.

Работают люди — и работают. Функциональность готова на первые 90%.

Это, пожалуй, даже хуже, чем предыдущие варианты. Если Проджект не думает о сроках — то он явно находится не на своём месте. Возможно, он просто некомпетентен. Возможно, ему никто не сказал, что сроки важны.

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

7. Кто-то думает, что он — Продакт,

хотя на деле он Проджект или вообще Тимлид.

Очень опасная иллюзия, приводящая к срыву как Проекта, так и Продукта. При этом возможны вариации:

1. когда человек де-факто находится на одной позиции, а де-юре объявляется, что он Продакт;
2. когда он де-факто и де-юре находится на позиции Продакта, а мышление у него осталось на уровне Команды (Тимлид) или Проекта (Проджект)

И в том, и в другом случае последствия будут печальными. А если оба варианта работают одновременно — то провал гарантирован. Проверено неоднократно.

8. Продакт топит за качество конечного продукта, забывая о сроках и стоимости.

Да, вообще-то качество продукта — это основная забота Продакта. И вроде бы за сроками и стоимостью проекта следит Проджект. Но если Продакт вообще не будет смотреть в сроки и стоимость — то его «идеальный продукт» рискует вообще никогда не выйти. Его либо прикроют, либо, грязно матерясь, судорожными усилиями выбросят на рынок какую-то промежуточную версию. Второе очень развито в игропроме.

Думая о качестве — нельзя забывать, что время и конкуренты не стоят на месте, а ресурсы ограничены.

9. Продакт считает, что кто быстро закрывает задачи — тот и молодец.

Вообще-то встречается и у Проджектов, но реже, т.к. Проджекты привыкли работать с рисками. А Продакт видит, что условный Вася фигачит юзерки, как из пулемёта — и выдвигает его в качестве примера. А то, что Вася жутко говнокодит — остаётся за рамками понимания Продакта. И если Тимлид, как описано выше, маскирует проблему — то в итоге получается, что «этот идиот» хвалит самого вредного разработчика, тем самым вредя морали всей команды, одновременно повышая Васино ЧСВ до уровня стратосферы и взращивая в нём уже личные разработческие иллюзии о самом себе.

Получается, что Продакт, мыслящий на уровне Продукта, становится источником проблемы на уровне Команды и Кода, поскольку ни о том, ни о другом он не думает — и вроде бы даже не обязан думать. Такая вот загогулина.

Хороший Продакт, хороший Проджект, хороший Тимлид, хороший Разработчик — все должны думать обо всех слоях пирога. Код, Команда, Проект, Продукт. Иначе — неизбежны проблемы и провалы.

Да, каждый из них концентрируется на своём слое. Сообщает другим о проблемах в нём. Фильтруя эти проблемы через призму понимания остальных уровней. Но если он зароется в своём слое, не заглядывая в другие и не думая о них — то весь торт перекособочится и в итоге развалится.

Общайтесь с коллегами. Собирайте общую картину. Думайте головой.