Железный треугольник

В последнее время на собеседованиях сталкиваюсь с тем, что не все люди, претендующие на роль team/dev lead, знают про железный треугольник. Хочется немного осветить этот вопрос. Сразу скажу, что опытные PM’ы не найдут для себя ничего нового в этой заметке, она ориентирована на тех, кто еще только начинает изучать проектный менеджмент.

Итак, железный треугольник (iron triangle, project management triangle) – это абстракция, описывающая взаимодействие основных атрибутов или характеристик проекта: объема работ, сроков и ресурсов (команды, а следовательно и бюджета). Выглядит он обычно так:

 

Иногда в центр этого треугольника кладут еще Quality, отмечая таким образом четвертую вершину, которая взаимосвязана с этими тремя, но мы сейчас не будем усложнять картину.

Смысл этого треугольника в том, что ограничения на объем работ (scope), сроки (time/schedule) и бюджет (cost/budget) должны быть разумными, и любой менеджер проекта должен уметь ими управлять. В противном случае проект рискует стать провальным.

Наверняка каждый, даже не занимающиеся непосредственного управлением проектами, сталкивались с ситуациями, когда оценка на разработку системы или ее куска превышает либо сроки, за которую необходимо сделать работу, либо бюджет, имеющийся у клиента. А может, сталкивался и с такими ситуациями, когда эта самая работа должна быть сделана в указанный срок ограниченными ресурсами (командой). Эту последнюю ситуацию как раз и называют железным треугольником, то есть треугольником, в котором все наши три вершины ограничены и зажаты, и у нас нет свободы действий ни по одной из них. И чем экстремальнее это “зажимание”, тем сложнее команде выполнить взятые на себя (или пообещанные кем-то сверху) обязательства.

Как же бороться с железным треугольником? Так же, как и с deadlock’ами – стараться не создавать предпосылок для его появления :)

Проще всего это сделать, когда железный треугольник начинает проявлять себя еще на стадии планирования проекта или его фазы. В этом случае у менеджера проекта есть единственная правильная стратегия: предложить клиенту выбрать две из трех вершин, которые ему наиболее важны, а третью оставить варьируемой и с ее помощью избежать проблем. Имея три вершины, имеем три варианта:

1. Клиент более важно иметь продукт готовым полностью (ограничен объем работы), и у есть бюджет лишь на определенную команду. В таком случае сроки выполнения работ выбираются нами (отталкиваясь от оценки, а также размера и качества команды) или вообще делаются варьируемыми, если это возможно. Здесь нужно понимать, что этот вариант возможен лишь когда у клиента ограничен месячный или квартальный бюджет, если не хватает бюджета на весь проект, то нужно искать уже пути удешевления производства: покупка или использование сторонних разработок, использование более “дешевой” рабочей силы (аутсорсинг), экономия на качестве. Варьирование сроков здесь никого не спасает.
2. Клиент хочет иметь продукт готовым полностью в указанные сроки. Единственный разумный (!) вариант здесь – увеличение команды. Не очень разумные варианты вроде сверхурочные работы тоже имеют право на жизнь, но их нужно использовать ОЧЕНЬ аккуратно. С увеличением команды тоже есть один нюанс: оно не всегда приводит к желаемому результату. Во-первых, новым людям нужно время на вливание в проект (если он уже идет). Во-вторых, не все задачи хорошо параллелятся – часто задача Б может быть сделана лишь только после завершения задачи А, поэтому добавлять людей для выполнения задачи Б нет смысла. В-третьих, большее количество людей в команде ведет к увеличению времени на их координацию и общение между собой, что увеличивает оценку объема работ и, следовательно, бюджет. То есть, опять же, клиент платит больше. Все это ведет к тому, о чем говорил еще дядюшка Брукс (перефразируя): 9 женщин не родят ребенка за 1 месяц.
3. Клиент хочет иметь продукт в указанные сроки, но у него нет бюджета на увеличение команды. В этом случае единственная наша возможность – это варьирование объема работы, т.е. приоритезация задач проекта и договор сделать лишь те, что мы успеем, с учетом приоритетов. Менее важные задачи рискуют оказаться за границами продукта к дате релиза.

Эта ситуация очень напоминает выбор спальника (да и кучи других товаров). Спальник имеет три основных атрибута для выбора, находящихся в обратной пропорциональности друг от друга: теплота, вес и стоимость. Если у вас ограничен бюджет на покупку, вы можете купить либо теплый спальник, либо легкий. Если же вы хотите и то, и другое – пожалуйста, но придется раскошелиться.

В железный треугольник можно попасть и в середине проекта. Причин может быть много: промах в оценке трудозатрат, давление со стороны руководства, в конце-концов, приход на уже идущий плохо спланированный проект. Что делать в случае, когда контракты уже подписаны?

Прежде всего, не паниковать :) Не вы первые, не вы и последние – по разной статистике в IT около 20-25% заваленных проектов, и еще около 45-50% – вышедших за рамки запланированных бюджетов, сроков, либо выпущенных не полностью готовыми (не вся функциональность либо плохое качество).

А вот дальше нужно сесть и хорошо подумать, причем желательно вместе с вашим клиентом. Возможно, вы сможете найти компромисс и освободить одну из вершин, а даже если и нет – клиенту лучше быть в курсе происходящего как можно раньше, а не за неделю перед релизом, чтобы успеть подстелить соломку, где это возможно. Оптимизация процесса работы и коммуникаций, более строгий контроль за выполнением работ, строгий change requests management, оплаченные сверхурочные, дополнительная мотивация сотрудников премиальными – все это может помочь не потерять лицо в глазах клиентов и избежать штрафов за срывы сроков. Но все-таки наилучшая рекомендация для менеджера проекта – постоянно держать в голове этот самый треугольник и отталкиваться от него, дабы свести возможность срабатывания этого риска к минимуму. Ну, и не забывать управлять остальными рисками, конечно же :)

А как вы решаете эту проблему?

Ошибки технических менеджеров проектов

В своей прошлой заметке я немного упомянул проблему перехода с технической карьерной лестницы на менеджерскую. Этот переход не так прост, как кажется многим техническим лидам. Очень часто он воспринимается просто как добавление новых обязанностей по общению с заказчиком, принятию каких-то проектных решений, а также как дополнительная ответственность. В том, что управление проектами - это абсолютно другая область знаний и навыков, которую необходимо изучать, отдают себе отчет не все. Как минимум, до первого заваленного проекта :)

