Microsoft Project delenda est

    В жизни многих обитателей софтверной индустрии иногда настаёт момент, когда им приходится нарисовать план проекта. Люди, что-то слышавшие об управлении проектами, читавшие книжки на эту тему (особенно книжки, не описывающие конкретную индустрию), а также учившиеся управлению проектами где-либо (в ВУЗе, на курсах и т.п.) чаще всего автоматически выбирают для создания этого плана 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, может применяться без особого риска превратить планирование в дымящуюся гору перепутанных макарон. В основном это касается сценариев, где выполняется одно из условий:
    1. Структура плана проекта (в основном мы говорим о структуре WBS) либо определяется стандартами соответствующей области деятельности (например, описывает стандартный технологический процесс), либо по крайней мере не меняется после создания плана.
    2. Количество задач и/или ресурсов невелико.
    3. Задачи независимы друг от друга, а ресурсы однотипны и взаимозаменяемы.

    Для минимально сложного проекта в области разработки софта обычно не выполняется ни одно из этих условий, хотя совсем простые проекты могут не меняться по ходу выполнения и/или содержать всего около 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 для управления проектом несмотря на его ограничения и неудобства существуют, но требуют от менеджера очень высокой квалификации и степени осознания, заставляя при этом тратить время и усилия на довольно непродуктивные действия по борьбе со странностями инструмента или по дублированию информации из альтернативного авторитетного источника.

    О том, что мы рекомендуем использовать, будет рассказано в отдельной статье.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 31

      +2
      Это иезуитство — рассуждать, почему программеры не могут вести проект разработки в MS Project.
      Да просто потому, что для этого есть совсем другие инструменты. А уж эти инструменты вполне можно интегрировать с Project, например, для портфельного управления, как это делает TFS или другие системы поддержки цикла разработки.

      >MS Project имеет очень много способов сделать процесс планирования и мониторинга сложным и невыносимым и по сравнению с необходимыми трудозатратами приносит довольно мало реальной пользы.

      Сдаётся мне, вы просто не умеете его готовить.
        +2
        А уж эти инструменты вполне можно интегрировать с Project

        А в чём value от Project'а тогда будет?

        Сдаётся мне, вы просто не умеете его готовить.

        Был бы благодарен за детальный разбор описанных в тексте проблем, а не за ответ на единственную фразу из summary.
          +1
          >А в чём value от Project'а тогда будет?
          Я же написал — портфельное управление проектами.
          Можно добавить расчет стоимости, агрегированных показателей и т.д.

          >Был бы благодарен за детальный разбор описанных в тексте проблем
          Суть описаных проблем в том, что MS Project — это инструмент, который надо изучать. Мне кажется, тут нечего обсуждать. Это всё равно, что наезжать на какой-нибудь скриптовый или динамический язык, что там нет жесткой типизации, а это путает непрофессиональных пользователей.

          Мне кажется, имело бы смысл рассматривать именно такой ракурс: кто из специалистов должен пользоваться и владеть MS Ppoject, а кому достаточно отмечать в своей среде разработки поставленную ему задачу как выполненную с указанием фактических затрат.

            +2
            Good point насчёт project portfolio management, это важная тема. А какие процессы управления портфелем поддерживает связка TFS + Project + Project Server? Я тут с готовностью признаюсь в невежестве, мы в нашей компании portfolio management ведём в некоем внутреннем самописном инструменте и альтернатив ему никогда не искали.

            Навскидку, может ли мне эта связочка ещё помочь сделать следующее:
            • Управлять загрузкой пула ресурсов. Кто в компании есть, что он умеет, чем он занят, сколько он стоит. Тупо глобальный список ресурсов Project Server умел ещё в 2002й версии, но я там честно говоря не помню, был ли там «внутренний рейт» (сколько стоит человек компании) в отличие от «внешнего рейта». Ну и всё остальное, типа «человек запланирован на проект X» и т.д.
            • Управлять пайплайном. Какие проекты на нас надвигаются, кто там нужен и как мы их будем делать. Интеграция с CRM (мы используем MS Dynamics CRM) очень желательна.
            • Управлять финансами. Какие у меня плановые показатели основных финансовых метрик и каковы актуальные (на уровне проекта и аккаунта как минимум)? Поддержка инвойсинга тоже очень бы не помешала.
            • Управлять портфельными рисками.
            • Всё, что связано с HRM, я опускаю, это мало кто умеет (тут мы кстати опять же CRM используем).

            Я подозреваю, что Microsoft должен обеспечивать какую-то интеграцию со своими ERP из семейства Dynamics.
          0
          Полностью поддерживаю.
          Мы рисуем всё в MS Project, а потом импортируем как User Story в TFS, а дальше подправляем экспортируя в Excel и после исправлений закидываем большим куском обратно в TFS.

          Понятное дело, что скрестить SVN/GIT/Mercurial или ещё 100500 — не реально, а прикрутить к этому всему ещё и трэкинг — не простая задача.

          У нас менеджеры работают с Excel'ем и Project'ом, программисты с задачами в TFS, тестеры с Test Lab'ом, который тоже есно связан с TFS… итд.
            0
            Да, один из нормальных сценариев.
            Есть ещё вариант, когда UserStory собираются и описываются в TFS, а потом синхронизируются в Project, чтобы выбрать сроки и распределить ресурсы.
            И куча всяких комбинаций сценариев.
          +2
          Проведите такой же детальный разбор использования Microsoft Team Foundation Server для планирования и ведения минимально сложных софтверных проектов.
            +3
            Я не имею личного опыта использования TFS и слышал про него диаметрально противоположные оценки. В компании, где я работаю, был опыт успешного исполнения проектов с использованием TFS, но у меня недостаточно данных, чтобы понять, помогал в тех командах TFS или мешал. В компании мы продвигаем в качестве стандартного инструмента либо Jira+Greenhopper, либо TFS. Я лично всегда рекомендую Jira+Greenhopper, но если менеджер проекта и команда настаивают на TFS, я обычно не сопротивляюсь.
              +3
              TFS очень удобная штука, хоть и требует бОльших ресурсов.
              У нас 3 сервера, которые обеспечивают нам работу: База данных TFS (MS SQL), Веб сервер (Sharepoint & TFS Web), Test Lab, иногда появляются ещё доп. сервера как сборки проектов.

              И о чудо, это всё работает вместе.
              Падает билд — сразу же открывается задача в TFS «Упал билд»,
              Тестеры закончили очередную проверку — вот тебе целая пачка разного рода задач.
              Нужна аналитика? Вот тебе и отчёты по проекту, большенство уже из коробки идёт.

              Нужно что-то массово изменить — экспорт в MS Project & Excel, исправления и потом импорт.

              Да, работать с RoR, PHP, и прочими non-msft продуктами там действительно ооочень сложно, мы пробовали фрэшовые проекты там держать — не самая удачная идея была. А весь MSFT stack — там живёт как в раю.
              +2
              Мы делали так: в TFS набрасывали все задачи со явными зависимостями, а MS Project использовали для распределения загрузки.

              В MS Project 2010 впервые появились реально две полезные вещи, немного повернувшие его лицом к софтверным проектам:

              1) Планировщик работы группы, визуально показывающий последовательность задач, назначенных на каждого человека, и
              2) Ручное планирование (когда искуственный интеллект спит)

              Это позволяло использовать такую схему: создавать в TFS все задачи (с оценками трудозатрат, но без указания сроков), потом подкачивать их в MS Project, там двигать задачи в планировщике, выравнивая нагрузку, и потом публиковать всё это обратно в TFS.

              Диаграмма Гантта при этом использовалсь как побочный продукт для отчётов, передаваемых начальству. А файл mpp не использовался вовсе: вся актуальная информация хранилась в TFS.

              Учитывая, что все остальные 99% наворотов Project при этом просто не использовались, наверное, было бы неплохо иметь вместо него облегченный инструмент как надстройку над TFS. Может, такой и появится (если уже не появился).
                +2
                О, вот то, что ты описываешь, это может быть забавно. Спасибо.
              +2
              >О том, что мы рекомендуем использовать, будет рассказано в отдельной статье.
              «Мы»- это кто?
                +2
                Это «авторское мы». Закос под научную статью типа.
                  0
                  Да, похоже на статью затравку, чтобы потом рассказать про свой чудо-продукт.
                  Чтобы привлечь внимание, есть вариант погавкать на слона.
                    +2
                    Не, не угадали. Продукта у меня нет. Рекомендовать буду сочетание инструментов от Microsoft и Atlassian, но не работаю ни там, ни там. Также не оказываю услуг процессного консалтинга. :)
                      0
                      А как Вам удалось интегрировать Jira и Project? Или ручками переносили изменения?
                  +1
                  Спасибо за статью. Работал когда-то с MS Project на уровне юниора для отслеживания больших не программных и частично программных продуктов. Ад и ужас.
                    +1
                    Имея за плечами большой опыт успешного применения MS Project для управления именно софтверными проектами, совершенно не могу согласиться с такой абсолютистской оценкой автора. Оценка скорее эмоциональная, чем практическая.
                    Я согласен с тем, что MS Project откровенно плохо приспособлен для управления часто изменяющимися проектами. Но, честно говоря, я не знаю другого инструмента, который бы имел сравнимую функциональность.

                    Я успешно применял MS Project для планирования и отслеживания хода выполнения проекта. Я никогда не рассматривал его как инструмент совместной работы. Файл MS Project — это моя личная модель проекта. Изменения в него вношу только я. Я могу отдельным людям показывать отдельные выжимки из него, может быть использовать верхнеуровневые диаграммы Ганта в качестве отчетов начальству. Но сам файл проекта — это мой персональные инструмент как руководителя проекта. Отслеживание выполнения задач осуществляется другими средствами. Тут назывались Jira, TFS — это не суть важно. Перенести несколько задач в эти системы и раз в неделю отмечать как что движется — это не напряжно. Зато узкие места проекта становятся видны сразу же, а не в конце этапа.

                    P.S. если кому-то интересно, могу поделиться своей методологией использования MS Project для управления софтверными проектами.
                      0
                      Было бы очень интересно ознакомиться с методологией.
                        0
                        ок, постараюсь до конца недели замутить пост, для комментария слишком много текста получается ;-).
                          0
                          С некоторым опозданием от обещанного срока :-) но написал :-)
                          habrahabr.ru/post/151593/
                            0
                            спасибо :)
                        +1
                        Согласен с автором.

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

                        1. Разработка софта — она очень разная. Технологии, инструменты и проблеммы, которые характерны для поточной автоматизации бизнеса внешним заказчикам практически не пересекаются с технологиями, инструментами и проблеммами в области, например, написания драйверов. Или разработки игр. Или создания веб страничек. Или создания коробочных продуктов.
                        2. Если напрячься и попробовать выделить нечто общее, что присуще большинству софтовых проектов и что отличает их от других областей, то вырисовывается нулевая цена копирования. Тоесть если что-то сделано один раз, то в большинстве случаев это же второй раз делать не нужно — достаточно скопировать существующее решение. Это очень грубая зарисовка, и из нее есть миллион исключений, начиная от «лицензия на 1С очень дорогая, давайте для наших скромных нужд напишем то же самое, но только то что нам нужно — выйдет дешевле» и заканчивая «у них там ноу-хау, которое позволяет обрабатывать звук в реальном времени в десять раз быстрее, чем у нас. Нужно повторить». Но в общем случае можно утверждать, что лицензия на существующее решение стоит дешелвле чем разработка такого же, а ноу хау реально мало — потому как патенты открыты, да и reverse engeneering софта дело не то чтобы очень сложное.
                        3. Технологии очень быстро меняются. Примерно раз в пять лет.
                        4. Нулевая цена копирования и быстрая смена технологий приводят к тому, что разработчики каждый раз делают что-то новое. Безусловно, также как и для нулевой цены копирования, тут есть миллион исключений — начиная от изготовления сайтов-визиток, где каждый последующий ничем не отличается от предыдущего, и заканчивая интеграцией какого-нибудь SAP для автоматизации бизнеса, где инструменты и подходы давно и надежно заморожены. Но в общем случае у нас на проекте нет людей которые именно это уже делали больше одного раза.
                        5. То, что значительная часть задач делается в первый раз, без накопленного опыта и проверенных решений, приводит к повышенным рискам. Если бригада строителей строит дом — то она до этого построила уже двадцать домов, отучилась в соответствующем ПТУ и ознакомилась с опытом старших товарищей. У них, за редким случаем, не будет сюрпризов. Если мы пишем клиет вконтакте под Android — то мы скорее всего первый раз пишем клиент вконтакте и первый или второй раз пишем под android :).
                        6. Разработка программ — очень широкая область. Умения топового веб разработчика могут пересекаться с умениями топового разработчика драйверов менее, чем на 20 процентов. Поэтому, в отличие от традиционных управленческих задач, у нас нету «строитель — одна штука». У нас есть программисты с разными наборами скиллов в сотнях областей и разными областями интересов, где они готовы изучать что-то новое. Соответственно срок и риски по задаче, если ее дать разным разработчикам, могут отличаться на порядок.

                        Последние два пункта приводят к тому, что задачи, которыеми мы управляем, в большинстве случаев нифига не характеризуются такими привычными категориями как «сложность в человекочасах» и «выполнено». У задачи просто отсутствует «объективная сложность» — в зависимости от набора умений разработчика одна и та же задача может выполняться как день, так и неделю. Во-вторых, так как мы на острие прогресса ползем по минному полю, то здачи естественно и регулярно порождают из себя другие задачи, неожиданно разваливаются на несколько несвязанных задач, отменяются (потому что оказалось, что так это сделать нельзя) и мутируют (потому что оказалось, что это надо делать по другому).

                        Microsoft Project хрошо приспособлен к управлению строительством домов и рытьем траншей. Но он не приспособлен к управлению строительством домов на Юпитере, по технологии Хищников командой Чужих :(.

                        Если кто считает что я где-то ошибся в выкладках — буду очень благодарен за комментарии.
                          0
                          Я считаю ошибкой думать, что MS Project должен что-то делать за нас. Это — просто инструмент. Он работает по определенным правилам. Если понимать и использовать эти правила, то есть возможность получать от этого инструмента немалую пользу, а именно — разгрузить мозг, составив модель проекта в виде плана в MS Project, внося изменения в модель понимать, как они скажутся на проекте в целом. MS Project окажется очень плохим инструментом, если целиком полагаться на его встроенную «автоматику» — она, действительно, не всегда очевидна. Также не всегда удобно пользоваться некоторыми очевидными возможностями, например, вложенные задачи — это просто кошмар! :-)
                            0
                            Э… А какое это отношение имеет к моему комментарию? O_O
                              +1
                              >>согласен с автором
                                0
                                А, понял. Поясню свою позицию. MS Project, конечно, никому ничего не должен. Но как инструмент он решает нам ряд задач. Позиция автора в том, что задачи, для решения которых создан MS Project и задачи, которые встают перед нами при управлении проектами по разработке — это очень разные задачи.

                                разгрузить мозг, составив модель проекта в виде плана в MS Project, внося изменения в модель понимать, как они скажутся на проекте в целом


                                Тоесть вы предлагаете использовать MS Project для какого-то «моделирования», а для планирования проекта другие решения? А зачем тогда MS Project? Насколько я знаю, любое специализированное решение для планирования и управления разработкой ПО способно по текущим данным строить «модели» любой степени детализированности.
                                  0
                                  Так моделирование — это есть планирование. Модель проекта (читай — план) в MS Project позволяет руководителю видеть что происходит в проекте и что (теоретически) будет происходить.

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

                                  Мне очень интересно, какое решение порекомендует автор в последующих постах, буду ждать.
                                    0
                                    Да JIRA с аддонами он порекомендует, к гадалки не ходи :).
                          +1
                          Всем порочащим на MS рекомендую сходить к экспертам Luxoft на курсы по Project. Там учат те, кто рулил не хилыми проектами по проектированию софта. Расскажут: что, как и зачем.
                            0
                            А продолжения статьи так и не появилось? Или автор просто взял небольшую паузу для написания? ;)

                            Only users with full accounts can post comments. Log in, please.