Содержание курса

3.  Этап 3. Предварительная оценка реализации

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

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

3.1.  Концепция

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

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

Таблица сравнения акцентов при разработке Видения и Концепции приведена ниже.

Видение (Vision)

Концепция (Concept)

Что описывает?

Глобальную цель и ценность

Как именно реализуется продукт

Фокус

Будущее, стратегия, смысл

Ближайшее будущее. Функциональность, UX, технологии на старте.

Вопрос

"Почему мы это делаем?"

"Как мы это сделаем?"

Изменяемость

Стабильное, долгосрочное

Гибкое, может меняться

Пример

"Мы хотим упростить управление финансами для малого бизнеса с помощью AI"

"Мы разрабатываем AI-платформу с автоанализом трат и предсказанием расходов"

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

3.2.  Предварительный план трудозатрат

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

Как это осуществляется?

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

П/№

Тип работы

Наименование работы

Квалификация исполнителя

Трудоемкость

1

Автоматизация шаблонного процесса

Инжениринг и реинжениринг бизнес-процесса.

Senior системный аналитик

48 ч.

2

Создание BPMN диаграммы

Middle системный аналитик

48 ч.

3

Документирование бизнес-процесса

Junior системный аналитик

8 ч.

4

Разработка GUI

Создание макапа формы

Junior системный аналитик

6 ч.

5

Реализация модальной формы

Junior Front-end разработчик

4 ч.

6

Реализация Блока модуля иерархического меню

Middle Front-end разработчик

6 ч.

7

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

Middle Front-end разработчик

16 ч.

8

Реализация страницы с дашбордом элементов системы

Senior Front-end разработчик

24 ч.

9

Реализация API

разработка интерфейса поддержки GUI карточки бизнес-объекта

Middle Back-end разработчик

12 ч

10

Реализация алгоритма

Создание процедуры обработки данных

Middle Back-end разработчик

6 ч,

Причем работы в таком формате могут оцениваться не в часах, а, например, в относительных единицах (story points) или идеальных человеко-днях/неделях.

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

п/№

Компонент / функциональность

Таблицы

Безопасность

Формы

Выборки данных

Сервисы и процедуры

Отчеты

Бизнес процессы

ИТОГО чел./дней

 

 

Кол-во

коэфиц

коэфиц

Кол-во

коэфиц

Кол-во

коэфиц

Кол-во

коэфиц

Кол-во

коэфиц

Кол-во

коэфиц

1

Управление нерегистрируемыми документами

12

0,1

1,3

3

0,7

4

0,7

2

3

3

1,5

1

6

22,96

2

Управление версиями

2

0,1

1,3

1

1,5

1

0,7

1

3

 

 

5,46

3

Использование Шаблонов Документов

3

0,1

1,3

1

1,5

1

0,3

2

3

 

 

8,19

4

Управление Согласованием

6

0,1

1,3

5

2

5

0,7

4

3

2

1,5

1

6

35,28

5

Разработка Документа Протоколы

 

 

 

 

1

1

1

2

 

3

10

Интеграция Организаций

5

0,1

1,3

3

1

3

0,7

 

 

 

5,75

14

Интеграция Организационной структуры

5

0,1

1,3

4

1

3

0,7

 

 

 

6,75

25

Управление совещаниями

10

0,1

1,3

5

1

3

0,7

3

1

4

1,5

1

6

23,4

25

Управление поиском

 

 

 

 

3

1

 

 

3

14

Синхронизация данных с СМ5

 

 

 

 

3

3

 

 

9

17

Интеграция в СМ6 справочников из СМ5

12

0,3

1,3

 

 

 

 

 

4,68

17

Интеграция GUI

 

 

 

5

2

 

 

 

 

10

25

Управление настройками системы

5

0,1

1,3

5

0,7

 

3

3

 

1

3

16,15

25

Доработка GUI для работы с иерхическими объектами

 

 

5

3

 

 

 

 

15

 

ВСЕГО разработка

43

 

 

27

 

14

 

17

 

7

 

3

 

117,01

 

Формирование требований на разработку

 

 

 

 

 

 

 

 

 

20

 

Тестирование коэфиц.  (от разработки)

 

 

 

 

 

 

 

 

 

 

 

 

29,25

 

Дорвботка платформы коэфиц. (от разработки)

 

 

 

 

 

 

 

 

 

 

 

 