Об общих ошибках управления проектами написано уже очень много, поэтому я не хотел бы повторяться. Об этом можно почитать здесь, здесь, а также в куче других мест - достаточно лишь погуглить по ключевым словам. Я же хотел бы остановиться на некоторых ошибках, которые свойственны именно бывшим техническим лидам, ставшим менеджерами проектов или начинающим выполнять эту роль в дополнение ко своим текущим обязанностям. Причем говорить я буду о бывших программистах, а не о QA, BA или ком-то другом, потому что:

• я на практике сталкивался в основном с PM, которые в прошлом были программистами, а не QA или BA - банально нет подобного опыта, поэтому мало о чем могу сказать
• на мой взгляд, PM из бывших QA и BA не будут совершать часть из перечисленных ниже ошибок, просто по тому что они специфичны для программистов
• я сам - программист, поэтому мне проще основываться еще и на своем личном опыте и своих ошибках :)

Думаю, любой человек, работая под началом разных менеджеров, видел различия в отношении и подходах. У каждого PM свой уровень знания и умений, менталитет, психология, поэтому стили управления отличаются. Но если посмотреть на PM, которые в прошлом были программистами, можно заметить некоторые общие черты и типичные ошибки, которые те совершают. Основная причина этих "типичных" ошибок - менталитет, установленные подходы и шаблоны работы в бывшей роли программиста, а не просто недостаток знаний или понимания процесса управления проектами. Почти любой программист, при условии хороших технических знаний и наличии лидерских качеств, может стать хорошим лидером, но это еще не значит, что он может стать хорошим менеджером. Между "управлением" продуктом, которым, по сути, занимаются DL или TL, и управлением проектом и командой, которым занимается PM есть большая разница.

Ошибка №1. Непонимание целей и задач роли PM

Я уже упоминал, что цели и задачи ролей DL и PM отличаются. Основная задача DL - реализовать продукт технически. Это его сфера ответственности. Основная задача PM - успешно завершить проект в рамках запланированных сроков, бюджета, объема функционала и его качества, таким образом сделав клиента довольным и счастливым. Попутно можно сказать, что основная задача QAL состоит в том, чтобы удостовериться, что полученный в результате выполнения проекта продукт - это именно то, что нужно клиенту и что качество этого продукта соответствует предъявленным требованиям, но QA мы пока что трогать не будем. Таким образом, обязанности PM состоят не только в том, чтобы общаться с клиентом, давать всем подзатыльники, а также писать спецификации и отчеты (изверги, бумажной работы навалили, ужас!), а в том, чтобы создать условия и наладить процесс работы, в рамках которых команда достигнет результата, попутно эффективно управляя требованиями, рисками, различного рода ресурсами (в том числе и человеческими) и т.д. И это все нужно понимать и делать, даже если PM - всего лишь дополнительная роль, которую вам приходится выполнять по долгу службы, а не настоящая должность.

Ошибка №2. Неумение смотреть на проект и продукт с точки зрения клиента (бизнеса)

Менеджер проекта в какой-то степени является промежуточным звеном между командой и клиентом. Поэтому если программист и DL могут позволить себе думать только о реализации и проблемах, связанных с ними, быть "по эту сторону баррикад", то PM уже должен думать не только о команде, но еще и о клиенте, его целях, желаниях и проблемах. Любой продукт, разрабатываемый в рамках проекта, несет для клиента какую-то выгоду (не обязательно финансовую). Если же мы в угоду желания попробовать новую технологию, реализовать эту фичу "по-своему" или даже просто по глупости убиваем эту выгоду - клиент не будет доволен. И PM иногда является единственным носителем полной информации о целях и желаниях клиента. Да, в какой-то степени это еще и обязанность QA, но зачастую они не могут принять решение в момент разработки, а лишь тогда, когда что-то уже сделано. Поэтому лишь PM может вовремя остановить разработку и направить ее в правильное русло. Нужно помнить, что PM является не только адвокатом команды перед клиентом, но и адвокатом клиента перед командой.

Ошибка №3. Считать себя самым умным и самым главным

Достаточно распространненая ошибка, особенно когда менеджером проекта становится очень технически подкованный программист, который был долгое время девлидом или архитектом. Авторитет бывших "лидеров" очень высок, и они с одной стороны не хотят его терять, а с другой - привыкают считать себя последней инстанцией в принятии технических решений, попутно перенося это и на управление проектом, становясь подлинными тиранами. Да, PM - это тот человек, который принимает окончательное решение, а также разрешает споры и конфликты. Но в то же время грамотный PM слушает команду, ее советы, дает оспаривать свои решения, а также старается создать условия для креатива и роста членов команды, попутно лишь поправляя курс по необходимости.

Ошибка №4. Злоупотребление делегированием-исполнением, а не делегированием-руководством (микроменеджментом)

Любой менеджер должен уметь распределять задачи (делегировать их). Существует два основных типа делегирования: делегирование-исполнение и делегирование-руководство. Делегирование-исполнение выглядит следующим образом: "Возьми пилу, пойди в сад, спили все сухие деревья, а когда закончишь - вернись и доложи мне". То есть фокус идет на методах исполнения обязанностей, на том, как что-то сделать. Делегирование-руководство в таком случае может выглядеть следующим образом: "Очисти сад от сухих деревьев". То есть фокус идет на результат, которого нужно достичь, на то, что нужно сделать, а не то, как. Как очистить сад от сухих деревьев - спилить, срубить или спалить - исполнитель может принять решение и сам. Право выбора, равно как и ответственность за результат, возлагается на исполнителя. Чем делегирование-руководство лучше - оно дает возможность человеку проявить свои способности и творчество в полной мере, возможно, быстрее или эффективнее добившись результата. Но в то же время если человек еще не умеет принимать решения (допустим, он еще неопытен), то нужно это делать за него, но только после того, как он хотя бы подумает над своим вариантом решения - чтобы он учился.

Конечно же, у менеджера проекта, которые сам был раньше программистом, всегда есть искушение рассказать кому, что и как делать, залезть в девелопмент и постараться порулить там. Но по сути это как раз и есть тот самый микроменеджмент, а также влезание в чужую сферу ответственности, которые не любит ни один специалист. К тому же это еще и отбирание у человека или команды в целом возможности выбора, права на ошибку и ответственности за свои поступки, ограничение творчества и инициативы.

