Подготовка технического задания для разработки ПО

Любая работа, совер­шаемая по требо­ваниям заказчика и отданная на “откуп” испол­нителю, должна начинаться подго­товкой техни­че­ского задания, разра­ботка ПО, то есть программного обеспе­чения, не является исклю­чением. Говоря иначе, начать разра­ботку ПО можно только после подго­товки грамотного и правильного ТЗ, охваты­ва­ющего все техни­ческие аспекты будущего проекта и пожелания заказавшей работу органи­зации или физиче­ского лица. Рассмотрим действия, необхо­димые для состав­ления правильного документа, который станет основой при написании требуемых программных продуктов.

За работу платят деньги

Подго­товка техни­че­ского задания для разра­ботки программного обеспе­чения требуется для четкого ограни­чения объемов работы, которую предстоит сделать для дости­жения требу­емого результата. Грамотно состав­ленное ТЗ необходимо для предот­вра­щения спорных ситуаций между испол­ни­телем и заказ­чиком, когда последний, к примеру, хочет выпол­нения каких-либо доработок, не входящих в утвер­жденный план мероприятий, основы­ваясь на возникших в процессе деятель­ности предприятия потреб­ностях. Начинать разра­ботку ПО без согла­со­вания всех нюансов предстоящей работы, то есть без состав­ления хорошего ТЗ, попросту нельзя. Это грозит непони­манием сторон и отказом принимать готовый заказ в связи с “неполным” его выполнением.

Как написать хорошее техни­ческое задание?

Чтобы самосто­я­тельно написать хорошее техни­ческое задание по разра­ботке ПО, необходимо обратиться к существующим ГОСТам, а также составить глоссарий — словарь терминов и опреде­лений, фигури­рующих в ТЗ. Это поможет не “утонуть” в много­чис­ленной специ­фи­ческом терми­но­логии, зачастую приме­няемой при описании функци­онала разра­ба­ты­ваемых программных продуктов. Глоссарий служит “мостом” между испол­ни­телем и заказ­чиком ПО, помогающим сторонам правильно понимать друг друга в процессе обсуж­дения деталей проекта и при оконча­тельном утвер­ждении резуль­татов проде­ланной работы.

Этапы подго­товки техни­че­ского задания для разра­ботки ПО

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

1. Цель проекта
Для написания хорошего техни­че­ского задания обяза­тельно требуется поставить конечную цель проекта, то есть охарак­те­ри­зовать, для чего он создается и какой функционал требуется от разра­ба­ты­ва­емого ПО.

2. Функци­о­нальные требования
Вторым этапом стано­вится опреде­ление функци­о­нальных требо­ваний, которые, в отличие от специ­фичных, описывают как бы внешний “вид” итога работы. То есть содержат описание действий или функций, которые требуется получить в итоге разра­ботки, что грубо можно охарак­те­ри­зовать как “при нажатии на кнопку А должно красиво отобра­жаться меню Б”. Для этого можно исполь­зовать функци­о­нальные решения из других программ или проектов, уже реали­зо­ванных в коде.

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

4. Критерии приёмки
Определить чёткие критерии приёма работы по произ­во­ди­тель­ности, функци­о­наль­ности, качеству исходного кода.

5. Сроки
Указание сроков на разра­ботку ПО при состав­лении грамотного ТЗ является обяза­тельным пунктом, при этом время, отведенное на выпол­нение работы, должно учитывать некоторый запас. Рассчи­тывать сроки необходимо так, чтобы у испол­нителя была возмож­ность осуществлять разра­ботку программы качественно, без аврального режима работы. Также это требуется для установ­ления границ ответ­ствен­ности, при нарушении которых одна из сторон понесет финан­совые потери, связанные с невыпол­нением взятых на себя обязательств.

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

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

Грамотное ТЗ — залог отличного результата

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

ПОСМОТРИТЕ НАШЕ СЕРВИС ПРЕДЛОЖЕНИЕ 

С чего начать подготовку технического задания | Статьи

Автор статьи: Котенков Сергей Викторович,
руководитель группы разработки ГК «БизнесРешение»

Техническое задание

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

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

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

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

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

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

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

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

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

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

↑

10.2 Композиция TOR

Автор: Warisse Griffith-Charles

Ключевые слова: Условия ссылки, технические требования

Ссылки:

ВВЕДЕНИЕ

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

 

Состав ТЗ

ТЗ обычно состоит из разделов, посвященных следующим пунктам (Махони и Дирден, 2012; Робертс, Хаттри и Вессал, 2011):

1. Зачем реализуется проект
2. Для кого реализуется проект и бенефициары результатов
3. Каковы конкретные цели
4. Каковы объем, подход и методология
5. Кто за какие аспекты будет отвечать
6. Требования к квалификации и опыту подрядчика
7. Четко определить вехи, когда ожидаются результаты, а также когда и как они будут оцениваться
8. Какие ресурсы доступны.
9. Бюджеты

 

1) Почему осуществляется проект

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

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

 

2) Для кого реализуется проект и бенефициары результатов

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

 

3) Каковы конкретные цели

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

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

 

4) Каков масштаб, подход и методология

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

 

5) Кто и за какие аспекты будет нести ответственность

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

 

6) Требования к квалификации и опыту подрядчика

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

 

7) Четкие вехи, когда ожидаются результаты, когда и как они будут оцениваться

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

 

8) Какие ресурсы доступны.

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

 

9) Бюджеты

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

 

Другие аспекты

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

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

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

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

 

Определение реалистичных целей

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

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

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

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

 

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

 

Ссылки

Махони, Дес и Филип Н. Дирден. 2012. Семиэтапный формат подготовки технических заданий на разработку. Центр международного развития и обучения (CIDT), Университет Вулверхэмптона

Робертс, Дон, Нидхи Хаттри и Арианн Вессал. 2011. Написание технического задания для оценки: практическое руководство. Всемирный банк. Вашингтон, округ Колумбия

 

Техническое задание | Государственное развитие, инфраструктура, местное самоуправление и планирование

Если проект объявлен скоординированным проектом, требующим отчета о воздействии на окружающую среду (ЗВОС), инициатор проекта должен подготовить ЗВОС, который содержит:

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

Чтобы инициатор проекта мог сделать это, Генеральный координатор готовит техническое задание (ТЗ), в котором излагаются вопросы, которые инициатор проекта должен решить при подготовке ЗВОС.

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

Консультация

До того, как Генеральный координатор завершит ТЗ для проекта, правительственным консультативным агентствам предлагается прокомментировать, адекватно ли проект ТЗ охватывает все вопросы, которые инициатор проекта должен решить при подготовке ЗВОС.

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

Публичные объявления

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

Период консультаций

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

Конфиденциальность

Генеральный координатор уполномочен собирать личную информацию в соответствии с разделом 29и Приложение 2 к Закону о государственном развитии и организации общественных работ 1971 (Закон SDPWO).

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

Ваша личная информация будет собираться с целью:

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

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

Встречи с консультационными агентствами

В период консультаций Генеральный координатор может организовать встречи между инициатором проекта и консультационными агентствами для:

• объяснить процесс EIS, включая роли агентств
• позволить инициатору обрисовать ключевые элементы проекта, его потенциальное воздействие и возможные стратегии смягчения последствий в ЕИС.

Окончательная доработка ТЗ

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

Сборы

Существуют сборы, связанные с доработкой ТЗ.

Пересмотр ТЗ

Техническое задание может быть пересмотрено, если:

• имеются существенные изменения в концепции или дизайне проекта
• при подготовке ЗВОС возникают новые важные вопросы.

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