Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается «как получится».
Как сказал Генри Шоу «Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи».

 

Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?

 

О чем эта статья?

 

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?».  Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.  В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:  

  • В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
  • Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.

Для начала надо разобраться, какой в действительности вопрос  интересует тех, кто спрашивает «Как разработать техническое задание?»  Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания.   О каких вариантах я говорю:

  • Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной  IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
  • Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную  IT-службу. Решили поступить так:  разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
  • Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
  • IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
    • Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
    • Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
    • Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
    • Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
    • Возможны и другие, реже встречающиеся варианты;

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

  • А почему нельзя разрабатывать Техническое задание всегда одинаково?
  • Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
  • Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
  • Как понять, хорошо составлено Техническое задание или нет?
  • За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли.  Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах.  Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

 Как ни странно, проблемы у всех одинаковые! У всех бывают как успешные документы (и проекты), так и совсем бестолковые  (исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия).  Почему так получается? Именно потому, что цели у проектов бывают разные, как и пользователи этих документов. И, конечно, компетенции непосредственных специалистов не на последнем месте.  В этих двух статьях я попытаюсь  поделиться своим личным  опытом, накопленном  за многие годы. Конечно, получится в сжатом виде, т.к. вопрос достоин целой книги (кстати, идея, а может написать?)…  

Что такое техническое задание?

 

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись.  Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели.  Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что  в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

  • ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
  • ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
  • ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ.  А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем  не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках! И это так. Конечно, есть много отличных (!) трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…

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

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

  • Требования в функциональности;
  • Требования к безопасности и правам доступа;
  • Требования к квалификации персонала;
  • …. И т.д. Вы можете  прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования.  Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома.  Красота!).  Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат  нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания.

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

  1. Требование должно быть понятным;
  2. Требование должно быть конкретным;
  3. Требование должно быть тестируемым;

 

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

 

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

  • на каком языке (в смысле сложности понимания) должно быть написано техническое задание? 
  • Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
  • А что такое техническое  проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

В ответах на эти вопросы кроется очень коварная вещь. Именно поэтому часто возникают споры о достаточности или отсутствии необходимой детализации требований, о понятности документа Заказчиком и Исполнителями, об избыточности, формате представления и т.д. А где вообще граница между Техническим заданием и Техническим проектом?

Так вот:

Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке. При этом может и должна использоваться отраслевая терминология, понятная Заказчику. Никаких привязок к особенностям технической реализации быть не должно. Т.е. на этапе ТЗ в принципе не важно, на какой платформе будут реализовываться эти требования. Хотя есть исключения. Если речь идет о внедрении системы на основе уже существующего программного продукта, то такая привязка может иметь место, но только на уровне экранных форм, форм отчетов и пр. Выяснением и формулированием требований, а также разработкой Технического задания должен заниматься бизнес-аналитик. И  уж никак не программист (если только он не совмещает в себе эти роли, такое случается). Т.е. этот человек должен говорить с Заказчиком на языке его бизнеса.

Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуются техническим специалистам. Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально).  А точнее группа специалистов во главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований.  Что, знакомая ситуация?  И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между  ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично  это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени — это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.

Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

  

А нужно ли вообще техническое задание? А Технический проект?

 

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей  так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так  что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ.  Должен ли с ним знакомиться  Заказчик? Если хочет, почему нет, но настаивать  и утверждать данный документ нет никакой необходимости, он будет только сдерживать и  мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы  и программистами.

Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

 

Формулирование требований к информационной системе. Структура Технического задания

 

Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, т.е. предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса – помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть,  считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий.  По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично!  Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю?  Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

И так, ГОСТ рекомендует следующие разделы:

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

Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.

Раздел 1. общие сведения.

Рекомендации по ГОСТ

Что с этим делать на практике

 полное наименование системы и ее условное   обозначение;

Тут все   понятно: пишем, как будет называться система, ее краткое наименование

шифр темы или шифр (номер)   договора;

Это не   актуально, но можно и указать, если требуется