Ошибка №5. Боязнь показать свое незнание

У программистов это чувство развито очень сильно :) Поэтому довольно часто менеджеру сложно спросить какие-то детали, попросить о помощи - ведь он вроде бы как самый главный в команде (см. ошибку №3), негоже перед подчиненными показывать свою слабость, вдруг перестанут уважать. Достаточно глупо и, к сожалению, иногда весьма критично для проекта. У PM есть куча других обязанностей, поэтому ему часто некогда вникать в детали, новые технологии и подходы разработки. Немудрено, что некоторые люди на проекте, которых вы раньше учили сами, вдруг окажутся осведомлены в чем-то техническом больше вас. Это нормально, не обращайте на это внимания, развивайтесь в свою сторону, и старайтесь наоборот стимулировать профессиональный рост своей команды, ведь чем сильнее команда - тем успешнее будет ваш проект.

Ошибка №6. Поверхностное отношение к команде и ее интересам

Как известно, программисты не всегда являются экстравертами. Менеджер проекта может запросто не интересоваться вопросами мотивации, создания и поддержания эффективных коммуникаций в команде, командного духа, тимбилдинга. Не говоря уже про решение личных проблем членов команды, с которыми сталкивается любой менеджер. Необходимо понимать, что для эффективной работы команды она: а) должна быть (!), б) должна быть единым здоровым организмом, в) должна быть хорошо мотивирована. Каждый член команды должен чувствовать, что он может без страха подойти к вам со своей проблемой и вы ему поможете по мере сил. Это еще один набор активностей и умений, которому нужно учиться практически с нуля, потому что ни программист, ни даже девлид подобными вопросами обычно не занимается.

Ошибка №7. Остановка технического роста

Казалось бы, какое отношение это имеет к управлению проектом? Никакого. Но зато это имеет самое прямое отношение к реалиям жизни. Если бывший программист, став PM, полностью останавливает свой технический рост по принципу "я уже и так достиг всего чего мог в техническом плане, могу забить", то это, по сути, рубание ветки, на которой сидишь. Да, технические навыки не обязательны для того, чтобы быть эффективным менеджером, но тем не менее кто вам даст гарантию, что один из ваших следующих проектов, который будет через год или два, не потребует от вас занятия должности PL, который будет руководить и технической, и организационной частью проекта? Или что на вашем следующем месте работы это не будет обязательным требованием? А будете ли вы тогда достаточно подкованы в новых технологиях или подходах для того, чтобы довести подобный проект до успешного завершения? На мой взгляд, если уж вам так повезло, и вы прошли весь путь от падавана до мастера Йоды в программировании, то не забрасывайте свои технические знания в темный чулан, развивайте их, хотя бы на поверхностном уровне изучайте новые технологии и подходы к разработке ПО, совершенствуйтесь!

Успехов вам и вашим проектам!

Должен ли PM быть техническим специалистом?

Я уже не первый раз сталкиваюсь с вопросом, должен ли PM быть технически подкованным человеком или нет. Иными словами, должен ли у него быть опыт работы программистом или QA, для того, чтобы успешно вести проекты, связанные с разработкой ПО. И собственно, вопрос здесь даже не в том, возможно это или нет - опыт показывает, что есть нетехнические PM, которые с разной степенью успешности ведут проекты. Но в то же время тот же опыт показывает, что а) таких людей довольно мало, б) им иногда бывает сложнее, в) общественное мнение в лице различных IT-специалистов иногда отрицает эффективность такого PM. Столкнувшись с этим вопросом, я решил провести небольшой опрос среди моих друзей и сотрудников (бывших и нынешних). Выборка была порядка 20 человек (знаю, нерепрезентативная, но я и не старался делать соцопрос, скорее, получить дополнительную пищу для размышлений), люди абсолютно разного уровня и позиций: программисты, QA, BA, девлиды/тимлиды различного плана, и несколько ребят, которые так или иначе выполняют функции PM на своих проектах или ими являются. Задавал я, как правило, один и тот же вопрос, в краткой форме приведенный в заголовке данной заметки, а потом, по ходу дела, спрашивал детальнее, уточнял подробности, иногда дискутировал :) Ответы были разными, некоторые совпадали с моим мнением, некоторые - нет. Но в любом случае, я благодарен всем, кто согласился ответить на эти вопросы, в независимости от точки зрения, т.к. вы помогли мне увидеть бОльшую картину, чем была у меня в голове до опроса. Все-таки опыт у разных людей разный, поэтому одна голова - хорошо, а двадцать лучше. Также я немного потерроризировал гугл, а также сайты вроде www.stackoverflow.com, www.rsdn.ru и прочие уважаемые ресурсы.

Если очень коротко, то результаты опроса были следующими: где-то 40% людей так или иначе высказывались в пользу идеи, что у PM должен быть технический опыт, и что технический PM лучше нетехнического, причем неоднократно подчеркивались 2 мысли: лучший PM - PM-бывший программист, и лучший PM - PM-бывший QA. Я думаю, не стоит уточнять, у кого какое мнение ;) Остальные говорили, что либо технический опыт не имеет никакого значения, а иногда даже мешает, либо нетехнический PM способен эффективно руководить проектом, но все же не любым. Я же хотел бы высказать свои мысли по этому поводу, в том числе навеянные и общением на эту тему.

Чем занимается менеджер проекта

Менеджер проекта обычно отвечает за то, что проект будет выполняет в срок, в рамках выделенного бюджета, что результатом проекта будет продукт, который является тем, что хотел заказчик, и что продукт этот будет надлежащего качества. При этом в принципе, не особо важно, является ли продукт заказным или нет, кто заказчик - твой начальник, пользователи продукта или дядя за океаном, а также какие методологии/подходы/технологии были выбраны для реализации продукта. Это все варьируется, но цели - качественный продукт, удовлетворенный "клиент" и финансовая рентабельность разработки - остаются.

Для достижения этих целей, менеджер проекта занимается самыми различными активностями:

• планирование работ (или хотя бы помощь в этом в случае хорошей самоорганизации)
• распределение задач и отслеживание их выполнения (или хотя бы помощь в этом в случае хорошей самоорганизации)
• налаживание и управление различными процессами
• управление рисками
• управление командой (начиная от ее создания и заканчивая разрешением конфликтов)
• налаживание коммуникаций (с "клиентом", внутри команды)
• создание эффективно работающей команды, мотивация ее членов
• создание среды для эффективной и плодотворной работы всех остальных членов команды
• и т.д.

