Дмитрий Ершов - Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов

После запуска цифрового продукта в интерфейсе можно увидеть два типа ошибок: серверные и клиентские. Серверные всегда выглядят шаблонно, например: «Ой, что-то пошло не так» или «Извините, страница не найдена» и т. п. Клиентские (ошибки фронтенда) отражаются в съехавших шрифтах, дёргающихся при загрузке блоках страниц и невозможности «свайпить» картинки на экране смартфона. И если к серверным ошибкам пользователи более-менее привыкли, поскольку они типовые, то косяки с вёрсткой всплывают неожиданно и тем самым больше раздражают, выдают низкое качество продукта и снижают лояльность ваших пользователей.

«У меня все готово, осталась буквально пара мелочей», – говорят люди, которые не умеют доводить дела до конца. Многие недооценивают этот навык.

Человек, способный проконтролировать работу специалиста (например, дотошный арт-директор работу дизайнера), выясняет, что доработка этих мелочей занимает такое же или большее время, чем вся «выполненная» работа.

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

Один из ста может довести до финала работу команды. Такой человек называется product owner. Другими словами, тот, кто за все отвечает в конце концов.

Каждый специалист должен быть менеджером продукта, к которому он прикладывает руку.

Зона ответственности дизайнера не заканчивается на этапе передачи макетов разработчикам. Он должен контролировать все до релиза. Это называется вовлеченность.

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

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

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

Спустя год была сформирована проектная команда, полностью изменены процессы взаимодействия с заказчиком, внешними и внутренними подрядчиками и, наконец, запущен продукт, который действительно полезен аудитории, поскольку решает её проблемы. Прародитель методики Agile провёл исследование более 20 000 проектов и доказал, что результат вовсе не связан с процессами.

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

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

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

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

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

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

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

Лучшим инструментом контроля качества является мнение разработчиков, которые будут продолжать проект после завершения текущего спринта. Это может быть одна и та же команда или даже один человек, а могут быть и разные. Главное – чтобы исполнитель понимал, как можно применить текущий результат для дальнейшей работы, и было создано достаточное количество материалов. Если же для закрытия задачи нужно что-то доделать – значит, она была недостаточно четко сформулирована и поэтому не выполнена. Постарайтесь в следующий раз формулировать задачу лучше.