2 июля 2013 г.

Техническое задание как база знаний о проекте

Разработка ПО - это процесс создания знания. Общая идея продукта, прототипы дизайна и концепция архитекутры могут появиться до начала разработки, но их правильность или неправильность будет проверена только в ходе работы над проектом.

ТЗ - как источник потерь

Я всегда довольно скептически относился к подробным техническим заданиям и со временем эта позиция только усиливается.

Что значит получить подробное ТЗ до начала работ?

  1. Заказчик рассказывает про проект и просит его оценить
  2. Мы просим описание проекта, чтобы понять объем работы
  3. Получаем техническое задание по проекту (оно не будет исчерпывающим, особенно в больших проектах)
  4. Читаем, анализируем, даем оценку. Нас попросят подписаться под сроком, поэтому оценка сразу включает наши риски, т.е. увеличиваем время и деньги
  5. Заказчик соглашается и просит нас подписаться под сроком и ценой
  6. На что мы, защищая свои интересы, поясняем, что после подписывания ТЗ изменения в него будет сложно внести. Придется пересогласовать и цену и срок
  7. Чтобы не идти на пересогласования, заказчик пытается заранее учесть в этом ТЗ всё что только можно и нельзя

Ситуация проиграл-проиграл

Давайте посмотрим, что каждая сторона получит в итоге:

  • Заказчик все равно будет вносить изменения в ТЗ, можно принять это за факт. Чем больше проект, чем чаще мы делаем релизы, тем больше изменений будет внесено. Мы все-таки не ТЗ делаем, а бизнес-задачу решаем, только в этом до последнего никто не признается
  • Если мы заранее согласовали архитектуру с техническими специалистами заказчика, то сразу после начала работы мы начнем вносить в нее изменения. Чем подробнее была эта изначальная архитектура, тем больше изменений в нее будет внесено. Опять же, если архитектура входила в ТЗ, то придется пересогласовывать сроки и бюджет
  • В ТЗ оказалось много задач, которые никогда не понадобятся заказчику, но раз они в ТЗ, значит нам надо будет их сделать. Это влечет потери времени и денег с обеих сторон
  • С помощью ТЗ мы хотели ограничить «хотелки» заказчика, а получили их с избытком: первая часть добавлена в ТЗ заказчиком на будущее + вторая часть пришла в виде изменений по ходу проекта
  • Хуже всего в этой ситуации пользователям, т.к. сроки реализации растягиваются

Проблемы пересогласования ТЗ

Самое интересное в таком подходе - процесс пересогласования сроков и бюджета. Это магическая процедура редко бывает с выходом win-win. Заказчик может сдвинуть сроки релиза, но будет до последнего упираться в изменении бюджета.

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

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

История знает и случаи успешного пересогласования бюджета, но это большая редкость.

Agile без ТЗ

Вы скажете, что этот рудимент в виде ТЗ уже не существует в Agile проектах. У нас есть заказчик под рукой, мы делаем Story Mapping, держим Kanban-доску у всех на виду, делаем релизы каждый день, всем понятно текущее состояние проекта. В этом случае никому не придет в голову полгода писать подробное ТЗ и только потом отдавать его в работу.

Случай из практики: У меня был один из проектов, когда заказчик очень хотел написать для нас ТЗ. Пока он его писал мы общались с его технически представителем и постепенно делали проект, получая обратную связь. Когда заказчик прислал нам ТЗ, мы прислали ему готовый продукт, чему он было очень рад.

Случай из практики: Мне удалось поработать с гос. заказчиком по моделе Agile. Изначально было некое ТЗ, жесткие сроки и бюджет, но заказчик хотел получить именно работающий продукт, а не реализованное ТЗ. Внутри жесткого waterfall'а мы устроили обычный Scrum. В итоге заказчик получил продукт на несколько месяцев раньше, чем требовалось.

Реинкарнация ТЗ

С недавнего времени я начал сталкиваться с интересными особенностями больших проектов. В них столько функциональности, что уже сам Product Owner начинает забывать на что способна система и как точно она должна работать.

В одном из проектов мы работаем с командой QA, которая находится в другой компании в другом городе. Это усложняет коммуникацию.

В этом случае получилось следующее:

  • Мы планируем задачи в понедельник
  • Каждый день делаем релизы
  • Раз в неделю проводим демо
  • Ведем документ, который описывает всю функциональность системы

Последней частью занимается Product Owner вместе с техническим писателем. Получающийся документ остает от разработки и постоянно меняется по ходу работы. Заказчик видит продукт, проводит демо для клиентов, получает обработную связь и хочет сделать продукт лучше. Мы получаем наброски дизайна и примерное описание. Реализуем, показываем, получаем более подробные User Story, доделываем задачу.

