Читать «Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов» онлайн - страница 20

Дмитрий Ершов

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

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

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

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

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

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

Между строк

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

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

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