?

Log in

No account? Create an account

psilonsk


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


Previous Entry Share Next Entry
Фуршетное - июль 2012
psilonsk
Я в июльском фуршете у tema. Ваши вопросы по управлению проектами, менеджменту, тренингам и т.д. Наши, соответственно, ответы. )


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

  • 1
вопрос: как менеджер выбирает связи по задачам проекта(последовательная, итерационная, перекрывающая)?

и еще, как собираете (технические, бизнес) требования к проекту?

и нужно ли "переучивать" внутреннего заказчика, чтобы он не путал ТехЗадание и ТехТребования.

Edited at 2012-07-16 06:43 am (UTC)

Я не очень понял первую часть вопроса - что значит как выбирает? Менеджер должен понимать суть проекта и последовательность/параллельность этапов, а затем, после декомпозиции на задачи - последовательность задач. У него всегда должен быть эксперт в конкретной области, чтобы можно было уточнить, правильно ли он эту последовательность понимает. Ну и опыт никуда не спрячешь, тоже пригодится. )
Менеджер не формализует требования, для этого есть аналитики, эексперты, специалисты. Менеджер работает с требованиями только на верхнем уровне - чтобы понимать, куда идет проект (и, если нужно, провалиться до деталей). Если менеджер собирает требования - он не менеджер, а исполнитель.
По поводу последнего вопроса. Вы взгляните на ситуацию со стороны заказчика - емуабсолютно плевать, как вы называете свои документы. Если ожидается, что у вас с ним будет еще много похожих проектов в будущем, возможно, есть смысл постепенно (!) приучить его к своей терминологии и форматам документов. Но если нет - зачем ему это? Надо, чтобы ему было удобно работать, а не только вам, ведь у него, кроме вас, еще полно других дел.

ок. спасибо.

то есть, связи могут быть комбинированы в одном плане проекта, типа: "эта группа задач, может идти с той группой задач параллельно" "эта задача, должна начинаться только после завершения той задачи" и "после пятой задачи, мы возвращаемся к первой, и так восемь раз"

по поводу итерационных связей. если их применять, то всем срокам ...здец ведь, так? или можно "по-российски" взять и отодвинуть дедлайн?

Задачи в плане графика проекта могут иметь какие угодно связи.

Последний вопрос не понял, приведите пример.

например, срок выполенения проекта 90 дней. время этапа разработки - 50 дней. есть задачи: собственно разработка, а потом тестирование полученного результата. добрались до тестирования, по критериям результата, посчитали, что результат не соответствует, отправили на доработку, теперь это пусть не 50 дней, а 10. соответственно, получается, что из-за этой итерации, к 90 дням+10=100 дней, и дедлайн приходится не на 1 апреля, а на 14 апреля. что делаем? сдвигаем дедлайн?(что разумеется не есть хорошо, и заказчик будет за это бить)
или, шлем нах итерацию на доработку, идем по плану последовательно, соблюдаем дедлайн, но получаем недоработанный продукт (за который получаем люлей от заказчика) и дорабатываем в процессе эксплуатации, но уже за дополнительные деньги.

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

Вижу тут несколько серьезных ошибок:
1. Даже если на проекте всего лишь один программер, 50 дней разработки - серьтезный риск. Если их больше - это катастрофа. Надо разбить разработку на итерации, каждая из которых включает тестирование. Это позволит замечать и решать проблемы не через 50 дней, а гораздо раньше. И это же кардинально улучшит качество продукта.

2. С заказчиком надо работать. Ситуация, когда заказчику говорят "приходи через 90 дней за результатом" не должна возникать в принципе. Заказчик должен получать промежуточные результаты, участвовать в тестировании и т.д. Он будет видеть, как идет прогресс, а вы не получите по мордасам в конце, когда уже все равно битье ни к чему не приведет. Даже если вы, пройдя половину пути, увидите, что оценили все неправильно и проект не сделать за 90 дней, вам будет в миллион раз легче убедить заказчика подвинуть срок.

3. Не очень понятно, как вы оценили сроки с точностью до дня до начала проекта. Такую точность можно получить только имея на руках детальную, согласованную с заказчиком и подписанную им спецификацию. Если она у вас была, а вы не выполнили договор и не поставили качественный продукт, надо задуматься, те ли люди занимаются проектом? Если спеки не было, оценить проект нельзя. Подсказка (если уж вам так хочется работать по фиксированным ценам и срокам) - можно разбить проект на два этапа, на первом создать ТЗ, на втором, по результатм первого, оценить длительность работ.

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

1. разбивали на итерации, включив это в срок. допустим, в разработке 3 промежуточных результата, определяешь для каждого итерации, даже ограничиваешь их, допустим: после 3 итераций на каждый промежуточный результат, как максимум, то есть их не может быть 4, но может быть 2. результат конечно получше, вы правы, но сроки... увеличиваются, как минимум на 40%, как если бы ты эти итерации не вводил.

2. это правильно, РАБОТАТЬ. но получается так, что при приемке результата (или промежуточного), начинаешь смотреть, тестировать, проверять: говоришь, "а что здесь не поправили" "почему это не работает", ответ "поправим", поправили, прислали, проверяешь, "молодцы, поправили, доработали, а здесь, что не доделали" ответ: "доделаем", доделывают и опять присылают акт-приемки, но при просмотре резуальтата видишь, что в одном месте они все-таки не досмотрели. срок уже к хуям. и поэтому, либо принимать "как есть", убеждая себя, что "постройку дома нельзя закончить, ее можно только прекратить" (жванецкий, кажется). платишь по счетам, клянешься себе больше не работать с этими.

какие есть еще программы для управления проектами, кроме MS project?

  • 1