говорит и показывает Павел Федотов
Я вот тут решил на досуге оформить и выложить библиотеку форм документов для проектных менеджеров, которой пользуюсь в повседневной жизни. Там почти все — от шаблона для устава проекта до актов, форм запросов изменений и прочего. Т.е., это такие готовые формы, которые — бац! — взял, адаптировал — и в бой.
Имеет смысл этим заморачиваться? Будет ли это кому-нибудь интересно?
Кстати, 11-ого ноября 2011 года я буду выступать на регулярном мероприятии для IT-шников, которое проводится в Астане — IT-Friday. Говорить буду про себя любимого, про управление проектами в условиях Казахстана и стартаперство. Приглашаю всех желающих посмотреть на меня и задать интересующие всех вопросы.
До встречи!
UPDATE: Похоже, что ITFRK перенесут на поздние числа, ближе к концу месяца. Там и встретимся :-)
Я не раз сталкивался с тем, что профессия проект-менеджера воспринимается в корне неверно. Как вы думаете, что считают окружающие непосредственным результатом труда проект-менеджера? Правильный, детальный и исчерпывающий план проекта. По этому плану, мол, потом все и работают. Отсюда – профанация и дискредитация профессии в глазах обывателя («а что, я тоже план нарисовать могу»).
Планирование – это, прежде всего, анализ поставленных задач и их альтернатив. Это эффективное использование доступных ресурсов. Это моделирование процессов и тестовый стенд всего проекта. Это база для эффективного взаимодействия всех участников. Это основа для отслеживания изменений и контроля.
Менеджер проекта – это врач, который держит руку на пульсе, постоянно осматривает больного (отслеживание и контроль), ставит диагнозы (анализ и управление требованиями), соответственно диагнозу назначает лечение (выбор методологии, управление рисками). Проект-менеджер – это лечащий врач, отвечающий за выздоровление пациента (выполнение проекта).
А не то, что многие думают.
Любые проблемы в разработке программного обеспечения и IT отрасли в целом – так выглядят лишь при первом приближении. Уже на стадии непосредственной работы, на проекте, понимаешь – это не проблемы, это просто «трындец»! Гигантский. И все твои оценки, все твои ожидания псу под хвост, к чертям, в тартарары.
И с этим ничего не поделаешь – лишь опыт, сын ошибок трудных, позволяет хоть в какой-то мере спрогнозировать и оценить размеры ожидающихся на проекте проблем. Но, такова жизнь, часто даже опыт не спасает от несмертельных ошибок – в один прекрасный момент, играют риски настолько неожиданные, настолько сложно прогнозируемые, что не устаешь удивляться.
Выход тут только один – заводить отдельную тетрадочку (или полочку в голове), куда непременно складывать все те ситуации, что возникают в вашей практике. День за днем, проект за проектом, копить эмпирические данные – да не просто копить, а учитывать в каждом последующем проекте (с оглядкой, конечно, на предметную область). Другого выхода нет.
А вы как хотели?
Не сложная, для разбирающегося в предметной области проекта, штука. Однако, в условиях быстро меняющихся приоритетов, технологий и областей применения собственных талантов – требует не всегда тривиальных решений. Две основные проблемы – как сделать так, чтобы исполнитель меньше «завышал» оценки и при этом, оценки соответствовали реальному уровню подготовки этого исполнителя.
Без эмпирических данных что-то говорить сложно в принципе. Именно поэтому, я в каждом уникальном для меня случае, готовлю специальную маленькую таблицу, в которой выписываю все мало-мальски значимые и часто появляющиеся задачи. Эта таблица выглядит примерно так:
Условные обозначения квалификации сотрудников могут быть любыми. Хотите – делайте как я, «поясами» всех обвешивайте. Можете даже устроить маленькую армию внутри компании, военные звания неплохо встраиваются в корпоративную культуру и сленг.
Зеленым цветом выделяются уже известные величины (то есть те, которые подтверждены реально выполненной задачей). Красным – те, что строятся на моих предположениях, опыте и прогнозах, основанных на «зеленых» показателях. Синие «вопросы» – это величины, которые мне не удалось проверить/просчитать.
Опираясь, впоследствии, на такую таблицу, нам будет проще оценивать стоимость задач – появится отправная точка в такой оценке и история изменения стоимости. Естественно, что чем больше будет у нас результатов, тем точнее будут цифры в этой таблице.
Разница в оценках зависит только от квалификации сотрудника – качество у нас остается всегда неизменной величиной. Поэтому, на эту же табличку можно легко повесить градации по заработной плате и бонусам: работаешь как «черный пояс» – значит и зарабатываешь как «черный пояс».
Исключительно удобно.
Устав проекта – это хорошо. Хорошо, когда он есть, когда в нем четко обозначены границы проекта и ответственности. Однако, наша с вами жизнь странная штука, и часто наличие такой замечательной штуки как устав – не спасает.
Когда заказчик видит первый документ, который ему необходимо утвердить, он задает вопрос: «А что это?». Приглядевшись, заказчик понимает, что этот самый «первый документ» донельзя серьезен и максимально строго оговаривает настолько принципиальные вещи, что утвердить этот документ невозможно категорически.
Во-первых, чаще всего заказчик не очень точно представляет себе, а что же ему нужно от проекта. Нет, мы легко получим принципиальное видение владельца бизнеса (руководителя), максимум пожеланий и заявок от непосредственных пользователей. Однако удовлетворить и тех, и других без явного определения реальной цели проекта будет невозможно.
Во-вторых, почти всегда видение заказчика проекта отличается от видения исполнителя. Принципиальная разница – в образовании, взглядах, профессии. То, что важно для профессионального финансиста или управленца, для IT-специалиста просто прихоть.
В-третьих, и это самая серьезная ошибка, почти всегда устав проекта готовится наобум. То есть, натурально, это первый документ, которым заказчика обрадует исполнитель, однако высасывается он, что называется, «из пальца». А на самом деле, требует тщательной подготовки и первичного обследования в виде серии интервью, и последующего полноценного анализа.
Если учесть, что с точки зрения наших с вами реалий, устав проекта лучше сделать частью непосредственно договора (в виде приложения к нему), то выходит, что работы по первичному обследованию мы с вами должны начинать: а) до подписания договора, б) бесплатно (не всегда).
Насколько к этому готовы вы (и те, кто у вас работает) – мне сложно судить. Но, если вы сделаете это именно так – вы сможете убить всех зайцев разом: и заказчику понимание его потребностей дать, и свои риски свести ближе к нулю, и шансы на успешный контракт – выше.
Главная проблема всегда и везде – это оценка объемов работ. Особенно, если приходится работать с государственными органами или частным бизнесом, построенным по принципам работы государственного органа. Проект в таком случае превращается в поле битвы, главная цель которой – выяснить кто, кому и сколько должен.
Виной тому – миллион самых разных причин (в том числе — несовершенство правил и директив, регулирующих процедуры закупок). Так или иначе, но проекты такого типа обладают одним общим свойством: рамки работ не конкретизируются, формулировки расплывчаты, ожидаемый результат описан витиеватой словесной конструкцией.
Именно это, к сожалению, приводит к разночтениям, неожиданным сменам курса в процессе работы над проектом, а то и вовсе полной переделке уже сделанного. Хорошо, если вы до этого успели закрепить границы проекта в соответствующем документе (в условиях постсоветского пространства, нет ничего лучше ТЗ, оформленного согласно ГОСТ).
Если нет, то вы имеете все шансы на то, чтобы стать вечной «дойной коровой» для своего заказчика. Ибо проектные требования имеют свойство разрастаться, увеличиваться в объемах и сложности, а потерявший границы заказчик – очень быстро входит во вкус.
Конечно, мы с вами обсуждаем весьма крайний случай. Но, опыт показывает, что жизнь, по большей части, как раз и состоит из таких крайностей. И надеяться на устав проекта, либо иные проектные артефакты, не приходится.
Разные люди воспринимают мир по-разному в силу воспитания, привычек, образования, опыта и многого другого. И через это, совершенно по-разному ставят задачи – особенно, если постановка задачи происходит в устном порядке.
Одно время я работал с весьма интересным руководителем, имевшим манеру (в силу ряда причин) ставить задачи в виде чисто гипотетического вопроса: «А можно ли сделать так-то?». То есть, это ему казалось, что задачу он поставил – я же, как человек простой, слышал лишь вопрос – и давал на него конкретный ответ: да или нет, и объяснял почему.
Первый наш конфликт произошел именно на этой почве. Почему я не выполнил задание? Потому, что его не было. Я получил вопрос и дал соответствующую консультацию. Магического – «это нужно сделать к такому-то сроку» — не было.
С тех пор, я предпочитаю письменную постановку задачи (во всяком случае, в том, что касается ее сути – сроков, границ, качества). Во-первых, легче избежать споров о формулировках и датах постановки задачи. Во-вторых, перед тем как описать задачу, руководитель сможет продумать ее формулировку (письменная речь и устная работает по-разному). В-третьих, всегда остается «след» (а это очень важно в групповой работе).
Именно поэтому, важно и нужно использовать любой доступный инструмент, способствующий организации процесса постановки и донесения задач: пусть это будет простая электронная почта, issue tracker, корпоративный календарь, что-нибудь специализированное и «заточенное» именно на групповую работу – но у вас обязательно должна быть система и некий стандарт в постановке задач.
Иначе, вы будете тратить неоправданно большое количество времени на разбор конфликтов, связанных с некорректной постановкой задачи, мучить себя и коллег, выясняя кто, что и когда сказал – и кто же, все-таки, сделал это раньше.
А нам этого с вами и даром не нужно.
В управлении проектами основное – это преодолеть инертность. Чью угодно – коллег, представителей заказчика, начальства, свою (в первую очередь). Это как в физике: свободное тело, на которое не действуют силы со стороны других тел, находится в состоянии покоя или равномерного прямолинейного движения.
Ну, так представьте себе проект, который находится в состоянии покоя (стагнации) или не торопясь движется к завершению. Это – мертвый проект по своей сути. Он не будет сдан никогда, в принципе.
И чаще всего, единственные в окружающем мире силы, которое воздействуют на тело проекта – это силы менеджера проекта. Иногда – единственного кровно заинтересованного в сдаче проекта участника.
Однажды, знакомый менеджер из Columbus IT, сказал мне, что я имел неосторожность сказать фразу, которую он оценил – и начал воплощать в жизнь. Я долго не мог вспомнить, что же такое «ляпнул» — и, в конце концов, попросил озвучить сказанную мной фразу.
«Когда я готовил описание проекта, то обнаружил, что ты его тоже делал одновременно со мной… Я в недоумении спросил, для чего эти излишние усилия? На что ты ответил, что некоторые вещи приходится делать и по 3-4 раза, потому как нельзя допустить, чтобы процесс останавливался.Я это оценил, подумал, что это отличный стандарт. Текущий проект, который я вел (и который вяло буксовал, потому что на нем все делалось последовательно) – с того момента стремительно развивается, так как каждый процесс дублируется (иногда не один раз), чтобы полностью исключить зависимость от конкретных исполнителей».
И действительно, в проектах, особенно на начальной стадии – и при избыточности выделенных ресурсов – важно и нужно дублировать задачи, чтобы избежать форс-мажоров, в виде заболевших или не успевших сделать вовремя работу сотрудников (например).
Дополнительным преимуществом для менеджера проекта будет возможность сравнить либо объединить итоги работы разных специалистов – и получить качественный, отчуждаемый результат. Еще одним полезным эффектом такого подхода при сложных либо новых типах задач, является возможность разработки стандартных ставок их стоимости.
Единственным «но» в таком случае становится нехватка ресурсов на проекте. К сожалению, чаще ресурсов катастрофически не хватает – и менеджеру проекта приходится искать баланс между надежностью и скоростью его реализации.
Самозванный эксперт в сфере управления проектами и стартаперства.
Комментарии