Управление проектами по Технологии быстрого результата

Планирование работ

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

Основные мысли

В результате изучения лекции слушатель будет способен:
1. Объяснить разницу между юридическим и проектным определением роли заказчика.
2. Описать процедуру ограничения объема работ через приоритизацию бизнес-целей.
3. Сформулировать критерии для согласования состава и сроков выпуска релизов.
4. Проанализировать риски и негативные последствия реализации требований для принятия заказчиком взвешенного решения.
5. Обосновать необходимость быстрой оценки трудозатрат без избыточных временных потерь.
6. Разработать подход к динамическому перепланированию графика при поступлении новой информации.
7. Составить регламент обработки срочных вопросов с четкими критериями их определения.
Показывать лекцию целиком
Краткое изложение
Записаться
Определение роли заказчика

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

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

Функции заказчика в планировании быстрого результата

Для достижения быстрого результата заказчик выполняет три ключевые задачи:
1. Ограничение объема работ
Заказчик определяет бизнес-цели проекта и конкретные бизнес-требования, подлежащие автоматизации. Это позволяет очертить границы системы.
2. Приоритизация
Требование «сделать всё и сразу» несовместимо с быстрым результатом. Попытка реализовать весь функционал одновременно ведет к затягиванию сроков и неопределенности. Заказчик обязан расставить приоритеты бизнес-целей.
3. Согласование релизов
Команда проекта распределяет приоритизированные требования по релизам и представляет план заказчику. Он должен согласовать состав и сроки выпуска каждой версии, четко понимая, какую пользу принесет конкретный релиз, и при необходимости скорректировать план.

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

Функции исполнителя (команды проекта)

Исполнитель решает следующие задачи:
1. Оценка трудозатрат
Необходимо быстро оценить стоимость и время реализации бизнес-требований. Важно помнить принцип: система оценки не должна быть дороже оцениваемого результата. Оценка не может длиться месяцами, иначе теряется сам смысл быстрого старта. Нужно научиться давать быстрые оценки и затем укладываться в них.
2. Анализ последствий и рисков
Команда обязана провести идентификацию и анализ рисков реализации требований. Задача специалистов — честно обрисовать заказчику полную картину и предупредить о негативных последствиях, позволяя ему принять осознанное решение. Такой подход минимизирует ненужные затраты и укрепляет доверие.
Пример из практики: Заказчик настаивал на перестройке системы бюджетирования под свои подходы, основанные на электронных таблицах, игнорируя идеологию коробочного продукта. Только постановка задачи заняла 160 человеко-часов, а кодирование потребовало нереальных ресурсов. Увидев результат, противоречащий общей логике системы, заказчик потребовал вернуть всё обратно. Финансовые и временные потери были оплачены, но ситуация несла и репутационные риски. Чтобы избежать подобного, необходимо всегда согласовывать с заказчиком последствия его решений.
3. Организация эффективной разработки
Команда выстраивает процессы так, чтобы разработка была быстрой и позволяла оперативно готовить очередной релиз к вводу в эксплуатацию.
4. Планомерное снижение технологических рисков
В соответствии с приоритетами заказчика необходимо минимизировать технические неопределенности. Рискованные и непонятные требования желательно реализовать в начале проекта, а стабильные и хорошо изученные оставить на потом.

Динамическое управление планом

Перепланирование — естественное состояние проекта. План не может быть статичным документом, он должен постоянно оставаться актуальным.

• Инструмент управления: План-график — основной инструмент руководителя проекта. Без него управление невозможно.
• Когда вносятся изменения: План корректируется при поступлении любой новой информации: выполнении задачи, задержке сроков, добавлении новых работ на основе утвержденных запросов на изменения.
• Анализ отклонений: Руководитель проекта постоянно сравнивает актуальный план с базовым, анализирует отклонения и прогнозирует, куда придет проект при сохранении текущих тенденций. Результаты прогноза демонстрируются заказчику и спонсору.

Регламент работы со срочными вопросами

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

Ключевые элементы регламента:
• Четкое и однозначное определение того, что считается срочным вопросом.
• Список представителей заказчика, уполномоченных принимать решения по таким вопросам.
• Порядок действий, который будет действовать в проекте.

Обновленный план верифицируется и согласуется с советом проекта (или советом по управлению изменениями) на регулярных совещаниях.

Краткие итоги
Центральной идеей эффективного планирования является смещение фокуса с тотального документирования на создание управляемой ценности через диалог и адаптацию. Успех быстрого результата закладывается не инструментами календарного планирования, а четким разделением зон ответственности между заказчиком и исполнителем. Заказчик выступает не просто источником финансирования, а активным архитектором ценности продукта, принимающим на себя сложную роль по отсечению второстепенного функционала. Без его волевого решения о приоритетах проект обречен на распыление ресурсов и имитацию прогресса. Приоритизация здесь является не просто сортировкой списка пожеланий, а инструментом концентрации усилий на ограниченном участке, что позволяет получить обратную связь и ощутимый результат до исчерпания бюджета. Смещение ответственности исполнителя с простого кодирования на экспертную аналитику рисков меняет саму природу взаимодействия с заказчиком. Команда выступает в роли профессионального советника, обязанного честно визуализировать «цену» каждого технического решения, включая потенциальный вред от внедрения требований, противоречащих архитектурной логике системы. Практика показывает, что молчаливое согласие на ошибочные требования заказчика, мотивированное страхом конфликта или желанием увеличить объем работ, неизбежно приводит к двойным потерям: финансовым и репутационным. Откровенность на этапе анализа последствий создает атмосферу партнерства, в которой решения принимаются взвешенно и осознанно. Организация планирования переосмысливается как непрерывный процесс ситуационной адаптации. План перестает быть застывшим обещанием и трансформируется в динамическую прогнозную модель. Его актуальность поддерживается не бюрократической процедурой, а ежедневной дисциплиной фиксации микроизменений. Это превращает график из формального отчета в инструмент навигации, позволяющий руководителю предвидеть будущие траектории проекта и своевременно инициировать переговоры о реалистичных сроках. Кроме того, формализация правил обработки срочных и критических запросов через отдельный регламент лишает хаос легитимности, создавая безопасный коридор для систематической работы без ущерба для стратегических целей.
Определение роли заказчика
В рамках методологии быстрого результата термин заказчик используется не в юридическом смысле (сторона по договору), а в контексте управления требованиями. Заказчик — это лицо, определяющее характеристики и свойства конечной информационной системы. Это может быть сотрудник вашей же организации. Наличие идентифицированного заказчика критически важно: если его нет, невозможно определить требуемый результат проекта.

