Как писать полезное ТЗ на ПО по ГОСТ 19.201

Ниже ключевые тезисы с одноименного семинара, который прошел 30.03.2017.

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

Огромное число легенд, заблуждений, ярких находок и обманутых ожиданий связано именно с ТЗ. Хорошее ТЗ помогает всем ролям в команде лучше выполнять свою работу. Перефразируя известное выражение, можно сказать: «хорошее ТЗ — половина успеха проекта, плохое — половина провала».

На прошедшем семинаре мы обсуждали вопросы написания ТЗ с применением стандарта ГОСТ 19.201-79. Что изменилось за, без малого, 40 лет с момента выхода стандартов серии 19, а что до сих пор актуально и полезно.

Читать далее Как писать полезное ТЗ на ПО по ГОСТ 19.201

Дайте ТЗ

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

Кроме этого рассмотрены вопросы:

  • почему по AGILE можно писать ПО, но нельзя строить успешные системы
  • почему тоже самое можно, но нельзя с командой из «студентов»
  • Как понять, какого рода ТЗ нужно писать в данный момент
  • Сколько можно позволить себе потратить на ТЗ на разных этапах создания ИТ системы или как продать предпроектные аналитические работы
  • Почему проектирования недостаточно и что еще нужно делать, чтобы получить успешную ИТ систему

Читать дальше

Как заказать автоматизацию

Я пишу статью из-за того, что не смотря на относительно солидный возраст отечественного ИТ мы до сих пор не до конца научились развязывать множество больших и маленьких конфликтов, возникающих в трех группах задач на старте большинства ИТ проектов:

  • снижение неопределенности в сроках и бюджете (а значит, и в плане, и в образе создаваемого продукта/системы) от одного-двух порядков до ±10%;
  • выделение бюджета на создание продукта/системы;
  • выбор марок покупных компонентов, поставщиков и исполнителей работ.

На старте проекта заказчик стоит перед громадной неопределенностью: на что (в чью пользу) направить деньги, что при этом надо купить и сколько это будет стоить. В отличие от простых товаров и услуг (наподобие закупок туалетной бумаги или билетов на поезд) в случае большинства ИТ проектов неопределенными являются не только цена и сроки, но и образ результата.

Линейка ГОСТов серии 34 была шагом в верном направлении, однако уже сейчас понятно, что туда надо кое-что добавить.
Практика показывает, что недостаточно простого понимания структуры автоматизированной системы и иерархии продуктов поставки ИТ проекта, недостаточно понимания порядка проектирования ИТ системы с ее первых стадий.
Необходимо понимание полного жизненного цикла ИТ системы/продукта, включая вопросы бюджетирования, выбора покупных компонентов и назначения субъектов на роли.

Читать дальше