В разных проектах, с использованием различных методологий менеджеры могут выполнять все эти активности или только часть их, но в любом случае они в какой-то степени организовывают команду, мотивируют, помогают достичь результата и успеха. В идеале, работа менеджера должна быть вообще не видна. Процитирую своего хорошего друга: "Класснее всего когда работа ПМ явно не заметна, проект как бы сам собой выполнился. Там Вася постарался, тут Петя что-то классное придумал, а потом все само получилось. А ПМ _как-будто_ ничего не делал". Спольски тоже об этом писал в одной из своих статей.

Вы заметили, что здесь нигде не прозвучало "умение программировать", "умение тестировать", "понимать технологии", "умение строить архитектуру приложения", даже анализа требований и написания спецификаций и прочих документов не было. Почему? Потому что это знания, умения и активности, связанные с совершенно другими ролями на проекте.

Чем отличается должность от роли на проекте

Должность и роль - это разные понятия. Должность - это позиция человека в команде, которая вроде бы как хотя бы теоретически описывает то, чем человек занимается, а вот роль - это уже некая практическая сфера деятельности и ответственности, некий набор активностей. В идеале, позиция соответствует роли, но очень часто они связаны соотношение один-ко-многим. Человек на определенной позиции может выполнять несколько ролей на проекте. Также возможна и ситуация многие-ко-многим, когда несколько человек выполняют одну и ту же роль.

PM, менеджер проекта - это как должность/позиция, так и роль, и это часто сбивает людей с толку. Еще более сбивает с толку наличие кучи других лидерских позиций: Project Lead, Team Lead, Tech Lead, Dev Lead, QA Lead, Software Architect, можете продолжить сами. Я тоже раньше не мог точно сказать, кто за что отвечает, чем отличается, и вообще, кто все эти люди и что они здесь делают. Связано это с тем, что в разных компаниях и даже на разных проектах люди на этих позициях выполняют зачастую различные обязанности, а единого реестра как бы и нет... Расскажу, как я это понимаю, а вы если что поправляйте. Проще всего разобраться с Dev Lead и QA Lead - это явно выраженные технические позиции, которые четко совпадают с соответствующими ролями: они отвечают за техническую сторону реализации проекта, то есть разработку и проверку качества продукта. Программируют и тестируют они при этом или нет - не так важно, хотя чаще всего да. Позиции Tech Lead и Team Lead более размыты, человек на этих позициях может выполнять как чистую роль Dev Lead, так и несколько ролей: DL, QAL, иногда также PM, SA, BA. К тому же должность Team Lead может относится и к совсем другим сферам деятельности, по сути, это просто руководитель команды: системных администраторов, технических писателей, дизайнеров, бизнес-аналитиков и т.д.

Позиции Project Lead и Project Manager - самые интересные в этом списке, так как человек на каждой из этих позиций может выполнять кучу ролей: PM, DL, QAL, BA, SA, и др., в зависимости от проекта, и того, что понимается под этой позицией в отдельно взятом государстве, в данной конкретной компании, на конкретном проекте и т.д. Но все же разница здесь тоже присутствует. Обычно PL все-таки является техническим товарищем, объединяющим в себя как управляюще-аналитические роли (PM, BA), так и технические (DL, SA, иногда QAL), а вот PM'ами называют зачастую либо людей, играющих только роль PM, либо роли PM и BA, хотя в общем и целом это тоже далеко не гарантия.

Факторы, влияющие на то, может ли PM быть "нетехническим"

Таким образом, активности роли PM очень слабо связаны с техническими умениями. Но означает ли это, что можно взять классного нетехнического PM, поставить его на проект и тот приведет его к успеху? Нет, не всегда.

Для успешного выполнения проекта в команде должны быть представлены все роли, необходимые для этого. Здесь мы подходим к первому фактору, который влияет на ответ на наш вопрос - специфика проекта. Если на проекте есть готовые требования, скорее всего, вашей команде не нужен человек, выполняющий роль BA (это не значит, что для успеха проекта совсем не нужен BA, просто его работа уже выполнена кем-то другим выше вашей команды), если вам прислали готовые документы по архитектуре и дизайну, значит, вам скорее всего не нужен SA, если проект технически не слишком сложен, возможно, вам достаточно не самой сильной команды, но роль DL все равно придется на кого-то возложить, и этот "кто-то" должен соответствовать уровню этой роли.

Таким образом, если в команде есть кому занять роли DL, QAL, SA, BA (а также роли программистов и QA :)), то на должность менеджера проекта можно поставить человека, у которого нет опыта программирования, тестирования, бизнес-анализа, написания документации, но который будет заниматься исключительно менеджерскими активностями, которых тоже очень много. И, как показывает практика, профессионализм и сильный уровень в этих активностях зачастую еще более редки, чем профессионализм и желание постоянно повышать свой уровень у программиста.

Еще один немаловажный фактор, который определяет, какие роли будет выполнять человек на должности менеджера проекта - это размер проекта. На небольшом проекте особо не разгуляешься. Если каждому человеку в команде назначить одну роль, то будет, как на картинке, где один копает, а остальные смотрят :), потому что объем "чистых" активностей одной роли невелик или продолжается незначительный период времени, а работы по разработке или тестированию продукта очень много. Поэтому очень часто на небольших проектах PM (или уже скорее PL) выполняет не только менеджерские функции, но еще и является основным техническим специалистом на проекте, который и анализирует требования, и пишет спецификации, и продумывает архитектуру, и руководит тестированием, в общем, и швец, и жнец. Не говоря уже о том, что в таком случае разработка выходит намного дешевле, т.к. достаточно взять одного самородка, дать ему в команду 25 джуниоров - и дело пойдет ;) Шучу, конечно, но в каждой шутке, как известно, доля шутки - я такие ситуации видел не раз. Поэтому это тоже нужно учитывать.

