В жизни многих людей, работающих в индустрии программного обеспечения, иногда наступает момент, когда им приходится составить план проекта.
Люди, которые что-то слышали об управлении проектами, читали книги по этой теме (особенно книги, не описывающие конкретную отрасль), а также изучали где-то управление проектами (в университете, на курсах и т. д.), чаще всего автоматически выбирают создание этого Microsoft. План проэкта.
Иногда использование MS Project навязано руководством, клиентом, стандартами процессов в компании и т.п.
Для программных проектов выбор MS Project обычно крайне неудачен, и ниже мы объясним почему, но сначала напомним вам несколько простых фактов о том, как структурируются программные проекты, особенно в контексте заказной разработки.
Отказ от ответственности и оправдания
Автор заранее приносит извинения за огромное количество использованных в тексте профессиональных жаргонных английских слов, но считает, что с ними лучше, чем без них.Автор фокусируется на проектах, реализуемых преимущественно сотрудниками профессиональных компаний, не слишком маленьких и не слишком больших.
Некоторые из явных и неявных предположений, лежащих в основе текста, могут не применяться в других организационных контекстах, таких как стартапы, фрилансеры или глобальные мастодонты с сотнями тысяч сотрудников.
Особенно это касается двух предположений:
- Члены команды проекта работают в среднем 8 часов в день и 40 часов в неделю и редко превышают эти показатели более чем в полтора раза.
- Основная цель реализованных проектов – успешное решение бизнес-задачи клиента.
Бизнес-контекст: как реализуется программный проект
Эта глава ни в коем случае не является полным описанием дисциплины управления программными проектами.Он охватывает только самый базовый уровень сложности и знакомит с некоторыми концепциями.
Итак, не вдаваясь в подробности, проект нужно сначала продать, а потом реализовать.
Распродажа
В ходе продажи мы должны с помощью сгенерированных артефактов (сметы, планы проектов, предложения и т.п.) ответить себе и клиенту на следующие вопросы:
- Объем.
Каков будет результат проекта?
- Время.
Как долго продлится проект? В какие моменты что произойдет (обычно с точки зрения поставок и этапов)?
- Расходы.
Сколько это стоит? Когда платить?
- Ресурсы и усилия.
Какие люди для этого нужны и в какие моменты? Сколько усилий и кто будет вкладывать в каждую задачу или элемент объема?
- Зависимости.
Какие материалы, информацию, действия и т.п.
ожидает команда проекта от клиента или третьих лиц? В какие моменты?
- Принятие.
Как мы определяем, что полученные в ходе проекта результаты соответствуют договоренностям и потребностям клиента?
- В процессе продажи и обмена смету и другие артефакты приходится переделывать несколько раз, зачастую за очень короткое время.
- Артефакты обычно существуют в виде файлов, которыми обмениваются по электронной почте.
- Клиентам нравится видеть разбивку затрат по самым разным критериям – особенно по частям системы и частям функциональности – а также задаваться вопросом: «Если мы это выкинем, как изменятся цена и условияЭ»
Исполнение
В ходе реализации проекта мы следим за происходящим с помощью инструментов управления проектом и периодически (в большинстве случаев с периодом от 1 до 7 дней) делаем обзор статуса и отвечаем на вопросы:- Объем.
Что сделано? Что осталось сделать? Какие новые требования появились и были сняты старые? Что входило в прошлые этапы поставки? Что будет поставляться в будущем?
- Время.
Когда произойдет следующая веха? Другие будущие вехи? Конец проекта?
- Расходы.
Сколько часов, денег поставщиков и денег клиентов уже потрачено? Сколько осталось потратить?
- Ресурсы и усилия.
Какие люди работали и работают над проектом? Сколько усилий они потратили? Какие люди и сколько усилий потребуются для доведения проекта до завершения?
- Появляются новые требования и задачи, а старые могут быть исключены из области действия.
- Части объема могут перемещаться между поставками (обычно в режиме «отложенного до следующего этапа»).
- Большинство людей работают над проектом полный рабочий день без перерывов, т.е.
8 часов в день, 40 часов в неделю, с момента присоединения к проекту и до момента выхода из проекта.
Иногда человек может работать над проектом сверхурочно, но мы очень редко беспокоимся об этом на этапе сметы.
Подработки с периодической нагрузкой существуют, но в 99% случаев участие этих ролей не превышает 10-20% от общего уровня трудозатрат в проекте и это обычно специальные роли (совместитель PM, дизайнер , и т. д.).
- Использование трекера задач, известного как централизованный инструмент управления проектами, например Jira, Rally или Redmine. Трекер обычно заполняется на старте проекта из сметы и регулярно обновляется, а также служит источником информации для мониторинга и отчетности.
- Отчетность о состоянии, письменная и устная, включая ответы на вопросы, перечисленные выше (а также все остальное).
Степени посвящения, они же Круги Ада
Разработка плана проекта в MS Project аналогична разработке программного комплекса на C/C++.В умелых руках этот инструмент очень мощный, но без особых усилий и навыков можно легко получить трудноизменяемый, плохо организованный результат с множеством ошибок.
Кроме того, для большинства встречающихся задач мощность этого инструмента избыточна - т.е.
никакой особой добавленной стоимости мы не получаем, но все недостатки и ограничения у нас как на ладони.
Этот инструмент также имеет принципиальные ограничения и недостатки, которые кардинально снижают производительность при работе с ним независимо от квалификации человека, его использующего.
С какими основными недостатками, ограничениями и рисками сталкиваются при работе с MS Project люди с разным уровнем квалификации и опыта? Для обозначения уровня «крутости» будем использовать простейшую трехуровневую лестницу оценок, состоящую из уровней Junior, Middle и Senior.
Младший дизайнер проектов MS
«Младший» обычно видит MS Project впервые в жизни и ничего о нем не знает. Возможно, он видел в прошлом планы в MS Project, сделанные старшими товарищами, но не имеет достаточного понимания увиденного, кроме общей визуальной формы диаграммы Ганта.Совершенно девственные новички часто используют Project вроде Excel — вводят список задач (часто даже не иерархический), распределяют по задачам часы и отправляют его на рассмотрение как черновую смету.
Более распространен вариант, когда автор оценки видел в своей жизни диаграмму Ганта и знает, что «колбаски» должны располагаться сверху вниз, слева направо.
В этом варианте мы получаем одну или несколько линейных пачек колбас, скрепленных между собой автосвязями.
Важно, чтобы новички не знали или не забывали о распределении ресурсов и ресурсов в проекте просто не было.
Отсутствие ресурсов в плане, составленном в MS Project, — ключевой признак джуниора.
Средний дизайнер проектов MS
«Средний ученик» обычно прошел курс или прочитал книгу, но не имеет (или недостаточен) личного опыта работы с Project. Он знает общие правила и принципы, но часто забывает о дьяволе в деталях.Кроме того, «средний» чаще всего не обладает навыками создания «архитектуры» проекта и либо не продумывает масштабные элементы плана, либо не умеет выражать их с помощью MS Project. Наиболее распространенными дефектами плана из мидлов являются плохо организованная архитектура плана и неравномерная рабочая нагрузка команды (в терминах проекта, на уровне рабочих заданий).
Под «плохо организованной архитектоникой» мы подразумеваем структуру плана (включая временную шкалу и структуру декомпозиции работ), в которой высокоуровневые элементы плана проекта, такие как фазы и вехи (для временной шкалы) и треки, они же являются подгруппами, характеризуются команды и т. д. для WBS и организации команд).
Сам MS Project не побуждает автора плана задуматься над этими темами — по сути, в MS Project просто нет большинства актуальных понятий и «примитивов» на уровне выше отдельных задач и ресурсов.
На самом деле люди в проектной команде редко работают в одиночку и совершенно независимо друг от друга.
Работа команды как минимум синхронизирована по вехам поставки, перед которыми необходимо выполнить определенные действия.
В командах, размер которых превышает определенный размер, часто выделяются подкоманды или треки (по вертикали или горизонтали, т.е.
либо по частям бизнес-функциональности системы, либо по частям технической реализации — например, фронтенд-трек, трек отчетности).
, команда контроля качества и т. д.).
Хорошо структурированный план проекта должен учитывать эти естественные закономерности.
Если не учитывать их, как это делает типичный мидл, мы обычно получаем большое количество перекрывающихся во времени кусков работы и отсутствующую или нечетко видимую структуру итераций и релизов.
В более тяжелых случаях автор вообще не следует никакой логике в относительном расположении задач, в результате чего отдельные задачи оказываются разбросанными по всей временной шкале, а большинство сводных задач растягиваются на всю длину проекта.
Более продвинутый автор мог бы даже подумать о структуре команды, но у него не так много способов выразить это в Project — в лучшем случае это названия ресурсов типа «Разработчик базы данных 1».
Авторы, которые действительно заботятся о ясности и наглядности, могут использовать цвет, чтобы визуально выразить различия между треками — обычно раскрашивая колбаски задач, включенных в разные треки, в разные цвета.
Сюда также входит способ использования зависимостей, известных как ссылки, не для выражения существенных зависимостей между задачами, а для размещения задач в плане в правильном порядке.
Функция автоссылки, автоматически создающая ссылку между двумя последовательно расположенными задачами, напрямую поощряет такое бездумное использование ссылок.
Отсутствие у «середины» четкого понимания семантики связей после нескольких итераций редактирования приводит к беспорядочной вставке плана со стрелками, идущими во все стороны.
Типичным проявлением неумелого использования ссылок являются связи, не имеющие реального смысла между задачами, включенными в разные сводные задачи, или между задачами, расположенными в СДР на разных уровнях (такие связи в целом могут иметь смысл, но соответствующие ситуации довольно редки в типичное планирование – хаотичные стрелки, оставшиеся от смешивания автоматически связанных задач, обычно везде следуют «среднему» плану).
Сами по себе лишние стрелки хоть и некрасивы, но превращаются в жуткую проблему при попытке выровнять нагрузку при объемном планировании.
Проблема тормозящей загрузки на самом деле носит системный характер и усложняет жизнь как новичкам, так и опытным пользователям Project. О опытных мы поговорим позже, а здесь опишем, какие типичные ошибки допускает «средний».
Эти ошибки просты – «середина» часто просто забывает посмотреть, какова загрузка ресурсов в итоговом плане, и в результате этот план нарушает правило, о котором мы говорили выше – «большинство людей работают над полноценным проектом».
без перерывов».
Типичным признаком является количество загрузок в представлении использования ресурсов, которое меньше или превышает 100%.
Проблему с перегрузкой (> 100%) обычно решают с помощью выравнивания, и продвинутые «мидлы» умеют это делать и часто об этом помнят (поскольку перераспределение обычно визуально заметно на диаграмме Ганта), но выравнивая задачи некоторых членов команды обычно создает еще большие дыры в рабочей нагрузке других.
Подобный план порождает массу практических проблем, поскольку он явно не описывает реалистичного хода реализации проекта и дает искаженное представление сразу обо всех параметрах проекта – как о цене (которая обычно занижается), так и о реальных сроках выполнения проекта.
задач (которые могут быть как завышены, так и занижены), а также о реальной нагрузке и требованиях к ресурсам.
Отдельной «средней» ошибкой является нечеткое разграничение продолжительности (т.е.
абсолютного времени, измеряемого в часах) и труда (т.е.
затрат труда, измеряемых в человеко-часах).
Здесь даже продвинутые «средние» сталкиваются с идиотской ловушкой Project, которая заключается в том, что по умолчанию в сетке отображается поле «Длительность», а задачи по умолчанию имеют фиксированные единицы или фиксированный тип работ и вводятся как управляемый усилиями.
Характерным признаком опытного «старшего» является то, что он понимает эти различия и как минимум вводит оценки в поле «Работы» (а в идеале меняет параметры по умолчанию в своей копии «Проекта» и решительно меняет тип всех задач при просмотре и редактирование).
Об искусственном интеллекте Project, который мучает «стариков», мы поговорим ниже.
В случае с «серединами» неразграничение часов и человеко-часов приводит к огромному количеству странных и не всегда явно заметных искажений параметров планирования в тот момент, когда автор начинает распределять ресурсы по задачам.
Еще большая проблема с часами и человеко-часами заключается в том, что, исходя из практического опыта, 90% клиентов не поднимаются в понимании Проекта выше базового «среднего» уровня и часто не понимают, в какую графу смотреть и что такое в этой графе написано.
Типичные вопросы таких клиентов при предъявлении полного плана в Project включают, например, «вы сказали, что проект продлится четыре недели, но по какой-то причине ваша общая работа составляет 560 часов — почему вы меня обманываетеЭ»
Старший дизайнер проектов MS
«Сеньоры», т. е.люди, освоившие все необходимые возможности Проекта, а также имеющие четкое понимание того, что именно они хотят выразить с помощью Проекта, начинают страдать от принципиальных недостатков Проекта как инструмента и средства выражения.
Проблема с рваной загрузкой никуда не уходит и зачастую возникает в полную силу даже у добросовестных «середняков».
Частично это объясняется тем, что не все четко помнят тип задачи в Project. Одной из причин является встроенный в Project «искусственный интеллект», который до недавнего времени имел тенденцию становиться все более и более сложным от версии к версии.
Задача искусственного интеллекта в Project — автоматически изменять одни параметры задачи при ручном или автоматическом изменении других.
Классический пример — уменьшение вдвое, утроения и т. д. продолжительности трудоемкой задачи при назначении ей второй, третьей и т. д. ресурс.
Количество подобных сценариев в рамках Проекта достаточно велико.
Поведение Project в некоторых из них регулируется настройками (некоторые из них являются настройками для конкретной копии Project на конкретной машине, а некоторые сохраняются в файле MPP и передаются между машинами).
Не все сценарии и правила одинаково хорошо документированы, некоторые настройки влияют на совершенно разные сценарии и т. д. и т. п.
Во многих сценариях поведение Project кажется нелогичным.
В целом эта часть Проекта чрезвычайно сложна и с высокой степенью уверенности можно сказать, что большинство пользователей Проекта не могут предугадать все проявления искусственного интеллекта в ходе своей работы и зачастую оказываются к ним неподготовленными.
«Средние» чаще всего остаются в блаженном неведении о тех изменениях, которые незаметно для них производит Проект. Судьба «старших» сложнее — после длительного опыта редактирования своих, а тем более чужих крупных планов в Project, они учатся ожидать внезапных гадостей от своего инструмента и периодически проверяют, чтобы Project ничего не испортил в проекте.
после их изменений.
Лакмусовой бумажкой является нагрузка, наблюдаемая посредством просмотра использования ресурсов – неожиданные и нелогичные искажения плана, вносимые автоматическими изменениями, обычно проявляются в виде отклонений в уровне загрузки ресурсов или в датах начала и окончания использования ресурса в проект. «Сеньор» обычно старается рисовать планировку с соблюдением простых базовых архитектурных принципов (помимо равномерной непрерывной загрузки важно, чтобы люди, занимающиеся смежными задачами т. е.
в одном треке, начинали работать над проектом и одновременно освобождались) и любое отклонение от этих принципов довольно легко увидеть в представлении использования ресурсов.
Заметить искажения, вносимые системой, легко, но исправить их зачастую бывает довольно сложно, особенно в проектах большого объема или сложной структуры.
Отмена часто не помогает — ручное изменение, которое привело к проблеме, откатывается, но безобразие, внесенное искусственным интеллектом, остается и его приходится исправлять отдельно, рискуя нарваться на другие автоматические изменения.
В определенных ситуациях искусственный интеллект становится упрямым и не позволяет исправить допущенные им ошибки.
Даже при редактировании не самых сложных планов нужно не забывать и избегать шалостей искусственного интеллекта при выполнении достаточно простых операций типа переноса задач из одного места плана в другое.
Простые, но не менее раздражающие ловушки, такие как автоссылка, о которой мы говорили выше, даже при простом копипасте могут создать ненужную связь между задачами или нарушить необходимую.
Некоторые «средние», склонные исследовать все варианты сложной системы, могут включить на своих машинах опасные и деструктивные функции, такие как автоматическая «оптимизация» распределения ресурсов (что имеет смысл только при планировании работы взвода строительного комплекса).
батальон с лопатами) — даже если «старший» небрежно начнет пересматривать такое планирование (особенно непосредственно на «средней» машине), Project с радостью перепутает распределение ресурсов и создаст беспорядок, не имеющий даже и следа смысла.
Но особенно очевидна неожиданная вредоносность искусственного интеллекта при редактировании планирования, в котором некоторые задачи уже помечены как выполненные, или, говоря более научным языком, задач, в которых появились данные о фактах (фактическая работа, фактическая продолжительность и т.д.).
Именно в таких ситуациях (хотя и не только в них) искусственный интеллект начинает вести себя особенно цинично и вносить в планирование изменения, которые трудно перенести и еще труднее откатить.
Яркими примерами являются внезапное создание пробелов в задачах, искажение плановой загрузки ресурсов внутри задачи, внезапный перенос задачи или группы задач после всех остальных и упорное нежелание вставлять их на место даже с помощью ручного нивелирования.
Опытный пользователь предвидит подобные неприятности и обычно знает некоторые приемы, позволяющие их избежать (например, дисциплинированное использование ограничений задач), но в целом при работе с объемным планированием, особенно с учетом фактических данных, обычно начинает тратиться все больше и больше времени.
борьба с инструментом, а не за редактирование контента.
В какой-то момент даже «старший» устает от борьбы, сдается, опускает руки и со вздохом отправляет коллегам или клиентам план, в котором ресурсы зачастую заняты на 83,58% в пятницу и 16,42% в следующую.
Суббота.
В качестве бонуса отметим квантовые эффекты, возникающие после нескольких итераций совместной работы над большим MPP-файлом (около пятисот задач), в котором коллега-буквалист решил исправить начало рабочего дня в календаре со стандартной 8: 00 на что-то «более соответствующее» нашим реалиям», например, на 11:00. Начинающий «старший», который обычно рассматривает планирование в масштабе дней или недель, будет слегка удивлен странной манерой, с которой некоторые задачи без видимых причин перескакивают на следующий рабочий день.
Заглянув в представление ежедневного использования ресурсов, он увидит в целом совершенно равномерную загрузку каждого ресурса со странными хвостами, скажем, 62% спереди и 38% сзади.
И только увеличив масштаб до часов, он ужаснется и поймет, что если он захочет привести все это в божеский вид, то его ждут полтора часа скучной ручной работы.
Обычно «старший» решает не быть перфекционистом (ведь в жизни есть вещи поважнее, чем грамотное планирование) и продолжает работать с тем, что есть.
Позже мы сталкиваемся с более зловещими проявлениями искусственного интеллекта, описанными выше, которые в сочетании с низкоуровневыми заусеницами в календаре зачастую выглядят особенно странно и особенно утомительно лечить.
Продолжая метафору разработки на C/C++ (возможно, в наши дни немного устаревшую), полное использование Project в сложных сценариях начинает напоминать попытку построить очень большую и сложную систему, написанную на C/C++, без использования make/ant и наличия библиотек для что нет никакой гарантии согласованности между заголовочными (.
h) и двоичными (.
a/.
lib и .
so/.
dll) файлами, имеющимися в нашем распоряжении.
Теоретически это можно сделать, но это может потребовать значительных усилий и хорошей квалификации, а собранная система может иметь критические ошибки.
Все естественное не безобразно, или коротко о хорошем
После обсуждения проблем и подводных камней MS Project может возникнуть вопрос — зачем Microsoft разработала и продвигала такую ерунду? Мы, конечно, далеки от обвинений Microsoft в непрофессионализме и злом умысле.Прежде чем продолжить обсуждение проблем, кратко коснемся того, для чего подходит MS Project, и попытаемся объяснить ряд его особенностей, которые на первый взгляд кажутся бросающимися в глаза.
Основная идея здесь будет достаточно простой и фактически совпадает с основным тезисом всей статьи: MS Project плохо подходит для планирования и сопровождения минимально сложных программных проектов.
Это не означает, что он одинаково непригоден для проектов в других сферах человеческой деятельности.
MS Project создавался как универсальный инструмент управления проектами — а управление проектами как технология управления используется не только при разработке программного обеспечения.
Существуют области человеческой деятельности и масштабы проектов, в которых MS Project можно использовать без особого риска превратить планирование в дымящуюся гору перемешанных макарон.
В основном это относится к сценариям, в которых выполняется одно из следующих условий:
- Структура плана проекта (речь в основном идет о структуре WBS) либо определяется стандартами соответствующей области деятельности (например, описывает стандартный технологический процесс), либо, по крайней мере, не меняется после план создан.
- Количество задач и/или ресурсов невелико.
- Задачи независимы друг от друга, а ресурсы однотипны и взаимозаменяемы.
Что касается тех функций Project, которые кажутся бессмысленными или даже вредоносными, любому, знакомому с историей индустрии программного обеспечения, должно быть ясно, что причина кроется в эволюции самого MS Project как продукта, а именно, в последовательных попытках Microsoft сделать он становится все более универсальным, сохраняя при этом обратную совместимость с предыдущими версиями.
Пресловутый «искусственный интеллект» и прочие опасные для новичков особенности — лишь следствие:
- стремление обслуживать как можно больше различных вариантов использования с помощью продукта (приводящее к усложнению концептуальной модели продукта и бессистемному увеличению числа доступных вариантов конфигурации);
- необходимость сохранения целостности и непротиворечивости этой модели данных при редактировании; И
- желание облегчить новым пользователям изучение продукта и сделать пользовательский интерфейс продукта и процесс редактирования «простыми и интуитивно понятными».
Увы, MS Project, в отличие от MS Word, предназначен для описания определенной модели реальности — и излишняя сложность в использовании инструмента приводит к тому, что модели неадекватны и не служат своему основному назначению — они не позволяют ответить на вопросы о проекте, которые были перечислены в начале этой статьи.
Мы признаем, что концептуальная модель MS Project действительно позволяет описывать вещи, которые сложно сразу выразить с помощью популярных альтернатив (обычно на основе линейных списков задач, известных как backlog-style).
К действительно полезным функциям относятся, конечно же, зависимости — зависимости между задачами, те самые ссылки.
Остальное (индивидуальные календари, возможность описания профиля нагрузки при работе над задачей и т.п.
) в контексте планирования программного проекта представляют излишнюю сложность и скорее мешают.
MS Project в реальном мире
Из предыдущей истории в целом следует очень печальный вывод - без блестящего владения MS Project всеми людьми, которые своими руками трогают файл MPP, планирование в MS Project практически невозможно использовать для отслеживания прогресса в реальном времени.-life-программный проект с достаточным уровнем детализации.
Ибо в реальном проекте неизбежно будут добавляться, удаляться и изменяться задачи, в том числе уже начатые, что, очевидно, создает среду, в которой зловещий Проект искусственного интеллекта может раскрыть весь свой потенциал.
Многие люди тем не менее продолжают использовать MS Project в своей практике — из-за давления со стороны руководства и клиента, предубеждений, незнания или привычки.
Как они это делают? Решение простое и предсказуемое — пользователи MS Project делают свою задачу выполнимой, упрощая ее.
Упрощения этого можно достичь разными способами: сознательно упрощая сам проект, сознательно или неосознанно игнорируя некоторые реальные аспекты проекта или используя какой-то другой инструмент параллельно с MS Project.
прокрустово ложе
Первый способ — настолько простая организация самого проекта, чтобы его можно было с относительным комфортом осуществить в MS Project, — на первый взгляд выглядит прямо-таки привлекательно.В конце концов, все, что позволяет нам упростить нашу работу, вероятно, хорошо, а просто организованный проект, вероятно, лучше, чем сложно организованный проект. В определенной степени это правда, но увы, в случае с MS Project порог «комфортной сложности» достаточно низок.
Чаще всего, как уже говорилось выше, довольно простые проекты уже настолько просты, что их можно более эффективно отслеживать, используя более простые инструменты, чем MS Project. Одним из характерных методов упрощения является, например, декомпозиция проекта на отдельные подпроекты, выполняемые изолированными, очень небольшими командами по принципу «разделяй и властвуй».
Другой подход, включающий модные элементы agile, предполагает выполнение проекта короткими итерациями, для каждой из которых создается и поддерживается в MS Project отдельный план – чтобы планы не успевали накопить достаточное количество изменений и с ними еще легко справиться.
Легко заметить, что во всех этих случаях использование MS Project вообще не дает никакой дополнительной пользы — задача планирования простого проекта достаточно тривиальна, чтобы ее можно было решить гораздо более простыми средствами (такими как канбан-доска, простой линейное отставание и т. д.).
Увы, хотя, повторимся, независимо от используемых инструментов, упрощение организации чаще всего полезно, не каждый проект поддается такому упрощению.
Блаженное неведение
Сознательная работа по упрощению фактической организации проекта – в некотором смысле даже признак настоящего мастера своего дела.Увы, большинство начинающих менеджеров проектов идут совершенно другим путем.
Понимая, что ведение полноценного планирования в MS Project требует значительного количества усилий и времени (которого всегда не хватает), вместо упрощения проекта упрощают процессы планирования и контроля проекта.
Обычно это достигается игнорированием некоторых его аспектов при ведении проекта – либо бездумно, либо в надежде, что он срастется сам собой.
Иногда такой выбор может быть оправдан (что-то действительно может быть не очень важно в конкретном контексте — гипотетический пример — работа над низкоприоритетным проектом «по остаточному принципу» без реальных ограничений по бюджету и времени).
Чаще всего то, что игнорируется, оказывается в «слепой зоне» руководителя и команды, откуда потом неожиданно могут вылезти неприятности.
Характерным признаком такой ситуации является искреннее недоумение, когда рецензент спрашивает: «А как вы отслеживаете Х в своем планированииЭ» и ответ варьируется от «Извините, я думал, в Project так нельзя» до «все знают, что в Project никто так не делает», в зависимости от степени уверенности автора в себе.
Другой вариант ответа: «Да кого вообще волнует XЭ» (особенно убедительно в контексте денег и сроков).
Поскольку MS Project становится наиболее хрупким в ситуации, когда проект изменяется в процессе его выполнения, одним из наиболее распространенных случаев является то, что план в Project перестает обновляться через некоторое время после запуска проекта (или не начинает обновляться вообще).
Если при этом Project как инструмент заменить чем-то другим, ситуация в целом может остаться под контролем.
Однако иногда мы видим, как файл MPP, созданный в начале проекта и больше не обновляемый, продолжает использоваться в качестве основы для измерения прогресса и отчетности.
По сути, в этом случае менеджер и команда игнорируют те самые изменения, которые происходят в любом работающем проекте.
Отчасти такому подходу способствует малопонятная философия управления, в которой базовое планирование считается чем-то священным и «истинным», а накапливающиеся по пути изменения — чем-то ошибочным или случайным — «отклонениями от плана».
Поскольку человек подсознательно часто считает, что любым случайным шумом в системе можно пренебречь, он охотно и естественно начинает игнорировать изменения.
Явным признаком поздней стадии разработки является использование менеджером файла MPP, который не обновлялся в течение нескольких месяцев, для описания статуса проекта.
Чаще всего между реальной картиной мира и таким файлом MPP нет ничего общего, но менеджер и команда проекта продолжают использовать старый файл MPP как своего рода внутренний герметичный коммуникационный каркас.
Человеку вне проекта зачастую сложно понять такое описание без особых умственных усилий.
Довольно часто люди понимают, что игнорируют что-то очень важное, используя Project таким образом, и естественным образом приходят к третьей стратегии — костылям и альтернативным инструментам.
Костыли и альтернативы
Как уже говорилось, иногда сама жизнь заставляет человека так или иначе использовать MS Project. Человек уже может быть достаточно опытным, чтобы понимать или хотя бы подозревать, что одного этого инструмента недостаточно для полноценного управления проектом, но может не иметь веса или способности убедить все заинтересованные стороны отказаться от него.Если человек достаточно добросовестный, он часто начинает дополнять Проект другими инструментами.
Самый простой и обычно наименее эффективный вариант — использовать собственную память в качестве дополнительного инструмента.
Понятно, почему этот метод неэффективен, когда проект выполняется командой из более чем одного человека, поэтому мы не будем на этом подробно останавливаться.
К этой же категории, увы, относится использование любых других труднодоступных артефактов, обитающих в личном пространстве руководителя, — бумажек, блокнотов, папок электронной почты, личных календарей.
Теги: #управление проектами #программное обеспечение для управления проектами #программное обеспечение для управления проектами #Microsoft Project #Project Management
-
Серия Dell Studio 1558-B74P43
19 Oct, 24 -
Ультрафиолет На Двух Пальцах
19 Oct, 24
