No gos
Часто релизы и тесты новых продуктов/фич/процессов тормозятся не из-за их основной гипотезы, а наоборот – из-за редких корнер-кейсов или добавления «приятных мелочей». Обсуждения, как их разрулить затягиваются, приходится привлекать всё больше людей, а решения начинают раскрывать всё больше технического и дизайнерского долга в продуктах, а значит увеличивают время разработки «хорошего решения».
Мы в работе стараемся не стопориться в таких ситуациях, а просто явно договариваемся о том, что мы не будем делать. Например:
– Не обрабатывать корнер-кейс для пользователя, а просто показывать ошибку и собирать в аналитику информацию, как часто она возникает
– Не добавлять в интерфейс возможность что-то изменить, но добавлять возможность обратиться в саппорт и попросить это сделать
– Не делать приятные мелочи обязательной частью задачи, а добавлять их только если успеваем.
Не могу представить себя лет 7 назад, мыслящим так же: «Это что, мы умышленно неработающее приложение выкатим на пользователя!?». Но оказалось, что так живётся намного лучше: продукты эволюционируют быстрее, данных собирается больше, а митингов, где мы решаем проблемы для 0.001% наших пользователей стало меньше. А часть идей всё равно приходится откатывать, так что корнер кейсы вообще не приходится решать.
Главное в таком подходе – фиксировать «долги» и обязательно к ним возвращаться. Вот тут мы часто обжигались – некоторые проблемы были понятны ещё на этапе разработки, но нигде не фиксировались и потом выстреливали в колено.
В общем, заранее договориться о том, что вы не будете делать – отличный способ ускорить разработку. А в книге Shape Up от Basecamp авторы вообще предлагают делать no gos частью описания любого проекта.
>>Click here to continue<<
