?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Задачка-водокачка № 9
psilonsk
Сегодняшняя задачка пришла от igrok_213, который столкнулся с описанной ниже ситуацией в своей работе. Что ж, поможем человеку добрым и, что важнее, умным советом!

Если есть уточняющие вопросы по условию – задавайте в комментариях к этой записи.

Итак, вы – менеджер проектов в небольшой ИТ-компании. У вас в команде есть системный архитектор Роман, с которым вы прошли огонь, воду и медные трубы. Вы ему всецело доверяете, и он вас никогда не подводил. Суть работы Романа – определить в проекте, из каких модулей нужно строить ту или иную систему, и как эти модули должны взаимодействовать друг с другом.


Однажды к вам обращается знакомый, Константин, директор компании-интегратора, с просьбой «вытащить» один заваливающийся проект.
Суть проекта – разработка и внедрение компьютерной системы для крупной газовой компании.

Константин выдвигает условие: в проекте должен участвовать его сотрудник и, по совместительству, старинный институтский друг – Александр. По словам Константина, Александр занимается разработкой подобных систем уже многие годы, и его опыт был бы полезен всей команде. Формально роль Александра в проекте не определена, но, по сути, он должен выполнять роль консультанта – «наблюдать, чтобы все было ОК».

Ваша команда, в которую входит и Роман, начинает быстро доделывать проект, постепенно налаживая контакт с заказчиком системы. В ходе работы Александр активно начинает давать рекомендации всей команде проекта, включая сотрудников заказчика. Это приводит к небольшим конфликтам между Александром и командой заказчика, а также к конфликтам между ним и вашей командой. Но вы ловкий менеджер – умело «обойдя» Александра, вам удается закрыть проект. Константин и заказчик довольны результатом.

Проходит время, и вам предлагают участвовать в продолжении проекта. Теперь внедренную систему нужно дополнить новыми функциями. Роман утверждает, что в текущем виде система не может быть расширена и предлагает ряд переработок, которые нужно выполнить. Идея Романа находит поддержку у всех участников – и в команде заказчика, и у Константина, и даже у Александра.
Вы вместе с Романом создаете детальный технический документ, в котором описываете планируемые переработки, структуру обновленной системы, модели баз данных и прочие технические подробности. Получается модель новой архитектуры системы. Теперь ее нужно согласовать со всеми участниками и приступить к работам.
У Константина и заказчика ваш документ вопросов не вызывает (хотя, им, по большому счету, все равно), но у Александра появляется куча замечаний, и он не готов дать свое разрешение на запуск работ, пока архитектура системы не будет приведена в соответствие с его требованиями. На мнение Александра начинает опираться и Константин.

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


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

Как вы предлагаете разрешить этот конфликт?


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


promo psilonsk февраль 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
Заменить имена - и будет 1 в 1 ситуация с моим предыдущим проектом :)
У меня, к счастью, была возможность убедить "Константина" убрать из проекта "Александра", которой я и воспользовался. Но до этого с "Александром" был длинный разговор, в котором я пытался прояснить окончательно для себя причину конфликта с "Романом", выяснить, чем конкретно предложение "Романа" хуже и что конкретно и по пунктам в документе плохо. В дальнейшем были планы использовать его аргументы для поиска удачного консенсуса, но "Александр" показал себя человеком, совершенно не склонным считаться с чужим мнением и затруднять себя аргументами не пожелал.

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

Edited at 2013-06-05 09:59 am (UTC)

(Deleted comment)
1. "На мнение Александра начинает опираться Константин."
2. можно и так.
3. Отличная идея, кстати.
Спасибо.

Edited at 2013-06-05 11:54 am (UTC)

(Deleted comment)
да воспринял, как "или"
Спасибо.

Александр не может "дать разрешение" на запуск. Разрешение дает Константин. Давим на него, упор на стоимость и сроки внедрения. Хочешь хорошо, быстро и дешево - делай по нашему. Потом доработаем. Хочешь работать по плану Александра - стоимость увеличивается в три раза, сроки в четыре, вот выкладки. Считай, принимай решение.

Я бы исходила из дальнейших планов. Если это последняя работа над этим проектом и с этим заказчиком - сделать по проекту Александра, утвердив перед этим его концепцию официально.
Но если в планах продолжать работу в будущем, то правдами и неправдами продвигать идею Романа. Потому что разгребать последствия Александру не придётся.

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

