В жизни многих обитателей софтверной индустрии иногда настаёт момент, когда им приходится нарисовать план проекта. Люди, что-то слышавшие об управлении проектами, читавшие книжки на эту тему (особенно книжки, не описывающие конкретную индустрию), а также учившиеся управлению проектами где-либо (в ВУЗе, на курсах и т.п.) чаще всего автоматически выбирают для создания этого плана Microsoft Project. Иногда использование MS Project навязывается руководством, клиентом, процессными стандартами в компании и т.п.
Для софтверных проектов выбор MS Project обычно крайне неудачен и ниже мы объясним почему, но сначала напомним несколько простых фактов о том, как устроены софтверные проекты, особенно в контексте заказной разработки.
Дисклеймеры и отмазы
Автор заранее извиняется за огромное количество используемых в тексте профессионально-жаргонных англицизмов, но считает, что с ними лучше, чем без них.
Автор ориентируется на проекты, исполняемые в основном наёмными работниками в рамках профессиональных компаний, не слишком маленьких и не слишком больших. Некоторые явные и неявные предположения, лежащие в основе текста могут не действовать в других организационных контекстах, например, в случае стартапов, фриланса или глобальных мастодонтов с сотнями тысяч сотрудников. Особенно это относится к двум предположениям:
- Члены проектной команды в среднем работают 8 часов в день и 40 часов в неделю и исключительно редко превышают эти уровни более чем в полтора раза.
- Основной целью исполняемых проектов является успешное решение бизнес-задачи клиента.
Бизнес-контекст: как делается софтверный проект
Эта глава ни в коем случае не является сколь бы то ни было полным описанием дисциплины управления софтверными проектами. Она описывает только самый базовый уровень сложности и вводит некоторые понятия.
Итак, если не вдаваться в детали, проект надо сначала продать, а потом исполнить.
Продажа
В ходе продажи мы должны с помощью порождаемых артефактов (эстимейты, планы проекта, пропозалы, etc.) ответить себе и клиенту на следующие вопросы:
- Scope. Что в результате проекта получится?
- Time. Сколько проект продлится? В какие моменты что будет происходить (обычно с точностью до поставок и фаз)?
- Cost. Сколько это будет стоить? Когда платить?
- Resources & Effort. Какие люди для этого нужны и в какие моменты? Сколько усилий и кого уйдёт на каждую из задач или элементов скоупа?
Другие вопросы, часто могущие лежать за пределами собственно «эстимейта» в узком смысле, но критичные для порождения полного плана проекта:
- Dependencies. Какие материалы, информацию, действия и т.п. проектная команда ожидает от клиента или от third parties? В какие моменты?
- Acceptance. Как мы определяем, что получившиеся в ходе проекта результаты соответствуют договорённостям и потребностям клиента?
Кроме того:
- В ходе продажи и торговли эстимейт и другие артефакты приходится переделывать по нескольку раз, часто в очень короткие сроки.
- Артефакты обычно существуют в форме файлов, обмен которыми происходит по электронной почте.
- Клиенты любят видеть cost breakdown по очень разным критериям – особенно по частям системы и частям функциональности – а также задавать вопрос «если вот это выкинуть, как изменятся цена и сроки?».
Исполнение
В ходе исполнения проекта мы следим за происходящим с помощью инструментов управления проектом и периодически (в большинстве случаев с периодом от 1 до 7 дней) делаем status review и отвечаем на вопросы:
- Scope. Что сделано? Что осталось сделать? Какие новые требования появились, а старые были убраны? Что было поставлено в прошлые delivery milestones? Что будет поставлено в будущие?
- Time. Когда случится следующий milestone? Другие будущие milestones? Окончание проекта?
- Cost. Сколько уже потрачено часов, денег вендора и денег клиента? Сколько ещё осталось потратить?
- Resources & Effort. Какие люди работали и работают на проекте? Сколько усилий они потратили? Какие люди и сколько усилий понадобятся, чтобы довести проект до конца?
Обычно в фазе исполнения проекта верно следующее:
- Появляются новые требования и задачи, а старые могут выводиться из скоупа.
- Части скоупа могут перемещаться между поставками (обычно в виде «откладываем на следующую фазу»).
- Большая часть людей работает на проекте full-time без перерывов, т.е. 8 часов в день, 40 часов в неделю, от момента прихода в проект до момента выхода из проекта. Иногда на проекте может работать человек в овертайм, но мы очень редко забиваемся на это на этапе эстимейта. Part-time роли с рваной загрузкой существуют, но в 99% случаев участие этих ролей не превышает 10-20% от общего уровня трудозатрат в проекте и это обычно специальные роли (part-time PM, designer, etc.).
Best practices при исполнении проекта включают в себя:
- Использование трекера задач a.k.a. centralized PM tool, такого например как Jira, Rally или Redmine. Трекер обычно заполняется на старте проекта из эстимейта и обновляется на регулярной основе, а также служит источником информации для мониторинга и отчётов.
- Status reporting, письменный и устный, включающий в себя ответы на вопросы, перечисленные выше (а также всякое другое).
Степени посвящения, они же Круги ада
Разработка плана проекта в MS Project похожа на разработку софтверной системы на C/C++. В умелых руках это инструмент очень мощный, однако без специальных усилий и умений легко можно получить трудно изменяемый, плохо организованный результат с большим количеством багов. Кроме того, для большинства встречающихся задач мощность этого инструмента избыточна – т.е. особого added value мы не получаем, а все недостатки и ограничения имеем в полный рост. У этого инструмента существуют также и фундаментальные ограничения и дефекты, которые принципиально снижают производительность при работе с ним вне зависимости от квалификации того, кто его использует.
Каковы же основные недостатки, ограничения и риски, встречаемые при работе с MS Project людьми с разными уровнями квалификации и опыта? Для обозначения уровня «крутости» будем использовать простейшую трёхуровневую лестницу грейдов, состоящую из уровней Junior, Middle и Senior.
Junior MS Project Designer
«Джуниор» обычно видит MS Project первый раз в жизни и не знает о нём ничего. Возможно, он видел в прошлом планы в MS Project, сделанные старшими товарищами, но не имеет достаточного понимания того, что он видел, кроме общей визуальной формы Gantt chart.
Совсем девственные новички часто используют Project как Excel – вводят список задач (часто даже не иерархический), приписывают к задачам часы и присылают это на ревью как черновик эстимейта.
Более распространён вариант, когда автор эстимейта видел в своей жизни Gantt chart и знает, что «сосиски» должны располагаться сверху вниз, слева направо. В таком варианте мы получаем одну или несколько линейных связок сосисок, скреплённых между собой через auto links.
Важно, что новички при этом не знают или забивают на resource allocation и в проекте просто нет никаких ресурсов вообще. Отсутствие ресурсов в плане, сделанном в MS Project, это ключевой признак джуниора.
Middle MS Project Designer
«Мидл» обычно прослушал курсы или прочитал книжку, но не имеет собственного опыта работы с Project (или имеет недостаточный). Он в курсе общих правил и принципов, но часто забывает про дьявола в деталях. Кроме того, «мидл» чаще всего не имеет навыков создания «архитектуры» проекта и либо не продумывает large-scale элементы плана, либо не умеет выразить их средствами MS Project.
Наиболее частыми дефектами плана от мидлов являются плохо организованная архитектоника плана и неровная загрузка команды (в терминах Project, на уровне work assignment).
Под «плохо организованной архитектоникой» мы понимаем структуру плана (включая timeline и work breakdown structure), в которой из общей кучи задач не выделены (или выделены неоптимально) высокоуровневые элементы плана проекта, такие как фазы и майлстоуны (для timeline) и треки (tracks, они же подкоманды, feature teams, etc., для WBS и team organization). MS Project сам по себе не подталкивает автора плана к тому, чтобы подумать на эти темы – более того, в MS Project просто нет большинства соответствующих концепций и «примитивов» выше уровнем, чем индивидуальные задачи и ресурсы.
В реальности люди в проектной команде редко работают в одиночку и полностью независимо друг от друга. Работа команды как минимум синхронизируется по delivery milestones, перед которыми нужно проделывать определённые действия. В командах больше определённого размера часто выделяются подкоманды или треки (по вертикальному или горизонтальному принципу, т.е. или по частям бизнес-функциональности системы, или по частям технической реализации – например, frontend track, reporting track, QA team, etc.). Хорошо структурированный план проекта должен учитывать эти естественные закономерности.
Если же их не учитывать, как делает типичный мидл, мы обычно получаем на выходе большое количество перекрывающихся по времени кусков работы и отсутствующую или не просматривающуюся чётко структуру итераций и релизов. В более тяжёлых случаях автор не следует вообще никакой логике в относительном расположении задач, в результате чего отдельные задачи становятся раскиданными по всему timeline’у, а большинство summary tasks растягиваются на всю длину проекта.
О структуре команды более продвинутый автор мог даже и подумать, но способов выразить это в Project у него не так много – в лучшем случае, это имена ресурсов вида «Database Developer 1». Авторы, которые действительно сильно заботятся о ясности и наглядности, могут использовать цвет для визуального выражения разницы между треками – обычно крася сосиски задач, входящих в разные треки, в разные цвета.
Сюда же относится манера использовать dependencies a.k.a. links не для выражения существенных зависимостей между задачами, а для размещения задач в плане в правильном порядке. Фича auto-link, автоматически создающая связь между двумя последовательно размещёнными задачами, прямо стимулирует такое бездумное использование связей. Отсутствие у «мидла» чёткого понимания семантики связей после нескольких итераций редактирования приводит к беспорядочной прошивке плана идущими во все стороны стрелочками. Характерным проявлением неумелого использования links являются не имеющие реального смысла связи между задачами, входящими в разные summary tasks, или между задачами, расположенными в WBS на разных уровнях (такие связи вообще говоря могут иметь смысл, но соответствующие ситуации встречаются в типичном планировании достаточно редко – беспорядочные же стрелочки, оставшиеся от перемешивания автоматически слинкованных задач, обычно тянутся по плану «мидла» повсеместно). Сами по себе лишние стрелочки безвредны, хотя и уродливы, но превращаются в страшную проблему при попытке выровнять загрузку в объёмном планировании.
Проблема с рваной загрузкой носит на самом деле системный характер и затрудняет жизнь как начинающих, так и опытных пользователей Project. Об опытных поговорим позднее, а здесь опишем, какие характерные ошибки допускает «мидл». Ошибки эти просты – «мидл» часто просто забывает посмотреть, какова загрузка ресурсов в получившемся плане, и в результате этот план нарушает правило, о котором мы говорили выше – «большая часть людей работает на проекте full-time без перерывов». Характерный симптом – это цифры загрузки в resource usage view, которые меньше или больше 100%. Проблема с перегрузкой (>100%) обычно решается применением leveling и продвинутые «мидлы» умеют это делать и часто вспоминают об этом (поскольку overallocation обычно визуально заметен на Gantt chart), но leveling задач одних членов команды обычно создаёт ещё большие дырки в загрузке других. Подобный план порождает массу практических проблем, поскольку очевидно не описывает реалистичный ход выполнения проекта и даёт искажённые представления обо всех параметрах проекта сразу – и о цене (которая обычно занижается), и о реальных сроках исполнения задач (которые могут как завышаться, так и занижаться), и о реальной загрузке и потребности в ресурсах.
Отдельной ошибкой «мидла» является нечёткое различение duration (т.е. абсолютного времени, измеряемого в часах) и work (т.е. трудозатрат, измеряемых в человеко-часах). Здесь даже продвинутых «мидлов» подстерегает идиотская ловушка Project, состоящая в том, что по умолчанию в гриде выводится поле Duration, а задачи имеют по умолчанию тип fixed units или fixed work и вводятся как effort-driven. Характерной приметой опытного «сеньёра» является то, что он понимает эти различия и как минимум вводит оценки в поле Work (а в идеале меняет опции умолчания в своей копии Project и решительно меняет тип всех задач при ревью и редактровании).
Про искусственный интеллект Project, мучающий «сеньёров», мы поговорим ниже. В случае «мидлов» же неразличение часов и человеко-часов приводит к огромному количеству странных и не всегда явно заметных искажений параметров планирования в момент, когда автор начинает назначать ресурсы на задачи.
Ещё же большая проблема с часами и человеко-часами состоит в том, что, исходя из практического опыта, 90% клиентов не поднимаются в своём понимании Project выше базового уровня «мидла» и часто не понимают, в какую колонку смотреть и что в этой колонке написано. Характерными вопросами от таких клиентов при предъявлении им полного планирования в Project бывают например «вы сказали, что проект продлится четыре недели, а суммарный work у вас почему-то 560 часов – зачем вы меня обманываете?».
Senior MS Project Designer
«Сеньёры», т.е. люди, которые освоили все необходимые фичи Project, а также обладают чётким пониманием того, что именно они хотят с помощью Project выразить, начинают страдать уже от фундаментальных недостатков Project как инструмента и выразительного средства.
Проблема с рваной загрузкой никуда не уходит и часто встаёт в полный рост даже у добросовестных «мидлов». Частью она объясняется тем, что не все чётко помнят про тип задачи в Project. Частью же причиной является «искусственный интеллект», встроенный в Project и до недавнего времени имевший тенденцию становиться от версии к версии всё более изощрённым.
Задачей искусственного интеллекта в Project является автоматическое изменение одних параметров задач при ручном или автоматическом изменении других. Классическим примером является уменьшение вдвое, втрое и т.д. длительности effort-driven задачи при назначении на неё второго, третьего и т.д. ресурса. Количество сценариев такого рода внутри Project довольно велико. Поведение Project в некоторых из них регулируется настройками (часть из которых это настройки конкретной копии Project на конкретной машине, а часть сохраняется в MPP-файле и переносится между машинами). Не все сценарии и правила одинаково хорошо документированы, при этом некоторые настройки оказывают влияние на довольно разнородные сценарии, и т.д., и т.п. Во многих сценариях поведение Project кажется контринтуитивным. В целом, эта часть Project является запредельно сложной и можно с высокой степенью уверенности утверждать, что большая часть пользователей Project не может предугадать в ходе работы все проявления искусственного интеллекта и часто оказывается к ним не готова.
«Мидлы» чаще всего остаются в счастливом неведении об изменениях, которые невидимо для них производит Project. Судьба «сеньёров» тяжелее – после долгого опыта редактирования в Project своих, а особенно чужих планов большого объёма, они приучаются ждать от своего инструмента внезапных гадостей и периодически проверяют, что Project по следам их изменений ничего не испортил. Лакмусовой бумажкой является загрузка, наблюдаемая через resource usage view – неожиданные и нелогичные искажения плана, вносимые автоматическими изменениями, обычно проявляются в виде отклонений в уровне загрузки ресурсов или в сроках начала и конца работы ресурса в проекте. «Сеньёр» обычно старается рисовать планирование с соблюдением простых базовых архитектурных принципов (кроме равномерной непрерывной загрузки важным является то, что люди, занятые на смежных задачах a.k.a. в одном треке, приступают к работе в проекте и освобождаются в одно и то же время) и любое отклонение от этих принципов достаточно легко видно в resource usage view.
Заметить внесённое системой искажение легко, но исправить его часто бывает довольно трудно, особенно в проектах большого объёма или сложной структуры. Undo часто не помогает – ручное изменение, приведшее к проблеме, откатывается, но уродство, внесённое искусственным интеллектом, остаётся и его приходится исправлять отдельно, рискуя при этом нарваться на другие автоматические изменения. В определённых ситуациях искусственный интеллект становится упрямым и не даёт исправить созданные им косяки.
Даже при редактировании не самых сложных планов нужно не забыться и не допустить шалостей искусственного интеллекта при достаточно простых операциях типа переноса задач из одного места плана в другое. Простые, но от того не менее надоедливые, ловушки, типа auto-link, который мы обсуждали выше, даже при простом copy-paste могут создать лишнюю связь между задачами или разорвать нужную. Некоторые «мидлы», склонные к исследованию всех опций сложной системы, могут включить на своих машинах опасные и разрушительные фичи типа автоматической «оптимизации» назначения ресурсов (имеющей смысл разве что при планировании работы взвода стройбата с лопатами) – даже если «сеньёр» неосторожно начнёт производить review такого планирования (особенно прямо на машине «мидла»), Project с удовольствием перемешает resource allocations и породит кашу, не имеющую даже следов смысла.
Но особенно сильно неожиданная вредоносность искусственного интеллекта проявляется при редактировании планирования, в котором какие-то задачи уже помечены как выполненные, или, говоря более научно, задачи, в которых появились данные по actuals (actual work, actual duration, etc.). Именно в таких ситуациях (хотя и не только в них) искусственный интеллект начинает вести себя особенно цинично и вносить в планирование изменения, которые трудно терпеть и ещё труднее откатить. Яркими примерами являются внезапное создание разрывов в задачах, искажение планируемой загрузки ресурсов внутри задачи, внезапный перенос задачи или группы задач после всех остальных и упорное нежелание вставить их обратно на место, даже с помощью ручного leveling’а. Опытный пользователь предугадывает такие неприятности и знает обычно некоторые приёмы, позволяющие их избежать (как например дисциплинированное использование task constraints), но в целом при работе с объёмным планированием, особенно включающем actuals, всё большая часть времени обычно начинает уходить на борьбу с инструментом, а не на содержательное редактирование. В какой-то момент даже «сеньёр» устаёт от борьбы, опускает руки, сдаётся и вздохнув отправляет коллегам или клиентам планирование, в котором ресурсы сплошь и рядом заняты на 83.58% в пятницу и на 16.42% в следующую за ней субботу.
В качестве бонуса упомянем квантовые эффекты, возникающие после нескольких итераций совместной работы над MPP-файлом большого объёма (задач эдак на пятьсот), в котором коллега-буквалист решил поправить начало рабочего дня в календаре с дефолтного 8:00 на что-нибудь «более соответствующее нашим реалиям», типа 11:00. Начинающий «сеньёр», просматривающий планирование обычно в масштабе дней или недель, будет слегка удивлён странной манерой части задач перескакивать на следующий бизнес-день без всякого видимого повода. Заглянув в daily resource usage view, он увидит в общем совершенно ровную загрузку по каждому ресурсу, со странными хвостиками, скажем, в 62% спереди и 38% сзади. И только увеличив масштаб до часов он ужаснётся и осознает, что если он хочет привести всё это в божеский вид, его ждёт час-полтора занудной ручной работы. Обычно «сеньёр» решает не быть перфекционистом (потому что в жизни есть более важные вещи, чем качественно составленное планирование) и продолжает работу с чем есть. Нарываясь позже уже на более зловещие проявления искусственного интеллекта, описанные выше, которые в сочетании с низкоуровневыми заусенцами в календаре часто выглядят особенно странно и лечатся особенно нудно.
Продолжая метафору разработки на C/C++ (возможно, слегка морально устаревшую в наши дни), полноценное использование Project в сложных сценариях начинает быть похоже на попытку сборки очень большой и сложной системы, написанной на C/C++, без использования make/ant и при наличии библиотек, для которых не гарантировано соответствие между имеющимися в нашем распоряжении заголовочными (.h) и бинарными (.a/.lib и .so/.dll) файлами. Теоретически, это возможно сделать, но может потребовать весьма заметных усилий и хорошей квалификации, а собранная система может иметь критические баги.
Всё естественное небезобразно, или Вкратце о хорошем
После обсуждения проблем и ловушек MS Project может возникнуть вопрос – зачем же компания Microsoft разработала и продвигает такую дрянь? Мы само собой далеки от того, чтобы обвинять Microsoft в непрофессионализме и злонамеренности. Перед тем, как продолжить обсуждать проблемы, коснёмся вкратце того, для чего MS Project подходит, и попытаемся объяснить ряд его особенностей, которые на первый взгляд выглядят вопиющими.
Основная мысль здесь будет довольно простой и собственно совпадает с основным тезисом всей статьи: MS Project плохо подходит для планирования и ведения минимально сложных софтверных проектов. Это не значит, что он столь же неадекватен для проектов в других областях человеческой деятельности. MS Project создавался как универсальный инструмент управления проектами – а project management как менеджерская технология употребляется далеко не только в разработке софта. Существуют области человеческой деятельности и масштабы проектов, в которых MS Project, может применяться без особого риска превратить планирование в дымящуюся гору перепутанных макарон. В основном это касается сценариев, где выполняется одно из условий:
- Структура плана проекта (в основном мы говорим о структуре WBS) либо определяется стандартами соответствующей области деятельности (например, описывает стандартный технологический процесс), либо по крайней мере не меняется после создания плана.
- Количество задач и/или ресурсов невелико.
- Задачи независимы друг от друга, а ресурсы однотипны и взаимозаменяемы.
Для минимально сложного проекта в области разработки софта обычно не выполняется ни одно из этих условий, хотя совсем простые проекты могут не меняться по ходу выполнения и/или содержать всего около 30-40 задач и 1-2 исполнителей (в последнем случае правда оправданность применения столь «тяжёлого» инструмента как MS Project всё равно вызывает сомнения).
Что касается тех особенностей Project, которые кажутся бессмысленными или даже вредоносными, любому человеку, знакомому с историей софтверной индустрии, должно быть понятно, что причина лежит в эволюции самого MS Project как продукта – а именно, в последовательных попытках Microsoft сделать его всё более и более универсальным, сохраняя при этом обратную совместимость с прошлыми версиями. Пресловутый «искусственный интеллект» и другие опасные для новичков особенности это всего лишь следствие:
- желания обслужить с помощью продукта как можно больше разнородных use cases (ведущее к усложнению концептуальной модели продукта и бессистемному увеличению количества доступных опций конфигурации);
- необходимости поддерживать целостность и непротиворечивость этой модели данных в ходе редактирования; и
- желания упростить изучение продукта новыми пользователями и сделать пользовательский интерфейс продукта и процесс редактирования «лёгким и интуитивно понятным».
Любой опытный пользователь легко приведёт несколько похожих примеров bloatware, во главе со всеми любимым MS Word, у которого, как известно, 90% пользователей используют только 10% фич. Увы, MS Project в отличие от MS Word призван описывать некую модель реальности – и чрезмерная сложность в использовании инструмента ведёт к тому, что модели получаются неадекватными и не служат своей основной цели – не позволяют отвечать на те вопросы о проекте, которые были перечислены в начале этой статьи.
Признаем при этом, что концептуальная модель MS Project действительно позволяет описать вещи, которые трудно сходу выразить с помощью популярных альтернатив (обычно основанных на линейных списках задач a.k.a. backlog-style). К действительно полезным фичам относятся конечно dependencies – зависимости между задачами, те самые links. Остальные (индивидуальные календари, возможность описывать профиль загрузки при работе над задачей и т.п.) в контексте планирования софтверного проекта представляют из себя избыточную сложность и скорее мешают.
MS Project в реальном мире
Из предыдущего рассказа в общем следует весьма печальный вывод – без блистательного владения MS Project всеми людьми, которые касаются своими руками MPP-файла, планирование в MS Project практически невозможно использовать для отслеживания прогресса в реально идущем софтверном проекте с достаточным уровнем детализации. Ибо в реально идущем проекте неизбежно будут добавляться, удаляться и изменяться задачи, в том числе и уже начатые, что очевидно порождает среду, в которой зловещий искусственный интеллект Project может развернуться в полный рост.
Многие люди тем не менее продолжают использовать MS Project в своей практике – из-за давления со стороны руководства и клиента, предрассудков, незнания или привычки. Как же это у них получается?
Разгадка проста и предсказуема – пользователи MS Project делают свою задачу исполнимой за счёт её упрощения. Упрощения этого можно достичь разными способами: сознательно упрощая сам проект, осознанно или бессознательно игнорируя какие-то реальные аспекты проекта или используя параллельно с MS Project какой-то другой инструмент.
Прокрустово ложе
Первый способ – организовать сам проект настолько просто, чтобы его можно было с относительным комфортом вести в MS Project – на первый взгляд выглядит прямо-таки привлекательно. В конце концов всё, что позволяет нам упростить свою работу, это наверное хорошо, а просто организованный проект наверное лучше, чем проект, организованный сложно.
До определённой степени это так, но увы, в случае MS Project порог «комфортной сложности» достаточно низок. Чаще всего, как уже говорилось выше, достаточно простые проекты уже настолько просты, что их можно с большей эффективностью отслеживать с помощью более простых инструментов, нежели MS Project.
Одним из характерных приёмов упрощения является например декомпозиция проекта на отдельные подпроекты, исполняемые изолированными, очень маленькими командами по принципу «разделяй и властвуй». Другой подход, включающий модные элементы agile, предполагает исполнение проекта короткими перебежками-итерациями, для каждой из которых создаётся и ведётся отдельный план в MS Project – так что в планах не успевает накопиться достаточное количество изменений и с ними всё ещё легко справиться. Легко видеть, что во всех из этих случаев использование MS Project не даёт вообще никакого added value – задача планирования простого проекта достаточно тривиальна, чтобы справиться с ней куда более простыми средствами (такими например как Kanban board, простейший линейный backlog и т.п.).
Увы, хотя, повторимся, безотносительно используемых инструментов, упрощение организации чаще всего полезно, не любой проект поддаётся подобному упрощению.
Blissful ignorance
Сознательная работа по упрощению реальной организации проекта – в чём-то даже знак истинного мастера своего дела. Увы, большая часть начинающих менеджеров проекта идёт по совсем другому пути. Осознав, что поддерживать полноценное планирование в MS Project требует значительного количества усилий и времени (которого всегда не хватает) они вместо упрощения проекта упрощают процессы планирования и мониторинга проекта. Обычно это достигается игнорированием при ведении проекта каких-то из его аспектов – или бездумно, или в надежде, что само срастётся. Иногда такой выбор может быть обоснованным (какая-то вещь может действительно быть не очень важной в конкретном контексте – гипотетическим примером является работа над низкоприоритетным проектом «по остаточному принципу» без реальных ограничений бюджета и времени). Чаще же игнорируемое попадает в «слепую зону» менеджера и команды, откуда потом могут неожиданно вылезать неприятности.
Характерным признаком такой ситуации является искреннее недоумение при вопросе reviewer’а «а как вы в своём планировании отслеживаете X?» и ответ в диапазоне от «извините, я думал, что в Project это сделать нельзя» до «всем же известно, что в Project это никто не делает», в зависимости от степени уверенности автора в себе. Другой разновидностью ответа является «да кого этот X вообще интересует?» (особенно убедительно звучащее в контексте денег и сроков).
Поскольку наиболее хрупким MS Project становится в ситуации, когда проект меняется в ходе своего исполнения, одним из наиболее частых случаев является ситуация, когда план в Project перестают обновлять через какое-то время после начала проекта (или же не начинают обновлять вообще). Если при этом Project как инструмент заменяется на что-то другое, ситуация в общем может оставаться под контролем. Иногда мы однако видим, как созданный в начале проекта и прекративший обновляться MPP-файл продолжает использоваться как основа для измерения прогресса и составления отчётности. По сути, в этом случае менеджер и команда игнорируют те самые изменения, которые происходят в любом живом проекте. Отчасти такому подходу способствует дурно понятая философия менеджмента, при которой baseline планирования считается чем-то священным и «истинным», а накапливающиеся по ходу изменения чем-то ошибочным или случайным – «отклонением от плана». Поскольку подсознательно человек часто считает, что всяким случайным шумом в системе можно пренебречь, он охотно и естественно начинает не обращать внимания на изменения. Ярким симптомом на поздней стадии такого развития событий является использование менеджером для описания статуса проекта MPP-файла, не обновлявшегося несколько месяцев. Чаще всего между реальной картиной мира и таким MPP-файлом нет вообще ничего общего, но менеджер и проектная команда продолжают использовать старый MPP-файл как некий внутренний герметический коммуникационный фреймворк. Человеку же извне проекта часто бывает трудно понять такое описание без специальных умственных усилий.
Довольно часто люди всё-таки осознают, что они, используя Project таким образом, игнорируют что-то очень важное, и естественным образом приходят к третьей стратегии – костылям и альтернативным инструментам.
Костыли и альтернативы
Как уже говорилось, иногда сама жизнь тем или иным способом заставляет человека использовать MS Project. Человек может быть уже достаточно опытным, чтобы понимать или хотя бы подозревать, что только этого инструмента для полноценного ведения проекта недостаточно, но может не иметь веса или возможностей, чтобы убедить всех стейкхолдеров от него отказаться. Если человек достаточно добросовестен, он часто начинает дополнять Project другими инструментами.
Наиболее простым и обычно наименее эффективным вариантом является использование в качестве дополнительного инструмента собственной памяти. Понятно почему такой способ неэффективен при исполнении проекта командой из более чем одного человека, так что мы не будем на этом подробно останавливаться. В эту же категорию, увы, относится использование любых других трудно разделяемых артефактов, живущих в личном пространстве менеджера – листков бумаги, записных книжек, папок с электронной почтой, личного календаря и т.п. Хотя такие инструменты вполне могут решать задачу личной организации (особенно в рамках системного подхода типа GTD), для управления работой проектной команды они обычно малопригодны.
В более жизнеспособном варианте план в Project поддерживается параллельно с каким-то другим артефактом или артефактами планирования и мониторинга. К этому варианту менеджеры и команды приходят двумя способами.
В одном сценарии они начинают использовать Project как единственный авторитетный источник данных о проекте, но затем не выдерживают тягот работы с ним. При этом они не желают идти по пути игнорирования кусков реальности, оставляют Project как инструмент для представления только одного из аспектов проекта и дополняют его чем-то ещё.
В другом сценарии опытный менеджер с самого начала осознаёт ограничения и неадекватность Project, но по каким-либо внешним причинам (часто это формальные требования внешних по отношению к проекту стейкхолдеров) вынужден продолжать его использовать. В таком варианте он, опять-таки с самого начала работы над проектом, осознанно организует работу так, чтобы Project корректно представлял некую сильно упрощённую точку зрения на проект, а основная часть детальной информации и особенно изменений поддерживается в другой форме.
Оба варианта рано или поздно приводят к тому, что картина мира, представленная в Project, становится высокоуровневой, нарочито огрублённой и как бы имеет «низкое разрешение». Характернейшим признаком этого является использование Project как инструмента для рисования high-level plan, в котором отдельные «задачи» в MPP-файле соответствуют целым фазам или итерациям. Если MPP-файл, описывающий большой проект, имеет форму одной ровной лесенки из 10-20 огромных сосисок, есть вероятность, что это на самом деле не «рабочее» планирование, а выжимка, executive summary, которую хорошо показывать высокопоставленным спонсорам проекта в ходе отчётного митинга раз в квартал. Настоящее планирование при этом скорее всего ведётся где-то совсем в другом месте. Добросовестный менеджер может при этом использовать авторитетный источник детальных данных (например, Джиру) для более или менее честного вычисления прогресса по каждой высокоуровневой задаче и таким образом вполне честно исполнять в MS Project техники earned value management (вопрос, насколько это осмысленно, мы вынесли за скобки в самом начале главы).
Заметим вскользь, что для такого способа вести планирование в Project тоже есть инженерная аналогия. Иногда клиент требует, чтобы внешняя команда обязательно коммитила исходный код проекта в расположенный на его, клиента, стороне, VCS repository, однако доступ к этому репозиторию крайне затруднён и неэффективен (например, связан с долгим поднятием нестабильного VPN-соединения и закачке данных через медленный канал, длящейся полчаса-час). Стандартным приёмом в таком варианте является работа команды с локальным репозиторием и promotion кода в клиентский репозиторий не как часть короткого (ежечасного или ежедневного) рабочего цикла одного разработчика, а как часть длинного (еженедельного или ежемесячного) поставочного цикла всей команды. Если в такой конфигурации не используется DVCS типа Git или Mercurial, то с точки зрения клиентского репозитория история изменений кода в проекте будет иметь «низкое разрешение» — состоять из очень редких во времени и очень больших по объёму коммитов. Аналогично, клиент или PMO, требующий «честной» отчётности в MS Project, скорее всего получит план, состоящий из малого числа очень высокоуровневых задач.
Таким образом, по мере того, как реальное отслеживание прогресса по проекту начинает исполняться в других, более приспособленных для этого инструментах, для MS Project остаётся только роль рисовалки красивых Gantt charts. Стоит отметить, что, к сожалению для Project, специализированные рисовальные инструменты типа Visio часто позволяют получить гораздо более привлекательный результат.
Заключение: жизнь после Гантта
После всего сказанного выше, для читателя не будет сюрпризом, что мы крайне не рекомендуем использовать MS Project на любой из стадий жизненного цикла софтверного проекта – от создания первых черновиков эстимейта до непосредственно фазы исполнения.
MS Project имеет очень много способов сделать процесс планирования и мониторинга сложным и невыносимым и по сравнению с необходимыми трудозатратами приносит довольно мало реальной пользы. Трудности использования MS Project часто приводят к тому, что менеджеры проектов начинают пренебрегать какими-либо аспектами реального проекта, часто достаточно критичными, что может приводить к неожиданным и иногда серьёзным кризисам. Способы всё-таки использовать MS Project для управления проектом несмотря на его ограничения и неудобства существуют, но требуют от менеджера очень высокой квалификации и степени осознания, заставляя при этом тратить время и усилия на довольно непродуктивные действия по борьбе со странностями инструмента или по дублированию информации из альтернативного авторитетного источника.
О том, что мы рекомендуем использовать, будет рассказано в отдельной статье.
Автор: dstillermann
