Подготовка технических заданий в строительстве

Мы с 2000 года интегрируем умные решения в разные бизнесы: занимаемся сложной веб-разработкой и развитием продуктов, внедряем CRM и ERP-системы, разрабатываем личные кабинеты. Создали более 530 сайтов и веб-сервисов. Имеем опыт заказной разработки для стартапов, а также запуска собственного продукта — MVP экспертной платформы «Консалт-Коллегия».

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

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

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

Организация строительства 6: Техническое задание

Какие тренды проявились в онлайне

• Мобильный трафик безоговорочно преобладает

По данным SlickJump, в 2020 году он достиг 80% в рунете. Это окончательно оторвало пользователей от привычных десктопов и заменило традиционные приложения на их веб-аналоги.

• Упростилось и ускорилось изменение IT-продуктов

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

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

• Изменились бизнес-модели целых отраслей

Компании запускают онлайн-каналы продвижения или полностью переходят в интернет.

• Онлайн увеличил конкуренцию в бизнесе

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

Итого: конкуренция усиливается, а цикл обновления и жизни продукта сокращается.

И что это меняет?

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

1) Подход с первоначальным проектированием всего продукта не обеспечивает необходимых скорости и гибкости.

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

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

Зачем нужно техническое задание на строительство или ремонт? Будет полезно и строителям и клиентам !

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

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

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

Шаг 1. Видение продукта

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

В результате получится концепция, которая состоит из трех разделов:

1. Product Vision — развернутое описание продукта.
2. Product Roadmap — дорожная карта по разработке.
3. Market Requirements Document — рыночные требования: как продукт будет выглядеть и работать.

Пример

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

Внутри команды их нет. Можно нанять консультанта. Но как определить его компетенции? На виду обычно те, кто активнее себя продвигает. Однако, навыки самопрезентации не равны профессионализму: часто бизнесу учат те, кто им никогда не занимался.

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

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

Шаг 2. Аналитика

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

• оцифрованные данные исследования с детально описанными портретами ЦА;
• обзор конкурентов;
• список дополнительных требований к продукту.

Пример

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

Мы привлекли к реализации проекта нашего партнера бизнес-сообщество «Конгресс-коллегия». В основу концепции легли две составляющие:

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

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

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

Шаг 3. Генерация идей

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

• список идей, отсортированный по значимости и данным Market Requirements Document. При отборе часто приходится опираться на интуицию;
• при необходимости — изменения в Vision и Roadmap.

Пример

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

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

Шаг 4. Проверка гипотез

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

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

• Customer Development — тестирование идеи или прототипа будущего продукта на потенциальных потребителях;
• Jobs to Be Done, или «работы, которые надо сделать» — изучение потребностей пользователей и определение задачи, которую решает продукт;
• опросы в чатах, где общается ЦА;
• создание тестовой версии продукта.

Если отработать процесс один-два раза, потом на этот этап будет уходить минимум времени.

Пример

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

Шаг 5. Формализация требований

На этом этапе составляют список функциональных требований к продукту — Product Requirements Document. Получится подробное описание функционала с кучей разных фич.

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

Пример

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

Шаг 6. Выделение MVP

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

На этом этапе выделяют:

• описание рамок MVP (сценарии использования продукта, user stories — краткие требования к системе, написанные языком пользователя, а также функционал для первой итерации);
• список метрик для оценки результатов.

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

Пример

Мы разработали MVP экспертной платформы с минимальным функционалом:

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

Лендинг и каталог экспертов собраны на «Тильде». Бэкенд реализован на «Битрикс24». Механика следующая:

1. Клиент заполняет форму записи на консультацию.
2. Заявка попадает в Б24 к администратору платформы.
3. Он уточняет запрос и при необходимости помогает выбрать эксперта.
4. Согласует стоимость и время консультации с обеими сторонами.
5. Генерирует и отправляет клиенту ссылку на оплату.
6. После завершения консультации сумма за вычетом комиссии платформы перечисляется эксперту.

Наши факапы: что мы не учли и к чему это привело

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

• Выделить время и собрать проектную команду

Я сам как владелец продукта разрабатывал концепцию платформы в свободное от других задач время. Мы привлекали сотрудников, занятых на других проектах. Разработка MVP затянулась более чем на полгода. Если бы работала выделенная команда, проект реализовали бы быстрее и проще.

