Рубрика «CIO/Управление ИТ». Руководитель отдела программных разработок ООО «Смарт Процессинг» Илья Семенов: «Гибкое управление проектами в условиях неопределенности и быстро меняющихся планов»

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

Оцени то, не знаю что, сделай так, не знаю как

Когда я начал карьеру ИТ-менеджера проектов, то столкнулся с проблемой плохо формализованных требований заказчиков. Тогда я не понимал, во что выльется срыв сроков. Все сводилось примерно к такому виду постановки задач: оцени то, не знаю что, сделай так, не знаю как. Планирование на тот момент заключалось в оценке требований заказчика и выдаче какого-то срока реализации. Требования, как правило, умещались на страничку формата A4, в лучшем случае на две. Следствие: неправильно оцененные границы проекта. Ближе к концу проекта наступал кризис, и приходилось смотреть правде в глаза – система не работает.

Пару раз обжегшись со сроками, я обратил свой взор на альтернативные техники, практикуемые в области управления проектами. И здесь мне попались итеративные методологии Agile, которые последовательно, но верно ведут проект мелкими релизами к финишной прямой, каждый релиз – это готовый продукт. Даже  если сроки изначально не определены, к концу проекта заказчик получает работающий продукт, удовлетворяющий его обязательным требованиям. В частности, я обратил внимание на scrum-подход. Практика показала, что этот метод  ведения проектов используют как малые команды, так и целые компании, включая производственные. Один из плюсов таких подходов – это избавление от необходимости говорить заказчику неправду: «К deadline мы реализуем все перечисленные требования».

Энтропия проекта
Прирост информации равен утраченной неопределенности.
Клод Шеннон

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

Стоит ли инвестировать средства и время в то, что с большой вероятностью будет изменено? Как отмечал Эдвард Йордон в «Путь камикадзе», статистика показывает, что в среднем оценка времени на реализацию долгосрочных проектов имеет ошибку минимум в полтора раза. В моей практике, если проект был рассчитан на 1 год, полутора лет разработки не миновать.  Если на 2 года, то тремя годами не обойтись. С планированием мелких проектов ситуация чуть лучше и степень оценки более точная.

Естественно, что если в начале проекта была сделана большая аналитическая работа по спецификации узлов системы и приоритизации функций с участием архитекторов и разработчиков, то проблем может и не возникнуть. Но как часто это происходит? Как правило, вся детализация проекта, так или иначе, превзойдет запланированное время. В момент работы над проектом задачи имеют свойство детализироваться, распадаться на подзадачи, и сумма времени всех подзадач начинает превосходить запланированное время на задачу в целом. И так происходит каждый раз! Часто я слышу вопросы: кто неправильно оценил, почему дали неправильную оценку? Искать виновных в этом случае не нужно.  Недооценка планов – это причина, по которой нет смысла планировать точную дату всего проекта. И это только вершина айсберга. Если копнуть чуть глубже, то выясняется, что предметная область оказывается не статичной, а меняется, и план проекта, который описывает временной срез на момент проектирования системы, уже не удовлетворяет ситуации на данный момент. А что делать, если контракт уже подписан?

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

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

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

Нет ничего идеального! Поэтому есть и минусы в быстрых методологиях, которые ведут к тому, что, не зная всего проекта в целом или его глобальной цели, команда может принять неправильное решение в построении архитектуры разрабатываемой системы. Поэтому в данном случае необходимо обсуждать  с командой требования к системе в целом, чтобы заложить их на начальном этапе разработки. Именно поэтому имеет смысл подключать архитектора проекта на ранних стадиях, чтобы заложить базис проекта. Необязательно описывать все возможные функции и задачи, которые нужно реализовать, со временем они устареют. Но концепцию проекта изложить нужно. Так или иначе, что-то возможно придется переделывать, то есть заниматься рефакторингом. А когда есть хорошо спроектированный «скелет» архитектуры, на его основе легко реализуются новые функции. Команда с каждой новой итерацией получает все новые и новые задачи, узнает о проекте или подпроектах все больше и больше.
То же самое касается каких-то больших модулей, которые владелец продукта доносит до команды постепенно. Риск может быть в том, что структура модуля будет реализована неправильно относительно глобальной цели. В моей практике был один топ-менеджер, который всем менеджерам продуктов доносил идею о пользе нераскрытия глобальных планов проекта разработчикам. Его идея заключалась в том, чтобы команда разработки получала всё мелкими порциями. Как результат такого подхода – большое количество переделок на уровне архитектуры. Этого допускать, конечно, не рекомендуется.