Кроме того, не стоит забывать, что в оффшорном аутсорсинге, которым многие из нас занимаются, есть такая проблема, как общение с клиентом. Безусловно, клиенту намного удобнее иметь одного человека, с кем он будет общаться по всем вопросам, начиная от требований и заканчивая обсуждениями технических решений. Конечно, клиенту можно объяснить, что по разным вопросам нужно обращаться к разным людям, но это его зачастую смущает. Поэтому нередки ситуации, когда нетехническому PM приходится "общаться" с клиентами на технические темы, по сути, являясь прокси между клиентом и техническими специалистами, что не доставляет удовольствия ни PM'у, ни этим самым техническим специалистам.

Таким образом, нетехническому PM часто приходится так или иначе вникать в технические детали, но если он умеет правильно наладить коммуникации и работать с людьми, это не должно создавать для него особых проблем. И это подводит нас к следующему вопросу.

Есть ли минимальный набор "технических" знаний, необходимых PM?

На мой взгляд, хороший менеджер проекта, при условии заполнения остальных ролей другими членами команды, не обязан знать программирование или тестирование даже на минимальном уровне. НО (!) он все-таки должен хотя бы на каком-то уровне понимать, что такое разработка ПО, какие процессы в него вовлечены, в каком порядке и почему, что такое требования и запросы на изменение функциональности (change requests), как с ними работать, что такое качество продукта, что делают те или иные члены команды, в конце-концов. То есть, по сути, понимать специфику разработки ПО. Во всем остальном ему помогут другие члены команды.

Это же помогает найти ответ и на другой вопрос: можно ли взять успешного менеджера проектов, скажем, в рекламе, и поставить менеджером проекта по разработке ПО? Или можно ли научить человека проектному менеджменту в университете, а потом взять на работу? Можно, но этот человек все-таки должен для начала разобраться в "предметной области" IT-индустрии, прочитать кучу книг, статей, возможно, сдать определенные экзамены, а еще лучше своими глазами увидеть реальные IT-проекты и потренироваться на небольших и не особо критичных. Если у человека есть опыт и он умеет думать и учиться, то все возможно.

Так, может, лучше взять DL или QAL и сделать менеджера проекта из них?

Возможно, в некоторых ситуациях это не только "лучше", но еще и единственный возможный вариант. В нашей стране именно так и случается в большинстве случаев - менеджерами проектов становятся бывшие программисты, тестировщики или бизнес-аналитики, которые дошли по карьерной лестнице до самого верха, и не имея дальнейшей возможности развиваться технически или увеличивать свою зарплату, просто сделали шаг в сторону на другую лестницу, менеджерскую. Или этот шаг в сторону сделали за них. Или никакого шага и не было, и человек просто стал выполнять дополнительные задачи, в дополнение к своим техническим обязанностям, являясь, по сути Project Lead'ом.

Но важно понимать, что это не всегда обязательно, и что выполнять обязанности PM может и человек, который не имеет опыта работы программистом, QA или кем-то еще. Конечно, при условии, что вы понимаете, какие роли будет выполнять человек, которого вы ставите на должность PM и учитывать факторы, которые были изложены выше.

Насколько мне известно, на западе сейчас довольно активно пытаются внедрять в работу "нетехнических" менеджеров, поскольку у людей, обогащенных техническим опытом, точно такое же количество проблем при переходе на медеджерские должности, что и у "нетехнических" менеджеров проектов, которые сталкиваются с техническими вопросами. Более того, у PM вообще своя карьерная лестница, идущая параллельно технической лестнице. Так 100% работает Microsoft, наверняка, и другие крупные (и не только) компании. В таком случае у технического специалиста есть возможность развиваться технически по-максимуму, в том числе и по зарплате, а вот как раз выход на параллельную лестницу, как правило, означает снижение зарплаты, потому что твой текущий менеджерский уровень еще очень низок по сравнению с теми, кто имеет в этом вопрос намного больше опыта.

Поэтому в случае с переходом технического специалиста в менеджеры нужно понимать, что роль управления проектами довольно слабо связана с теми активностями, которые выполнял этот специалист раньше. И, в первую очередь, это нужно понимать самому этому специалисту. Кроме того, у бывших программистов и QA (хоть у последних и в меньшей степени) есть свои проблемы с выполнением менеджерских обязанностей. Не все хорошие технические специалисты становятся хорошими менеджерами - это давно известно, но об этих проблемах мы поговорим как-нибудь в другой раз - это тоже обширная тема. Но если Вы - именно тот человек, у которого это получается, и это вам интересно, то почему бы и не попробовать? Не получится - всегда можно вернуться в техническую сферу :) И тем более стоит пробовать, если вы нетехнический PM - у вас также есть хорошие шансы.

Успехов вам!

PS. Еще раз спасибо всем, кого я доставал своими глупыми вопросами :)

След Шерлока Холмса в программировании или Немного об agile для программистов

Задумывались ли вы, чем отличаются между собой waterfall и agile подходы к разработке программного обеспечения? Для меня, человека, который раньше работал либо по ad hoc, либо по waterfall, либо по итеративным процессам вроде UP, agile-подходы вроде XP, Scrum и др. (прошу не бить сильно ногами, что буду все причесывать под одну гребенку) раньше казались чем-то сродни ad hoc'а, только с дополнительными правилами, чтобы совершенно не скатиться в анархию. У нас даже шутка ходит о том, на проекте часто бывает не просто agile, а полный agile :) Однако после прочтения книжки Книберга я изменил свое мнение.

Итак, что же такое agile и как его проще всего понять программисту? Помните, что такое программирование сверху-вниз, а что такое - программирование снизу-вверх? При первом подходе мы сначала все продумываем, разрабатываем каркас, создаем классы верхних слоев, а затем уже спускаемся вниз, к деталям, наполняя их кодом и смыслом. Второй подход - прямая противоположность первому: мы сначала пишем код нижних слоев, потом интегрируем их друг с другом посредством более высоких уровней и, наконец, пишем вызывающую программу. По сути, если говорить математическим (или детективным ;)) языком, это дедукция и индукция.

Примечание. Кстати, лично мне кажется, что Шерлок Холмс пользовался все-таки индуктивным методом, а не дедуктивным, т.к. он, как и любой другой детектив, строил общую версию исходя из более мелких, частных фактов и улик, но это мое личное мнение и оно к делу не относится :).

