4.27.1 Жизненный цикл проектов DS-API

Общее описание

Любая задача по автоматизации имеет свой жизненный цикл – от возникновения проблемы (осознания необходимости автоматизации) до ввода в эксплуатацию, эксплуатации, изъятия из эксплуатации или выводу на внешний рынок.

Каждый этап жизненного цикла имеет:

• цель;
• ответственного (Task Owner — TO, руководителя процессом достижения цели);
• исполнителя (Task User — TU, сотрудника, принимающего участие в достижении цели);
• эксперта (Expert — EXP, человека, выполняющего согласовательную и консультационную функции в процессе достижения цели).

Данная инструкция содержит правила формирования новых запросов на:

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

Условно жизненный цикл инструмента можно разделить на следующие стадии:

1. Получение идеи/заказа – сбор идей и предложений от команды DS;
2. Составление ТЗ – анализ полученных идей, разработка расширенного ТЗ, оценка экономической эффективности и возможности, установление сроков и ответственных и др.;
3. Разработка – процесс разработки инструментов и тестирования внутреннего кода;
4. Тестирование – тестирование инструмента;
5. Эксплуатация на пилотном проекте – использование инструмента на пилотном проекте;
6. Массовое внедрение – использование инструмента на всех проектах;
7. Упаковка продукта – подготовка инструмента к выходу на внешний рынок;
8. Выход на внешний рынок – позиционирование инструмента, продажа, поддержка внешних пользователей.

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

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

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

Получение идей/заказов – постоянный процесс внутри компании. Инструменты разрабатываются пакетно раз в квартал , а также существует процесс решения срочных «задач-молний» (подробнее в разделе «Составление ТЗ»). За 1-2 недели до старта разработки происходит комплексный анализ полученных идей, оценка их эффективности, установление сроков разработки, формирование ТЗ.

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

В процессе составления ТЗ PDM совместно с CAM составляют график разработки инструмента в формате excel с назначением ответственных и сроков (Рисунок ?). Файл размещается в папку «00_База данных»:

Сбор обратной связи происходит на протяжении всего жизненного цикла инструмента через Google-форму, информация консолидируется в Google-таблице (подробнее в разделе «Получение идеи/заказа» ). PDM фиксирует все идеи/баги и размещает их в папке «01_Обратная связь» . Информация анализируется на возможность реализации и актуальность, часть отсеивается, остальные пункты отрабатываются в процессе до выхода на внешний рынок или в следующей версии инструмента (в процессе разработки следующего пакета плагинов).

Начиная от стадии разработки и до выхода на внешний рынок инструмент имеет определенный статус для каждого этапа (Рисунок 179):

• Alfa (α) – начальный статус инструмента, прошедшая стадию разработки. На этой стадии инструмент может иметь критические ошибки. Данная версия полноценно проходит стадию тестирования внутри отделов.
• Beta (β) –активное тестирования внутри компании на пилотном проекте.
• Release candidate (RC) – инструмент, прошедший комплексное тестирование на пилотном проекте и применяемый на других проектах.
• Release to manufacturing (RTM) – стабильная версия программы, пригодная для массового тиражирования. RTM* — упакованный продукт готовый к дальнейшему выходу на рынок.
• General availability (GA) – инструмент, для которого завершены все необходимые мероприятия по коммерциализации, и программный продукт доступен для покупки.

Информация об инструментах хранится в разных базах данный:

• Идеи и планируемые инструменты хранятся в Google-таблице, сформированные с помощью Google-опроса (подробнее в разделе «Получение идеи/заказа» ):

• Инструменты, которые находятся в разработке, проходят этап от составления расширенного ТЗ к формированию таблицы по разработке с назначением сроков и ответственных лиц (подробнее в разделе «Составление ТЗ» ):

• Существующие инструменты хранятся в базе данных DS с информацией о лицензиях и пользователях, которым установлены инструменты. В будущем данную систему планируется перевести на платформу redmine.

