Наш совместный с коллегами из отрасли анализ факторов успеха ИТ проектов подходит к концу, а факторы становятся все менее и менее очевидными, хотя вполне объяснимыми. Давайте рассмотрим наш следующий по порядку аспект проектного управления. Сегодня мы поговорим вместе с Александром Лепехиным, бизнес-аналитиком Диалог ИТ, о важности масштаба контрольных точек в проекте. Итак, что мы узнали.
Меньший масштаб контрольных точек делает проект, по всей видимости, более управляемым. Что ж, не поспоришь, звучит логично. В жизни тоже, зачастую, происходит так, что есть у вас какое-то дело, которое надо закончить, скажем, через неделю. Когда 99% людей за него сядут, если оно кажется не сложным? Правильно, через 5-6 дней. А представьте, что вы ошиблись с оценкой трудоемкости? Сделать то, вы скорее всего его сделаете, но какими усилиями и каков будет конечный результат, это, конечно, большой вопрос. А вот если бы это дело разбито на 5 подзадач, по 1 на каждый день и плюс буфер в конце, наверняка результаты были бы куда лучше. Чем от этого примера отличается ИТ проект? Да практически ничем, чуть большим масштабом. Давайте копнем поглубже и посмотрим на несколько аспектов, которые становятся более управляемым, если мы уменьшаем масштаб контрольных точек.
- Ожидания заинтересованных сторон. Помните о чем говорила Аня Гашкова в предыдущей части нашей серии статей? «Лучше конечно создавать прототипы, создавать продукт постепенно и сразу демонстрировать, чтобы получать обратную связь». Это и есть ни что иное, как меньший масштаб контрольных точек, благодаря которым мы точно понимаем, в ту ли сторону копаем.
- Контроль качества. Исследования и практический опыт показали, что очень часто, когда тестирование продукта является последним отдельным этапом, на него может остаться времени и ресурсов меньше запланированного, потому что мы «задержались по пути». Если мы будем контролировать работы постепенно, гораздо больше шансов иметь на выходе более качественный продукт.
- Контроль продуктивности команды. Первоначальный план может потребовать существенных корректировок, если мы поймем, что команда просто не справляется с запланированной нагрузкой. Но как это понять, если мы сверяем план-факт только в конце проекта? Делать это желательно чаще, причем также необходимо учитывать то, что скорость работы команды может со временем возрасти, потому что люди могут сработаться.
Все эти аспекты напрямую влияют на наш любимый проектный треугольник, рамки-сроки-бюджет, у которых есть все шансы «поплыть», если не уделять должного внимания контрольным точкам.
Последнее, что добавим, это выбор контрольных точек, если у руководителя есть несколько проектов. Что такое контрольная точка? Это как маленький дедлайн, который нужно удержать. А что будет, если поставить все дедлайны на один день? Любой нормальный человек ответит, что будет «тяжеловато». Поэтому, если проектов ведется несколько, очень важно стараться их раскидать во времени таким образом, чтоб контрольные точки не наслаивались или хотя бы не сильно наслаивались.
Читайте далее ВВОДНАЯ ЧАСТЬ 2 ЧАСТЬ 3 ЧАСТЬ 4 ЧАСТЬ 5 ЧАСТЬ
