Обычная история в продуктовой команде: продакт-менеджер хочет быстрее внедрить фичу, разработчики отправляют задачу на дно бэклога и говорят, что сейчас самое время для работы с техническим долгом. Почему так?
Мы решили задать самые болезненные вопросы продакт-менеджеров о разработке. Вопросы задавала Валерия Розова, ex-СРО Qlean, BestDoctor, сейчас CEO Emex DWC. На вопросы отвечал техдир Самат Галимов, ex-CTO Bookmate, автор канала «запуск завтра» и основатель компании, где команда говорит на языке бизнеса и продукта.
[card]
Это краткая выжимка дискуссии, которую Валерия провела с Саматом. Разговор целиком вы сможете послушать в конце этой статьи.
[/card]
Почему разработчики называют долгие сроки для простых задач?
Сроки — «вечная головная боль» для всех в команде. Продакт хочет всё быстро, разработчик — качественно и надолго. В итоге возникает недопонимание: почему простую задачу нельзя взять и сделать за день.
Может быть так, что задача вроде элементарная, но на самом деле внутри куча сложностей, которые продакт-менеджер не видит. Стоит разобраться, на что разработчик закладывает дополнительное время. Возможно, продакт сможет переформулировать решение таким, чтобы «побочной работы» было меньше, например, выкатить новую функцию не на всех пользователей, а только на свежих. Такие оптимизации — процесс индивидуальный, именно поэтому важен откровенный диалог и совместный поиск решения.
<<products-1>>
Как понять, что они не тянут резину специально?
Задавать вопросы. Например, если разработчик говорит, что задача займёт две недели, можно спросить: «Что конкретно потребует столько времени?» Может оказаться, что задача затягивается из-за интеграции с устаревшей системой и что нужно больше времени на тестирование. Хороший пример: разработчики могут закладывать дополнительные дни на рефакторинг старого кода, чтобы новая функция не вызвала падения всей системы.
Важно понять, почему нарушаются сроки. Многие проекты страдают от недостатка чёткого планирования и коммуникации. Программисты должны уметь предсказывать риски и честно озвучивать возможные задержки. Важно задавать вопросы и разбираться в деталях задачи до того, как она станет критичной.
Например, часто бывает ситуация, когда в середине недели прилетают «новые срочные задачи», а срок на уже запланированное никто не увеличивает. Конечно, задача хорошего разработчика — ясно указывать на такие конфликты в момент их возникновения, а не когда наступят последствия.
Как избежать потерянных задач?
Если разработчики не понимают, зачем нужна их работа, они просто выполняют задачи для галочки. Нужно, чтобы обе стороны двигались к общей цели и говорили на одном языке.
Хороший разработчик понимает, зачем он выполняет ту или иную задачу. Только тогда он сможет предложить оптимальное решение. Если между продактом и разработчиком нет доверия, возникает недопонимание, а сроки растут.
Для того чтобы наладить взаимодействие, нужно, чтобы продакт и разработчик договорились о том, какие у каждого вклад и роль. Продактам важно делиться контекстом и объяснять конечную цель. Например, вместо «сделай кнопку» лучше объяснить, что цель — увеличить конверсию на определённом этапе. А дальше уточнить, как это связано с целями бизнеса.
Даже конфликты могут быть продуктивными, если у команды есть общие цели и каждый понимает, как он на эти цели работает. Продакты хотят быстрее запустить новые функции, разработчики заботятся о стабильности системы. Баланс можно найти через открытые обсуждения: какую часть работы можно ускорить, а на что лучше выделить больше времени.
Часто продакты или стейкхолдеры пытаются добавить дополнительные функции уже в процессе работы над задачей. Лучше так не делать, а зафиксировать сроки и то, что именно делаем в этой итерации, — даже если этот функционал не идеален, лучше завершить его, чем бесконечно добавлять новые требования и откладывать релиз. Для бизнеса лучше два внедренных улучшения в продукт, которые уже будут работать на цели, чем эти же задачи, которые зависли в бесконечных доработках на 80% готовности и не приносят ничего.
Что такое технический долг и почему его постоянно надо отдавать (часто именно тогда, когда так нужно внедрить что-то новое)?
Технический долг — это проблемы, которые накопились в коде и архитектуре работы. Его можно сравнить с неопрятной башней из кубиков, которая растёт всё выше, но её фундамент уже начинает рушиться. Техдолг неизбежен, особенно в живых продуктах, которые развиваются и изменяются с течением времени.
Проблема в том, что приоритет всегда отдаётся новым фичам и задачам, которые видны клиентам и приносят пользу бизнесу. Вернуться к старым проблемам сложно: клиенты и руководство не требуют менять архитектуру или старый код. Однако чем дольше откладывать возвращение долга, тем больше он накапливается — вот мы и приходим к тому, что «по-быстрому сделать просто кнопку» не получается. И эта кнопка ломает всё остальное.
Вместо того чтобы переписывать всё с нуля, лучше работать с техническим долгом постепенно, без остановки разработки. Один из таких методов — обновление системы частями, так называемый подход Strangler Fig Pattern. Можно выделять 10–20% времени команды на технические улучшения или включать задачи по устранению долга в каждый спринт. Так долг не будет расти, а работа над новыми задачами не замедлится.
Как оценить, когда технический долг становится критическим?
Если команда начинает замечать, что внедрение новых фич занимает всё больше времени, это сигнал к тому, что накопленный технический долг мешает работе. Важно мониторить скорость выполнения задач и качество кода. Если слишком много времени уходит на исправление багов, стоит обратить внимание на рефакторинг, перепроектирование кода.
Как замотивировать разработчиков пробовать новое?
Все хотят, чтобы команда придумывала новые решения и двигалась вперёд. Но правда в том, что далеко не все разработчики готовы к инновациям. Важно создавать такие условия, в которых даже самые осторожные сотрудники смогут что-то предложить.Не все любят рисковать и пробовать новое. Обычно это 10–20% разработчиков, остальные предпочитают стабильность. Но если не создать условия, где можно безопасно экспериментировать, то самые «бодрые» сотрудники рано или поздно разбегутся.
Иногда продакты просят разработчиков протестировать новую гипотезу и встречают сопротивление. Разработчики боятся, что временное решение останется в системе навсегда и потом с ним будет куча проблем. Поэтому они медлят с тестированием гипотез. Чтобы этого избежать, важно заранее продумать, как очистить систему после эксперимента, и заложить на это время и ресурсы.
<<zapis-iventa-s-samatom>>
