Пишем техническое задание

История вопроса

Информационный век, как “многим” кажется, только наступает. Могу “многих” разочаровать. Он был всегда.

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

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

Но, мы живем в 21 веке и у нас сейчас “эра автоматизации и информатизации”, т.е. если еще 50 лет назад разработкой различных технических систем занимались только на государственном уровне в НИИ и КБ, то теперь эту задачу решает каждый блогер, малый предприниматель, учитель в школе и даже школьник. То-есть в тысячи раз увеличилась востребованность в специалистах из этой области. Но, те кто вступают на этот путь, путь проектирования технических и автоматизированных систем, часто совершают одни и те же ошибки.

Ошибки при создании техничекого задания

— ТЗ не нужно, разработчик умный сам во всем разберется, расскажу свою идею, а он обязательно сделает.

— ТЗ напишет разработчик сам. Он специалист, напишет сам себе ТЗ и сам по этому ТЗ сделает работу.

— ТЗ на 2-3 страничках с описанием моих хотелок. Я все равно ничего не понимаю в технических нюансах, мне важен конечный результат.

— ТЗ напишет мой знакомый, он работает программистом, знает как пишутся программы.

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

Конечно, таких ошибок гораздо больше и все их не перечислить. Но я пройдусь по этим 5-ти основным, в которых многие читатели увидят свое отношение к написанию ТЗ. Или отношение вашего начальника, который поручил вам создать автоматизированную систему и считает, что создать ТЗ может любой, кто окончил технический ВУЗ.

Работа над ошибками

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Межгосударственный  стандарт.

Информационные технологии

Призыв “Руководствоваться ГОСТами” звучит многообещающе, но поверьте, это та редкость, когда в Госте написали то, что действительно нужно и очень подробно и исчерпывающе.

ТЗ не нужно, разработчик умный сам во всем разберется, расскажу свою идею, а он обязательно сделает.

Разработчик умный, все верно, только людям свойственно видеть мир по своему и в своих красках.

ТЗ напишет разработчик сам. Он специалист, напишет сам себе ТЗ и сам по этому ТЗ сделает работу.

Техническое задание на строительство дома:"

— Заложить фундамент

— Возвести стены

— Поставить крышу

— Настелить пол

— Покрыть кровлю

— Вставить окна

Утверждаю: СТРОИТЕЛЬ ДОМА

Получите

Я утрирую. Но я часто пишу ТЗ для компаний разработчиков и у нас копья ломаются на разделе: Требования к приемке продукта. Почти все в один голос заявляют: “Но это же нам сдавать”. “Давайте этот раздел опустим”.

Это жизнь.

ТЗ на 2-3 страничках с описанием моих хотелок. Я все равно ничего не понимаю в технических нюансах, мне важен конечный результат.

Этот раздел отчасти можно сравнить с предыдущим.

Когда хочется сделать подешевле, всегда получается подороже или не получается ничего.

Разработка программного обеспечения — это очень сложный и трудоемкий процесс и особенно когда вы решили сделать подешевле и приглашаете фрилансера, у вас не много шансов, что его команда укомплектована постановщиками задач, аналитиками и тестировщиками. Как правило все это выполняется в одном лице.

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

ТЗ напишет мой знакомый, он работает программистом, знает как пишутся программы.

Знакомые — это святые люди. За ваши деньги, с любыми скидками и только для вас, сделают все, что захотите.

А это перечень только разделов для создания ТЗ

1. общие сведения;
2. цели и назначение создания автоматизированной системы;
3. характеристика объектов автоматизации;
4. требования к автоматизированной системе;
5. состав и содержание работ по созданию автоматизированной системы;
6. порядок разработки автоматизированной системы;
7. порядок контроля и приемки автоматизированной системы;
8. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу автоматизированной системы в действие;
9. требования к документированию;
10. источники разработки. документы и информационные материалы (ТЭО, отчеты о законченных НИР, материалы на системы-аналоги и пр.)

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

Считаем экономику.

Вспоминаю свой личный опыт. При своем техническом образовании, 2 недели изучение ГОСТов, минимум 3-4 ТЗ с пинками от заказчика и работа в четверть от реальной стоимости, а оказывается к этому нужно еще знания по описанию бизнес-процессов, стандарты BPMN, IDEF и т.д. Плюс четкое понимания всего цикла разработки программного обеспечения, технологии его эксплуатации, тестирования, доработки и развития… — ребята, это годы опыта!

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

Этот раздел отправляет вас прочитать предыдущую фразу в рамочке.

Основная задача ТЗ — это удовлетворить всех и снять разногласия и недопонимания. Когда вы разговариваете с человеком, говорящем на другом языке, вы приглашаете переводчика, который говорит на обоих языках и тогда у вас будет взаимопонимание.

Создание ТЗ — это работа переводчика, который сможет сделать перевод вашей идеи на язык разработчика, а разработчику поможет объяснить, что от него будет требовать заказчик, когда настанет время сдавать задачу.

В итоге: Мир, Любовь и Взаимопонимание. А также дружба на многие годы.

Сколько раз вы меняли разработчиков? Сколько раз вы пренебрегали написанием хорошего ТЗ? Задайте себе эти вопросы и у вас могут родиться ответы, почему же так с программистами сложно работать?

Мой план по созданию ТЗ

— интервью с заказчиком, обсуждение и структурирование его идеи.

— изучение прототипов и конкурентов

— составление функциональной схемы автоамтизированной системы и выявление участников и объектов автоматизации

— согласование с заказчиком перечня разрабатываемых функций и уточнения требований к выполняемым функциям

— написание ТЗ и формирование рекомендаций для выбора разработчика

— (по желанию заказчика) сопровождение разработки в соответствии с ТЗ, приемка работы

— (по желанию заказчика) разработка полного комплекта документации на разработанную автоматизированную систему:

1. Формирование требований к АС
   • Обследование объекта и обоснование необходимости создания АС
   • Формирование требований пользователя к АС
   • Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС
   • Изучение объекта
   • Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя
   • Оформление отчета о выполненной работе
3. Техническое задание
   • Разработка и утверждение технического задания на создание АС
4. Эскизный проект
   • Разработка документации на АС и ее части
5. Технический проект
   • Разработка документации на АС и ее части
   • Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (ТЗ) на их разработку
6. Рабочая документация
   • Разработка рабочей документации на систему и ее части (руководство пользователя, руководство администратора)
7. Ввод в действие
   • Обучение персонала
   • Проведение предварительных испытаний
   • Проведение опытной эксплуатации и сбор обратной связи
   • Проведение приемочных испытаний
8. Сопровождение документации по АС
9. Оформление функционального описания АС для сдачи в Минцифры (подготовка полного пакета)

• ←Предыдущая
• Следующая→