Оценивая быстрые методологии разработки, можно с уверенностью заключить, что это не панацея от всех болезней, это просто некий механизм или framework, позволяющий минимизировать риски проекта, например, путем внедрения заказчика в процесс планирования каждой конкретной итерации проекта. Давайте рассмотрим китов, на которых базируются гибкие методологии разработки (Agile software development).

Манифест Agile

Взглянем на манифест Agile – Manifest of Agile Software Development, предложенный его основоположниками (http://agilemanifesto.org/). 

В переводе он выглядит так:

• Люди и их взаимодействие важнее, чем процессы и инструменты.
• Работающий продукт  важнее, чем исчерпывающая документация.
• Сотрудничество с заказчиком важнее, чем согласования условий контракта.
• Готовность к изменениям  важнее, чем следование первоначальному плану.

То есть, не отрицая важности того, что перечислено справа, мы всё-таки больше ценим то, что упоминается слева.

Можно увидеть по определениям манифеста, что он направлен на удовлетворение потребностей клиента, а именно на создание продукта, удовлетворяющего меняющимся требованиям. Рассмотрим, как это происходит, на примере scrum-подхода.

Scrum

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

В планировании итерации принимают участия люди с разными ролями:

• Product Owner – человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон;
• Scrum Master – тот, кто занимается процессами и работает в качестве руководителя проекта;
• Scrum Team – команда разработчиков (архитекторы, программисты, тест-инженеры, аналитики).

Одним из артефактов подхода является «Журнал историй» (Product Back log), в котором отмечаются задачи и приоритеты. Именно из этого журнала берутся задачи на каждую следующую итерацию.  Кстати, заказчик (Product owner) имеет полный контроль над журналом.

Начинается разработка, ежедневно происходит контроль разработки самой командой за счет ежедневных коротких статус-митингов (standup).

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

Нужно ли планирование в Agile?
План всегда уточняется!

Многие воспринимают Agile как методы, в которых не нужно заниматься долгосрочным и краткосрочным планированием. И что релиз проекта будет тогда, когда сможет сделать команда, без определенного срока. Хотя на самом деле планирование никто не отменял. Более того, без него трудно заниматься управлением ресурсами для достижения целей проектов.
Поэтому это миф, что в Agile нет планирования. Более того, оно по факту происходит более детально, чем в других методологиях разработки, например, классической последовательной.

Проекты, работающие на базе Agile, делят задачи на «истории» – функции, которые можно типизировать по приоритетам, например, «обязательные», без которых смысл реализации проекта бесполезен, «достаточные», без которых функции проекта будут бедны, и «второстепенные», которые нужны, но без них можно обойтись. На этапе формирования итерации (спринта) Scrum команда вместе с владельцем продукта приоритизируют наиболее ценные задачи, оценивают стоимость разработки, продолжительность, тем самым планируя, делая оценку проекту и постоянно его уточняя.

Альтернативные подходы Agile

Kanban – Agile-подход, позволяющий организовать процесс выпуска продукта точно в строк. Успешно используется в компании Toyota. Применяется многими производственными компаниями. Суть метода в непрерывном процессе производства. В Kanban отсутствует остановка процесса над разработкой, он непрерывный. Есть пул задач, который непрерывно поступает на команду. Оценка затрат на выполнение задач в данном методе вообще отсутствует, считается, что по определению она будет ошибочной. Но можно опытным путем оценить время работы над задачей.

Если рассматривать, например, «стартап»-проекты, то в них часто поток задач быстро меняется даже в условиях двухнедельного планирования, приоритеты имеют свойства изменяться на лету, за счет необходимости развития конкурирующих направлений. А команды в стартапах, чаще всего, небольшие. Встает задача еще более гибкой разработки и управления продуктом в таких изменяемых условиях. На помощь приходит комбинированный Agile, основанный на Scrum и Kanban, – Scrum-ban. Метод позволяет справиться с быстроменяющимся непрерывным потоком (срочных) задач.

Синергетика команды проекта

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

Рассмотрим преимущества самоорганизующихся команд:

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

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

Производительность команды

В вялотекущем проекте, разрабатываемом классическим методом, производительность команды в лучшем случае стабильная, а обычно ниже среднего, из-за отсутствия заинтересованности. К завершению проекта, как следствие, скачкообразно увеличивается объем сверхурочных работ. Вызван он не только из-за вялости работы над проектом в начале и середине этапа разработки, но и из-за ошибок планирования. Первое устраняется вовлечением команды в проект на 100 %, второе устраняется просчетом рисков, постоянным уточнением статуса разработки.

Вовлеченная команда должна быть заинтересована в конечном результате, проект должен быть интересен, команда должна быть в «потоке» разработки, заряженной на 100 %. Для этого есть командная разработка, ежедневные standup-ы, совместные митинги для обсуждения архитектуры, совместное решение проблем, вовлечение владельца продукта в процесс разработки.

Однако это состояние довольно хрупко и сломать его довольно легко. Представьте человека, находящегося в «потоке». Он погружен в работу, живёт ею, на нем наушники, и он абстрагирован от внешнего мира. Мозг сконцентрирован на решении какой-то интересной задачи. И тут неожиданно заходит топ-менеджер с мировыми новостями, которые почерпнул с новостного портала, или, еще хуже, начинает заниматься микроменеджментом. Следствие этого – «поток» прерван, раздражённость, эффективность падает, открывается страница социальной сети.

Каждого члена команды нужно заряжать, как электрический конденсатор. Энергия всей команды будет равна сумме всех энергетических ёмкостей членов команды. Как в электротехнике.

Для максимальной энергии в любой команде нужно поддерживать состояние «потока» и пытаться всеми усилиями его не тревожить. В этом случае к концу срока разработки скорее всего не понадобятся сверхурочные работы.

В Scrum приветствуется привлечение владельца продукта, как эксперта в области, но он не допускается в процесс разработки. Это же касается и других подходов, здесь уже затрагивается вопрос психологии программирования, команд разработки. Учитывать эти вопросы следует, будь то scrum-команда или какая-либо другая.

Экспансия гибких методологий

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

Классические схемы не всегда эффективны, особенно в условиях динамично меняющихся предметных областей.

Команда проекта должна быть готова к гибкой методологии. Кого-то, в какой-то мере пассивного по своей природе, нужно вести за собой, используя директивный подход, а в каких-то случаях лучше использовать гибкий подход к управлению. И в каждом конкретном проекте нужно уметь выбирать нужный подход к людям.

Быстрые методологии разработки стремительно входят в обиход. Они используются вендорами, консалтинговыми компаниями, отделами разработки внутри производственных компаний и многими другими. Становится нормой следовать практикам, которые члены команды считают наиболее правильными, чем навязывать строго регламентированные методологии. Отсутствие каких-либо стандартов само по себе ведет проект в неизвестность. Но чему-то придерживаться все же следует.

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

Гибкие методологии не исключают и порядка в инфраструктуре системы разработки, и обязательно включают такие вещи, как:

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

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

Экспансия Agile проникает и в более сложные подходы разработки, например, есть адаптация Microsoft Solutions Framework (MSF) for Agile корпорации Microsoft, или модифицированный IBM Rational Unified Process (RUP) в виде Agile Unified Process, или HP Agile Accelerator, который помогает предприятиям внедрять приложения. Классический метод Waterfall почти отошел или еще используется в строго регламентированных компаниях. Следует отметить, что Agile, в частности Scrum, совместим с такими стандартами, как ISO 9001, CMMI.

Сейчас мы находимся в самом разгаре развития гибких методологий, команды применяют новые подходы, обнаруживают неудобные моменты, создают гибридные схемы работы, например, Scrum-ban, накапливают знания в области управления программными продуктами.

Мы находимся на этапе развития гибких методологий разработки и, рано или поздно, с новыми подходами столкнутся все.