наименование предприятий   (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;  

указывают,   кто (какие организации) будут работать над проектом. Можно указать и их роли.

Можно   вообще удалить этот раздел (достаточно формальный).

 перечень документов, на основании которых   создается система, кем и когда утверждены эти документы;

Полезная   информация. Тут стоит указать ту нормативно-справочную документацию, которую   Вам предоставили для ознакомления с определенной частью требований

 плановые сроки начала и окончания работы по   созданию системы;

Пожелания   по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в   договорах на работы

сведения об источниках и   порядке финансирования работ;

Аналогично,   как и в предыдущем пункте про сроки. Более актуально для государственных   заказов (для бюджетников)

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

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

 

 

Раздел 2. назначение и цели создания (развития) системы.

Рекомендации по ГОСТ

Что с этим делать на практике

Назначение системы

С одной   стороны с назначением все просто. Но желательно формулировать конкретно. Если   написать что-то вроде «качественно автоматизировать складской учет в компании   Х», то потом можно долго обсуждать результат при его завершении, даже   независимо от хорошей формулировки требований. Т.к. Заказчик всегда может   говорить, что под качеством он имел ввиду нечто иное. В общем, нервов можно   попортить друг другу много, а зачем? Лучше сразу написать примерно так:   «Система предназначена для ведения складского учета в компании Х в   соответствии с требованиями, зафиксированными в данном Техническом задании».

Цели создания системы

Цели – это   безусловно важный раздел. Если уж его включать, то надо уметь эти цели   формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще   исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое   оформление документов менеджером». Что такое быстрое? Это можно потом   доказывать бесконечно. Если это важно, то лучше переформулировать  данную цель так: «Менеджер по продажам   должен иметь возможность оформить документ «Реализация товаров»  из 100 строк за 10 минут». Подобная цель   может появиться,  если, например, в   настоящее время менеджер тратит на это около часа, что слишком много для этой   компании и для них это важно. В такой формулировке цель уже пересекается с   требованиями, что вполне естественно, т.к. при разворачивании дерева целей   (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к   требованиям. Поэтому, увлекаться не стоит.

 

Вообще,   умение выделять цели, формулировать их, строить дерево целей это тема   совершенно отдельная. Запомните главное: умеете – пишите, не уверены – вообще   не пишите. А что будет, если не сформулировать цели? Будете работать по   требованиям, такое часто практикуется.

 

Раздел 3. Характеристика объектов автоматизации.

Рекомендации по ГОСТ

Что с этим делать на практике

краткие сведения об объекте автоматизации или ссылки на документы,   содержащие такую информацию

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

сведения об условиях эксплуатации объекта автоматизации и   характеристиках окружающей среды

Не   актуально для проектов по автоматизации учета

 

Раздел 4. Требования к системе

Рекомендации по ГОСТ

Что с этим делать на практике

Требования к системе в целом.

 

ГОСТ расшифровывает перечень таких требований:

 

  •   требования к структуре и функционированию системы;
  •   требования к численности и квалификации персонала системы и режиму его   работы;
  •   показатели назначения;
  •   требования к надежности;
  •   требования безопасности;
  •   требования к эргономике и технической эстетике;
  •   требования к транспортабельности для подвижных АС;
  •   требования к эксплуатации, техническому обслуживанию, ремонту и хранению   компонентов системы;
  •   требования к защите информации от несанкционированного доступа;
  •   требования по сохранности информации при авариях;
  •   требования к защите от влияния внешних воздействий;
  •   требования к патентной чистоте;
  •   требования по стандартизации и унификации;

 

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

  •   Требования к квалификации. Возможно, разрабатываемая система потребует   переподготовки специалистов. Это могут быть как пользователи будущей системы,   так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное   внимание к данному вопросу нередко перерастает в проблемы. Если квалификация   имеющегося персонала явно недостаточна, лучше прописать требования к   организации обучения, программе обучения, срокам и т.п.
  •   Требования к защите информации от   несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению   доступа к данным. Если такие требования планируются, то их нужно расписать   отдельно, как можно более детально по тем же правилам, что и функциональные   требования (понятность, конкретность, тестируемость). Поэтому, можно эти   требования включить и в раздел с функциональными требованиями
  •   Требования к стандартизации. Если существуют какие-либо стандарты   разработки, которые применимы к проекту, они могут быть включены в   требования. Как правила, такие требования инициирует IT-служба Заказчика.   Например, у компании 1С есть требования к оформлению программного кода,   проектированию интерфейса и пр.;
  •   Требования к структуре и функционированию   системы. Тут могут быть описаны   требования к интеграции систем между собой, представлено описание общей   архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел   или даже отдельное Техническое задание, т.к. эти требования могут оказаться   достаточно сложными.

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

Требования к функциям (задачам), выполняемым системой

Вот он, тот   самый главный и ключевой пункт, который будет определять успех. Даже если все   остальной сделать на отлично, а этот раздел на «3», то и результат по проекту   будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы   и займемся более детально во второй статье. Именно к этому пункту относится   «правило трех свойств требований», о которых я говорил.

Требования к видам обеспечения

 

ГОСТ выделяет такие виды:

  •   Математическое
  •    Информационное
  •   Лингвистическое
  •   Программное
  •    Техническое
  •   Метрологическое
  •   Организационное
  •   Методическое
  •    и другие…

 

На первый   взгляд может показаться, что эти требования не важны. В большинстве проектов   это действительно так. Но не всегда. Когда стоит описывать данные  требования:

  •   Решения   о том, на каком языке (или какой платформе) будет вестись разработка не   принято;
  •   К   системе предъявляются требования мультиязычного интерфейса (например,   русский/английский)
  •   Для   функционирования системы должно быть создано отдельное подразделения или   приняты на работу новые сотрудники;
  •   Для   функционирования системы у Заказчика должны произойти изменения в методиках   работы и эти изменения должны быть конкретизированы и запланированы;
  •   Предполагается   интеграция с каким-либо оборудованием и к нему предъявляются требования   (например, сертификации, совместимости и пр.)
  •   Возможны   другие ситуации, все зависит от конкретных целей проекта.

 

 

Раздел 5. Состав и содержание работ по созданию системы

Рекомендации по ГОСТ

Что с этим делать на практике

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

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

 

 

 

Раздел 6. Порядок контроля и приемки системы

Рекомендации по ГОСТ

Что с этим делать на практике

Виды, состав, объем и методы испытаний системы и   ее составных частей (виды испытаний в соответствии с действующими нормами,   распространяющимися на разрабатываемую систему);

 

Общие требования к приемке работ по стадиям   (перечень участвующих предприятий и организаций, место и сроки проведения),   порядок согласования и утверждения приемочной документации;

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

Но даже   наличие тестируемых требований может оказаться недостаточно при сдаче   системы, если четко не прописан порядок приемки-передачи работ. Например,   распространенная ловушка: система сделана, вполне работоспособна, но Заказчик   по каким-либо причинам не готов в ней работать. Причины эти могут быть любые:   некогда, поменялись цели, кто-то уволился и т.п. И говорит: «Поскольку мы еще   не работаем в новой системой, значит и не можем быть уверены, что она   работает». Так что учитесь правильно выделять этапы работ, способы проверки   результатов по этим этапам. Причем Заказчику такие способы должны быть   понятны изначально. Если они зафиксированы на уровне Технического задания, то   всегда можно при необходимости к ним обратится и подвести работы с передаче.

 

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

 

Рекомендации по ГОСТ

Что с этим делать на практике

Приведение поступающей в систему информации (в соответствии с   требованиями к информационному и лингвистическому обеспечению) к виду,   пригодному для обработки с помощью ЭВМ;

Весьма   важный момент. К примеру, для функционирования системы так, как задумано,   может потребоваться использование каких-либо отраслевых или общероссийских   справочников и классификаторов. Эти справочники должны каким-то образом   появляться в системе, обновляться и правильно использоваться.

 

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

Изменения, которые необходимо осуществить в объекте автоматизации

 

Создание условий функционирования объекта автоматизации, при которых   гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ

Любые   изменения, которые могут потребоваться. Например, в компании отсутствует   локальная сеть, устаревший парк компьютеров, на которых система не   заработает.

 

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

 

Возможно,   что-то упрощалось, а теперь требуется учитывать более детально,   соответственно кто-то должен собирать информацию по определенным правилам.

 

Этот   перечень может быть длинным, смотрите на конкретный случай своего проекта.

Создание необходимых для функционирования системы подразделений и   служб;

 

Сроки и порядок комплектования штатов и обучения персонала

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

 

Раздел 8. Требования к документированию

Рекомендации по ГОСТ

Что с этим делать на практике

Согласованный разработчиком и Заказчиком системы перечень подлежащих   разработке комплектов и видов документов

Наличие   полноценной документации – важная часть результата. Все мы знаем, что   документирование чего-либо трудоемкий труд. Поэтому, необходимо заранее   оговорить с Заказчиком, какие виды документации будут разрабатываться, как   они будут выглядеть (содержание и желательно примеры).

 

Подумайте,  как будут представлены руководства   пользователя.

 

Возможно, у   Заказчика есть принятые корпоративные стандарты, значит надо к ним   обращаться.

 

Игнорирование   требований к документации очень часто приводит к самым неожиданным   последствиям на проектах. Например, все сделано и все работает. Пользователи   тоже умеют работать. Про документацию вообще не договаривались и не   разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров Заказчика,   который даже не участвовал в проекте, но участвует в приемке работ, Вас   спрашивает: «А где руководства пользователя?» И начинает Вас убеждать, что о   наличии руководств пользователя договариваться было и не нужно, это «само   собой» якобы подразумевается. И все, не хочет принимать у Вас работу. За чей   счет будете разрабатывать руководства?    На этот крючок попадали уже многие команды.

 

Раздел 9. Источники разработки

Рекомендации по ГОСТ

Что с этим делать на практике

Должны быть перечислены документы и информационные материалы   (технико-экономическое обоснование, отчеты о законченных   научно-исследовательских работах, информационные материалы на отечественные,   зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и   которые должны быть использованы при создании системы.

Если   честно, это ближе к лирике. Особенно, когда говорят об экономическом эффекте   и пр. вещах, которые объективно посчитать практически невозможно. Т.е. можно   конечною, то это будет скорее на бумаге, чисто теоретически.

 

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

 

И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.

Но вот без главного: функциональных требований ни одно грамотно  Техническое задание не обходится.  Хочу  заметить, что в практике такие Технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится (т.е. он его утвердит). Но вот работать по нему может не получиться, т.е. практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег  именно под Техническое задание, а сделать его надо быстро и не погружаясь в детали. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.

Во второй статье  будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

Вид   требования

Неправильная   формулировка

Комментарий   и как можно было сформулировать

Функциональность

«Сумма затрат должна корректно распределяться по   соответствующим товарам»

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

Конкретное ли это требование?  Не сказано, как должна распределяться   затрата, по сумме, по количеству, равномерно или как-то иначе?

Тестируемое ли это требование? Вроде бы простая   вещь, но как ее проверять, если нет конкретики?

Как можно было бы это переформулировать: «Сумма   затрат, указанная в документе, должна распределиться на все товары, указанные   в данном документе пропорционально стоимости этих товаров». Получилось и   понятно, и конкретно. Как проверить тоже не составит труда.

 

Эргономичность

Программа должна иметь удобный интерфейс

Признаться, под данной формулировкой пришлось   однажды подписаться самому – проблем потом было не сосчитать. Конечно же,   подобных формулировок быть не должно. Тут нет не конкретики, ни возможность   проверить это требование. Хотя, безусловно, понятное (субъективно). Тут   переформулировать никак нельзя, надо подробно расписывать каждый элемент   «удобности», раз Заказчик на этом настаивает. Например:

  •   Строки в документ должны добавляться как по   нажатию на кнопку «Добавить», так и при нажатии на клавиши «insert», а также вводе пользователем   части наименования;
  •   При просмотре списка товаров должна быть   возможность поиска по наименованию, штрихкоду и артикулу;
  •   И пр.

Разграничение прав доступа

Доступ к данным по прибыли должен быть доступен   только финансовому директору

Понятно? Почти. Правда, прибыль бывает разная,   надо уточнить.

Конкретно? Конечно нет.  Как это видится в реализации? Если речь   идет о валовой прибыли, то значит необходимо ограничивать доступ к данным о   стоимости закупки, т.к. в противном случае валовую прибыль вычислить не   составит труда, поскольку  данные о   стоимости реализации известны широкому кругу лиц. К тому, что относится к   правам доступа, надо относиться очень аккуратно. А если у менеджеров по   продажам мотивация построена на валовой прибыли, так эти требования еще и   противоречат друг другу, т.к. менеджеры никогда не смогут это проверить. Если   уж включать такое требование, то нужно указывать конкретные отчеты и объекты   системы, в которых указывать, какая часть данных должны быть доступна   отдельным категориям лиц. И рассматривать каждый такой случай индивидуально.

Производительность

Отчет по продажам должен формироваться за 1   минуту.

Да, понятно. И даже есть конкретное ограничение   по времени: 1 минута. Но не известно, какая детализация при этом   предполагается: по каждому товару, группам товаров, клиентам или как-то еще?

Можно сформулировать примерно так: «Отчет по   продажам в разрезе клиентов с детализацией до каждой товарной позиции (см.   образец) должен выводится не более, чем за 1 минуту при условии, что   количество товаров в выборке не превышает 5000 строк».

 

Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.

Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:

  • Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию.
  • Следует стараться не использовать длинных предложений;
  • Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;
  • Используйте больше схем, графиков, таблиц, рисунков – так информацию воспринимается гораздо легче;
  • Следует избегать таких слов: «эффективный», «адекватный», «простой», «понятный», «быстрый», «гибкий», «улучшенный», «оптимальный», «прозрачный», «устойчивый», «достаточный», «дружественный», «легкий» и др.  Перечень можно продолжать, но, мне кажется идея понятна (попробуйте его продолжить самостоятельно).

 

Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».

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

 

56 Comments

  1. chavalah

    В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается «как получится».

    Как сказал Генри Шоу «Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи».

    Перейти к публикации

    Reply
  2. FE_D_OR83

    Полезно, поставил плюс.

    Reply
  3. romansun

    замечательная статья, спасибо!

    совсем недавно читал примерно на эту же тему на хабре «Документирование по ГОСТ 34* — это просто»

    к сожалению, в 1С все эти темы, я так понимаю, не шибко популярны… используются в основном только в средних и крупных франчах, в проектах, ориентированных на разработку

    Причина, имхо, именно в той самой специфике 1С, которая была затронута в статье — 1С-ник и аналитик, и архитектор, и кодер. В саппорте типовых конфигураций это, действительно, работает. А вот при серьёзной переработке или при полной разработке с нуля оказывается, что 1С-ники не готовы к методикам и схемам разработки, применяемым остальным программистским миром.

    И, что еще хуже, к этому совершенно не готовы заказчики. Сам столкнулся с ситуацией, когда при серьёзной разработке по старому клиенту он пришел в шок, когда узнал, что на разработку только проектной документации придется затратить кучу и кучу времени. «Раньше ничего не документировали и всё было нормально, а сейчас зачем это тогда?». Аргумент, что раньше был саппорт с мелкими доработками, а сейчас целая новая подсистема как-то особенно не проходит…

    Всё это в итоге и приводит к тем самым «легендарным» работодателям, где 20 баз, 15 пользователей, всё переписано вдоль и поперек, программисты меняются раз в два года, документации нет вообще и т.п.

    —-

    Хотелось бы узнать у автора, используете ли вы какие-либо стандартизированные блок-схемы при описании ТЗ и ТП?

    Reply
  4. ValeraEm

    Благодарю за статью, надеюсь на скорое появление второй статьи.

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

    Reply
  5. awk

    (0)+++ Мне бы эту статью, да лет 6 назад. Но я не я если не придерусь:

    Цели – это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел.

    Это раздел как раз то, ради чего вся заваруха устроена. Если можно отказаться от цели, то можно отказаться и от автоматизации. Так как без цели мы получим повышение энтропии системы или говоря простыми словами: «Автоматизация хаоса приводит к автоматизированному хаусу».

    Reply
  6. chavalah

    (2) romansun,

    Хотелось бы узнать у автора, используете ли вы какие-либо стандартизированные блок-схемы при описании ТЗ и ТП?

    Да, конечно используем, и очень много. Я планирую рассказывать об этом в своей рассылке.

    Reply
  7. chavalah

    (3) ValeraEm,

    Тут возможны варианты:

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

    2. Он просто не хочет с Вами работать. Просто так корректно об этом говорит

    3. Вас разводят

    4…. много еще чего может быть.

    Reply
  8. chavalah

    (4) awk,

    Цели — это важно.

    Но с Вашим утверждением не соглашусь, т.к. конкретные требования можно тоже назвать целями. Например, раздела целей нет, но в требованиях четко прописано, по какому алгоритму должна считаться себестоимость продукции, как она нужна директору. Если это требование реализовано, то это не автоматизация хаоса, это хороший результат. А раздела «Цели» в таком ТЗ могло и не быть 🙂

    Reply
  9. Mistrall

    Хорошая статья. Правильная. Плюсую.

    Reply
  10. sam41

    Статья безусловно полезная, написана интересно. Только слова «И так» и «по началу» здесь всё-таки являются наречиями и должны писаться слитно.

    Reply
  11. tristagram

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

    Reply
  12. ta44ik

    Если проектированием (написанием ТЗ) и собственно разработкой занимаются больше одного человека — а во франчах именно так, то ТЗ нужно 2. Первое — на языке, доступном заказчику, и второе — на языке, доступном программисту-кодеру. В противном случае кодеру придется вникать во все тонкости механизмов ведения учета заказчика, а это во-первых не всегда возможно физически — бывает что кодируют по десятку проектов одновременно — а во вторых потребует как минимум столько же времени, и родит столько же вопросов, сколько задавал клиенту человек, пишуший ТЗ.

    Reply
  13. awk

    (7) Я конечно понимаю, что предмет обсуждения субъективный, но не соглашусь. Постановка целей и определение их приоритета — это важный этап планирования. Более того, без него само планирование теряет смысл. В 90% организаций системы автоматизации разбухают по геометрической прогрессии, дополняясь не нужным функционалом. А ведь 60-80% доработок — это разработки носящие разовый характер или разработки под конкретного человека (не сотрудника).

    Кто ставит цели? И кто выдвигает требования? В правильной организации — это разные люди. Цели ставит руководство, а требования выдвигает линейный персонал. Другой вопрос: «Есть ли правильные организации в России?», но это не вопрос создания ТЗ.

    Проект — это вектор, который имеет величину и направление. Цель — это направление вектора, а требование — это ограничение его величины. Без направления нет вектора, нет и проекта.

    Reply
  14. alika

    Статья интересная, полезная, спасибо.

    Reply
  15. dk410

    Большое спасибо! Очень интересная статья! Считаю, что техническое задание очень даже необходимо.

    С нетерпанием жду вторую часть! ))

    Reply
  16. chavalah

    (11) ta44ik,

    Думаю, Вам стоит еще раз прочитать:)

    те два ТЗ, о которых Вы говорите, одно для программиста, второе для Заказчика называются Технический проект и Техническое задание.

    В простейших случаях их объединяют.

    Reply
  17. chavalah

    (12) awk,

    Сказал-то как красиво, сразу видно, что человек «в теме». Все так и есть на 100%.

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

    И в этом случае раздел «Цели» можно упустить:))

    Направление можно и создать, если нужно.

    Reply
  18. awk

    (16)

    И в этом случае раздел «Цели» можно упустить:))

    Направление можно и создать, если нужно.

    Полностью согласен. Если воспринимать заказчика как контрагента, то цели его нас волновать не должны. У нас есть свои (погреться за счет теплоотдачи клиента). Или переводя на русский: «Любая прихоть за ваши деньги». Здесь, мы помня треугольник проектирования: Деньги-Функционал-Время должны наращивать функционал, для максимизации прибыли.

    Вот только такой подход гарантирует на 100% потерю клиента.

    Это выгодно или нет?

    Ответить на данный вопрос можно только в конкретной ситуации. А точнее проанализировав рынок наших услуг.

    Вариант 1. Клиентов много, тренд имеет положительный наклон. Безусловно выгодно. Так как затраты на привлечение новых клиентов <= затратам, на удержание старых.

    Вариант 2. Клиентов мало, тренд имеет отрицательный наклон. Безусловно не выгодно. Так как затраты на привлечение новых клиентов >= затратам, на удержание старых.

    На сформировавшихся рынках мы обычно видим отношение затрат на привлечение к затратам на удержание 4:1, так что отношения «Клиент есть контрагент» становится не выгодным. И требуется перейти к отношению «Клиент есть партнер». А данное отношение характеризуется не прибылью нашей, а прибылью общей. Так что говоря по русски: «Рука руку моет».

    Reply
  19. romansun

    (11)

    ну, собственно, так и написано:

    Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке.



    Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании.

    Или, примерно так: техническое задание — это BRD, технический проект — это FSD (FRD)

    Вот такую схему можно в пример привести еще http://www.gramant.ru/HowWeWork/Analysis (не реклама :), к конторе отношение не имею)

    Reply
  20. new_user

    Александр, спасибо за статью! С нетерпением буду ждать вторую часть! Сам пытался писать тех. задание, а в результате убил зря время, так и работаю без тех. заданий, может с Вашей помощью научусь!?! Удачи!

    Reply
  21. adhocprog

    Спасибо за статью!

    Reply
  22. chavalah

    (17) awk,

    И требуется перейти к отношению «Клиент есть партнер».

    Правильно, зрелый бизнес так и должен работать. Заметил такую вещь: когда я говорю клиентам (новым/потенциальным), что относимся к ним как к партнерам и заинтересованы в их прибыли, они смотрят какими-то странными глазами — явно не вярят!

    Reply
  23. chavalah

    (19) new_user, я особо на роль учителя не претендую, но полезного точно для себя найдете.

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

    Reply
  24. chavalah
    Или, примерно так: техническое задание — это BRD, технический проект — это FSD (FRD)

    (18) romansun,

    прочитал эту статью. Вы аналогию не совсем правильно провели.

    То, что там названо FSD (функциональные требования), это как раз и есть Техническое задание.

    А то, что названо Бизнес-требованиями (BRD) это то, что предшествует Техническому заданию, т.е. по сути может являться его частью, либо быть отдельным документом, типа «концепции».

    А про техничское проектирование у них ничего не сказано. Думаю потому, что стиль изложения ориентирован на клиентов, а им это неинтересно. Или, как вариант, эта команда как таковым техническим проектированием не занимается, т.к. пишут системы «с нуля» и практикуют SCRUM и XP, о которых, кстати, я упоминал в статье:)

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

    Reply
  25. awk

    (21)

    смотрят какими-то странными глазами

    Подвоха ждут. Вы же не успев познакомиться уже замуж зовете. А как же конфетно-букетный период? Выбор платья, ресторана, куда в медовый месяц поехать и т.д. :)))

    Reply
  26. USER--1C

    Заказчик не любит ТЗ — это время, которое надо оплатить, это записанные требования. Часто в ходе работы заказчик выдвигает новые требования, пожелания. При этом заказчик не считает новые пожелания новым заданием, которое должно отдельно оплачиваться. Поэтому заказчик не хочет фиксировать свои требования в ТЗ. А нечетко поставленная задача имеет плохие последствия: заказчик считает что не выполнены его мечты и невысказанные мысли, а разработчик считает, что если нет особых требований — главное чтобы работал основной функционал.

    Reply
  27. chavalah

    (25) USER—1C,

    Это ловушка, в которую попадает много внедренцев. Надо уметь управлять такой ситуацией.

    Мысли фиксировать тоже надо. Но главное — это зафиксировать те критери, по которым можно будет понять (всем сторонам), что проект выполнен. Это не означает, что после этого не может быть следующего этапа (или нового проекта), в который войдут новые требования и новые цели.

    Иначе, если вписаться в проект «хотим все наши ожидания» за столько-то денег (фиксированный бюджет) — 100% будет убыточный проект.

    С таким Заказчиком тоже можно работать, но он должен понимать, что бюджет в таком случае открытый, какой он будет неизвестно (нет требований — нет бюджета), и работать по принципу «сделали работу — оценили, оплатили». Как правило, очень быстро Заказчик захочет зафиксировать требования.

    Reply
  28. zhenia74

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

    Reply
  29. awk

    (27) zhenia74, Без ТЗ нет проекта. Сначала ТЗ, потом проект. Тут получается вопросы:

    1. Если на этапе составления ТЗ клиент решает остановится, кто должен нести убытки?

    2. Если на этапе составления ТЗ мы понимаем, что проект не реализуем. (Пример: нарисовать семь красных линий, две синие.) Кто должен оплатить работу?

    Reply
  30. chavalah

    В связи с интересом опубликовал вторую часть.

    Reply
  31. juker

    ТЗ, в широком его понимании подразделяется на три вида:

    1. Крупный, модульный проект.

    2. Один модуль.

    3. Пояснительная записка.

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

    В первом случае описывается общая концепция типа — автоматизация розничной торговли сети торговых точек. Здесь подразумевается три модуля: центр, торговая точка, агрегация данных. Думаю тут все понятно с дальнейшим составлением ТЗ.

    Во втором, на выше приведенном примере — торговая точка в единственном экземпляре. 🙂

    В третьем — необходим рабочий стол продавца.

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

    Телефонные ТЗ — забудьте об их существовании. Пусть обзовут бюрократом поначалу, потом скажут — профессионал! 🙂

    Reply
  32. chavalah

    вторая часть тут

    Reply
  33. chavalah

    (30) juker, ничего не понял, кому ты написал, причем тут телефон и причем тут почта?

    Типа сам себя спросил и сам себе ответил? :))

    Reply
  34. juker

    (32)

    )) Ты совершенно правильно понял написанное. Это не вопрос, а по теме из собственного опыта.

    Reply
  35. chavalah

    (3) ValeraEm, (5) (14) dk410,

    кто интересовался продолжением, можно ознакомиться!

    Reply
  36. AlekseiLeit

    спасибо за статью! как говорится научный взгляд с чем сталкиваешься почти каждый день, и на многие моменты

    не обращаешь внимания..

    Reply
  37. chavalah

    Как и обещал, анонсирую семинар на данную тему: про семинар

    Reply
  38. Aleksey.z

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

    Reply
  39. borrman

    (28) И какие ответы на эти вопросы?

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

    Пример работы (все касается 1С, бывает ли такое с другими системами — не знаю):

    Все ТЗ (и что особенно неправильно — важный пункт о критериях приемки работ) фиксировалось общими фразами в приложении к договору (вне зависимости от сложности проекта — без ТЗ это просто «финиш»!) и при сдаче работ зачастую возникали разночтения : например, «Разработать отчет по оборотам товара на складе». Все. Т.е. ТЗ — общее описание функционала, которое не содержит критериев описанных в статье:

    Требование должно быть понятным;

    Требование должно быть конкретным;

    Требование должно быть тестируемым;

    На его разработку идет времени не больше 5-6 часов (ну на особо сложных проектах выделялось больше времени на согласование проекта с заказчиком — 8-12 часов).

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

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

    Reply
  40. borrman

    Забыл — однозначно (+). Сейчас перевожу работу полностью на ТЗ + ТП. За статью огромное спасибо!

    Reply
  41. awk

    (39) borrman, У меня два последних проекта проходят: «У вас есть ТЗ? Конечно. А можно его посмотреть? Сейчас я тебе его расскажу, оно у меня в голове.» Не надо наверное объяснять куда идут проекты.

    не включая ТЗ в стоимость (ну и не составляя его толком)

    Я его то же не выделяю. Оно размазывается по стоимости проекта в целом.

    Заказчик не захочет платить за ТЗ

    Пока он не хочет — это не заказчик. Это хотельщик. Пусть пройдется по конкурентам. Обломает копья. Если не станет адекватным, то и не нужен он. На такого «клиента» затрат больше, чем отдача от него.

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

    Reply
  42. borrman

    (41)

    А с этим как боретесь:

    если в процессе разработки у Заказчика меняется бизнес-схема так, что половина ТЗ уже не актуальна? Такое может быть или это ошибка аналитиков? И если часть проекта уже готова, то кто должен издержки оплачивать?
    Reply
  43. dimonsky

    Отличная статья, спасибо автору.

    Reply
  44. tango

    о! давно собирался почитать. ладно, не сейчас. как бы это в закладки добавить?

    **

    спасибо, улыбнуло:

    Reply
  45. beigka

    Статья понравилась, спасибо)

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

    Часто заказчик не берет на себя ответсвенность за то что не вся информация предоставлена и не все решения приняты — по организации справочной информации, по учетной политике, или что озвученные решения не соответсвуют действительности…

    И тут уже нужна способность убедить и опыт аналитика.

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

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

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

    Reply
  46. denn15

    Интересная статья.

    Reply
  47. Evgen.Ponomarenko

    (7)

    Отличная статья! Поддержу (12) awk по поводу целей. Нет, конечно, если ты Профи в проектном управлении, то раздел «Цели» можно и опустить. НО… для возможности сделать «контрольный в голову» наличие «точки прицеливания» приветствуется 😉

    Не открою секрета, что цели бывают декларируемые и действительные. Определить на сколько они соответствуют,

    друг другу можно только по действиям. В нашем случае на эту роль могут играют требования. Часто сталкиваешься

    с тем, что декларируемые цели не соответствуют поставленным задачам, и хорошо, если данная проблема выявляется

    в начале пути.

    Хотелось бы процитировать автора статьи «Сам проект автоматизации не решает проблем бизнеса – помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть, считая, что если купят программу, то наступит порядок в хаотичном бизнесе.»

    Обычно такие заблуждения выявляются во время формулирования Целей Заказчиком, если он не лукавит, конечно ;))

    Таких руководителей особенно раздражает безобидный вопрос «С какой целью?».

    Так, что для новичков раздел «Цели» можно рекомендовать как обязательный.

    В любом случае, спасибо автору за доставленное удовольствие.

    Reply
  48. Sintson

    Зеленка в актив!

    Многое знал (понял на собственном опыте), о чем — то догадывался, но так стройно выстроить подход к реализации ТЗ и ТП не мог, статья внесла порядок в понимание проблемы.

    Пошел читать вторую часть, автору успеха и новых статей подобного качества!

    Спасибо.

    Reply
  49. chavalah

    (48)Спасибо за отзыв,

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

    Reply
  50. dimetra2008

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

    Reply
  51. hiduk

    Статья понравилась. Интересно было бы почитать, в Вашем изложении, и так же подробно, о других этапах проекта. Вы упомянули о книге. Думаю это будет востребованная вещь, если она будет написана в том числе в контексте проектов 1С. У Вас на сайте есть статьи, которых нет здесь. Думаю, они будут интересны для местной аудитории.

    Reply
  52. chavalah

    (51) hiduk, Спасибо за отзыв. Да, книга в планах есть, она не отменилась, но пока приостановилась.

    С одной стороны, нет времени, с другой как раз есть вопрос по поводу «востребованности».

    Хотя мне бы в свое время такая книга очень помогла. Она будет действительно интересной.

    Reply
  53. -=blackhawk=-

    А вот интересно, каково должно быть соотношение в работе общения и работы с информацией у аналитика?

    Reply
  54. chavalah

    (53) -=blackhawk=-, из практики где то от 1:1 до 1:4 (общение/обработка) в зависимости от сложности задачи и требований к документированию на проекте.

    Reply
  55. Kamikadze

    (54) думаю, что вы правы. Соотношение конечно сильно может меняться в зависимости от стадии проекта, но в целом гте-то пополам.

    Reply
  56. acanta

    Спасибо за интересную статью.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *