Назначение технологии быстрого результата и предпосылки создания
Многообразие технологий и их общие черты
Существует множество подходов к ведению проектов. С одной стороны, это семейство
гибких (agile) технологий, нацеленных на скорость и адаптивность:
экстремальное программирование (XP),
Scrum,
Rational Unified Process for Small Projects и другие. С другой —
тяжелые полномасштабные технологии: PRINCE2, большой
Rational Unified Process (RUP),
SPC Essential Set, методики Министерства обороны США, серия стандартов
ISO 15504 (SPICE), а также отечественный
ГОСТ-34, который по своей сути тоже является технологией.
Несмотря на различия, у всех этих технологий есть общие структурные элементы:
1.
Инструменты планирования.
2.
Инструменты управления требованиями. Это особенно критично для ИТ-проектов, так как, по общеизвестной статистике, основная причина провалов — именно плохое управление требованиями.
3.
Мониторинг и контроль. Здесь реализован полный
управленческий цикл PDCA (Plan-Do-Check-Act).
4.
Специфические дисциплины, зависящие от предметной области. В нашем случае это архитектура программных систем, конфигурационное управление, проектирование, организация
верификации и валидации и так далее.
Проблема универсальности и необходимость адаптации
Теоретически любую из перечисленных технологий можно успешно применять. Но важно осознавать: каждая технология — это обобщение конечного опыта, поэтому она не является «серебряной пулей» и не может быть абсолютно универсальной. У любой технологии есть сильные и слабые стороны, и применять её там, где она объективно неработоспособна, нельзя.
Существует и другая крайность: часто технологию пытаются использовать фрагментарно. Например, выдергивают один документ из целостного набора (допустим, содержащего 60 документов), имитируют применение технологии и закономерно не получают результата.
Целостность теряется, польза исчезает, и делается ложный вывод о неработоспособности всего подхода. Технологию нужно использовать целиком, так, как она задумана.
Поскольку технологии общего назначения достаточно универсальны, перед стартом требуется их многоуровневая адаптация.
Адаптация проводится по пяти направлениям:
1.
К компании. Учитываются конкретные люди, корпоративная культура, знания, умения, навыки, опыт, компетенции, регламенты и привычки.
2.
К предметной области. Разработка онлайн-системы, системы реального времени, бизнес-системы или системы жизнеобеспечения имеют кардинально разные особенности.
3.
К инструментальным средствам. Адаптация к среде разработки, системам управления жизненным циклом проекта, контроля изменений и так далее.
4.
К уровню технологической зрелости участников. Это критически важный пункт. Нельзя требовать от людей решения тригонометрических уравнений, если они еще не освоили таблицу умножения. Многие технологические инициативы терпят крах именно из-за завышенных требований к неготовому персоналу. Развитие должно быть пошаговым.
5.
К внешним условиям проекта. Руководитель часто ошибочно ставит себя в положение «сферического коня в вакууме», пытаясь применить идеализированные инструменты без учета реальной специфики.
Происхождение и составные части ТБР
Технология быстрого результата (ТБР) не является изобретением еще одного «велосипеда». Она базируется на общепринятых в мире принципах, методах и инструментах, переосмысленных через призму практики. Её основа —
обобщение опыта партнерской сети фирмы «1С».
Ключевое преимущество ТБР заключается в том, что она
изначально и в значительной степени адаптирована. Её не нужно с нуля подгонять под специфику, так как при разработке уже были учтены:
•
Организации: партнеры фирмы «1С».
•
Предметная область: автоматизация бизнес-систем (не real-time или системы жизнеобеспечения).
•
Инструментальные средства: платформа «1С:Предприятие».
•
Специалисты: с определенным уровнем подготовки (от «1С:Профессионала» до «1С:Эксперта»).
•
Опыт: практика работы с конкретными программными продуктами.
Составные части, из которых выросла ТБР:
1. Опыт партнерской сети.
2. Опыт внедренческих проектов самой фирмы «1С», где обкатывалась бета-версия методологии.
3. Сценарий стандартного внедрения и сохранившие актуальность наработки из предыдущей технологии «1С:Профкейс».
4. Идеологический подход семейства
Agile. ТБР можно по праву отнести к гибким методологиям, близким по духу к экстремальному программированию.
Назначение Технологии быстрого результата
ТБР — это
технология управления проектом внедрения программных продуктов на платформе «1С:Предприятие».
Необходимо четко разделять:
•
Управленческая технология (ТБР): регулирует организацию работ, управление командой, рисками и заказчиком.
•
Технология выполнения основных процессов (внедрения): описывает, в какой последовательности запускать систему, какие справочники заполнять и какие вводить начальные данные. Это не предмет ТБР.
Область применения технологии:
• Предназначена для
партнеров и клиентов фирмы «1С» (является открытой и может быть приобретена любой заинтересованной стороной).
• Ориентирована на внедрение
тиражных (типовых или отраслевых) решений.
• Эффективна в рамках комплексных проектов на
малом и среднем рынке, а в ряде случаев — и в
корпоративном сегменте.
Ключевые цели ТБР:
1. Получение
быстрого,
регулярного и полезного для заказчика результата без существенного снижения уровня качества.
2.
Снижение финансовых рисков для обеих сторон, участвующих в проекте автоматизации.
Краткие итоги
Современный ландшафт проектных методологий насыщен как тяжелыми (RUP, PRINCE2), так и гибкими (Scrum, XP) подходами. При всем их внешнем различии архитектура любой зрелой технологии включает типовые узлы: от планирования и контроля до управления требованиями, которые являются критическим фактором успеха в ИТ-сфере. Однако ключевое заблуждение, приводящее к провалам, кроется в восприятии этих инструментов как «серебряной пули». Ценность представляет не просто выбор методологии, а глубокая, многоступенчатая адаптация её полного, целостного набора практик. Фрагментарное изъятие отдельных элементов разрушает систему и дискредитирует сам подход.
Эффективная трансформация процессов невозможна без учета текущего уровня технологической зрелости команды. Попытка форсировать внедрение сложных инструментов без фундаментальной базы столь же бесперспективна, как обучение высшей математике без знания арифметики. Именно поэтому возникла потребность в решении, которое снижает порог входа и нивелирует риски адаптации. ТБР заполняет этот пробел, снимая с пользователя нагрузку по первичной настройке универсальных фреймворков. Будучи «выращенной» на стыке мирового Agile-опыта и многолетней практики экосистемы «1С», данная технология изначально представляет собой предадаптированный инструмент. Её специфика жестко ограничивает область применения (автоматизация бизнес-задач, тиражные решения, платформа «1С:Предприятие»), но именно эта фокусировка позволяет добиваться прогнозируемого качества.
Практическая значимость такого подхода заключается в смещении фокуса с процесса ради процесса на регулярную поставку полезного заказчику результата. Управленческая сущность ТБР отделяет организацию взаимодействия и рисков от сугубо технических операций по запуску системы. Это позволяет в сжатые сроки выстроить прозрачный контур управления, радикально снижая финансовые риски обеих сторон и делая проект автоматизации предсказуемым, а не героическим преодолением хаоса.
1. Любая технология управления проектами (и тяжелая, и гибкая) базируется на едином фундаменте: планирование, управление требованиями, мониторинг и контроль (цикл PDCA).
2. Плохое управление требованиями является статистически главной причиной провалов ИТ-проектов.
3. Не существует универсальной технологии, одинаково эффективной для всех типов проектов и организаций.
4. Выборочное («лоскутное») применение отдельных инструментов разрушает целостность технологии и не приносит пользы, а часто вредит.
5. Технологию обязательно адаптировать к компании, предметной области, инструментарию, зрелости персонала и внешним условиям проекта.
6. Требования к методологии должны соответствовать уровню технологической зрелости команды: нельзя требовать сложных действий без освоения базовых.
7. Технология быстрого результата (ТБР) — это не новый «велосипед», а синтез мирового опыта (Agile) и наработок сети «1С».
8. ТБР изначально глубоко адаптирована под экосистему «1С» (платформа, типовые продукты, специфика партнерского бизнеса).
9. ТБР — сугубо управленческая технология; она не регламентирует технические операции по наполнению справочников или запуску подсистем.
10. Технология ориентирована на внедрение тиражных решений на предприятиях малого и среднего рынка, с возможностью применения в корпоративном сегменте.
11. Ключевая цель ТБР — получение быстрого, регулярного и полезного для заказчика результата без существенной потери качества.
12. Применение ТБР направлено на взаимное снижение финансовых рисков как для внедренца (партнера), так и для заказчика.
1. Какие четыре общих структурных элемента присущи большинству технологий управления проектами?
2. Почему управление требованиями считается наиболее критичным фактором успеха ИТ-проекта?
3. В чем опасность фрагментарного использования методологии (когда из целостного комплекта берут 1-2 документа)?
4. Перечислите пять ключевых направлений, по которым требуется адаптировать универсальную технологию перед внедрением.
5. Как отсутствие учета технологической зрелости команды может погубить инициативу по внедрению новой методологии?
6. Что значит метафора «сферический конь в вакууме» применительно к работе руководителя проекта?
7. Почему ТБР нельзя считать «изобретением велосипеда»?
8. Чем принципиально отличается управленческая технология внедрения (ТБР) от технологии выполнения основных процессов (содержательной части внедрения)?
9. Для какого класса программных продуктов и сегментов рынка в первую очередь предназначена ТБР?
10. Какие четыре компонента опыта легли в основу создания Технологии быстрого результата?
11. Почему ТБР относят к семейству гибких (Agile) методологий?
12. Какие две ключевые цели преследует внедрение ТБР на проекте?