В результате у нас есть документы, которые содержат все User Story и подробные описания частей системы. Недавно я понял, что это и есть ТЗ, только сделанное итеративным путем и готовое к изменению, а не навязанное с начала работы над проектом.

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

Избавляемся от потерь

Написание подробного ТЗ до начала работы, как и Big Design Up Front, приводят к потерям на IT-производстве.

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

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

7 комментариев:

  1. Всё отлично с точки зрения исполнителя, но как быть с заказчиком ? Ведь первое, что он хочет узнать - это сроки и стоимость выполнения его задачи, которые рассчитываются (хотя бы ориентировочно) на основе какого-никакого но вчё же ТЗ, иначе ни вы ни он не сможете сказать сроки и объём работ. Как быть с этой проблемой ?

    ОтветитьУдалить
  2. Отличный вопрос. Вообще позиция заказчика: решите мою проблему. И это правильная позиция, заказчик не обязан знать про разные методологии и т.п.

    Как же дать оценку и взять на себя некие обязательства? Мы можем взять описание проекта, провести Story Mapping и оценить объем работы. Если заказчик будет в этом участвовать, то он будет понимать откуда берутся сроки и что в проекте будет сложной частью, а что простой.

    Всё это не означает, что конечный объем работы будет зафиксирован в договоре, мы можем начать работать по схеме T&M, постоянно давая обратную связь и показывая резульаты своей работы.

    ОтветитьУдалить
  3. Андрей Валяев2 июля 2013 г., 12:01

    Какое же это задание? это получается Техническое Решение. :)

    ОтветитьУдалить
  4. Андрей, да, скорее уже Решение, спасибо :)

    ОтветитьУдалить
  5. С одной стороны все правильно. Работали как то с заказчиком. Нам сразу же выдали ТЗ на 80 листов, с описанием функционала, юзкейсов и тд. Описание было настолько подробное, что даже для каждого поля в УИ было указано, какая должна быть маска, длина поля, валидация. Сделали все довольно быстро. Затем началась вторая итерация, в ТЗ начали вносить изменения, объём его распух вдвое. Но вот какое дело - при изменении ТЗ, авторы этого ТЗ забывали (или не хотели) вносить правки во всех нужных местах. Например, номер телефона где то стал с плюсом, где то просто с семерки, где то с восьмерки, где то 7значный. Некоторые необязательные поля стали обязательными в юзкейсах и наоборот. В общем, на 160 страницах ТЗ было много мест, которые противоречили друг другу. Такие моменты очень сильно затрудняют разработку и тестирование, учитывая, что время отклика заказчика было от одного дня до месяца.

    Но есть и другая сторона медали. Существует множество контор, которые берут заказы на разработку, но не содержат штатных программистов, только менеджеры проектов. Они под каждый заказ могут нанимать программистов или отдать его на аутсорс другой конторе. То есть конечным программистам, тестировщикам и даже менеджерам заказчик не всегда доступен напрямую, потому подробное ТЗ практически единственный вариант узнать, что нужно заказчику, и единственный способ определить, что работа над проектом завершена. Если заказчику что то не нравится и он просит доработать (бесплатно, естесственно), то только тыкнув в ТЗ можно ему показать, что это дополнительные задачи и дополнительная оплата.

    ОтветитьУдалить
  6. вместо классических ТЗ мы уже достаточно давно используем концепты: пишется быстрее, не на столько детализирован, но декомпозиция технически грамотная. сейчас ещё к концепту стали добавлять мокап, а в совсем сложных ситуациях предлагаем функциональный прототип (но пока не делали). заказчику с мокапом и понятным описанием легче добавить в задачу всё, что забылось в процессе обсуждения, а нам легко дать стоимость и подобрать команду разработчиков. не спасает ото всех проблем, потому что от шизанутого заказчика ничего иногда спасти не может, но всё же не чистый Agile, на капельку больше предсказуемости.
    забыл сказать, что концепт и мокапы делаются за отдельные деньги, поэтому не все проекты так получается выполнить - не все готовы платить за проработку задачи, а не за её непосредственное решение.

    ОтветитьУдалить
  7. То ли в прагматике-программисте или в человеко-месяце как раз и было описано про базу знаний о проекте. Что то теперь осознал, что тогда аутсорса было меньше и делали больше проекты внутренние и продукты - там больше нужно заботиться о проекте и задаче, нежели о том как цену выставить и тылы прикрыть. Так что тут скорее не реинкарнация ТЗ, а старая добрая база знаний о проекте.

    Спасибо за статью, актуально!

    ОтветитьУдалить