Техническое задание: что за зверь и с чем его едят
Техническое задание — основа качественного и ожидаемого продукта. Научнее — структурированный документ с требованиями к продукту, написанный на понятном для всех сторон языке.
ТЗ не чисто техническая документация. Существуют стандарты и ГОСТы, например ГОСТ 19, ГОСТ 34, SWEBOK, BABOK, которые определяют, как должно быть написано техническое задание. Однако многие компании внедряют свои шаблоны и правила, чтобы сделать ТЗ читаемым и понятным для всех заинтересованных сторон: разработчиков, менеджеров, руководителей, клиентов и других стейкхолдеров.
Одно техническое задание может включать сразу несколько задач для разработки. Почему так? Концепт и все желаемые процессы удобнее и понятнее описать в одном месте. При этом большие задачи неэффективно делать за раз, поэтому их дробят на мелкие. При описании каждой такой задачи в нашей команде используются критерии SMART.
Аббревиатура из пяти английских слов:
- specific — конкретная, сформулированная так, чтобы каждый понимал ее одинаково;
- measurable — измеримая, результат должен иметь критерий для оценки;
- achievable — достижимая, должна укладываться в реалистичные сроки и опираться на объективные показатели;
- relevant — значимая, должна соответствовать целям компании;
- time bound — ограниченная во времени, должна иметь конкретный срок реализации.
ТЗ написано по всем правилам, согласовано со всеми инстанциями, взято в разработку и… На тестах (если не в продакшене) выясняется, что реализовано совсем не то, что требовалось. Что же произошло?
Предпочитаю НЕ читать ТЗ
Проводим расследование. Слышим от разработчиков фразы: «Я читал, но, наверное, не до конца», «Ой, а эту строчку пропустил», «Тут вообще было не ясно, поэтому сделал так». С такой проблемой сталкиваются как в крупных, так и в небольших IT-компаниях. Что же не так? Часть ответа на поверхности: огромные документы читать скучно и сложно, но копнем глубже.
Почему ТЗ не читают? Одна из причин «нечтения» ТЗ — наличие дизайна. Дизайн покрывает не конкретную задачу, а все задание. Если разработка опирается на него, создается лишний функционал для текущей задачи.
Из-за этого тормозится выпуск функционала, который нужен именно в этой задаче. Интересный факт: такая причина «нечтения» затрагивает не только фронтенд-разработчиков, но и бэкенд.
Еще одна причина — в ТЗ нет структуры и содержания. Особенно актуально для больших технических заданий. Нехотя разработчик может читать огромный непонятный документ, но толку от этого будет немного. Отвлекся на секунду, потерял половину, забыл, где закончил, а перечитывание не помогает.
Почему не читают джуны? По моему опыту, джуны — амбициозные, уверенные в себе ребята. В них много энергии, стремления переписать и оптимизировать весь код. Они всё знают, поэтому пробегают по верхам ТЗ и уходят в себя. Дописывают логику, которая не требовалась, меняют ту, что была нужна. Они не задают уточняющих вопросов. Иногда их идеи бывают интересными благодаря свежему взгляду на продукт, но когда нужно четко выполненное ТЗ — это неактуальный плюс.
Бывает по-другому: джуны скрупулезно вчитываются в каждую строку и боятся выглядеть некомпетентными. Поэтому количество их вопросов по содержанию задачи стремится к нулю.
В любой из этих картин в результате получим неполноценную реализацию продукта из-за «нечтения» ТЗ.
Почему не читают мидлы и сеньоры? Или читают, но все равно не делают? Это люди с опытом и шишками. Они чаще вчитываются в ТЗ, задают вопросы. Согласуют изменения и предлагают свою логику с аргументированной критикой. При этом все равно иногда пропускают небольшие, но важные моменты в ТЗ.
Можете возразить: «Нормально пиши — нормально будут делать». Но все не так просто…
НЕидеальное ТЗ
Каким бы идеальным ни было ТЗ, вопросы у разработчиков и тестировщиков по нему будут всегда.
На это есть причины:
- Аналитик не всегда осведомлен об особенностях кода на проекте. Он может попасть в проект не сначала, еще не успеть вникнуть в специфику реализации или просто не обладать информацией по техническим ограничениям проекта. Нужно ли ему в этом разбираться и уметь писать код — тема для отдельной статьи.
- Тестировщики обладают отличающимся от остальных членов команды складом ума. Они замечают больше проблемных мест в продукте и кейсов его использования. Как минимум они всегда рассматривают возможность нестандартного поведения пользователя.
- Аналитик сам не разобрался в требованиях заказчика и написал ТЗ с подтекстом: «Ты ж программист, разберешься». Жаль, что это так не работает. Есть специалисты, которые сами до конца не понимают своих же требований. Или им лень описывать их подробно, разложив по полочкам каждый шаг. Они перекладывают это на айтишников, что тормозит работу.
- Заказчик не дал полных требований, а ожидал совсем другого. Приведу пример из своей практики. Наша компания разрабатывает массовый продукт. При этом мы всегда открыты к пожеланиям от клиентов. Один из них попросил вывести для него дополнительную статистику. Начали общаться и в процессе выясняли, что нужна была не статистика, а новый фильтр по клиентам и выгрузка отфильтрованного списка.
Что делать-то будем?
Проблема есть — найдем решение. Чтобы убедить разработчиков в важности чтения ТЗ, в AppEvent мы сделали следующее:
- Внедрили ретроспективу по ТЗ. Собираемся на совещания раз в месяц. На этих мероприятиях обсуждаем, что удобно или неудобно, нравится или не нравится, чего не хватает в ТЗ. Важно выслушать мнения всех участников команды и учесть их.
- Стали открыты к обратной связи и обсуждениям. В любой момент (не только на совещаниях) разработчик может сказать, что есть сложности с ТЗ. Это безопасная среда. Сотрудники уверены, что за это не последует никаких санкций, а их мнение будет учтено. Мы вместе ищем решение задачи.
Оптимизировали шаблон ТЗ и внесли изменения на основе обратной связи. Структура должна стать удобной и понятной для всех членов команды.
- Начали писать в ТЗ с дизайном первым пунктом: «Читайте ТЗ». Возможно, это решение покажется странным, но оно сработало.
- Привлечение разработчиков и тестировщиков на этапе проектирования ТЗ.
Этот пункт вызывает много разногласий, поэтому выделим его отдельно. Привлечение команды на постоянной основе отнимает много времени, но дает большой выхлоп. Как быть?
Что делаем мы?
- В обсуждении ТЗ мы никогда не задействуем всю команду. Привлекаем только руководителей по каждому направлению: бэкенд, фронтенд, тестирование.
- Прибегаем к этому методу, только если задача вызывает вопросы о возможности реализации. Или кейс специфический уже на этапе проектирования. Например, ранее нами не использовались технологии, которые в этой задачи применить необходимо.
Универсальных методов-таблеток не существует. В статье я описала то, что помогло нашей компании. И это подтверждает статистика: 85% сотрудников разработки AppEvent всегда читают ТЗ. Почти всегда с ходу понимают его и задают уточняющие вопросы.
P. S. Интересно услышать мнение разработчиков и тестировщиков о ТЗ и важности его прочтения для вас.
