Юлий Минькин, директор по развитию проектного офиса
"1С:Технология быстрого результата" (ТБР) относится к продуктам и методологиям компании "1С". Она типичный представитель адаптивного подхода к управлению проектами на платформе "1С:Предприятие".
ТБР ориентирована на достижение быстрых, регулярных и качественных результатов, которые имеют реальную ценность для заказчика. Эта технология подразумевает следующие ключевые аспекты:
- Снижение финансовых рисков путем регулярного анализа и оценки проектов, ТБР помогает минимизировать финансовые риски, связанные с внедрением программных продуктов.
- Быстрое получение результатов, благодаря регулярному и четкому планированию, когда заказчики могут видеть прогресс и результаты работы уже на ранних этапах проекта, а также четкую структурированность процесса внедрения, где каждый этап работы регулярно оценивается и закрывается, что обеспечивает постоянный контроль над ходом проекта.
- Гибкость и Адаптивность, которая позволяет быстро адаптироваться к изменениям в требованиях и условиях рынка, что особенно важно в динамичной бизнес-среде.
- Обеспечение регулярного финансирования, что способствует более эффективному планированию и управлению ресурсами.
Условия эффективного применения
Несмотря на многочисленные преимущества ТБР существуют несколько условий, которые ограничивают возможности ее применения.
Масштаб проекта. Для эффективного применения ТБР следует выбирать малый или средний масштаб проекта. На практике, как правило, для этой технологии оптимальным является численность команды не превышающая 7-8 человек. Для больших проектов целесообразно применять Технологию корпоративного внедрения (ТКВ).
Готовность компании. У руководства компании и проектной команды заказчика должна быть высокая мотивация на результат, а также способность к быстрому принятию решений. Немаловажным фактором является наличие в компании методических моделей (методологии) и учетных политик, от которых непосредственно зависит успешность внедрения прикладных решений.
Объем и критичность изменений. Технология ТБР отлично применяется для проектов, где не предполагается значительных технологических или организационных изменений. Другими словами, если требуется большой объем проектирования изменений или разработки методологии, тогда следует применять Технологию корпоративного внедрения (ТКВ).
Описание процесса
Весь процесс внедрения автоматизированной системы выполняется итерационно, что означает, что после первого этапа, все последующие работы выполняются циклично с целью постоянного улучшения и адаптации системы. Это может включать обратную связь от пользователей, улучшение функциональности и исправление обнаруженных ошибок.
В общем виде процесс создания автоматизированной системы по технологии ТБР состоит из следующих этапов:
- Формирование требований к автоматизированной системе и развертывание сред: Это первоначальный этап, на котором определяются основные требования к системе и подготавливается необходимая инфраструктура.
- Составление ЛТ (Лист требований): На этом шаге разрабатывается документация, которая будет определять перечень требования в рамках итерации, способы их реализации и методика испытаний.
- Разработка по ЛТ: Непосредственное создание части автоматизированной системы в соответствии с Листом требований.
- Проведение испытаний: После разработки программы проводятся тестирование для проверки её работоспособности и соответствия заявленным в ЛТ требованиям.
- Ввод в действие: После успешного завершения испытаний инкремент системы вводится в эксплуатацию.
Документирование разработки
Документирование создания АС играет критически важную роль в успешном управлении проектами по внедрению программного обеспечения. Несмотря на то, что в эпоху гибких методологий акцент смещается в сторону рабочего программного обеспечения, а не обширной документации, наш опыт показывает, что правильно организованное документирование остается ключевым элементом для эффективности и устойчивости проектов. Вот основные причины, почему документирование в рамках технологии ТБР так важно:
Ясность и согласованность целей. Документация помогает всем участникам проекта иметь единое понимание целей и требований. Это уменьшает риск недопонимания и ошибок в процессе разработки.
Улучшение коммуникации. Документация обеспечивает эффективный обмен информацией между членами команды, особенно в распределенных или многонациональных командах.
Облегчение процесса онбординга. Новые сотрудники могут быстрее включиться в работу, если у них есть доступ к хорошо оформленной документации по проекту.
Упрощение технической поддержки и обслуживания. Документация изменений и архитектуры облегчает постпроектное обслуживание и обновление программного обеспечения, особенно когда проектная команда покидает проект.
Упрощение Процесса Тестирования. Документация тестовых сценариев и результатов помогает в обеспечении качества продукта и ускоряет процесс выявления и исправления ошибок.
Помощь в планировании и оценке. Документация помогает в планировании проекта, оценке ресурсов и времени, необходимых для его реализации.
В рамках технологии ТБР документирование разработки не является слишком обременительным или излишним. Вместе с тем, оно адаптировано к потребностям проекта и команды, обеспечивая баланс между необходимостью и достаточностью.
Журнал требований (ЖТ)
Это упорядоченный список всего, что может потребоваться в целевой системе, и является источником требований для любых изменений, которые будут в нее внесены. Журнал требований постоянно меняется и эволюционирует вместе с системой и потребностями пользователей.
Структура ЖТ:
- Элементы ЖТ. Это могут быть функции, функциональные и нефункциональные требования, улучшения, исправления ошибок, технические работы и т.д.
- Описание. Каждый элемент должен иметь краткое описание, объясняющее его суть.
- Приоритет. Указывает на важность элемента относительно других.
- Оценка. Примерная оценка трудозатрат на реализацию элемента.
- Статус. Текущее состояние элемента (например, запланировано, в работе, выполнено).
Основные характеристики ЖТ:
Динамичность. ЖТ непрерывно обновляется для отражения изменений в потребностях пользователей.
Приоритизация. Элементы в ЖТ ранжируются по приоритету, чтобы гарантировать, что команда сначала работает над самыми важными задачами.
Гибкость. ЖТ должен быть достаточно гибким, чтобы позволять быстро реагировать на изменения.
Подробность. Элементы в верхней части ЖТ обычно более детализированы, чем те, что находятся ниже.
Прозрачность: Весь ЖТ должен быть доступен для просмотра всеми участниками команды.
Процесс управления ЖТ:
- Создание ЖТ. Анкетирование и интервью. Сбор всех потенциальных требований и идей для продукта.
- Оценка и приоритизация. Оценка каждого элемента по его значимости и сложности, а затем установление приоритетов.
- Уточнение и детализация: Постоянное уточнение и детализация элементов ЖТ, особенно тех, что будут реализованы в ближайших итерациях.
- Планирование этапов: Выбор элементов из ЖТ для включения в очередные этапы и ЛТ.
- Ревизия и адаптация: Регулярный пересмотр ЖТ для его актуализации в соответствии с изменяющимися потребностями и условиями.
Управление журналом требований – это итеративный процесс, который требует постоянного взаимодействия между командой и заинтересованными сторонами. Эффективное управление ЖТ помогает обеспечить, что команда всегда работает над задачами, максимально приносящими ценность бизнесу и пользователям.
Лист требований (ЛТ)
Этот вид документа в технологии ТБР служит основой для формализации требований, описания способа разработки и тестирования и по-задачного планирования этапа работ.
По своей сути, он один заменяет несколько проектных документов, которые составляются в рамках технологии ТКВ: ТЗ, Технический проект, Программа и методика испытаний, План-график работ. Качество этих документов напрямую влияет на успех всего проекта.
Как видно из рисунка структура этого документа довольно проста. Вместе с тем важно соблюдать основные принципы при его составлении:
- Ясность и Конкретика: ЛТ должно быть написано ясно и понятно, чтобы избежать двусмысленности и недопонимания.
- Детализация: Все требования и описание способа реализации должны быть детализированы и в полной мере описаны для обеспечения полного понимания задач и ожиданий.
- Гибкость: ЛТ должно быть достаточно гибким, чтобы позволить вносить изменения в процессе разработки.
- Согласование: ЛТ должно быть согласовано со всеми заинтересованными сторонами проекта.
Приоритезация требований
Метод MoSCoW (Must have, Should have, Could have, Won't have) является инструментом для определения и управления приоритетами в технологии ТБР. Он позволяет команде проекта сфокусироваться на наиболее важных задачах и определить, какие требования из Журнала требований должны быть реализованы в первую очередь, а какие в последующие. Более подробно об этом методе можно прочитать в нашей статье.
Ролевая модель
Вот детализированное описание ролей на в рамках технологии ТБР:
Руководитель проекта исполнителя (РПИ):
В контексте управления проектами, руководитель проекта исполнителя отвечает за непосредственное управление проектом, гарантируя выполнение работ и достижение целей проекта в соответствии с требованиями заказчика. Он или она также обеспечивает коммуникацию и координацию между всеми членами команды проекта. Основные функции:
- Проводит совещания.
- Планирует и контролирует ход выполнения работ.
- Организует рабочую среду для команды.
- Исполняет условия договора.
- Разрешает противоречия и защищает команду от отвлекающих факторов.
Руководитель проекта заказчика (РПЗ):
Руководитель проекта заказчика, с другой стороны, служит связующим звеном между конечными пользователями и исполнителем проекта. Он отвечает за то, чтобы требования и ожидания пользователей были четко сформулированы и чтобы конечный продукт соответствовал этим требованиям. РПЗ также участвует в процессе приемки проекта, проверяя, соответствует ли работа установленным стандартам и требованиям пользователей
- Представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
- Организует приемку-передачу результатов работ.
- Организует взаимодействие команды исполнителя с функциональными заказчиками.
Команда исполнителя: Выполняют задачи проекта
Команда заказчика: Формулируют требования и участвуют в тестировании продукта.
Ролевая модель проекта выполняемым по ТБР обычно используется для определения обязанностей, ответственности и взаимодействия между различными сторонами, участвующими в проекте. Это помогает обеспечить, чтобы все аспекты проекта были покрыты и что каждая сторона знает свои задачи и ожидания.
Регламентированные мероприятия
Методология ТБР включает в себя ряд обязательных мероприятий, направленных на эффективное управление проектами и достижение быстрых результатов. Вот подробное описание каждого из мероприятий:
Планирование этапа – включает вопросы на этапе планирования, такие как:
- Какую ценность можно добавить продукту на следующем этапе?
- Как организовать работу, необходимую для создания ценности?
Команда должна учитывать журнал требований, последний инкремент продукта, среднюю скорость работы, ограничения, наложенные бизнесом, и результат планирования должен содержать границы работ, описание результата работ, план выполнения работ и стоимость работ.
Ежедневная планерка – это короткие совещания продолжительностью до 15 минут, во время которых команда обсуждает:
- Что было сделано вчера?
- Что будет сделано сегодня?
- Какие проблемы и препятствия возникли?
Проведение испытаний – испытания проводятся согласно программе, зафиксированной в ЛТ, а их результат - в протоколе тестирования, при участии функциональных заказчиков, и по результатам испытаний подписывается протокол.
Подведение итогов – рекомендуется проводить в конце каждого этапа для:
- Выявления "слабых мест" в процессах работы команды.
- Планирования улучшений процесса.
- Недопущения перерастания конфликтов в команде в что-то большее.
Эти регламентные мероприятия являются ключевыми элементами адаптивного управления проектами в рамках ТБР, они способствуют постоянной корректировке работы и постоянному улучшению процессов.
Заключение
В этой статье мы рассмотрели различные аспекты ТБР, а также общие принципы и важность документирования в процессе разработки и внедрения программных продуктов, поскольку оно обеспечивает ясность, согласованность и эффективность коммуникации внутри команды и с заинтересованными сторонами.
ТБР, как и любой другой подход, имеет свои сильные и слабые стороны. Ее выбор должен опираться на тщательный анализ и понимание конкретных задач и целей проекта. В конечном итоге, успех в разработке программного обеспечения зависит не только от выбранной технологии, но и от умения команды эффективно ее применять, адаптируя под динамично меняющиеся условия и требования проекта.
Если статья была полезна, ставьте палец вверх и подписывайтесь на канал. Свои вопросы и комментарии по теме пишите под статьей или отправляйте нам напрямую. Контакты для связи с нами:
Telegram
Проектный офис erp.lab@1cbit.ru