Задачи заказчика
Для успешного старта заказчик должен выполнить три функции:
1. Ограничить объем: Определить бизнес-цели и бизнес-требования для автоматизации.
2. Приоритизировать: Отказ от приоритетов в пользу «всего и сразу» ведет к медленной работе без четких перспектив завершения. Заказчик обязан выделить главные бизнес-цели.
3. Согласовать релизы: Утвердить состав и сроки выпуска версий системы, понимая выгоду от каждого этапа. Это дает команде уверенность в правильности принимаемых решений.

Задачи исполнителя (команды проекта)
Исполнитель отвечает за следующие аспекты:
1. Быстрая оценка трудозатрат: Анализ времени и стоимости реализации требований. Оценка должна производиться максимально оперативно, чтобы не тормозить проект (принцип: система подсчета прибыли не должна стоить больше самой прибыли).
2. Анализ последствий и рисков: Идентификация рисков и предупреждение заказчика о негативных сценариях. Команда обязана честно показывать полную картину, чтобы заказчик мог принять взвешенное решение. Это позволяет избежать ситуаций, когда реализованный функционал противоречит логике системы и требует дорогостоящего отката (как в примере с бюджетированием, где переделка подхода заказчика привела к напрасным тратам).
3. Организация разработки: Процессы должны обеспечивать быструю и эффективную подготовку релизов к вводу в эксплуатацию.
4. Снижение технологических рисков: При планировании в начале проекта следует реализовывать требования с наибольшей неопределенностью и рисками. Стабильные и понятные задачи можно оставить на потом.

Динамическое планирование
Перепланирование — это не экстренная мера, а естественное и регулярное состояние проекта. План не может быть статичным.

• План-график является настольным инструментом руководителя проекта и должен быть актуальным всегда.
• Триггеры для изменений: выполнение задачи, сообщение о задержке, добавление утвержденных запросов на изменения и любое другое событие, влияющее на сроки.
• Анализ и прогноз: Руководитель проекта регулярно сравнивает актуальный план с базовым, выявляет отклонения и демонстрирует заказчику и спонсору прогноз финала проекта при текущих тенденциях.

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

Выводы

1. Заказчик в проекте — это не юридическая сторона договора, а лицо, определяющее характеристики и свойства результата.
2. Отсутствие номинального заказчика делает невозможным определение конечных требований к системе.
3. Быстрый результат невозможен без жесткой приоритизации бизнес-целей заказчиком, так как стремление получить всё сразу затягивает сроки.
4. Состав и сроки релизов должны быть явно согласованы с заказчиком, который понимает свою выгоду от каждого этапа.
5. Оценка трудозатрат должна производиться быстро, чтобы не превращаться в отдельный дорогостоящий подпроект.
6. Команда обязана анализировать риски и честно предупреждать заказчика о возможных негативных последствиях его требований.
7. Игнорирование архитектурной логики системы ради требований заказчика ведет к финансовым потерям и техническому долгу.
8. Снижение технологических рисков требует реализации наиболее неопределенных требований на ранних стадиях проекта.
9. План-график является динамичным инструментом управления и требует постоянной актуализации при любых изменениях.
10. Перепланирование — непрерывный процесс прогнозирования на основе сравнения актуального состояния с базовым планом.
11. Руководитель проекта обязан демонстрировать заказчику прогноз развития ситуации для своевременной корректировки ожиданий.
12. Регламент срочных вопросов должен содержать четкие критерии их определения и полномочия для быстрого принятия решений.

Вопросы для самопроверки

1. Чем отличается понятие «заказчик» с проектной точки зрения от юридического определения в контексте данной лекции?
2. К каким последствиям для проекта приводит отсутствие явно назначенного заказчика?
3. Почему требование заказчика «сделать всё и сразу» несовместимо с технологией быстрого результата?
4. Какие три ключевые задачи должен решить заказчик на этапе планирования для ограничения объема работ?
5. По какому принципу определяется допустимая длительность процесса оценки трудозатрат на проект?
6. Почему прямой обязанностью команды проекта является анализ последствий реализации бизнес-требований?
7. Какая стратегия управления технологическими рисками позволяет минимизировать неопределенности в проекте?
8. Почему перепланирование считается естественным состоянием проекта, а не признаком плохого управления?
9. Какую роль играет план-график в прогнозировании будущего состояния проекта перед заказчиком и спонсором?
10. Какие типы задач подпадают под категорию «срочные вопросы» и почему для них нужен отдельный регламент?
11. Какую критически важную информацию должен содержать регламент обработки срочных вопросов?
12. Какие действия должен совершить руководитель проекта с планом-графиком при поступлении утвержденного запроса на изменение?
Предыдущее занятие Следующее занятие
Вернуться к учебному плану
^