?

Log in

No account? Create an account

psilonsk


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


Previous Entry Share Next Entry
Задачка-водокачка № 1
psilonsk
Время от времени буду теперь публиковать задачки по управлению проектами. Никакой нудятины, только реальные кейсы. )) Комментарии скрыты на сутки (по крайней мере, я надеюсь на это - у меня ЖЖ вообще весь день глючит).

Итак, для начала совсем легкая задачка.

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

Как вы поступите?

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

В. Я подготовлю заявку на изменение и вынесу этот вопрос на обсуждение управляющего комитета. Все решения по изменению сроков проекта должны проходить через спонсора проекта и УК.

С. Это предложение не может быть принято – мы все тщательно распланировали, все идет гладко, и никакие изменения нам не нужны. План есть план, зачем портить то, что работает?

D. Сначала я посоветуюсь с заказчиком. Если мы можем завершить проект раньше, это может быть большим плюсом и для нас как вендора в глазах заказчика и, возможно, для самого заказчика в глазах его начальства.

E. Сначала я должен все тщательно взвесить и оценить предлагаемое решение с точки зрения влияния на проект. Только после этого я смогу принять решение, что делать дальше.

F. Завтра же утром я соберу команду на совещание, и мы вместе обсудим это предложение. Наш проект прозрачен для всех участников, команда должна принять решение по этому вопросу.


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

1. Я не программист, поэтому не буду принимать решение, не посоветовавшись с альтернативным экспертом. Как бы ни был человек мудр, он может не видеть некоторых аспектов. Например, в результате решения возьмёт и отвалится интеграция с другими системами. Надо оценить риски.
2. Заказчик - госконтора. Премию за досрочную сдачу проекта нам не дадут. Зато к отсрочке отнесутся с пониманием, особенно если все будет работать.
3. То есть я бы приняла предложение опытного программиста. Даже если его идея окажется лажей, и вылезет куча боков - кто сказал, что при первичном плане они не вылезут? А если выгорит, у нас будет месяц времени. Но для пущей уверенности собрала бы команду девелоперов и обсудила с ними. Вариант Е. Возможно, в сочетании с вариантом Ф, но не в силу прозрачности проекта, а в силу того, что они ближайшие доступные эксперты по оному. И бока, кстати, разгребать тоже им.

E, потом скорее всего А :)
Очень опытных профессиональных программистов очень не много на рынке. Если мы не будем давать ему возможность заниматься "творчеством" есть шансы его потерять.

Тут, наверное, нет однозначного ответа. Торопиться нам некуда, и пока проект движется своим чередом, я:
1. Подумаю сама, посоветуюсь со своей командой - вдруг программист ошибается?
2. Посоветуюсь с заказчиком.
3. Если заказчик за, обсудим "в широком кругу".
(если против, надо не забыть похвалить программиста за идею и объяснить, почему от нее отказались).
4. А закончится все, наверное, все равно подачей заявки в УК (государство же))).


Почти пальцем в небо)))
F

В. Я подготовлю заявку на изменение и вынесу этот вопрос на обсуждение управляющего комитета. Все решения по изменению сроков проекта должны проходить через спонсора проекта и УК.

Сначала F (проверить мега-идею людьми), потом - E.
Склонен к варианту "заказчику ничего не говорим до последнего", ибо 1 - это время может быть съедено каким-нибудь факапом (а впереди еще полпроекта) и 2 - так будет проще переносить ресурсы в др. проекты, исходя из своих потребностей.

В случае госзаказа D - вообще нереальная вещь, на мой взгляд. При таком сокращении сроков тебе скорее предъявят завышение стоимости, чем похвалят за сообразительность :)

Я выбираю вариант Е. Но сам по себе этот вариант не самостоятелен и потребутся дальнейшие действия. Следующий ход: вариант А.

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

+1 самое разумное.

Я отвечу, если можно, в виде пронумерованного списка аргументов, которыми я руководствовался бы в такой ситуации.

1. Самая первая ошибка, которую может совершить менеджер, когда узнаёт, что может сократить срок выполнения задачи — сообщить об этом клиенту / высшему руководству. Появляются риски: а) можно не выполнить задачу на месяц раньше и прослыть пустобрёхом; б) клиент может сделать вывод об изначально завышенной смете / сроках; в) клиент может попробовать сократить срок, поскольку появляется экономия, и тогда цейтнот никуда не денется, а срок сокращенный — появится; г) можно получить недовольство клиента, если он замешан в откатах (умышленно не стремится сократить сроки, чтобы больше получить дельты на карман).

2. Поскольку проект перевалил за экватор, можно сделать вывод, что несколько месяцев он исправно шел в срок. Скорее всего, работа ведется по проектной документации а также в соответствии с методиками и технологиями, которые дают команде такую прогнозируемость и стабильность в двжиении. Появляются риски: а) ведущий программист мог впервые обсчитаться и ошибиться в своих предположениях о выигрыше времени и, наоборот, проиграть его; б) в случае ухода/болезни/исчезновения по другой причине этого ведущего программиста, высока вероятность потерять проект совсем ввиду неполноценного понимания «что делать?» другими участниками, или менее продуктивной работой; в) внедрение новой технологии означает отклонение от проектной документации, что само по себе невероятный риск, учитывая, что проект выполнен более чем на 50%, и нет предпосылок к его неудачному завершению. А отклонение от проектной документации может привести к плохим последствиям. Например, даже если какая-то часть программистов уйдет, начнется саботаж, конфликт или иное действие, которое ставит под удар судьбу проекта, то наличие проектной документации и работы, выполняемой по ней, позволяет с большей вероятностью закончить проект успешно с новыми людьми, найденными срочно, чем аналогичная ситуация, возникшая после решения применить новую технологию ведущего программиста.

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

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

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

Я выбираю ответ E.

Edited at 2013-02-20 02:27 pm (UTC)

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

Совещание (вариант F) я, конечно, соберу. Но решение приму сам.

     37. Если мой доверенный заместитель скажет мне,  что мои Легионы Страха
терпят поражение в  битве, я поверю  ему. В конце концов, он мой  доверенный
заместитель.

Если всё норм, воспользуюсь предложением. В конце концов - он "один из ведущих программистов".