ТЗ на разработку программного обеспечения: подводные камни
Мы разрабатываем программное обеспечение для сложных бизнес-процессов, которые укладывать в рамки готовых продуктов неэффективно. Часто готовых решений нет в принципе.
Как мы работали
- Заказчик описывает проблему и желаемое решение.
- Мы изучаем бизнес-процессы, помогаем составить максимально детальное техническое задание или принимаем готовое.
- Подписываем договор и приступаем к разработке.
- Сдаем продукт с проверкой ТЗ.
Недостатки такого подхода
- Долгое составление ТЗ
Со стороны заказчика проектом руководит собственник бизнеса или руководитель одного из отделов. У них и до этого времени не хватало, а стало ещё меньше. - Ошибки в ТЗ
Заказчик привлекает других сотрудников к обсуждению, но невозможно учесть все моменты без опыта использования нового продукта. - Нет оперативной обратной связи
Компания ждет итоговый вариант продукта.Смотреть на промежуточные результаты не горит желанием.
- Долгий процесс разработки
Между составлением ТЗ и сдачей рабочей версии проходит несколько месяцев. За это время может многое поменяться в компании.
Как стали работать
Совместили итеративную разработку с техническим заданием:
- Согласуем с клиентом общее видение целей, задач, аудитории и приоритетных функций продукта.
- Составляем общее техническое задание без излишней детализации. Для первой итерации готовим более детальное ТЗ.
- Оцениваем ориентировочно стоимость всего проекта и точную для первого этапа, на котором внедряем самые важные функции с учетом проектирования по DDD.
- Приступаем к разработке и максимально быстро сдаем первую версию продукта. Упор на функции, на уровне интерфейса минимализм.
- Собираем обратную связь по доработке или внедрению новых функций.
- Итеративно дорабатываем продукт. При необходимости составляем дополнительные технические задания на крупные итерации.
Ситуация из практики
К нам обратилась компания, с которой мы быстро нашли общий язык. Первый релиз небольшой, но достаточный для погружения в предметную область.
В приложении к договору ТЗ оформляем почти всегда. Исключение — постоянные клиенты, продукт которых развиваем на протяжении многих лет. Однако для новых клиентов ТЗ — обоюдная гарантия выполнения работ.
В этом случае наше ТЗ уместилось на 7 листов с описанием основной функциональности первого релиза с точки зрения бизнеса. Это то, что важно для компании и по чему можно принять работу.
Но со стороны клиента внезапно появились новые требования — ТЗ по ГОСТ со всеми вытекающими: начиная от структуры БД, заканчивая пунктами о разрешении коллизий. От проекта отказались.
Мы не всегда против жесткого ТЗ. Иногда оно нужно. Например, работаем с одним крупным заводом. В проекте много вычисляемых параметров, расчетов и т.д. ТЗ здесь необходимо, без него проект не оценить и не реализовать.
Понимаем требования клиента: формализация проекта желательна. Вдруг с нами что-то не срастется — продукт хотелось бы легко передать другим разработчикам. Но это решается не до мелочей проработанным до начала разработки ТЗ, а документацией после.
По ходу разработки ПО меняется многое. Зачастую клиент сам вносит новые идеи. Кроме того, команда погружена в проект и в предметную область лучше, чем до начала работ. В итоге решения будут более взвешенными, чем при составлении ТЗ для данных и процессов в вакууме.
Техническое задание :: HighExpert.RU
Даже при самом простом техническом задании, как правило, невозможно немедленно заняться его непосредственным решением.
Соврешенно понятно желание сразу по получению техзадания на проектирование устремиться на поиски готовых технических решений, однако это таит в себе опасность оказаться привязанным к некоторому решению, которое хотя и пригодно, но не является лучшим; вследствие же патентной защиты оно может быть и неприемлемым.
При таком методе «скорого» решения о творческой работе не заботятся, хотя профессиональные знания при этом и повышаются. Поэтому всегда разумнее сначала продумать техническое задание, сделать обзор возможных вариантов, привести в порядок собственные мысли и лишь затем приступить к тщательным исследованиям в соответствии с уровнем техники.
Такой приём разумен ещё и потому, что могут возникнуть проблемы, которые в задании не ставятся, а их решение как раз необходимо.
При стремлении быстро получить готовое техническое решение часто упускают продумывание задания, забывая, что анализ его объёма и содержания в большинстве случаев мог бы разъяснить и существенно упроситить его разработку.
Составитель технического задания, который высказывает обоснованные, на его взгляд, обязательные требования, не всегда станет думать о том, что влияет на объём работы и на последующие затраты в производстве оригинальных изделий.
При разработке торцевого уплотнения заполненный опросный лист с указанием требований и рабочих параметров [с дополнительной пояснительной запиской], может приниматься в качестве краткого технического задания на проектирование;
тогда напрашивается ряд вопросов, в частности, что не отражено в тексте техзадания, но необходимо знать.
Относительно необходимости уточнения технического задания не должно быть никаких соменений. На практике такое задание выполняется тем легче, чем лучше оно разработано.
Для выполнения проекта по требованию исполнителя заказчиком должны быть представлены дополнительные данные и материалы для проектирования. При проектировании разрабатывают графические (чертежи, схемы, графики и т.п.) и текстовые (отчёт, пояснительную записку, спецификацию и т.п.) конструкторские документы (КД). Эти документы должны определять состав и устройство проектируемого изделия и содержать необходимые данные для его разработки, изготовления, входного контроля, монтажа [установки], эксплуатации и ремонта.
Согласно ГОСТ 2.102 конструкторские документы подразделяют на определённые виды, номенклатура таких документов должна быть согласована с заказчиком.
Стадия создания конструкторской документации вновь разрабатываемого или модернизируемого изделия, характеризуется литерой документа.
◉ При разработке эскизного проекта по ГОСТ 2.119 документам присваивается литера «Э».
◉ При разработке технического проекта по ГОСТ 2.120 конструкторской документации присваивается литера «Т».
◉ Разработка КД для изготовления опытного образца [опытной партии] серийного или массового производства — без литеры.
◉ Корректировка документации по результатам изготовления и предварительных испытаний опытного образца (опытной партии) серийного или массового происзводства — литера «О».
Читать по теме ⇛ Техническое предложение.
Техническое задание: уроки по их структуре и интерпретации результатов
Lire en francais | Leer en español
Автор: Dr. Issa Sombié/Из Буркина-Фасо. Он научный сотрудник Национального центра научных и технологических исследований и профессор университета. Доктор социологии и обладатель степени магистра в области оценки
Техническое задание (TdR) представляет собой структуру, которая позволяет описать цель, объем и процесс, включая управленческие и технические аспекты, оценки в соответствии с потребностями. тех, кто запрашивает оценку программы или проекта.
Это руководство имеет первостепенное значение в процессах оценки, так как именно на него возлагаются ожидания тех, кто запрашивает оценку. Кроме того, они служат ориентиром для оценщика, поэтому их ясность и точность очень важны.
Часто на отношения между оценщиками и лицом, запрашивающим оценку, влияют отсутствующие, вводящие в заблуждение или двусмысленные элементы технического задания. Обычно в ходе этой разработки реальные потребности программы не находят адекватного отражения.
Далее мы рассмотрим наиболее приемлемые базовые элементы в качестве структуры для использования Технического задания (ToR) и применимой к процессу оценки, согласно Детскому фонду Организации Объединенных Наций (ЮНИСЕФ).
Таблица 1 : Основные элементы структуры Технического задания (ТЗ) ЮНИСЕФ
Содержание основы анализа | 900 05 Описание |
Фон | Презентация программы, ее характеристики, ее эволюция с течением времени, участвующие игроки, национальный и международный фон, а также составляющие ссылки на оценку. |
Цели оценки | Причины оценки, ее дополнительная ценность, а также процесс использования результатов. |
Вопросы и критерии оценивания | Список вопросов, на которые необходимо ответить при оценивании, различные критерии оценивания, которые необходимо учитывать. |
Существующие источники данных | Источники информации имеются и доступны. |
Методология | Различные шаги, подходы и методы сбора данных процесса, чтобы ответить на вопросы. |
Участие игроков, участвующих | Процессы участия всех игроков, участвующих в оценке.![]() |
Ответственность и обязательства вовлеченных игроков | Определение обязательств и ответственности игроков. |
Состав группы по оценке | Описание профилей и навыков оценщиков. |
Бюджет | Общий бюджет и его основные разделы. |
В одном упражнении мы оценим три процесса оценки, в которых использование Технического задания (ТЗ) в различных программах, осуществляемых в Буркина-Фасо в Африке, привело к неоднозначным результатам.
Первый касается оценки программы борьбы с лимфатическим филяриатозом.
СОДЕРЖАНИЕ АНАЛИЗА | ЧТО БЫЛО ПОСТАВЛЕНО |
Исходная информация | 90 025 Включено|
Цели оценки | Включено |
Вопросы и критерии оценки | Не включены |
Существующие источники данных | Не включено |
Методология | Не включено |
Участие вовлеченных игроков | Не включено |
Re обязанности и обязательства вовлеченных игроков | Не включено |
Состав группы оценки | Включено |
Процедуры и логистика | Не включено |
Бюджет | Не включено |
Второй — это оценка программы по ВИЧ/СПИДу, реализуемой местной организацией.
СОДЕРЖАНИЕ АНАЛИЗА | ЧТО БЫЛО ПОСТАВЛЕНО |
Исходная информация | 90 025 Включено|
Цели оценки | Включено |
Вопросы и критерии оценки | Не включены |
Существующие источники данных | Не включено |
Методология | Не включено |
Участие вовлеченных игроков | Не включено |
Re обязанности и обязательства вовлеченных игроков | Не включено |
Состав группы оценки | Включено |
Процедуры и логистика | Не включено |
Наконец, показан процесс оценки программы борьбы с малярией международной НПО.
СОДЕРЖАНИЕ АНАЛИЗА | ЧТО БЫЛО ПОСТАВЛЕНО |
Исходная информация | 900 25 Включено|
Цели оценки | Включено |
Вопросы и критерии оценки | Включены |
Существующие источники данных | Не включено |
Методология | Включено |
Участие вовлеченных игроков | Не включено |
Ответственность и обязательства вовлеченных игроков | Включено |
Состав группы оценки | Включено |
Процедуры и логистика | Не включены |
Из таблиц видно, что различные элементы, предлагаемые аналитической структурой , не всегда учитываются при составлении технического задания. Мы обнаружили, что «исходная информация» не была представлена в трех примерах ТЗ, как это было предложено в рамках анализа ЮНИСЕФ.
«Цели оценки», а также «состав команды» также учитывались в трех примерах, хотя и не совсем так, как предполагает аналитическая схема. Что касается элементов: «существующие источники данных», «вовлечение вовлеченных игроков», «процедуры и логистика» и «бюджет», то они не были разработаны ни в одном из трех примеров.
Наконец, «методология», «оценочные вопросы», «ответственность и обязательства вовлеченных игроков» рассматривались только в одном из трех примеров. Мы отмечаем, что некоторые важные элементы не всегда учитывались.
Благодаря этому краткому анализу технического задания на процесс оценки мы узнали несколько вещей:
Первый урок:
Необходимо уточнить цель и задачи оценки. Точное и подробное описание целей оценки позволит группе по оценке предложить соответствующие методы для удовлетворения заявленных потребностей. Для этого любой, кто запрашивает оценку программы или проекта, должен стремиться установить свои приоритеты с точки зрения ожидаемой информации, а не в соответствии с критериями оценки. Прежде всего, руководители программ должны избегать стандартных формул технического задания, в которых просто меняется название проекта.
Второй урок:
Очень важно составить вопросы для оценки, которые, хотя и не являются исчерпывающими или правильно сформулированными, всегда позволяют команде по оценке лучше понять ожидания и информационные потребности тех, кто запрашивает оценку. С точки зрения оценщика мы склонны говорить, что не бывает неправильных вопросов и что важнее всего знать, что вы хотите найти. Во многих случаях отсутствие навыков оценки скрывает реальную проблему в установлении потребностей, даже выбор вопросов для оценки остается в руках оценщика.
Третий урок:
Хотя сложно требовать стандартной структуры Технического задания, его формулировка должна включать ряд существенных элементов. Мы считаем, что элементы, относящиеся к контексту, цели и задачам оценки, вопросам, критериям и методологии, имеют основополагающее значение для оценщиков при подготовке их технического предложения. Руководителям программ рекомендуется изучить различные руководства в этой области. Перед установлением цели и задач оценки необходимо предусмотреть возможное использование результатов оценки.
Заключение:
Качество оценок во многом зависит от проработанной структуры технического задания. На самом деле сложно дать адекватный ответ на плохо сформулированный вопрос или плохо поставленную проблему.
Этот анализ позволил нам выявить определенные недостатки, которые могут повлиять на техническое задание. Таким образом, мы обнаружили, что цели и вопросы оценки часто мало или плохо определены, что приводит к отсутствию навыков при подготовке ТЗ. Наиболее серьезным является то, что, основываясь на результатах, недостаточное внимание уделяется важности, придаваемой процессу оценки.
Зачем мы проводим оценку? Следует напомнить, что первая цель оценки заключается в поддержке принятия решений. Это означает, что перед ее разработкой игроки уже провели инвентаризацию ожидаемой информации и знают, для чего она будет использоваться.
Однако в контексте управления программами и проектами в Африке мы часто наблюдаем, что оно просто направлено на выполнение положений, изложенных в документе о разработке программы или проекта. Оценка заказана, потому что она уже была запланирована во время разработки проекта, поэтому она должна быть сделана. Это также объясняет редкое использование результатов оценки.
В этих условиях проблема формулирования потребностей в оценке, а также качества ее результатов, вероятно, сохранится.
Что такое масштаб проекта?
ИТ-директор Объем проекта — это часть планирования проекта, которая включает определение и документирование списка конкретных целей проекта, результатов, задач, затрат и сроков. Документация по объему проекта называется описание области применения или техническое задание . В нем разъясняются границы проекта, устанавливаются обязанности каждого члена команды и устанавливаются процедуры проверки и утверждения выполненной работы.
Во время проекта эта документация помогает проектной группе сосредоточиться на задаче. Заявление о содержании также предоставляет команде рекомендации по принятию решений о запросах на изменение в ходе проекта. Обратите внимание, что описание содержания проекта не следует путать с его уставом; устав проекта просто документирует существование проекта.
Большие проекты имеют тенденцию изменяться по мере их выполнения. Если в начале проект был эффективно «распределен», то утверждение этих изменений и управление ими будет проще. При документировании масштаба проекта заинтересованные стороны должны быть как можно более конкретными, чтобы избежать расползания масштаба. Расползание масштаба — это ситуация, в которой одна или несколько частей проекта требуют больше работы, времени или усилий из-за плохого планирования или недопонимания.
Для эффективного управления областью действия требуется хорошая коммуникация. Это гарантирует, что все в команде понимают масштабы проекта и согласны с тем, как именно будут достигнуты цели проекта. В рамках управления содержанием руководитель группы должен запрашивать одобрение и одобрение заинтересованных сторон по мере продвижения проекта, гарантируя, что предлагаемый готовый проект соответствует потребностям каждого.
Важность определения содержания проектаНаписание описания содержания проекта, включающего информацию о результатах проекта, является первым шагом в планировании проекта. Преимущества описания содержания проекта для любой организации, предпринимающей новую инициативу, включают следующее:
- формулирует содержание проекта, чтобы все заинтересованные стороны могли понять, о чем идет речь;
- предоставляет дорожную карту, которую менеджеры могут использовать для назначения задач, планирования работы и бюджета;
- помогает сфокусировать членов команды на общих целях; и
- не позволяет проектам, особенно сложным, выйти за рамки установленного видения.
Определение масштаба проекта гарантирует, что проекты будут сфокусированы и выполнены в соответствии с ожиданиями. Объем обеспечивает прочную основу для управления проектом по мере его продвижения и помогает гарантировать, что ресурсы не отвлекаются и не тратятся впустую на элементы, выходящие за рамки.
Как определить объем проектаДля определения содержания проекта требуется участие заинтересованных сторон проекта. Они работают с менеджерами проектов, чтобы установить ключевые элементы бюджета, целей, качества и сроков.
Чтобы определить объем, менеджеры проекта должны собрать требования к тому, что нужно заинтересованным сторонам от проекта. Сюда входят следующие элементы:
- цель и результаты проекта;
- , когда проект должен быть завершен; и
- сколько заинтересованные стороны могут заплатить за это.
Цель состоит в том, чтобы собрать и записать точную и точную информацию во время этого процесса, чтобы объем проекта отражал все требования. Это повышает шансы руководителей проектов выпускать продукты, отвечающие ожиданиям заинтересованных сторон, в срок и в рамках бюджета.
Описание содержания проекта — это письменный документ, который включает всю необходимую информацию для получения результатов проекта. Это более подробно, чем техническое задание; это помогает команде проекта оставаться сосредоточенной и на задаче. Заявление о содержании также предоставляет руководителю проектной группы или фасилитатору рекомендации по принятию решений о запросах на изменение в ходе проекта.
Описание содержания проекта устанавливает, что не включено в его инициативы, явно или неявно. Цели и задачи, не перечисленные в описании содержания, следует считать выходящими за рамки. Руководители проектов также могут перечислить конкретные работы, которые не будут частью проекта.
Таким образом, это утверждение устанавливает границы проекта. Руководители проекта должны принять эти требования и составить карту того, что должно происходить и в каком порядке эти элементы должны выполняться. Это приводит к созданию структурной декомпозиции работ (WBS). WBS разбивает запланированную работу на более мелкие, определенные части и необходимые задачи.
Четко сформулированное описание содержания является важной частью эффективного управления проектом. Объем проекта должен быть определен для каждого проекта, независимо от того, какой метод управления проектом используется. Заинтересованные стороны проекта должны просмотреть описание содержания проекта, при необходимости пересмотреть его и утвердить.
После завершения и утверждения описания содержания проекта руководители проектов могут назначать задачи и давать своим командам указания о том, что им необходимо сделать для соблюдения установленных сроков, бюджета и целей.
Планирование содержания и управление им Обновления и изменения являются частью процесса управления проектом. По ходу работы менеджеры должны тщательно контролировать, какие изменения вносятся в содержание проекта, и документировать их. Это требует сильных навыков управления проектами.
Процесс управления изменениями также требует, чтобы руководители проектов и заинтересованные стороны придерживались описания содержания проекта. Они должны понимать, какие элементы входят в рамки проекта, а какие запросы выходят за рамки.
Процессы управления изменениями помогают руководителям проектов определить, как оценивать запросы на обновления и изменения в проекте. Различение необходимых запросов и тех, которые выходят за рамки, позволяет организациям избежать расползания области.
Расширение масштаба — это когда к проекту добавляется больше работы, пока он находится в стадии реализации. Это может привести к дополнительным затратам и ненужной работе, отвлекая от целей и угрожая качеству намеченных результатов.
Пример содержания проекта Заявления о масштабах пытаются предоставить ключевым заинтересованным сторонам всю необходимую им информацию. Ниже приведены некоторые элементы, которые должны быть включены в описание области действия:
- Введение. Это определяет что и почему проекта. Примером может быть: «Этот проект по созданию контента и маркетингу осуществляется компанией RealContent Inc. для распространения статей в своем блоге и на сайтах социальных сетей для повышения узнаваемости бренда и увеличения посещаемости веб-сайта».
- Объем проекта. Это определяет требования проекта. Он устанавливает общие цели для графика проекта и задач и определяет, кто будет вовлечен. В примере с созданием контента можно указать: «Проект будет включать в себя исследование, написание, стратегию контента и поисковую оптимизацию, а также публикацию на веб-сайте компании и в профилях социальных сетей в марте 2021 года. Джон Смит, директор по контенту RealContent, будет контролировать эти задачи. Персонал и авторы контрактов создадут результаты».
- Результаты. Раздел результатов определяет, что будет предоставлено в конце проекта, и указывает дату отправки.
В нашем примере «Результаты проекта будут включать хорошо проработанную статью из 2000 слов, которая будет опубликована не позднее 28 февраля 2021 года. тот же срок».
- Критерии приемки. Здесь описываются цели проекта и показатели, которые будут использоваться для оценки успеха. Например, «Основная статья наберет 3000 кумулятивных просмотров страниц в течение шести месяцев после публикации и создаст двух новых лидов».
- Исключения. Описывает то, что не будет включено в проект. Например, «Проекту не потребуется создавать мультимедиа для статей».
- Ограничения. Здесь перечислены жесткие ограничения проекта и вещи, которые нельзя изменить. Ограничения проекта могут относиться к графику проекта, бюджету проекта или техническим проблемам. Например, «Проект имеет точную дату подачи 28 февраля 2021 года и твердый бюджет в размере 5000 долларов США».
Объем проекта не следует путать с объемом продукта. Объем продукта определяет возможности, характеристики, особенности и функции результатов в конце проекта.
Руководители проекта должны создать отдельное описание содержания продукта. Они должны использовать как описание содержания проекта, так и описание содержания продукта, чтобы дополнять друг друга и обеспечивать четкое понимание того, к чему стремится каждый проект.
Еда на выносОпределение содержания проекта — важный шаг в планировании проекта и управлении им. Прежде чем приступить к проекту, менеджеры проекта должны понять, каков объем проекта, чтобы определить, что необходимо сделать, а что выходит за рамки проекта.
Объем проекта определяется в описании содержания, документе, в котором указаны цели, графики, задачи и результаты проекта. Заявления о масштабах согласовывают ожидания заинтересованных сторон и дают проектам основу для успеха.
Как только проект запущен, важно следить за его ходом и в рамках. Различные инструменты и стратегии управления проектами помогут командам в этом.
Последнее обновление: сентябрь 2021 г.
Продолжить чтение О масштабах проекта- 15 основных вопросов для собеседования с менеджером ИТ-проекта
- Проверьте себя по принципам управления проектами Agile
- Удаленное внедрение ERP: 10 основных принципов управления проектами
- Почему проекты терпят неудачу в модели гражданского разработчика
- От общего объема проекта к полному контролю над проектом
Как написать документ с бизнес-требованиями в Agile
Автор: Дайан Хоффманустав проекта
Автор: Александр Гиллисограничение проекта
Автор: Пол КирванПланирование проекта: что это такое и 5 шагов для создания плана
Автор: Бен Луткевич
- HPE делает большие ставки на общедоступное облако для ИИ
HPE выходит на рынок публичных облачных провайдеров ИИ — но готова ли она? Узнайте больше о предложениях ИИ для HPE GreenLake и .
..
- Усовершенствование HPE GreenLake, нацеленное на все
Брайан Томпсон из HPE рассказывает о том, как HPE GreenLake стала синонимом бренда, смотрит в будущее и о том, как …
- Подходят ли локальные зоны AWS для моего приложения с малой задержкой?
AWS предлагает своим клиентам несколько вариантов минимизации задержки приложений. Давайте посмотрим, какую роль локальные зоны AWS могут сыграть в …
- Свежий взгляд на бизнес-примеры использования AR и VR
Дополненная и виртуальная реальность развивались годами как технологии, но варианты их использования в бизнесе не были такими устойчивыми. Однако будущее…
- Как обеспечить соответствие мобильным требованиям в бизнес-среде
Когда организации планируют соответствие требованиям и безопасность данных, им необходимо учитывать мобильные устройства из-за их распространения в .