Мы выявили и подробно описали боли ЦА — предпринимателей и экспертов. Но не убедились в том, что формат экспертной платформы наиболее востребован целевой аудиторией. Тестовая версия могла бы быть проще — не отдельный сайт, а группа на Facebook со списком услуг и конверсионной кнопкой или канал в Telegram с чат-ботом для записи на консультации.

Можно было создать сайт не на «Тильде», а на «Битриксе». Тогда на верстку ушло бы меньше времени — через админ-панель было бы удобнее выкладывать контент.

• Тратить меньше ресурсов на работу с экспертами

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

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

Источник: rb.ru

Как написать ТЗ, часть 2: еще раз про стандарты, представление требований и UML

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

Agile по-разгильдяйски или зачем нам ТЗ?

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

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

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

Ближайшая дата курса

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

Для кого аналитик пишет техническое задание?

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

• Заказчик – стейкхолдеры со стороны бизнеса, проблемы которого должен решить продукт с помощью его функциональных возможностей в заданных условиях его использования;
• Разработчик – к этой роли можно отнести как непосредственно программиста, пишущего программный код, так и архитектора ИТ-решения, а также тим/техлида и DevOps-инженера, т.е. всех непосредственных участников процесса реализации заявленных в ТЗ требований;
• Тестировщик– который проверяет, что результат соответствует заявленным ожиданиям, трассируя требования в набор тестов;
• Руководитель проекта– отвечая за бюджет и сроки поставки продукта, project manager должен понимать объем работы, который следует из контекста и набора требований к создаваемому продукту.

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

Можно ли написать ТЗ не по стандартам?

Как уже было отмечено, все российские и международные стандарты по разработке ТЗ и спецификации требований – это всего лишь шаблоны для создания документа «техническое задание». Поэтому, если вы не работает с госзаказчиками и нет необходимости четко следовать структуре и содержанию этих ГОСТ’ов, а ТЗ нужно для единого понимания требований к продукту у бизнеса и исполнителей, можно разработать этот документ самостоятельно. Например, я предлагаю вам следующую рабочую структуру ТЗ на основе SRS по ISO IEEE 29148-2018, исключив некоторые пункты, предписываемые стандартом. Курсивом отмечены мои комментарии по включению в данный документ иллюстраций в виде UML-диаграмм и экранных форм.

• Введение

• Краткое описание — зачем и кому нужен продукт, какие бизнес-задачи и проблемы он решает, т.е. каковы бизнес-требования с плановыми целями и показателями их достижения
• Термины и сокращения
• Категории и характеристики пользователей и их потребности относительно продукта, т.е. требования стейкхолдеров, которые можно наглядно показать в видеUML-диаграммыusecase
• Ограничения, бизнес-правила и стандарты

• Функциональные требования – по каждому требованию:

• Название и кодировка
• Приоритет и трассировка с другими требованиями и/или бизнес-правилами
• Детальное представление в виде вариантов (сценариев) использования, так называемых юз-кейсов (use case) с возможными иллюстрациями основных и альтернативных потоков, например, в видеUML-диаграммы деятельности,BPMN илиEPC-схемы бизнес-процесса. Также здесь можно показать экранные формы, доступные для актора в данном варианте использования.
• форматы и объем входных и выходных данных (результатов выполнения функции) — может входить в пункт Результат в описании вариантов использования

• Доменные сущности и связи между ними, что можно показать в видеUML-диаграммы классов илиER-схемы, описывающей таблицы базы данных
• Среда развертывания (программное и аппаратное обеспечение, например, операционная система ПК или мобильного телефона) — можно показать с помощьюUML-диаграммы развертывания и компонентов
• Внешние компоненты (СУБД, браузер, сетевые подключения и пр.)
• Программные интерфейсы
• Интерфейсы оборудования
• Интерфейсы связи и коммуникации

• Производительность
• Надежность и доступность
• Информационная безопасность и сохранность данных
• Удобство использования (пользовательские интерфейсы)

• К интеллектуальной собственности (патентная чистота)
• Требования к документации

Предложенную структуру можно дополнять и изменять по своему усмотрению. Например, добавить RACI и CRUDL-матрицы или включить в состав нефункциональных требований некоторые характеристики качества ПО, регламентированные стандартом ГОСТ Р ИСО/МЭК 25010-2015 «Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов» (ISO/IEC 25010:2011). О том, что такое нефункциональные требования и чем, например, надежность отличается от доступности, а также как измерить удобство пользовательского интерфейса, мы поговорим в следующий раз, а сейчас предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях.

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

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

Источник: babok-school.ru