Делать продукт качественно или быстро? Как тимлиду найти баланс и принимать верные решения
Привет! Меня зовут Саша Сахаров, я бэкенд-инженер и тимлид в Авито.
В бизнесе большую роль играют и сроки, и качество продукта, важно находить золотую середину. Есть ситуации, когда продукт нужно выпустить в определенный срок, иначе компания потеряет деньги. В других случаях лучше подождать, но написать идеальный код, потому что в случае ошибок, компания потеряет не только деньги, но и доверие пользователей.
Решения о сроках и скорости работы принимает тимлид. Во многом успех работы команды зависит именно от стратегии, которую он выбрал. Давайте разберемся, как понять, когда надо писать максимально хороший код, а когда стоит добавить костылей?
Почему выбор подхода зависит от конкретного проекта
Соотношение скорости и качества работы зависит от сферы, в которой работает компания, и специфики конкретного проекта. Схема, которая подходит для одной команды, не обязательно сработает в другой.
Тимлид должен оценивать риски и принимать решения на основе сразу множества факторов: нужно учитывать бюджет, потребности пользователей, график работы команды, мнение руководства компании. Важно видеть всю картину целиком (Big picture), чтобы понять, какую стратегию выбрать.
Например, в банковских приложениях нужен очень надежный код. Если клиенты не смогут вовремя, например внести платеж за ипотеку или если их личные данные окажутся под угрозой, последствия будут очень серьезными. В работе над продуктами, где важна безопасность, разработчики выбирают медленный темп. Они предпочтут позже выкатить обновление, но перепроверить каждую мелочь и свести риск ошибок и недовольства пользователей к минимуму.
В стартапах, наоборот, важна скорость. Например, мой друг работает в компании, которая с помощью machine learning рассчитывает скидки на товары по регионам для разных клиентов. Скидки часто приурочены к праздникам или сезонным распродажам, поэтому сроки сжатые. От того, смогут ли ребята предоставить информацию клиенту вовремя, зависит, обратятся ли к ним ещё раз.
В моей работе в Авито бывали ситуации, когда я просил разработчика писать код быстрее, чтобы гарантировать успешный релиз. «Костыли» в коде — это плохо и их потом все равно придётся исправлять. Но как тимлид, я обязан принимать решения, которые в итоге принесут команде пользу: провалить спринт не страшно, а вот провалить каскад задач семи разных команд — недопустимо.
Ещё важно помнить, что у команды тоже есть право голоса и к её мнению стоит прислушиваться. Не стоит всегда принимать решения единолично, просто на основании того, что вы руководитель.
Почему важно понимать, какой темп работы подходит для команды
В идеальном мире разработчик будет писать код с той скоростью, с какой его попросят: если скажут, что надо срочно, он сделает срочно. На практике это практически невозможно, потому что все люди и команды — разные, у всех есть свой комфортный ритм работы.
Например, один человек будет отлично себя чувствовать в постоянно «горящем» режиме. Да, он будет вертеться, как белка в колесе, но покажет высокую эффективность именно в условиях стресса. Разработчикам, которые умеют и любят делать все в очень быстром темпе, будет комфортно в тех же стартапах или в проектах, где важен высокий ритм работы. Они быстро заскучают и выгорят, если попадут в энтерпрайз-культуру, где релиз раз в пол года, а не раз в две недели.
Есть разработчики, которые, наоборот, будут тщательно разбираться в каждой детали и по десять раз все перепроверять. Такому сотруднику будет важна спокойная рабочая обстановка, в спешке он с большей вероятностью наделает ошибок. «Основательному» разработчику в стартапе будет тяжело, потому что упор будет делаться на скорость, а не надежность.
Тимлиды по типу мышления тоже условно делятся на «быстрых» и «медленных» и очень важно, чтобы они с командой были идейно близки друг другу. Здесь работает тот же принцип: дотошный и вдумчивый тимлид скорее всего не сработается с командой скоростных стартапщиков.
Например, я сейчас отлично сконнектился с командой Авито: я по натуре въедливый, и они тоже. Если им дать задачу, то они сразу подхватывают и сделают то, что нужно.
Ещё я знаю, что если не дать разработчику подробное ТЗ, он будет три дня исследовать плохо описанную задачу, писать и уточнять требования. Поэтому мне, как лиду, надо хорошо готовиться к каждому проекту, чтобы в итоге разработчики тратили меньше времени на обсуждения и писали код намного быстрее.
Почему важно разбираться в задаче и оценивать ее в перспективе
Тимлид должен уметь оценивать реалистичность задачи, которую ему ставит клиент или руководство компании, даже если она интересная и амбициозная. Если из-за неё придется сжечь команду до углей, то лучше отказаться или сдвинуть сроки вперед. Благодаря этому команда не выгорит, а разработчикам не придется писать плохой код.
В таких ситуациях именно на тимлида ложится ответственность за качество работы и атмосферу в коллективе. Иногда он должен вдохновлять и мотивировать, а иногда — служить буфером, который защитит команду от неадекватных сроков и требований. Никто не захочет работать много, когда остальные отдыхают, но когда аврал на работе обоснован, то тут важно объяснить разработчикам, за что они страдают. В таких случаях можно, например попросить для команды лишнюю премию.
А еще важно смотреть не только на текущий спринт, но и на два, три месяца вперед и думать, что будет с продуктом дальше. Например, если менеджер просит сделать промоакцию, велика вероятность, что через какое-то время нужна будет еще одна. Тогда имеет смысл заложить возможность передавать данные батчами. Когда бизнес захочет масштабировать продукт, у вас все уже будет подготовлено.
Сейчас у меня в Авито сейчас есть право выбора. Когда мне ставят цели, я могу их обсудить, а не просто пойти страдать во имя бизнеса. Всегда можно отказываться или обсудить — это ценная возможность.
В итоге нужно придерживаться простого правила: прежде чем реализовать фичу, стоит подумать, что будет, если эта фича взлетит и потребует развития. Если тимлид и разработчики интересуются, как дальше будет жить продукт, то оказывается, что техдолг можно предусмотреть.
Почему иногда нужно просто смириться и дописывать код как можно быстрее
Бывает, что и лид, и команда топят за качество, но неправильно оценивают время на выполнение задачи. Если сроки уже прогорели — надо смириться с тем, что придётся дописывать код быстрее. Это Damage Control: попытка минимизировать последствия ошибки, закрыться какими-то костылями и сдать проект. В этот момент важно фокусироваться не на маленькой цели — доставить задачу, а на большой — запустить продукт.
Мне такой выбор дается достаточно просто в процессе: провал затронет всех, показатели продукта ухудшатся и никто не получит премию. Поэтому я склонен выбирать общий успех — важно выкатить продукт, а техдолг отработать позже. Это не значит, что мы всегда пихаем в код костыли, но есть ситуации, когда можно себе это позволить.
Тем не менее лид со своей стороны должен сделать все, чтобы предотвратить такую ситуацию в принципе. Потому что если ты скажешь разработчикам — надо доставить код быстро, то именно ты окажешься тем человеком, который позволил делать некачественный продукт. Про эту ответственность нужно всегда помнить.
