Руководства, Инструкции, Бланки

техзадание для тендера образец img-1

техзадание для тендера образец

Категория: Бланки/Образцы

Описание

Техзадание на тендер образец

Скачать техзадание на тендер образец и блейд музыка из фильма

Техническое задание – это раздел в котором определяются требования к результату закупки. Подробную информацию - Образец заполнения Формы 2 или звоните по в тендерах (участие в торгах) - удаленная работа · Техническое задание. Техническое задание (форма 2). целесообразность участия клиента в конкретном тендере. Образец заполнения формы 2 первой части заявки. Тендер - конкурсная форма проведения подрядных торгов; сайта (текст, таблицы и графику сайта) и техническое задание на разработку сайта.

Тендеры. Техническое задание · - Бланк Заявки · - Бланк опросного листа по ПБ, ОТ и ООС · - Перчень документов для участия в тендере. Как правильно составить техническое задание для тендера: пример. Какие требования Образец технического задания можно посмотреть здесь. Техническое задание на проектирование (образец заполнения) затраты на организацию и проведению подрядных торгов (тендеров);; затраты на. Техническое задание на проведение комплекса проектных и ремонтно- строительных работ на объекте по адресу. 23 янв 2015 экологии: Обменяемся опытом - Техническое задание к Тендеру. образцы приказов по экологической безопасности предприятия. Техническое задание разрабатывает контрактная служба заказчика, либо Поскольку на федеральном уровне бланк технического задания не.

27 дек 2010 Контракты по госзакупкам часто достаются организациям дополнения для garrys mod бесплатно и papers please на русском 1 1 67 s. близким к ответственным за это чиновникам. Никто этого не отрицает, даже. Аннотация: С недавних пор на просторах ДДГ оказались десятки попаданцев. К сожалению. Составление Технического Задания для организации тендера на разработку сайта Разработчику предварительное техническое задание нужно для описать — что именно будет делать форма: формировать лид в CRM. На участие в открытом конкурсе. Техническое задание. Примерный образец заявки на участие в открытом конкурсе (конверт №1). УСЛОВИЕ. АО «Банк Русский Стандарт» объявляет о начале проведения тендера по определению контрагента Техническое задание docx (27 КБ). Кориченков. Танки мира. Виртуальная энциклопедия бронетехники от простых бронемашин Первой мировой. группы компаний «Ценный совет» вы найдете подробную информацию - Подготовка.

Техническое задание образец. Качественная подготовка технического задания на закупку является залогом успешного тендера, ведь при проработке. Восточная Европа. Купол ВЗО установлен на здании реактора энергоблока №1 Белорусской АЭС.

Другие статьи

Тендер по защите информации: как подготовить ТЗ

Каждый год компания СКБ Контур проводит конкурс для предпринимателей «Я Бизнесмен », в нем участвуют сотни бизнесменов из разных городов России — от Калининграда до Владивостока.

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

Их опыт и cоветы будут полезны каждому, кто задумывается об открытии своего дела.

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

Тендер по защите информации. Как подготовить техническое задание

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

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

Как правильно подготовить техническое задание к тендеру по информационной безопасности

При подготовке ТЗ для тендера желательно руководствоваться требованиями стандарта ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Документ поможет выстроить четкую структуру технического задания, определить разделы, которые будут заполняться необходимыми требованиями.

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

Техническое задание на тендер, образец (примерная структура) Общие сведения

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

Основание проведения работ. Цели создания системы

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

Зачастую основанием для создания системы выступают требования законодательства. В таком случае необходимо перечислить нормативные документы, в соответствии с которыми система должна быть создана. Например, требования 152-ФЗ «О персональных данных».

В подразделе «Цели создания системы» заказчик приводит характеристики и показатели, которые должны быть достигнуты в результате создания системы. Например, «Защита персональных данных, передаваемых по открытым каналам связи».

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

Общая характеристика информационных систем

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

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

Подробное и качественное заполнение данного раздела позволит исполнителю сформировать оптимальное техническое решение.

Требования к системе защиты информации

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

Общие требования к системе

В подразделе «Общие требования к системе» указывают:

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

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

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

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

Требования к программным средствам

В данном подразделе к программным средствам системы защиты следует указать:

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

В подразделе указываются:

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

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

Порядок контроля и приемки системы

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

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

Требования к исполнителю

Один из завершающих разделов — «Требования к исполнителю».

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

Требования по гарантийному сопровождению

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

Требования к документированию

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

Например, документы должны быть предоставлены в печатном виде на бумажном носителе и в электронном виде, записанные на носитель CD-Rom, DVD-Rom.

Какие ошибки чаще всего встречаются при подготовке ТЗ

Заказчик не знает, на основании какого документа подготовить техническое задание.

За основу можно взять ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» и наполнить документ необходимым материалом.

В разных местах одного и того же технического задания идут противоречия.

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

Сжатые сроки выполнения технического задания.

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

