В моём докладе про управление в кризис много эмоций вызвала тема «сушки» работы. Разработке эта парадигма непривычна: стандартный процесс выглядит как «нате требования — пилите, Шура».
«Сушка» подразумевает, что требования можно обсуждать и менять. То, что принёс бизнес-заказчик, — не истина в последней инстанции, а исходная версия решения.
Сначала понять потребность
Чтобы сушить работу, разработке нужно выйти из технологического пузыря и подумать о клиентах. Нельзя просто выкинуть половину требований ради удобства команды. Сначала приходится разобраться:
- какую потребность клиента закрывает задача;
- подтверждена ли эта потребность или это пока гипотеза;
- можно ли получить нужный результат проще и дешевле;
- какие части решения обязательны, а какие появились по инерции.
Ответы показывают, что нужно реализовать полностью, а что можно упростить или отложить.
Это совместная работа с продуктом
Этому подходу я научился, запуская собственные стартапы. Они не взлетели, зато привычка экономно обращаться с объёмом работы осталась.
Разбираться в потребности клиента — ответственность продукта. Но инженерная команда знает стоимость и последствия конкретного решения. Поэтому её вопросы помогают вместе найти вариант проще, быстрее и дешевле.
Именно так я подаю эту работу в разговоре с продактом. Мы не спорим, чья задача важнее, а проверяем решение с двух сторон. В моём опыте такой разбор иногда сокращал объём разработки вдвое.
Одна из задач руководителя разработки — обеспечить стабильную и быструю поставку результата. Для этого можно улучшать процесс, а можно не начинать работу, которая не нужна клиенту. Второй способ часто дешевле.
Разработка перестаёт быть исполнителем не тогда, когда отбирает у продукта его работу, а когда приносит в обсуждение стоимость, ограничения и более простые варианты решения.