29,25

 

ВСЕГО Разработка + Тестирование

 

 

 

 

 

 

 

 

 

 

 

 

195,52

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

  • Эффект оптимизма – команда верит, что всё пойдет по плану, недооценивая сложности.
    Когнитивные искажения – люди переоценивают свои способности и опыт.

  • Давление заказчика – когда сроки навязываются сверху, а команда подстраивается.

  • Отсутствие данных – если проект новый, нет исторических данных для оценки.

  • Боязнь показать низкую продуктивность – разработчики могут завышать оценки, чтобы не выглядеть медленными.

Поэтому необходимо еще учесть факторы, увеличивающие оценку, добавив поправочные коэффициенты (неопределенности, команды, рисков, операционной деятельности и прочих),

3.3.  Принятие решения о запуске проекта

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

На графике наглядно видно, насколько уменьшается неопределенность по мере уточнения контекста производства.

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

Итоговое принятие решения чаще всего опираться на следующие критерии:

  1. Ценностная гипотеза (Problem-Solution Fit). Нашли ли реальную, болезненную пр��блему у конкретных людей и убедительное решение?

  2. Рыночная и бизнес-гипотеза (Market & Business Fit). Есть ли для этого решения жизнеспособный и привлекательный рынок?

  3. Технологическая и операционная выполнимость (Feasibility).  Можно ли это построить с имеющимися (или доступными) ресурсами?

  4. Стратегическое соответствие (Strategic Alignment). Этот проект соответствует долгосрочным целям компании и нашей миссии?

Существует три варианта итогового решения:

1)  Запускать проект в предложенном виде.

2)  Остановить производство.

3)  Серьезно изменить концепцию (целевую аудиторию, решение, бизнес-модель) и пройти этап исследования заново.

Если принято решение о целесообразности продолжения производства ИС, происходит переходе от неопределенности к обязательствам, фокус переводится с исследовательской деятельности на проектную.

3.4.  Порядок инвестирования фазы Предпроектного исследования

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

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

Существуют следующие рекомендации по этому вопросу:

1)  Платит ЗАКАЗЧИК (модель “Исследование как отдельный проект”)

Ситуации:

  • Крупный корпоративный или государственный заказ с высокими рисками и строгим бюджетным планированием.

  • Разработка уникального, высокоспециализированного продукта (например, ПО для управления атомной станцией, кастомизация ERP под специфический бизнес-процесс).

  • Заказчик имеет четкое ТЗ на исследование.

  • Исполнитель является консалтинговой или исследовательской компанией.

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

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

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

Минусы для исполнителя: риск не получить контракт на дальнейшую разработку. Может возникнуть конфликт интересов (исполнителю выгодно “раздуть” исследование).

Форма договора: договор на НИОКР (научно-исследовательские и опытно-конструкторские работы) или договор на оказание консалтинговых услуг с четким SOW (Statement of Work).

2)  Платит ИСПОЛНИТЕЛЬ (модель “Инвестиция в продажу/продукт”)

Ситуации:

  • Разработка рыночного (продуктового) SaaS или массового приложения.

  • Стартап, который ищет product-market fit (соответствие продукта рынку).

  • Исполнитель (продуктовая компания/студия) хочет создать новый продукт/сервис для последующей продажи или лицензирования.

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

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

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

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

Минусы для заказчика: может не получить полных прав на результаты исследования. Исполнитель может быть менее объективен.

Форма: Внутренний R&D-бюджет компании, инвестиции основателей или инвесторов в стартап.

3)  Гибридные и партнерские модели (Самые современные и эффективные)

Модель 1: “Сплит-стоимость” (Cost-sharing)

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

Результаты и права на интеллектуальную собственность также делятся по согласованию.

Модель 2: “Оплата по результату” (Success-based)

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

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

Модель 3: “Предпроектное исследование как первый спринт” (Agile-подход)

В рамках гибкого контракта (например, Time&Materials) выделяется фиксированный бюджет (на 2-4 недели) на “Спринт 0: Открытие”. Команда (заказчик и исполнитель) совместно проводит интервью, подготовку, строит прототипы.

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

При этом Заказчик оплачивает этот спринт как неотъемлемую часть разработки.

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

 В продолжении мы рассмотрим следующую фазу – Проектирование.