Про техзадание и его призраков
Jun. 1st, 2012 12:22 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rВ принципе, блог этот не для подобных целей, но недавно вопрос всплыл, так что коротко
Техзадание (aka Requirements Specification, aka Pflichten-/Lastenheft и т.п.) - это понятное обеим сторонам актуальное, удобное и достаточное описание необходимых заказчику результатов работы исполнителя.
Это не вся правда, но основная её часть.
Актуальность означает постоянные изменения и уточнения, достаточность - отсутствие дыр, а удобство гарантирует то, что люди будут это использовать. (Кстати, именно насчёт удобства у меня идут основные споры с теоретиками Requirements Engineering)
Десять томов подробнейшего текста, который никто не читает, - это эмуляция, а не техзадание, а вот пошедшие в работу разговор с заказчиком в коридоре или набросок на салфетке быть техзаданием могут.
Устаревшее описание функций и качеств - это архивные материалы. Не понятные пользователю UML диаграммы и туманные измышления о желаемых функциях - запасы для грядущих споров и судебных тяжб. Записки на манжетах и карточки с обрывками текста в agile - это тоже не техзадание, потому как всё это без скомпилированного и запущенного кода не обладает ни свойством понятности, ни свойством полноты, да и актуальность заменяется на истерическое придумывание.
Техзадание должно быть адекватно задаче, уровню понимания сторон и объёмам работ. Хотя, набросок на салфетке не вызовет у меня удивления ни в embedded, ни в mission critical: если критерий удобства потерян, люди начинают рыть под завалами документов кротовые ходы. Документы на пять сотен страниц для задачи на два дня работы я тоже видел.
Стоящая ниже картинка - это состояние техзадания в текущем проекте за два рабочих дня. Как, что и зачем - объяснять долго, и надо начинать с описания потока микрозаданий, которое валяется где-то в архивах ньюсов пятнадцатилетней давности. Так что это просто картинка для общего впечатления.
Не смотря на лаконичность и необычность формы, это на самом деле техзадание, которое однозначно переводится в документ привычного вида (и наращивается добавлением воды до любого объёма), которое масштабируется вверх на коллектив или субподрядчиков и которое простым переносом порождает план проекта. Правда, при любом из этих действий непропорционально растёт сложность восприятия и обслуживания. Впрочем, об этом уже в другой раз.
Картинка (открывается по щелчку здесь. Не надо пытаться открыть новый таб по этой ссылке)"
Тут не видно, так что небольшое добавление: Позеленевшие ветви не удаляются, а сворачиваются. Полное дерево практически только растёт, с редкими удалением, изменением или переносом ветвей. Свёрнутые ветви иногда исправляются (скажем, была найдена ошибка), но потребность в этом возникает очень редко.
Техзадание (aka Requirements Specification, aka Pflichten-/Lastenheft и т.п.) - это понятное обеим сторонам актуальное, удобное и достаточное описание необходимых заказчику результатов работы исполнителя.
Это не вся правда, но основная её часть.
Актуальность означает постоянные изменения и уточнения, достаточность - отсутствие дыр, а удобство гарантирует то, что люди будут это использовать. (Кстати, именно насчёт удобства у меня идут основные споры с теоретиками Requirements Engineering)
Десять томов подробнейшего текста, который никто не читает, - это эмуляция, а не техзадание, а вот пошедшие в работу разговор с заказчиком в коридоре или набросок на салфетке быть техзаданием могут.
Устаревшее описание функций и качеств - это архивные материалы. Не понятные пользователю UML диаграммы и туманные измышления о желаемых функциях - запасы для грядущих споров и судебных тяжб. Записки на манжетах и карточки с обрывками текста в agile - это тоже не техзадание, потому как всё это без скомпилированного и запущенного кода не обладает ни свойством понятности, ни свойством полноты, да и актуальность заменяется на истерическое придумывание.
Техзадание должно быть адекватно задаче, уровню понимания сторон и объёмам работ. Хотя, набросок на салфетке не вызовет у меня удивления ни в embedded, ни в mission critical: если критерий удобства потерян, люди начинают рыть под завалами документов кротовые ходы. Документы на пять сотен страниц для задачи на два дня работы я тоже видел.
Стоящая ниже картинка - это состояние техзадания в текущем проекте за два рабочих дня. Как, что и зачем - объяснять долго, и надо начинать с описания потока микрозаданий, которое валяется где-то в архивах ньюсов пятнадцатилетней давности. Так что это просто картинка для общего впечатления.
Не смотря на лаконичность и необычность формы, это на самом деле техзадание, которое однозначно переводится в документ привычного вида (и наращивается добавлением воды до любого объёма), которое масштабируется вверх на коллектив или субподрядчиков и которое простым переносом порождает план проекта. Правда, при любом из этих действий непропорционально растёт сложность восприятия и обслуживания. Впрочем, об этом уже в другой раз.
Тут не видно, так что небольшое добавление: Позеленевшие ветви не удаляются, а сворачиваются. Полное дерево практически только растёт, с редкими удалением, изменением или переносом ветвей. Свёрнутые ветви иногда исправляются (скажем, была найдена ошибка), но потребность в этом возникает очень редко.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-05-31 11:13 pm (UTC)Это Freemind у Вас?
no subject
Date: 2012-05-31 11:35 pm (UTC)А читаемо не будет, потому как здесь реальные данные, а делать демонстрационный вариант мне лень, да и времени нет.
Впрочем, предыдущие прикидки можно найти по тегу GTD. Просто оказалось, что глаголы не нужны. Описания результата достаточно, а действие из него вытекает однозначным образом (или может быть выбрано по обстоятельствам).