vit_r (vit_r) wrote,
vit_r
vit_r

Про техзадание и его призраков

В принципе, блог этот не для подобных целей, но недавно вопрос всплыл, так что коротко

Техзадание (aka Requirements Specification, aka Pflichten-/Lastenheft и т.п.) - это понятное обеим сторонам актуальное, удобное и достаточное описание необходимых заказчику результатов работы исполнителя.

Это не вся правда, но основная её часть.

Актуальность означает постоянные изменения и уточнения, достаточность - отсутствие дыр, а удобство гарантирует то, что люди будут это использовать. (Кстати, именно насчёт удобства у меня идут основные споры с теоретиками Requirements Engineering)

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

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

Техзадание должно быть адекватно задаче, уровню понимания сторон и объёмам работ. Хотя, набросок на салфетке не вызовет у меня удивления ни в embedded, ни в mission critical: если критерий удобства потерян, люди начинают рыть под завалами документов кротовые ходы. Документы на пять сотен страниц для задачи на два дня работы я тоже видел.

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

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


Картинка (открывается по щелчку здесь. Не надо пытаться открыть новый таб по этой ссылке)"


Тут не видно, так что небольшое добавление: Позеленевшие ветви не удаляются, а сворачиваются. Полное дерево практически только растёт, с редкими удалением, изменением или переносом ветвей. Свёрнутые ветви иногда исправляются (скажем, была найдена ошибка), но потребность в этом возникает очень редко.
Tags: freelancer, gtd, it, management, qa, quality, re, ru
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 7 comments