Мы рекомендуем заказчикам при подготовке ТЗ обращать больше внимания на раздел «Состав и содержание работ». В этом пункте можно детализировать работы и разбить их на отдельные этапы, провести анализ сроков выполнения каждого из этапов. Это позволит получить более объективную картину по срокам выполнения всего ТЗ.

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

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

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

При подготовке ТЗ на работы / услуги часто встречаются варианты, когда не зафиксирован четкий перечень работ / услуг, не определены результаты оказания работ /услуг.

В таких случаях вероятны конфликты между заказчиком и исполнителем, поскольку оказанные исполнителем услуги или работы не будут соответствовать ожиданиям заказчика. Чтобы этого не произошло, заказчику при подготовке ТЗ необходимо больше внимания уделять разделам «Основание проведения работ. Цели создания системы» и «Состав и содержание работ». Практика показывает, что лучше разбить работы на отдельные этапы. Описать требования к каждому из этапов, зафиксировать сроки выполнения и результаты работ по каждому из этапов. Эти действия позволят улучшить контроль за выполнением работ или оказанием услуг.

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

Станислав Шиляев. руководитель проектов по информационной безопасности компании «СКБ Контур»

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

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

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

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

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

  • Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
  • Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
  • Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.

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

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

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

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

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

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

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

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

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

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

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

  • ГОСТ 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 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разграничение прав доступаДоступ к данным по прибыли должен быть доступен только финансовому директоруПонятно? Почти. Правда, прибыль бывает разная, надо уточнить.Конкретно? Конечно нет. Как это видится в реализации? Если речь идет о валовой прибыли, то значит необходимо ограничивать доступ к данным о стоимости закупки, т.к. в противном случае валовую прибыль вычислить не составит труда, поскольку данные о стоимости реализации известны широкому кругу лиц. К тому, что относится к правам доступа, надо относиться очень аккуратно. А если у менеджеров по продажам мотивация построена на валовой прибыли, так эти требования еще и противоречат друг другу, т.к. менеджеры никогда не смогут это проверить. Если уж включать такое требование, то нужно указывать конкретные отчеты и объекты системы, в которых указывать, какая часть данных должны быть доступна отдельным категориям лиц. И рассматривать каждый такой случай индивидуально.ПроизводительностьОтчет по продажам должен формироваться за 1 минуту.Да, понятно. И даже есть конкретное ограничение по времени: 1 минута. Но не известно, какая детализация при этом предполагается: по каждому товару, группам товаров, клиентам или как-то еще?Можно сформулировать примерно так: «Отчет по продажам в разрезе клиентов с детализацией до каждой товарной позиции (см. образец) должен выводится не более, чем за 1 минуту при условии, что количество товаров в выборке не превышает 5000 строк».

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

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

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

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

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

Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов. Часть 2

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

Как обычно происходит в жизни:

Решение принято, проекту быть!

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

Провели совещание с руководителями, собрали некоторую информацию об их видении результата.

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

Документирование результатов работы

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

Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».

Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?

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

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

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

Как это может происходить при более грамотной организации работ

Решение принято, проекту быть!

Тут ничего не меняется относительно первого варианта, эмоции никто не отменял

Провели совещание с руководителями, собрали некоторую информацию об их видении результата.

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

Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей

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

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

Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике. Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны.

Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами:

  1. В первую очередь тем, как Вы обучили проектную группу Заказчика. Они должны четко понимать, как происходит процесс анкетирования и уметь донести информацию до всех участников
  2. Сама форма анкет. Анкеты должны быть понятными. Желательно, чтобы была инструкция по заполнению анкет. Еще лучше, если будет пример заполнения.
  3. Состав участников. Необходимо правильно выбрать состав участников. Если ограничиться только руководителями, собрать достоверную информацию не получится. Я рекомендую включать в состав анкетирования всех, кто будет в будущем являться пользователем конечных результатов. Например, если речь идет о внедрении автоматизированной системы, то стоит включить всех, кто будет являться пользователем. Бывают случаи, когда из 10 сотрудников одной должности найдется один, который выполняет какую-нибудь особенную функцию, о которой никто из оставшихся 9-ти больше не знает (например, готовит особый отчет для руководства). Если речь идет о дальнейшем перераспределении обязанностей или разработке должностных инструкций, следует поступить аналогично.

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

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

Выделение ключевых бизнес- процессов или областей автоматизации

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

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

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

Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.

Выделяем бизнес-требование/область автоматизации

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

Детальное изучение бизнес-требования

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

Моделирование требований в информационной системе

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

  1. А что, если планируется разработка новой системы и моделировать попросту не в чем?
  2. Что, если для демонстрации не хватает функциональности, и систему надо дорабатывать?

Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная.

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

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

Демонстрация информационной модели рабочей группе

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

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

Документирование требований в виде Технического задания

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

Дальнейшие действия (или их отсутствие), в зависимости от целей проекта

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

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

Приложение 1. Описанный бизнес-процесс в нотации EPC.

Приложение 2. Вариант использования подсистемы « Заказы»