Ответственность за установку необходимых плагинов на компьютеры пользователей внутри DS несет PDM. Информацию об изменениях в составе компании до PDM доносит HRM,  после чего плагины устанавливаются для новых пользователей, для уволившихся сотрудников лицензии отзывается.

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

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

[wpdatatable id=17]

Получение идеи/заказа

Цель: Формирование списка идей/заказа.
TO: PDM.
TU: DD, DM, BPM, BM, PM, CPM, PDM, CAM, AD.
EXP: CBM.
Результат: Сформированный список идей/задач.

Драйвером процесса формирования заказа выступает PDM. Для регулярного получения идей в начале месяца PDM делает рассылкудляDD,DM с установленными сроками сбора информации. BM, BPM, PDM в течение каждого месяца после сбора обратной связи исследуют внешние решения полученных идей, в процессе которого могут появляться новые идеи, которые заносятся в Google-форму. Подобный анализ также происходит после сбора обратной связи по окончанию проекта и при возникновении срочных «задач-молний».

Формирование заказа происходит по схеме:

Для удобства аккумулирования идей каждый сотрудник имеет возможность записать их в Google-форму: https://forms.gle/UdGseTZZR3jwRMTGA .

В форму заносятся:

• пожелания по разработке плагинов/замечания по существующим плагинамотDD, DM;
• проблемы и ошибки, возникшие в процессе проектирования от PM, CPM, BPM (сбор осуществляет PDM на встрече по сбору обратной связи по окончанию проект и заносятся в Google-форму);
• идеи/проблемы/замечания, возникающие в процессе проектирования от BPM;
• при возникновении срочной «задачи-молнии» необходимо зафиксировать её в форме и сообщить о ней PDM;
• идеи, решения, возникшие в процессе анализа внешнего рынка от BM, BPM, PDM;
• идеи и предложения от отдела API.

Все полученные данные формируются в Google-таблице, которая впоследствии используется PDM для анализа информации.

В матрице ответственности прописаны основные шаги данного этапа в той последовательности, в которой они происходят:

[wpdatatable id=18]

Составление ТЗ

Цель: Формирование списка задач, включенных в пакет разработки инструментов, с их приоритезацией, сроками и трудозатратами и внесение их в базу данных инструментов на разработку.
TO: PDM.
TU: PDM, BM, BPM, CAM, AD.
EXP: CBM, CEO.
Результат: Список инструментов на разработку, сформированных в базе данных инструментов на разработку.

За 1-2 недели до старта разработки нового пакета плагинов происходит комплексный анализ сформированных ТЗmin, оценка их эффективности, установление сроков разработки, формирование расширенного ТЗ.

Для установления сроков и определения трудозатрат на выполнение задачи введено понятие «общий размер задачи» – первоначальная (грубая) оценка сложности поставленной задачи. Выражается в общем количестве времени, требующегося для решения данной задачи (включая ресурсы BIM, АР, КР и возможное подключение других специалистов), без затрат на внедрение и (или) сопровождение:

• XS – задача требует до 3-х дней (1-3 дня). Задача, требующая менее одного дня, округляется до одного рабочего дня;
• S – задача требует одну рабочую неделю (3-5 рабочих дней);
• M – задача требует 2-3 рабочих недели (10-15 рабочих дней);
• L – задача требует 3-5 рабочих недель (приблизительно один месяц, 20-25 рабочих дней);
• XL – задача требует 1-2 рабочих месяца (30-40 рабочих дней);
• XXL – задача требует от 3 до 6 рабочих месяцев;
• XXXL – задача может потребовать год(ы).

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

• универсальные – направлены на решение широко распространенных задач, подходят для вывода инструмента на рынок. Для таких задач необходимо заложить дополнительное время на массовую кастомизацию (разработка дизайна, сбор обратной связи и дополнительных требований, доработка инструмента, создание инсталлятора, защита и лицензирование и прочее);
• специализированные – направлены на решение узконаправленных задач внутри DS.

В матрице ответственности прописаны основные шаги данного этапа в той последовательности, в которой они происходят:

