Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы. В техническом задании мы описываем предметную область, существующую инфраструктуру Заказчика, требования к создаваемому функционалу, а также нефункциональные требования. Получившийся документ необходим как бизнес-пользователю для того, чтобы он убедился в том, что все его пожелания к будущей системе учтены, так и нам, чтобы оценить стоимость разработки системы.
Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document).
Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.
Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том, чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.
Приведем ниже принципы, которыми мы руководствуемся при написании технического задания, и проиллюстрируем их выдержками из разработанного нами технического задания на многокомпонентную систему баннерной рекламы для крупной Интернет-компании.
Структура технического задания
Каждое техническое задание содержит несколько обязательных разделов.
В них определяется назначение документа, терминология, общий контекст проекта. Обычно первая часть документа выглядит так:
1. Оглавление
2. История изменений документа
3. Участники проекта
4. Назначение документа
5. Терминология
6. Общий контекст
Если в начале документа даётся общая, концептуальная информация о разрабатываемой системе, то во второй, основной части документа, детально прописываются бизнес-требования и существенные для оценки стоимости разработки функциональные требования к системе.
В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.
7. Система размещения баннеров
8. Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine
Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами. Учитывая специфику данного проекта, мы посвятили отдельный раздел взаимодействию баннерки с биллинговой системой. Также в отдельный раздел мы выделили требования к достаточно независимой компоненте сбора и отображения статистической информации, которая является для заказчиков рекламных кампаний и менеджеров рекламных агентств едва ли не основным компонентом системы.
Отдельный раздел технического задания описывает требования к компоненту Banner Engine, отвечающему за показ баннеров, учёт статистики, её обработку и сохранение в виде, пригодном для дальнейшего анализа и построения отчетов.
Это – технически самый сложный и самый высоконагруженный компонент баннерной системы. В ТЗ мы включили раздел, содержащий некоторые технические и архитектурные детали, связанные с работой Banner Engine. Прежде всего, это позволяет минимизировать риски при оценке стоимости разработки системы, ведь в зависимости от выбранной архитектуры трудоемкость может отличаться в разы.
Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.
Бизнес vs Функциональные требования
В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта. Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
Пример бизнес-требования:
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
Пример функционального требования:
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию, когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Дата добавления: 2020-04-25 ; просмотров: 105 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
Чек-лист по написанию ТЗ (общий)
Дисклеймер: эту статью я буду еще очень много дописывать и менять, пока в ней только 1% от всего, что я хочу рассказать. Поэтому добавляйте в закладки и иногда заходите за новым контентом.
Техническое задание (ТЗ) по разработке IT-продукта — это документ, в котором указываются характеристики будущего комплекса ПО (от 1 и более программ), требующиеся для полноценной реализации проекта.
«Как сделать ТЗ?» — повсеместный вопрос, я его крайне часто задавал и за 5 лет не обнаружил полноценного ответа. Чаще всего, это попытка описать ТЗ по ГОСТу. В современной разработке это необязательно + они не покрывают большинство вопросов из «реальной жизни».
В данной статье я постарался собрать все лучшие практики написания ТЗ для IT-проектов, которые получил за более чем 5 лет их написания.
Этот чек-лист огромен, состоит из кучи пунктов, которые отвечают на вопрос: кто, как, когда, в какой последовательности, для чего, при каких условиях должен составлять ТЗ и так далее.
Поскольку такой большой материал невозможно охватить разом, я буду постепенно дополнять его, писать новый статьи и прикладывать сюда ссылки.
Добавляйте эту статью в Закладки, с каждым новым возвращением вы будете находить новые пункты. А мы приступаем (пока вразнобой):
Всегда начинайте с БФТ
Мало кто знаком с этим термином, а жаль. БФТ («Бизнес Функциональные Требования») — это документ, в котором описывается запрос от бизнеса по логике и специфике работы системы БЕЗ учета технической реализации. Скоро будет статья на жту тему.
Делайте ТЗ
Отсутствие ТЗ фатально.
Это относится как с Исполнителям, Заказчикам и даже Партнерам по проекту: если вы заранее не договоритесь о результате работы, вам не на что будет опираться, когда придет время приемки работ.
Многие честные люди погубили свои отношения и проекты просто потому что не договорились на берегу и не описали свои ожидания в ТЗ.
Не пишите все и сразу
Вопросы, которые вам заранее неизвестны могут таковыми и остаться. Главное, сделать пометку, когда конкретно будет корректировка ТЗ.
Также, абсолютно нормально представить варианты технологий, которые предстоит попробовать для оптимального решения задачы.
Если у заказчика нет технического навыка, он всегда будет недоволен
У людей, не понимающих принципов разработки ПО, до начала проекта складывается крайне размытая картинка результата. И даже ТЗ тут не поможет.
Если предположить, что ваш заказчик / руководитель более менее адекватный человек, чтобы его удовлетворить, всегда нужно сделать больше, чем вы прописали и сказать об этом.
Помните, что вас всегда обманут
Это связано с предыдущем пунктом: если у вас не было опыта в сфере, то любой специалист способен сделать такие формулировки, которые выглядят здраво, а на деле смысла не имеют, или например опустить детали, которые ему не сильно будет хотеться делать. В любом случае, если вы не дадите ТЗ на перепроверку знающему человеку, вы одной ногой уже в нереализованном проекте и огромных тратах.
Если нет референсов, то оценка проекта возможна только после ТЗ
Если вы разрабатываете площадку, у которой меньше 2-3 референсов, то сказать стоимость и срок разработки возможно только после составления ТЗ.
Вообще нет референсов? Тогда очень важно сделать Прототип
Прототип — это визуально очень упрощенная версия дизайна, которая позволяет блок-схемой накидать основной функционал на странице. Это позволяет на этапе проектирования понять удобство использования будущего продукта, В 100% СЛУЧАЕВ увидеть насколько много вы и заказчик забыли прописать в ТЗ и спланировать. Короче, прототип иногда невероятно спасает и дает сразу +20-30% к успеху разработки.
ТЗ возможно сделать только в плотной кооперации заказчика, специалиста области и IT-архитектора
Этим грешат большие фирмы и некоторые агентства: ТЗ составляют проджекты, а еще хуже продажники. А в процессе проекта не допускают архитектора до клиента.
Да, фирме так легче продавать, только качество продукта и настроение в команде страдают. Если вы заказчик, то требуйте общения с архитектором, если вы отдел разработки, то требуйте доступа к клиенту.
«Сущности» и «Сценарии»
В каждом из них вы описываете:
- Сущности (пример «Соц сеть: Пользователь, Друг, Чат, Участники чата, Сообщение, Прикрапление, …»)
- Свойства Сущностей (пример «Пользовать- имя, фамилия, адрес, email, дата последнего захода, …»)
- Сценарии, которые с ними происходят (пример «Добавление в друзья: после добавления в друзья у человека автоматически создается чат с приветственным сообщением обоим участникам, отправкой письма на почту и …»)
Более подробно я раскрою это в статье, но если упрощенно, то вы из «Сущностей» напишите «Models», а из «Сценариев» сделаете «Controllers».
Рисуйте
Визуализация ТЗ — очень важный этап, который возволяет на ранних этапах обнаружить ошибки. А иногда единственный способ понять текущую картину.
Вот несколько примеров: карта сущностей и их взаимосвязей, карта сервисов и их расположение на серверах, карта модулей и их зависимость друг от друга (+ каналы коммуникации), EPC Сценария и так далее.
Не бойтесь выделять самые большие куски в отдельные ТЗ
Видите, что какой-то Сценарий слишком большой? Вынесите в отдельный документ и приложите ссылку в ТЗ
Скоро будет продолжение…
Нужна помощь с ТЗ?
Уже есть ТЗ или БФТ? Тогда можете его отправить, я посмотрю и скажу рекомендации. Если ТЗ нет, то подскажу, что надо собрать, чтобы начать его делать.
Источник: davidshekunts.ru
Под заказ и “под ключ”: чем привлекает бизнес заказная разработка программного обеспечения
В начале 2023 года сегмент заказной разработки ПО показал устойчивую динамику роста: количество обращений за подобными услугами увеличилось почти в два раза. Это говорит о том, что российский бизнес вновь готов инвестировать в развитие своей ИТ-инфраструктуры, хоть и в краткосрочной перспективе. Рассмотрим, какие преимущества дает заказная разработка ПО отечественным компаниям.
Динамика развития сегмента в годы
Последствия ковида, дефицит кадров, спецоперация стимулировали рост российского рынка заказной разработки. В позапрошлом году он, по данным Tadviser, продемонстрировал положительный результат — общий доход отечественных софтверных разработчиков составил более 1,5 трлн. руб. — на 19% больше, чем в Из них 815 млрд. руб. — доход в России и 745 млрд. руб. — за границей. При этом объемы заявок на разработку ПО со стороны бизнеса в России увеличился до руб., что выше показателя прошлого года на 20-21%.Таким образом, 2021 год стал для сегмента заказной разработки одним из самых эффективных за последние десять лет.
2022 год можно разделить на два больших этапа. За период с января по июнь российский рынок покинули крупнейшие мировые вендоры ПО, в связи с чем большинство клиентов поставили на паузу реализацию своих стратегий по масштабированию ИТ-инфраструктуры. Другие при этом нарастили количество проектов, и, благодаря импортозамещению, это стало драйвером 35%-ного роста сегмента заказной разработки ПО. С июня и до конца 2022 года произошла адаптация российского бизнеса к сложившейся ситуации, и практически все проекты были разморожены.
Важным моментом является общее согласие, что потребность в автоматизации бизнес-процессов любой компании никуда не делась. Бизнес продолжает свою работу, развитие, и ИТ-составляющая, системы автоматизации и управления процессами, продолжают оказывать значительное влияние почти в любом бизнесе.
Драйверы развития сегмента
Предпосылками роста объемов рынка заказной разработки стали такие ее преимущества, как возможность создания собственного продукта, максимально учитывающего все возможные бизнес-задачи и обеспечивающего эффективность автоматизации уже существующих бизнес-процессов без необходимости перестраивать их под процессы, которые могут быть в «коробочных» программных решениях. В большинстве случаев (вне зависимости от того, насколько точно и детально были сформулированы бизнес-функциональные требования (БФТ) к программному обеспечению до начала его разработки) в процессе разработки или внедрения, которые могут занимать достаточно продолжительное время, возникает необходимость в изменениях, которые в очень короткие сроки могут быть учтены при заказной разработке, тогда как получить аналогичное от уже готового ПО, не адаптированного под требования конкретного клиента — мало реально. Трансформация и цифровизация устоявшихся бизнес-процессов, особенно на крупных предприятиях, начались не вчера, остановить их невозможно, поэтому в той или иной парадигме компании вынуждены продолжать развитие, чтобы достичь поставленных внутри целей и быть готовыми к изменениям. Заказная разработка, соответственно, позволяет достичь этого с большей скоростью и эффективностью.
Этапы проведения работ и подходы к реализации
В абсолютном большинстве случаев, обращаясь к заказной разработке, бизнес уже имеет внутреннее понимание того, к чему необходимо прийти. Часто это может быть в виде БФТ, которые буквально на нескольких листах на очень высоком уровне могут перечислять существующие процессы в компании и необходимые действия с ними. В процессе консультаций, на предпродажной стадии, БФТ могут уточняться, наполняясь новыми подробностями.
Следующим шагом является разработка технического задания (ТЗ), где от абстрактных идей необходимо перейти к конкретике. Разрабатывается документ, отвечающий на вопрос «Что?», который создается в результате работы бизнес-аналитиков, изучающих процессы заказчика и требования к ним.
Они проводят серии интервью с ответственными лицами компаний, представляющими различные бизнес-функции. Подобный документ преследует очень важную цель — описание границ и способов их достижения для того, чтобы проект по разработке имел свое завершение. Техническое задание должно предусматривать конкретику, которая позволит провести приемо-сдаточные испытания, тем самым завершив процесс разработки и передачи продукту заказчику. Как уже было сказано выше, нередко в процессе работы, возникает понимание необходимости внесения изменений в уже утвержденное ТЗ. Это, скорее, норма, чем исключение, и обеим сторонам стоит относится к этому с должным пониманием.
Крупные заказчики зачастую имеют свои пожелания к реализации проекта, которые должны быть разработаны, обсуждены и утверждены еще до этапа начала фактического написания программного обеспечения. В этой связи, в дополнение к ТЗ, создается другой документ — «Частное техническое задание (ЧТЗ)», — цель которого — ответить на вопрос «Как?». Этот документ содержит детали, часто описание алгоритмов и структур данных, которые во многих случаях архитекторы и разработчики бы разработали и реализовали при написании ПО без дополнительного документирования, но в ряде требований ГОСТ, для некоторых областей, например, государственного программного обеспечения, наличие этой фазы проработки может быть обусловлено условиями государственного контракта. После создания, согласования и утверждения подобного документа начинается процесс разработки программного кода.
Нередко в процессе создания ЧЗ или ЧТЗ выполняется и прототипирование интерфейсов. Это большая работа, в которую вовлечены дизайнеры, аналитики, эксперты по интерфейсам, разработчики и, конечно же, конечные пользователи, для работы которых и разрабатывается система. Все вместе они преследуют общую цель — создание максимально эффективных интерфейсов, которые будут удобны конечному пользователю и позволят ему наилучшим образом выполнять свою ежедневную работу. Данный шаг может занимать продолжительное время, но оно с лихвой окупается его экономией на этапе разработки.
Очень часто при разработке заказчик просит сформировать некую «пилотную» версию в кратчайшие сроки, которая может дать понимание направления, в котором движется программный продукт. ТЗ хоть и может содержать много деталей, но в любом случае не дает такого же представления, как живой продукт. Часто на этом этапе и приходит понимание того факта, что какие-то нюансы не были учтены при согласовании разработанных документов или интерфейсов, равно как и того, что процесс мог быть достаточно продолжительным и бизнес-требования за прошедшее время эволюционировали. Обратная связь пользователей и инженеров по тестированию позволяет собрать новые отзывы и, в конечном счете, разработать продукт, отвечающий ожиданиям и достигающий целей.
После завершения разработки первой версии продукта в дело вступают инженеры внедрения, которые помогают заказчику начать использование нового продукта, проводят обучение пользователей, убеждаясь, что бизнес-цели достигнуты.
В любом программном обеспечении встречаются ошибки — вне зависимости от того, насколько профессиональной была команда разработчиков и как хорошо были созданы документы, проведено тестирование. Ни одно тестирование не способно воспроизвести все возможные ситуации, с которыми могут столкнуться реальные пользователи в своих повседневных задачах. Служба технической поддержки разработчика должна всегда оставаться на связи, быть готова помочь советом, если возникшая ситуация требует дополнительного обучения пользователя, либо оперативно устранить проблемы в кратчайшие сроки путем исправления программной ошибки, если того требует ситуация. Поэтому важно уделить внимание доступности подобной службы поддержки, а не надеждам на то, что ошибок не будет и поддержка не понадобится.
Разумеется, не стоит забывать и про развитие продукта. Новые функции расширяют возможности, внедрение которых позволит достигать новых высот благодаря автоматизации и тем плюсам, которые современные технологии дают бизнесу любого масштаба.
Состояние рынка заказной разработки в 2023 году и прогнозы на будущее
Если до прошлого года за услугами заказной разработки чаще обращались крупные холдинги, то в текущем году рынок расширяется — спрос растет независимо от масштаба бизнеса. При этом многие большие организации пока продолжают использовать зарубежные платформы по причине того, что полная трансформация ИТ-архитектуры нуждается в крупных расходах. Однако это — вопрос времени, так как долго продолжать эксплуатацию решений западных вендоров при отсутствии обновлений и техподдержки невозможно. Это позволяет прогнозировать дальнейший рост спроса на заказную разработку ПО у отечественных компаний.
Александр Гордеев, генеральный директор ООО «Регеора Девелопмент», архитектор и ведущий разработчик высоконагруженных систем, с 20-летним опытом работы в ИТ-индустрии, в том числе в международных ИТ-корпорациях, таких как HPE и Dell
Источник: www.itweek.ru
