Делать продукт качественно или быстро? Как тимлиду найти баланс и принимать верные решения

Привет! Меня зовут Саша Сахаров, я бэкенд-инженер и тимлид в Авито и создатель IT-сообщества.

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

Решения о сроках и скорости работы принимает тимлид. Во многом успех работы команды зависит именно от стратегии, которую он выбрал. Давайте разберёмся, как понять, когда надо писать максимально хороший код, а когда стоит добавить костылей.

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

Соотношение скорости и качества работы зависит от сферы, в которой работает компания, и специфики конкретного проекта. Схема, которая подходит для одной команды, не обязательно сработает в другой. 

Тимлид должен оценивать риски и принимать решения на основе сразу множества факторов: нужно учитывать бюджет, потребности пользователей, график работы команды, мнение руководства компании. Важно видеть всю картину целиком (Big picture), чтобы понять, какую стратегию выбрать.

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

В стартапах, наоборот, важна скорость. Например, мой друг работает в компании, которая с помощью machine learning рассчитывает скидки на товары по регионам для разных клиентов. Скидки часто приурочены к праздникам или сезонным распродажам, поэтому сроки сжатые. От того, смогут ли ребята предоставить информацию клиенту вовремя, зависит, обратятся ли к ним ещё раз. 

В моей работе в Авито бывали ситуации, когда я просил разработчика писать код быстрее, чтобы гарантировать успешный релиз. «Костыли» в коде — это плохо, и их потом все равно придётся исправлять. Но как тимлид, я обязан принимать решения, которые в итоге принесут команде пользу: провалить спринт не страшно, а вот провалить каскад задач семи разных команд — недопустимо. 

Ещё важно помнить, что у команды тоже есть право голоса и к её мнению стоит прислушиваться. Не нужно всегда принимать решения единолично, просто на основании того, что вы руководитель.

Почему важно понимать, какой темп работы подходит для команды

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

Например, один человек будет отлично себя чувствовать в постоянно «горящем» режиме. Да, он будет вертеться, как белка в колесе, но покажет высокую эффективность именно в условиях стресса. Разработчикам, которые умеют и любят делать всё в очень быстром темпе, будет комфортно в тех же стартапах или в проектах, где важен высокий ритм работы. Они быстро заскучают и выгорят, если попадут в энтерпрайз-культуру, где релиз раз в пол года, а не раз в две недели.

Есть разработчики, которые, наоборот, будут тщательно разбираться в каждой детали и по десять раз всё перепроверять. Такому сотруднику будет важна спокойная рабочая обстановка — в спешке он с большей вероятностью наделает ошибок. «Основательному» разработчику в стартапе будет тяжело, потому что упор будет делаться на скорость.

Тимлиды по типу мышления тоже условно делятся на «быстрых» и «медленных» и очень важно, чтобы они с командой были идейно близки друг другу. Здесь работает тот же принцип: дотошный и вдумчивый тимлид скорее всего не сработается с командой скоростных стартапщиков.

Например, я сейчас отлично сконнектился с командой Авито: я по натуре въедливый, и они тоже. Если им дать задачу, то они сразу подхватывают и сделают то, что нужно. 

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

Почему важно разбираться в задаче и оценивать её в перспективе

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

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

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

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

В итоге нужно придерживаться простого правила: прежде чем реализовать фичу, стоит подумать, что будет, если эта фича взлетит и потребует развития. Если тимлид и разработчики интересуются, как дальше будет жить продукт, то оказывается, что техдолг можно предусмотреть.

Почему иногда нужно просто смириться и дописать код как можно быстрее

Бывает, что и лид, и команда топят за качество, но неправильно оценивают время на выполнение задачи. Если сроки уже прогорели — надо смириться с тем, что придётся дописывать код быстрее. Это Damage Control: попытка минимизировать последствия ошибки, закрыться какими-то костылями и сдать проект. В этот момент важно фокусироваться не на маленькой цели — доставить задачу, а на большой — запустить продукт.

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

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