[wpdatatable id=19]

* – с привлечением DD, DM, PM определяются показатели задачи (описание проблемы, как часто она появляется на проектах, и сколько времени «отнимает» у проектировщика).

По окончанию составления расширенного ТЗ PDM, по согласованию с CAM иAD, вносит задачи в базу данных на разработку с установлением ответственных, исполнителей и сроков.

В случае, когда возникает срочная/важная «задач-молния» с высоким приоритетом, требующая оперативного решения (срок выполнения менее 3 дней) она может быть принята в работу (с созданием карточки в Trello). Запуск таких задач определяет PDM по согласованию с CBM. CBM выделяет ресурс по согласованию с CEO.

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

Для задач с высоким приоритетом создаются отдельные карточки в Trello со сроками разработки.

Разработка

Цель: Разработать первичную версию продукта (Alfa).
TO: CAM.
TU: AD.
EXP: PDM, CAM.
Результат: Инструмент статуса Alfa.

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

В матрице ответственности прописаны основные шаги данного этапа.

[wpdatatable id=20]

Тестирование

Цель: Тестирование версии Alfa и получение инструмента, который может быть запущен в эксплуатацию с ограничениями (Beta).
TO: PDM.
TU: BM,BPM.
EXP: PDM.
Результат: Инструмент статуса Beta.

Проверка разработанного инструмента на соответствие стандартам DS, на наличие ошибок и на влияние инструмента на данные производит BM по согласованию с PDM с установлением плановых сроков на тестирование. Время на тестировании в BIM-отделе может занимать 1-5 рабочих дней.

После проверки в BIM-отделе происходит тестирование разработанного инструмента на пилотном проекте. Плановые сроки определяют PDM совместно с BPM с привлечением DD илиDM,назначенным ответственным за тестирование. Время на тестирование может занимать 1-5 рабочих дней. В случае наличия ситуации, на которой можно произвести тестирование инструмента определяются сроки наступления этого момента, выбирается ответственный за тестирование. В ином случае, искусственным путем создаются условия, имитирующие данную ситуацию и назначается ответственный за тестирование.

Ошибки и замечания формулируются в Google-форме и PDM заносит их в таблицу обратной связи — аналог Google-формы с кратким ТЗ, располагается в папке «Обратная связь» . В случае критичных ошибок и замечаний AD может дорабатывать инструмент. Остальные ошибки и замечания (при возможности их реализации) в последствии будут проанализированы и отработаны в новой версии плагина при разработке следующего пакета плагинов.

После успешного тестирования инструмент переходить на следующую стадию жизненного цикла.

В матрице ответственности прописаны основные шаги данного этапа в той последовательности, в которой они происходят:

[wpdatatable id=21]

Эксплуатация на пилотном проекте

Цель: Оценка работы инструмента, прошедшего тестирование (Beta), на пилотном проекте. Выявление ошибок и необходимости расширения функционала.
TO: PDM.
TU: DD, DM, BM, BPM.
EXP: CBM
Результат: Инструмент статуса RC (Release candidate).

После получения разрешения от CBM плагин тиражируется внутри команды DS и применяется в рамках пилотного проекта.

За установку плагинов на компьютеры пользователей несет ответственность PDM, срок установки в течение 3-ёх дней после получения разрешения от CBM.

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

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

Учет пользователей внутри DS, которым были установлены плагины, происходит на платформе DS. Для фиксации информации по распространению лицензий на внешний рынок PDM ведёт учёт в формате excel (подробнее в разделе «Выход на внешний рынок»  ).

Ошибки и замечания формулируются в Google-форме и PDM заносит их в таблицу обратной связи — аналог Google-формы с кратким ТЗ, располагается в папке «Обратная связь». AD осуществляет техническую поддержку специалистов по работе с инструментом и в случае критичных ошибок и замечаний может дорабатывать инструмент. Остальные ошибки и замечания (при возможности их реализации) в последствии будут проанализированы и отработаны в новой версии плагина при разработке следующего пакета плагинов. Кроме того, в ходе эксплуатации AD разрабатывает справку/инструкцию по работе с инструментом.

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