Так к чему я это все? Да к тому, что waterfall - это как раз способ разработки методом сверху-вниз. То есть мы сначала получаем от клиента по возможности все требования (при помощи бизнес-анализа), анализируем их, оцениваем, строим архитектуру, документируем это все - и вперед, арбайтен. От общего к частному или, иными словами, посредством дедукции. Именно на этом подходе работает большинство нормальных человеческих проектов, начиная от строительства дома и заканчивая запуском спутника в космос. Но разработка ПО - это даже близко не строительство дома, хотя определенные аналогии провести можно. Все-таки поменять в последний день логику работы приложения намного легче, чем соорудить автостоянку под уже построенным зданием. То есть в разработке ПО есть такое понятие как гибкость (agility). Ко всему прочему, заказчики (а это может быть кто угодно) - люди зачастую не очень понимающие то, что они хотят получить в результате, а если и понимающие, то склонные менять свое мнение, иногда очень кардинально. Так что же, заставлять их выдавать на-гора все функциональные и нефункциональные требования к приложению ДО начала разработки?

Вот собственно из этого всего и родились различные agile-подходы к разработке ПО. А потом появился небезызвестный манифест - и пошло-поехало. Так что же такое agile и чем он отличается от обычной водопадной или итеративной практики разработки? Ну, отличий, конечно, много, но я бы в первую очередь сказать, что это - процесс разработки ПО снизу-вверх, то есть индуктивный процесс. С самого начала мы очень мало знаем о том, что мы вообще строим, иногда даже так же мало, как и заказчик. Но нам по барабану. Мы берем то, что есть, тратим не очень много времени на планирование - и стартуем. Сделали что-нибудь стоящее, показали заказчику, определили следующие задачи - и поехали дальше. И так до тех пор, пока заказчик не получит то, что хотел. При этом необходимо отметить, что гибкие методологии, в отличие от своих "жестких" товарищей, все же имеют свою жесткость - жесткость правил, по которым ведется разработка. Если у вас нет unit-тестов - вы обломаетесь на первых же серьезных рефакторингах системы. Если у вас нет code review или pair programming - вам будет сложно организовать коллективное владение кодом, что можем повлечь серьезные проблемы, если кто-то из ведущих разработчиков вдруг заболеет. Если вы забиваете на product backlog - у вас в скором времени возникнет каша с требованиями (впрочем, каша с требованиями возникает и тогда, когда они есть, но на их обновление точно так же забивают). Если вы не проводите ежедневные митинги - ваши разработчики будут дублировать действия друг друга и изобретать велосипеды сотнями, а код превратится в мусорку. А все потому что работа ведется в условиях самоорганизовывающейся команды (self-management team) и нет никого, кто бы мог сверху спустить план, в котором будет четко сказано, кто, что и когда должен делать.

Надо сказать, это сложно, т.к. получается, что каждый член команды должен не просто ответственно работать, но еще и быть достаточно подкованным с технической точки зрения. Так что перед тем, как с криками "ура, я познал истину и теперь все мы будем жить счастливо" бежать к своей команде, подумайте сначала, а сможет ли она работать в таких условиях? И, что еще более важно, подумайте, а надо ли оно вам? Если у вас есть нормальные требования и клиент знает, чего он хочет, то зачем городить огород? Возьмите какой-нибудь UP - и будет вам счастье. Если же этого нет, то добро пожаловать в мир agile :)

PS. А вообще, серебряной пули нет, вы же знаете. Успех или неудача вашего проекта зависит не только от того, какой процесс вы выберете, но и от того, насколько вы сможете его кастомизировать под свои нужды в процессе работы. А для этого нужно просто уметь думать.

Отзыв о книжках: DDD Нильссона и Scrum из окопов Книберга

Последние несколько недель были плодотворными в плане чтения книжек. Дочитал "Применение DDD и шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET" Джимми Нильссона и прочитал "Scrum и XP: заметки с передовой" Хенрика Книберга. Спешу поделиться отзывами, так как уже давно ничего толкового не читал.

 

Про первую книгу я уже писал относительно недавно. Рекомендую всем, кто чувствует, что ему стало тесно в рамках стандартных технологий и подходов, а архитектура и дизайн его приложений хромают на обе ноги. Domain Driven Design - это радикально другой подход к разработке ПО, поэтому книжка отлично освежает голову, дает совершенно другую перспективу и точку зрения на привычные вещи. Нильссон дает общее представление о DDD, а также на примерах показывает, как можно разрабатывать реальные приложения с использованием DDD, TDD, и различных паттернов проектирования. Автор начинает с простых вещей, вводит рабочий пример и потихоньку продвигается по пути его реализации, задевая вопросы архитектуры, модели предметной области, инфраструктуры для сохраняемости, архитектурных паттернов, unit-тестов, правил, аспектно-ориентированного программирования, пользовательского интерфейса, а также немного проходится по NHibernate. В общем и целом, после прочтения книжки в голове появляется намного более серьезное понимание всех вышеперечисленных вопросов, и даже если DDD вам не подходит, вы вынесете из книги много новых знаний. Сразу хочу предупредить, что это не Эванс, здесь нет серьезной теоретической базы, лишь практика, практика, и еще раз практика. Ну, и ложка дегтя: русский перевод этой книги просто ужасен. Не понимаю, как можно было перевести кучу названий паттернов (чего стоят только прецеденты использования и неведение сохраняемости), а также стандартных терминов (DDD - ППО, проектирование предметной области, TDD - РПТ, разработка посредством тестирования). Да и ладно бы, но там не только это перевели, поэтому постоянно приходится думать, как эта фраза звучит по-английски и что это за очередной термин такой. По всей видимости, после перевода книжку не проверил эксперт в данной предметной области. Поэтому читайте оригинал :)

Вторая книжка была переведена сообществом Agile Ukraine, за что ребятам огромное человеческое спасибо! Причем, больше спасибо за то, что они разрекламировали ее, потому что в реальности, как и предыдущая книга, эта читается на английском легко и непринужденно. Книжка переведена просто замечательно, в отличие от перевода того же Нильссона. Сама же книга повествует об опыте Хенрика Книберга в постановке и использовании Scrum'а в нескольких командах. Хенрик последовательно проходится по вопросам планирования спринта, работы с product backlog'ом, ролям команды, ведения burndown-диаграммы, проведения scrum-митингов, демо, ретроспектив, а также, что более важно, объясняет, как работать по Scrum-у в условиях fixed-cost проектов, показывает родство Scrum и XP, и делится опытом постановки процесса QA и работы с несколькими командами. В общем и целом, для человека, который знаком с другими процессами разработки ПО, и который имеет не только положительный, но и отрицательный опыт, эта книга может стать хорошим стимулом попробовать поднять Scrum у себя на проекте. Тем более, если у вас ничего другого нет :) В общем, рекомендую не только PM'ам.

