Понравился пост? Добавь его в Твиттер или в закладки! Быстро добавить в закладки легко — просто нажми на нужную кнопку слева.
Хочешь больше постов? Жми на кнопку не стесняясь. Чем больше у меня читателей, тем больше у меня мотивации писать чаще и интересней...
Управление проектами давно занимает мой мозг, я хочу повысить свою эффективность, но уменьшить количество работы, которую выпоняю. Стремясь к этому, я изучаю, как построены процессы управления проектами в разных компаниях.
Недавно я был в одном из специализированных отделов по управлению проектами в компании с иностранными инвестициями. У людей все, как положено. Доска, на которой можно рисовать схемы, установленный лицензионный Microsoft project, который рисует временные диаграммы, куча книг, документации. В отделе по управлению проектами работают специальные люди, которых специально обучают управлять сложными проектами. Такой себе спецназ, способный решать разные боевые корпоративные задачи, у многих помимо высшего образования часто в области экономики есть современное бизнес-образование, на стенах висят сертификаты, свидетельствующие о прохождении дорогих тренингов.
Начинаю более тщательно изучать обстановку. Я как разведчик в тылу врага, должен быть внимательным, острожным и выискивать самую скрытую информацию, которая может быть полезна мне, человеку, у которого непрофильное военное образование, связанное не с управением проектами, а с сетями передачи данных, построением ИТ-систем, программированием и прочей чепухой.
Разведка становится интересней из-за того, что этот этот отдел управляет проектами в моей родной предметной области — информационные технологии.
Под доской, на которой рисуют интересные схемы, нахожу шикарную отпечатнную типографским способом большой плакат-иллюстрацию, который описывает процесс управления проектами. Вся картинка глобально разбита на 4 больших квадрата со стрелочками, перетекающими из одного квадрата в другой.
Первый квадрат маленький (но не самый маленький, как многим должно показаться) — постановка задачи на проект, создание первичной проектной документации.
Второй квадрат самый большой и расписан наиболее подробно — подготовка проекта, изучение предметной области.
Четвертый квадрат средний по размеру — управление проектом после его реализации и сдача проекта заказчику.
А где же третий квадрат? А третий квадрат самый маленький, и находится в углу плаката. Расписан буквально двумя-тремя словами и называется он "Реализация и внедрение проекта".
В этот момент я прекратил разведку. Спецназ на деле оказался полувоенным подразделением, основная задача которого — на учениях надувать резиновые цели в виде танков для обучения действующих боевых подразделений. Сразу стало понятно, что работа этого отдела никак не влияет на качество исполнения того, чем они пытаются управлять. Т.е. от хорошего или плохого надувания резинового танка попадание или непопадание в цель при отрабтке налета авиации зависит от того, кто стреляет в цель из боевого самолета, а не от того, кто этот танк надувает.
Почему я пришел к выводу, что отдел бутафорский, и в отделе никто ничем реально не управляет и ни на что не влияет? А потому, что даже на сильно формализированной схеме управления проектами в квадратике, где расписана реализация и внедрение, должно быть больше всего информации, т.е. этот квадратик должен быть на схеме самым большим, а не самым маленьким и должен быть проработан по максимуму. Ибо как бы ни был важен этап изучения рынка, как бы ни был важен этап изучения предметной области, постановки целей, расчета точки безубыточности и других экономических показателей проекта, практически все зависит от внедрения.
Более того, в условиях, когда отдел по управлению проектами во время подготовки проекта изучает то, что давно известно практикам, которые берут участие в проекте на стадии его реализации, становится еще больше понятно, почему стадия реализации плохо проработана — руководители проектов просто не понимают предметной области в момент, когда проект стартует.
Второй достаточно противоречивый (для некоторых) вывод, сделанный в этот же день, по своей ценности может обойти первый. Сам вывод звучит так:
За исключением тех сфер и областей, где для подготовки к внедрению требуется задействовать фундаментальную науку или продолжительные теоретические изыскания, подразделение теоретиков в компании должно быть сокращено как класс. Грубо говоря, если вы не работаете в атомной энергетике, в медицине, в самолето и ракетостроении, в отрасли, которая по своей сложности не уступает ранее перечисленным, то чем раньше вы пройдете процесс подготовки проекта и приступите к его внедрению, чем подробнее будет проработан именно процесс внедрения и реализации проекта, тем раньше вы получите результат, а результат скорее всего будет положительным.
Последующая методичная итеративная обработка и исправление ошибок позволит в сравнительно короткие сроки исправить большинство недочетов и язъянов, которые появились при быстром планировании. Выраженная реакция потребителей продукта даст понимание, чего в этом продукте не хватает, после чего вторая и последующая версии продукта явно будут выглять лучше.
Да. Вы можете сказать, что многие вещи потом сложнее менять из-за ошибок и промахов, допущенных на этапе создания дизайна, но во многих случаях, опять таки за исключением тех случаев, когда для реализации проекта необходимо задействовать фундаментальную науку, серьезные математические изыскания или подготовить большую и серьезную теоретическую базу, перед выпуском продукта и постановкой его на конвейер необходимо провести разработку рабочего прототипа.
Да, когда рабочий прототип сам по себе стОит более миллиона долларов, то подготовка к реализации проекта и его планирование должны быть сложней и более продуманными, т.е. штат теоретиков должен быть, но это автоматически должно увеличивать сложность и глубину проработки на этапе реализации проекта, что автоматически означает только одну вещь — если у вас есть проектный спецназ, то он должен решать практические задачи, сами задачи должны быть важнее, чем подготовки к их решению, решение практических задач даже в формализированном виде должно быть более проработанным, чем подготовка к решению.
Ваши выводи классически для аутсорсинговой сферы. Типа реализация это "всё" а остальное - только приложение.
Поработав в аутсорсинге в Украине 7 лет и третий год работая в Лондоне я поменял свою точку зрения координально. Изначально она была идиентична Вашей.
Прям сейчас со мной на 2у миллионном проекте работают 5 аналитиков, один ПМ, четыре бизнес эксперта и т.д. - и это всё до того, как мы начали набирать команду разработки. Саму разработку отдадим на этот раз в Сингапур (хотя есть отдел в Киеве, но в том отделе плохо с пониманием бизнеса. А жаль - мне было бы проще).
Итого - постановка и требования занимают с января до сих пор но разработка будет только июль-декабрь.
Таки небольшой квадратик. Для взрослых проектов.
PS: моя жена пошла в стартап работать с этой недели. У них 40 человек из которых только 8 разработчиков.
Дата комментария: 2011.05.27
Автор: Yukko
Andrey, я только что приехал из другой страны. Своими глазами видел, как 20 опытных техников делают то, что не делают 200 аналитиков, к которым присоединены 20 опытных техников.
Судя по всему, проблемы возникают тогда, когда есть непонимание бизнеса, чтобы понять бизнес, нанимается человек со стороны. А когда разработка отдается в Сингапур при наличии команды бизнес-аналитиков — это явный признак автоматизации бардака. Сама разработка не сложная, но просто непонятно, что разрабатывать.