В матрице ответственности прописаны основные шаги данного этапа в той последовательности, в которой они происходят:

[wpdatatable id=22]

Массовое внедрение

Цель: Внедрить инструмент внутри компании DS на всех проектах.
TO: PDM.
TU: BM,BPM.
EXP: PDM.
Результат: Инструмент статуса RTM (Release to manufacturing).

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

Степень внедрения:

• Высокая – более 90 %.
• Средняя – более 80%.
• Низкая – менее 60%.

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

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

Для оценки массового внедрения используется статистика продукта DCM. Данные анализируются BIM-отделом, после чего проводится диалог с DD, DM для получения обратной связи по используемым и неиспользуемым продуктам. Формируются причины, по которым тот или иной инструмент не востребован, принимаются решения по конкретному продукту.

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

Для внедрения инструментов используются следующие методы:

• Информирование сотрудников в стандартах DS и карточках Trello. Ответственный за своевременное внесение изменений PDM.
• После запуска инструмента для массового использования PDM совместно с BM и BPM проводят презентацию и отвечают на вопросы сотрудников.
• Регулярный диалог и вербальная коммуникация с сотрудниками происходит в процессе проектирования, во время консультаций. Ответственной стороной процесса является BIM-отдел.
• Обучение новых сотрудников по использованию всех разработанных и выпущенных в эксплуатацию инструментов. По итогу обучения проводится проверка на полученные знания. Обучением сотрудников занимается образовательный центр компании DS.
• Обучение сотрудников по использованию плагинов, которые используются для решения стоящих перед ними задач (по журналу BPM).
• Проверка знаний существующих инструментов включена в карты компетенций сотрудников.

Для выбора стратегии внедрения инструментов их можно разделить на:

• Инструменты, направленные на решения конкретных задач (полы, отделка и др.). Такие инструменты фиксируются в журнале BPM, стандартах компании и в карточках Trello с привязкой к определенной задачи. Внедрение плагинов, направленных на решение конкретных задач, необходимо производить для все команды каждый раз перед началом нового этапа проектирования, где может применяться этот плагин. Ответственным за эту задачу является BPM по каждому из проектов. Прогнозирование внедрения таких плагинов производится по журналу BPM;
• Инструменты для систематического  использования, для постоянных процессов (расширенный фильтр, управление типами и др.). Внедрение плагинов, используемых для постоянных процессов (расширенный фильтр, управление типами и т.п.), производится посредством обучения сотрудников, мотивации к использованию, вербальной коммуникации.

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

Сбор обратной связи ведёт PDM, происходит по аналогичному сценарию, что и на предыдущих шагах.

В матрице ответственности прописаны основные шаги данного этапа:

[wpdatatable id=23]

Упаковка продукта

Цель: Упаковка инструмента
TO: CAM.
TU: AD, PDM, Подрядчик по дизайну.
EXP: CBM.
Результат: Инструмент статуса RTM* (Release to manufacturing).

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

В матрице ответственности прописаны основные шаги данного этапа:

[wpdatatable id=24]

Выход на внешний рынок

Цель: Выход на внешний рынок, привлечение компаний к продукту
TO: PDM.
TU: PDM.
EXP: CBM, CEO.
Результат: Продаваемый продукт.

Обязательным условием успеха продаж плагинов является доступность и удобство их установки и использования. Ответственным за эти процессы является PDM, работающий в связке с AD и BM:

• Консультация клиентов в процессе установки плагинов – PDM;
• Внутренние проблемы в работе плагина – AD;
• Проблемы в процессе использования плагина, не связанные с внутренним кодом – PDM,BM.

Для учета проданных лицензий PDM заносит данные в таблицу excel. Данная схема сбора информации впоследствии будет перенесена на платформу DS.

В матрице ответственности прописаны основные шаги данного этапа:

[wpdatatable id=25]