Технология быстрого результата: принципы и ключевые практики

Определение и цели создания

Технология быстрого результата (ТБР) — это технология внедрения тиражных программных продуктов семейства «1С:Предприятие», направленная на получение быстрых, регулярных (в идеале — ежемесячных) результатов, имеющих ценность с точки зрения заказчика, и предполагающая снижение финансовых рисков. Другими словами, это технология, «...предполагающая снижение финансовых рисков, регулярное закрытие выполненных работ и обеспечивающая исполнителю получение регулярного финансирования на выполнение работ».

Хотя ТБР — методология управления проектами внедрения информационных систем (ИС), прежде всего, на базе тиражных продуктов «1С», однако ее принципы и практики могут применяться и при внедрении других продуктов, что повышает её ценность.

Технология ТБР была разработана как ответ на вызовы текущего момента, а именно:

• изменения стали постоянно действующим фактором, влияющим на все аспекты деятельности компаний;
• сократился горизонт планирования развития информационных технологий (ИТ);
• изменились парадигмы развития ИТ: период наступления «широким фронтом» и радикального изменения компании для реализации «лучших практик» постепенно уходит в прошлое, новая парадигма – короткие проекты с быстрой отдачей и последовательное и постепенное изменение компании.

Именно в ответ на эти требования фирма «1С» и создала методологию ТБР. Следует отметить, что ТБР – не единственная методология управления проектами внедрения тиражных продуктов «1С».

Для простых внедрений типовых продуктов фирма разработала методологию стандартного внедрения. Длительные и сложные корпоративные проекты ведутся по методологии корпоративного внедрения. В этой линейке проектных методологий «1С» ТБР занимает особое положение, находится как бы «посередине».

Ценности, принципы и практики ТБР

Безусловно, ТБР впитала в себя опыт партнерской сети «1С» по внедрению систем в условиях повышенной неопределенности и необходимости получить быстрые результаты. Но не только. Поставив задачу разработать методологию получения быстрых результатов, авторы обратились к накопленному в мире опыту и прежде всего — к быстрым и гибким Agile-технологиям разработки программного обеспечения (ПО). В частности, ТБР несет в себе много черт, характерных для методологии XP (от англ. Extreme Programming, экстремальное программирование).

Следует заметить, что XP — это методология разработки ПО, а ТБР — методология внедрения тиражного ПО. И в этом принципиальная разница. Однако принципы и практики XP оказываются весьма полезными и продуктивными и при внедрении тиражных систем. Таким образом, в некотором смысле ТБР — это реализация идей Agile для внедрения тиражных продуктов. И в этом ее большая ценность.

Описание методологий, ориентированных не на процессы и области знаний, а на конкретные принципы и практики, удобно проводить в следующей структуре (см.рис. 1):

ценности + принципы + практики.

1. Ценности — это набор убеждений, или аксиом, которые служат основой для принимаемых решений и значимы для всех участников проекта внедрения. Для многих очень сложно изменить свои убеждения. Если команда принимает эти ценности, у неё изменяется командное поведение, принципы работы и даже привычки. Ценности определяют стиль мышления и способы взаимодействия в команде.
2. Принципы — это мост между ценностями и практиками, они разъясняют характер ценностей и раскрывают содержание каждой из них, выражают требования, касающиеся конкретных элементов проекта: модели жизненного цикла, организации проекта, структуры команды и др.
3. Практики (инструменты) — набор активностей, соблюдая которые можно повышать вероятность успеха. Принципиально, что набор практик может меняться от команды к команде согласно ситуации в текущем проекте, но ценности и принципы при этом остаются неизменными.

  Рис. 1. Ценности, принципы и наиболее важные практики TБР.

 Примечания

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

2 Аналогичный принцип есть и в Agile–методологиях. «Первая ценность XP — это коммуникация. Проблемы, которые возникают в процессе работы над проектами, почти всегда связаны с тем, что кто-то не сказал кому-то о чем-то важном, — пишет Кент Бек в книге «Экстремальное программирование» (Питер, 2002). — ... Для всех очевидно, что общение должно быть открытым и искренним, однако зачастую приходится сталкиваться с обратным». Причем ТБР делает акцент не только на эффективных коммуникациях в рамках проектной команды, но и на тесных и быстрых коммуникациях с заказчиками ИТ-системы. Если команда проекта будет бегать за всеми лицами, принимающими решения, о быстрых результатах придется забыть.

3 ТБР исходит из того, что требования к ПО постоянно меняются, поэтому грамотно спроектировать систему со всеми подробностями в начале проекта невозможно. Приходится создавать ИТ-систему итеративно. Однако при этом необходимо соблюдать условие простоты дизайна, иначе в какой-то момент система окажется неработоспособной.

Отметим, что практики ТБР эффективно работают не поодиночке, а в комплексе, и при этом комплекс практик позволяет соблюсти не один, а сразу несколько принципов. Наиболее важные практики и инструменты, которые поддерживают выполнение принципов ТБР следующее.

Практики (инструменты) снижения трансакционных издержек в проекте:

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

Практики (инструменты) роста доверия между заказчиком и подрядчиком в ходе проекта:

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

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

• четкая технология управления требованиями;
• быстрое и технологичное обнаружение дефектов, запросов на изменения;
• процесс обработки обращений и запросов на изменения;
• регулярное планирование и перепланирование работ и ресурсов, практика «игры в планирование»;
• архитектура системы программ «1С:Предприятие» и средства разработки.

Практики (инструменты) достижения компромисса между качеством и временем/ объемом/ресурсами:

• высокоэффективные коммуникации с заказчиком проекта;
• применение закона Парето, который можно переформулировать так: 80 % требований можно с достаточным качеством реализовать за 20–50 % ресурсов и времени, остальные 20 % требований, а также повышение качества потребуют всего оставшегося времени и бюджета.

Выделим несколько важнейших инструментов и практик ТБР:

 1). Команда проекта. В команде проекта нет разделения на заказчика и подрядчика; команда проекта едина, хотя и состоит из тех и других сотрудников. Участники команды проекта доверяют друг другу. В ней существует четкое разделение зон ответственности, каждый член команды проекта делает то, в чем более всего компетентен (рис. 2).

Рис. 2. Разделение зон ответственности в команде проекта

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

3). Информационная система, фиксирующая несоответствия и запросы на изменения. Это необязательный, но крайне желательный инструмент ТБР. Информационная система необходима для сокращения трансакционных издержек на передачу несоответствий и запросов на изменения всем членам команды проекта, а также для контроля сроков внесения изменений.

Комментарии 0