Senior PM - это звучит гордо

Вдогонку моему посту об уровнях программиста и их оценке сегодня в голову пришла еще одна идея. В каком-то смысле она была навеяна комментариями к этому посту, в которых ребята справедливо указали, что я рассмотрел лишь уровни программистов, хотя попытался причесать под эту гребенку еще тимлидов и архитекторов. На деле же я просто попытался рассмотреть техническую сторону развития программиста, упустив из виду другие навыки, необходимые на более высоких ступенях. Рассмотрим текущую ситуацию. У нас есть следующие роли/должности на проекте: разработчик, QA, лидер команды (dev/team lead), лидер QA (QA lead), менеджер проекта, архитектор и т.д. При этом мы рассматриваем уровни, как правило, исключительно для разработчиков и QA: junior, middle, senior. А ведь на деле те же тимлиды или менеджеры проекта ничем особо не отличаются. Да, стать тимлидом или архитектором junior-разработчик вряд ли сможет и здесь у нас есть определенные ограничения в стартовом уровне, но ведь все равно тот же senior-разработчик, которого ставят тимлидом по сути является junior-тимлидом. У него, несмотря на достаточный технический уровень, еще нет опыта в некоторых сферах: слабо развиты навыки управления командой, распределения обязанностей, тесного общения с клиентом, решения других менеджерских задач. Ему вряд ли можно доверить большой проект и большую команду сразу. Скорее всего, это сначала будет небольшой коллектив, на котором он будет расти. С опытом такой тимлид будет продвигаться по этой должности и в конце-концов сможет стать зубром своего дела, senior-тимлидом, грубо говоря. У него будет достаточно знаний и умений, чтобы вести проекты разного уровня и длительности. Он будет владеть большим количеством методологий, глубже понимать процесс разработки, лучше уметь находить общий язык с командой и клиентом. То же самое касается тех же менеджеров проекта, QA лидов, архитекторов и т.д. Более того, насколько я слышал, на западе в крупных компаниях такие подходы практикуются, по крайней мере, для некоторых из этих должностей. В гугле есть даже какие-то продвинутые senior-разработчики, но их сакрального смысла я не уловил, похоже, просто расширили шкалу. Да и в Харькове, думаю, есть компании, которые имеют такое деление на уровни. Но этих компаний реально мало – взгляните на любой сайт вакансий. А ведь идея-то здравая. Насколько было бы проще как менеджерам, так и самим сотрудникам, если бы они могли знать приблизительный уровень специалистов этого профиля и подбирать для команды тех, которые подходят ей больше всего. Не говоря уже об HR и рекрутерах, думаю, их жизнь бы тоже облегчилась значительно :)

Планирование, учитывающее предыдущие результаты

Даже не знаю, как можно правильно перевести термин "Evidence Based Scheduling"... Джоэль Спольски разразился в своем блоге отличной статьей, посвященной объяснению вот этой вот самой штуки. Термин "Evidence Based Scheduling", похоже, придуман Джоэлем и его командой, а сам метод планирования внедрен и активно продвигается в их продукте FogBugz 6.0 (демо, которое заслуживает отдельных похвал, можно глянуть здесь, а запись выступления Джоэля - здесь). Итак, для тех, кто не любит читать "много букофф", вкратце, что же это такое и с чем его едят. Evidence Based Scheduling - это метод планирования проекта, основанный на 2-х основных принципах:

• учет предыдущих результатов для получения реальной оценки (estimate) времени, которое будет затрачено на разработку продукта
• прогнозирование вероятности релиза продукта в конкретный день (с использованием метода Монте-Карло)

По первому пункту, в принципе, все понятно. Есть люди, склонные переоценивать свои силы и недооценивать их, и это нужно учитывать при планировании проекта. Каждый грамотный team/dev/QA/project lead (нужное подчеркнуть) более-менее хорошо знает свою команду и может на основании эмпирических фактов проставить каждому девелоперу/QA коэффициент, на который нужно домножить его собственный estimate. Однако существует еще очень много факторов, которые могут повлиять на то, что проект затянется во времени и мы выпадем из графика или бюджета. Часть из них являются непроизводственными, например, прогулки по Интернету, общение в команде, кофе/чай, "а глянь какие фотки мы сделали на выходных!", часть - абсолютно честно относятся к разработке продукта: изучение новой технологии, митинги в команде, философские дискуссии с QA, что есть баг, а что фича и др. естественные, но от того не менее опасные для развития проекта активности. Все это невозможно предусмотреть заранее. Однако, если трекать процесс разработки продукта, то потом можно сравнить estimate с реальными данными и на основании этого сравнения сделать определенные выводы на будущее. Второй пункт вызывает больше интереса. Честно говоря, я не видел еще подобного способа прогнозирования дат релиза и отдельных mileston'ов (кто видел, подскажите продукт или где почитать). Как мы обычно планируем проект? У нас есть нижняя и верхняя граница оценки определенной задачи, мы выбираем цифру от 0.5 до 1 на этом отрезке (думаю, меньше 0.5 никто не выбирает :)), а затем устанавливаем ее для этой задачи в MS Project или кто чем пользуется. Строим диаграмму Ганта и в результате получаем приблизительные даты mileston'ов и релизов. Джоэль предлагает другой подход, который состоит в вычислении вероятности различных будущих, основанном на методе Монте-Карло. Данный подход достаточно тесно связан с предыдущими результатами работы наших программистов, которые у нас есть. Если мы случайным образом возьмем одно из предыдущих значений отношения оценки выполнения какой-либо задачи к реально затраченному времени (в идеале оно будет равно 1, но, конечно же, будут вариации), и разделим на него текущую оценку новой задачи, то мы получим другое число с учетом предыдущего результата. А теперь представим себе, что мы рассматриваем все задачи всех программистов и для каждой задачи вычисляем 100 различных новых значений, каждое с вероятностью в 1%. Тогда, сложив вместе эти значения (с учетом графика выполнения работ, выходных, праздников и т.д.), мы получим 100 вариантов развития события, 100 вариантов будущего нашего проекта. А уже сопоставив эти 100 графиков мы можем дать вероятность того, что наш проект завершится 10 декабря, 15 января или вообще 30 апреля. У такого подхода есть ряд преимуществ перед обычным, т.к. он дает большую гибкость и учитывает больше факторов, что, соответственно, делает результат более точным. Дальше нам остается только сказать себе, что вероятности 90% нам достаточно и мы можем поставить milestone в данную точку времени и пространства. Кроме этих интересных вещей, Джоэль также дает несколько советов по оценке задач:

