Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов - [12]

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

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

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

7 – Как принимать работу

Стандарты качества

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

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

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

Между строк

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

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

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

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

Чтобы не забыть

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

Помните: недосказанность всегда работает против вас!

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

Иной раз, задавая вопросы, вы сталкиваетесь с тем, что готового ответа на месте не найдётся. Обязательно фиксируйте непосредственно во время обсуждения все вопросы, договорённости, сроки решения и ФИО/контакты того, кто за это отвечает. Если вы общаетесь по скайпу – пишите всё это в сообщениях. Если лично – держите открытой почтовую программу и составляйте на ходу «протокол» совещания. Это позволит впоследствии не ломать голову над тем, кто кому что обещал и почему ничего до сих пор не готово.