А сейчас.. ситуация - двойственная.
С одной стороны - нужно верить Роману и довести до логического завершения борьбу за его вариант реализации. Рассчитать затраты и сроки для обоих вариантов (его - и Александра), получить у Александра добро на качество этих оценок - и презентовать Константину (не заказчику). Пусть он ясно увидит, чем чревато для проекта и для будущего сотрудничества с газовиками то, что предлагает Александр. Заодно, упирая на то, что ситуация в команде изменилась - и налицо конфликт мнений - внести изменения в проектную документацию, описав в ней четко роль и границы ответственности Александра. Но... не уверен, что все это прокатит (хотя попробовать - нужно).

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

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

Вообще при многообразии технологий, для решения проблемы есть как правило не больше 2х возможных путей решения.

Предлагаю независимых консультантов в количестве 3 человек пусть проголасуют за или 2 вариант системы. Тот и внедряйте.


Ни слова не сказано об Уставах проектов: как первого, так и второго. Я считаю, что отсутствие Устава увеличивает вероятности возникновения негативных рисков в проекте.
Понятно, что на момент входа моей команды в 1-й проект, переделывать Устав(если он был) было проблематично. Однако, перед стартом второго проекта, я бы настоял на создании Устава, в котором бы были зафиксированы роли и ответственности. Такой шаг помог бы мне явно обозначить роль и самое главное ответственность Александра в проекте. Определение уровня ответственности в случае нарушения им установленных требований или взятых на себя обязательств, сильно помогло бы ему найти ясные и чёткие аргументы в пользу своего решения.

Другие "решения":
1. Отжать проект у команды Константина, сыграв на конфликтах Александра с командой Заказчика в первом проекте.
2. Если Роман не против, принять решение Александра и просто зарабатывать деньги, но ясно зафиксировав свою ответственность в случае недостижения целей проекта.
3. Эскалировать конфликт, попытаться найти "адекватного" стейкхолдера в команде Заказчика и объективно представить картину.





Edited at 2013-06-05 01:27 pm (UTC)

Мне кажется, ilazyloser высказал совершенно верную мысль: пусть Александр попробует формализовать свое видение и обосновать свой подход. Нужно сказать что-то вроде: "ок, может ты и прав, но мне нужно иметь письменное обоснование почему мы меняем технологию". Очень важно потребовать, чтобы качественные характеристики "потому, что так лучше" были оценены количественно. Скорей всего, Александр стухнет. Если нет, то со всем этим надо идти к Константину, показать сей документ и объяснить, что Александр и сам не может работать, и другим не дает и попросить его заменить.
Есть, конечно шанс, что Александр действительно дело говорит.

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

Всех участников заставить выйти за рамки "я знаю и точка", иначе лишать его права голоса. В случае с Александром, у которого голоса итак нет, надо действовать, как буд-то голос есть. </p>

Ну или дайте им подраться, пар выпустят, пропустят по рюмке, подружатся.


С чего бы отстранять от дел Романа, который успешно завершил предыдущую часть проекта, которым заказчики остались довольны? И слабо верится в то, что К. такой уж идиот, что не знает, что А. является занозой в заднице. Мне кажется, что без его вмешательства ситуация не разрешится таким образом, чтобы раз и навсегда.
Но, конечно, не просто так подойти и сказать "а Саша бааалуется", а иметь на руках доказательства. Для того, чтобы К. лучше всего было понятно, что рекомендации Р. стоит претворить в жизнь, а возражения А. лишь тормозят рабочий процесС, необходимо эти рекомендации визуализировать.
Если ваши deliverables слишком сложны для быстрого восприятия, то стоит опуститься на несколько уровней ниже, и просто схематизировать решение проблемы в лоу-файном, но достаточном для восприятия разницы ключе. Ну то есть вот наша схема - четыре квадрата, на них прямоугольник и треугольник сверху. а у А. вместо прямоугольника круг. Круг - это очень красиво, но треугольник на нем стоять не будет.
Как-то так..

1) заставить Александра предложить полностью описанный свой вариант решения
2) при условии принятия его проекта он соглашается нести полную ответственность за любые последствия. согласовать с Константином и заказчиком.

80-90% того что он сам сольется:) нет - вариант тоже рабочий, хоть и дороже.
вариант помягче - требовать с него детальное описание претензий/недостатков и ГЛАВНОЕ варианты их устранения. иначе Александра лесом - консультировать бурундуков (Константину доходчиво объяснить что без формализации и описания претензий не с чем работать т.е. исправлять).

Edited at 2013-06-06 08:16 pm (UTC)

кстати, кто-то выше написал про формализацию. варианты выше надо использовать именно в ключе, нужны конкретные детальные предложения/решения/варианты/претензии - все остальное мусор.

  • 1