• только программист, который будет реализовывать функциональность, должен оценивать ее - известный совет, которым, тем не менее, часто пренебрегают, что влечет либо к тому, что lead оценивает задачи с точки зрения "среднестатистического" программиста, либо вообще себя, а потом этим занимается либо более слабый, либо просто менее знакомый с данной предметной областью/технологией программист и весь график летит в тартарары
• время, затраченное на исправление ошибки в определенной функциональности, должно добавляться ко времени, потраченному на эту функциональность в целом - помогает хранить более точные результаты для будущей оценки и вычисления вероятностей
• не давать менеджерам загонять программистов в более узкие оценки с целью зарелизить продукт быстрее/дешевле - это вообще отдельная песня... "а можешь ли ты скроить шапку из этого куска шкуры?" - "могу" - "а 2 шапки?" - "могу" - "а 3 шапки?" - "и 3 могу"
• план проекта это коробка с бревнами - пункт, связанный с предыдущим: если у нас есть куча бревен и они не помещаются в коробку, но нужно либо убрать часть бревен из коробки, либо взять коробку побольше, но уж никак не пытаться уменьшить бревна в размерах

В общем и целом, это все. Советую прочитать статью Джоэля целиком (а также и другие его статьи), там еще много чего интересного. Вывод: FogBugz 6.0 из простой (пусть и удобной) системы багтрекинга превратился в полноценную систему управления проектами, с интересными и смелыми решениями. Интересно было бы попробовать ее в действии на реальном проекте, а то продукты MS уже как-то приелись :). Посмотрим, чем ответят разработчики других приложений. Kiwi :)

Mind maps и анализ требований

Наверняка многие слышали про mind maps и даже использовали их в жизни. Однако, в IT-проектах mind maps используются не очень широко. Недавно попробовал применять их для несколько иной задачи, чем простой брейнсторминг - для анализа требований и управления фазой проекта, чем и спешу поделиться.

Безусловно, такой способ подойдет не для всех типов проектов (да и не для всех людей), но все же в запутанных случаях, когда идет изменение большой системы и клиент сам не совсем понимает, чего он хочет, схема работает.

Наш проект как раз и является таким «запутанным» случаем. Клиент хочет сделать низкоуровневые изменения, которые отразятся на многих компонентах. При этом клиент уже сам не очень хорошо помнит, как именно эта система работает и из каких частей состоит. Работает, и хорошо :). В результате мы получаем достаточно высокоуровневые требования, в которых детально описано лишь то, что клиент «вспомнил» и то, что он хочет получить в результате. Приходится потом сидеть и самому анализировать, какие компоненты системы будут затронуты и в каком объеме. Количество вопросов к клиентам увеличивается, потому что мы зачастую не знаем, как они захотят изменить старое бизнес-правило, чтобы оно работало в новой обстановке. Вследствие этого каждый вечер проводятся обсуждения, идут тучи писем, в документе требований появляются новые и исчезают старые пункты. Источников данных – тьма, вопросов – тоже, как за этим всем следить самым оптимальным способом и при этом не забыть чего-то важного – непонятно. Не говоря уже о том, что по пути мы занимаемся брейнстормингом в команде, и его результаты тоже нужно где-то записывать.

И вот здесь-то на помощь приходят различные способы компактного и по-возможности визуального представления данных. Одним из наилучших, на мой взгляд, являются mind maps. Вкратце, это способ представления различных задач, идей и прочих сущностей в произвольном формате. Единственное ограничение – это все-таки своеобразный граф, поэтому циклические зависимости представить в нем сложно. Применять mind maps можно в абсолютно разных случаях, начиная от планирования поездки в отпуск и заканчивая брейнстормингом на проекте запуска спутника в космос. Основной их фичей является то, что автор может помещать на дуги абсолютно любые слова, целые фразы, картинки, числа, даты, лишь бы между ними сохранялись семантические связи. Оказывается, это удобно и для анализа требований :). Например, вот, что у меня получилось при анализе новых требований и постепенного их обсуждения:

Приложение, которым я пользовался (кстати, абсолютно бесплатное, т.к. я специально не рассматривал платные варианты), позволяет добавлять ряд картинок к текстам, что очень удобно. Например, карандашиками я обозначил пункты, которые нам нужно заимплементить/сделать, warning'ами – различные предупреждения, знаками вопроса – требования, которые могут изменится, а числами в кружочках – фазы, в которых та или иная фича должна быть сделана. Здесь уже каждый волен обозначать пункты как ЕМУ удобнее для восприятия и понимания.

Преимущества подобного представления информации:

1. Подобную диаграмму всегда можно охватить «одним взглядом», в то время как 50-100-500-страничный документ – нет. Мозги не резиновые.
2. На диаграмме можно отображать абсолютно любую информацию: идеи, сомнения, риски, даты, степень выполнения и т.д. Я не призываю не пользоваться MS Project :), просто он предназначен для другого типа задач. Например, у нас сейчас на проекте есть документ требований, mind map и project plan – сосуществуют очень даже сносно.
3. Диаграмму можно изменить в любой момент времени, если что-то поменялось.
4. Диаграмму можно обновлять из разных источников. Пришло письмо с каким-то комментарием, меняем диаграмму. Пообщались с клиентом – снова меняем.
5. По диаграмме можно легко оценивать, сколько времени займет девелопмент, т.к. объем изменений и все взаимосвязи хорошо видны.
6. По диаграмме можно легко составлять списки вопросов клиентам и трекать состояние обсуждаемых вопросов.
7. Без сомнения, по диаграмме можно много еще чего, но до этого еще нужно добраться :)
   

Недостатки:

1. Приходится делать дополнительную работу на составление диаграммы. Впрочем, это еще вопрос, сколько она времени сэкономит в будущем. Плюс в этот момент мы «укладываем» требования в нашей голове, что позволяет быстрее их запоминать.

В общем и целом, впечатления от использования mind maps очень положительные. Mind maps - в массы? :)