Архив метки: Customer

Персональная методология проекта

Задаетесь ли вы иногда вопросом, а ту ли методологию я, как руководитель, выбрал для своего проекта? Верной ли дорогой веду проект к успеху?

Насчет успеха — есть очень интересный отчет «Chaos Report» (пока за 2013й год) от известнейшей группы Standish Group о состоянии дел в управлении проектами со списком факторов, приводящих к успеху выполнения проекта и подробным анализом таких факторов с разных сторон и под разными углами. Рекомендую глубоко изучить его на досуге, запланировав для этого как минимум несколько часов в спокойной обстановке. Также ребята из Стратоплана регулярно проводят опрос «Какая методология используется в вашем проекте» и получают очень веселые и показательные результаты. Реальность же такова, что у меня за почти 10 лет управления проектами ни разу не получалось использовать какую-либо методологию в ее каноническом, книжном, классическом виде. Подозреваю, что у вас дела обстоят похожим образом. Всегда есть какие-то обстоятельства, которые заставляют нас из, к примеру, Scrum’а конструировать зверька под названием ScrumBut (Скрам, Но). Про более тяжелые методологии речь даже не идет. Водопад в чистом виде в software development — вообще довольно большая редкость. Периодически встречаю, что на словах он задекларирован, а в реальности по результатам аудита там что угодно, но не водопад.

Расскажу вам одну историю. Руководил я одной программой проектов (группа проектов), где в контракте было указано, что мы работаем с заказчиком по Fixed Price и у нас водопад. Нюанс был в том, что водопад был на каждый релиз, который в свою очередь длился примерно 4-6 месяцев. Такие себе небольшие водопадики, длиной до полугода. Жестокая реальность показала, что если fixed price в такой схеме еще можно сделать прибыльным, то водопад — совсем никак не приживается. Система была настолько сложная, старая, большая, связанная с еще порядка 30 другими системами, ответственная и часто используемая бизнес пользователями заказчика, что изменения приходили пачками каждую неделю. Мы никак не могли заморозить рамки проекта (scope) на срок даже в 1 месяц, не говоря уже про период в 6 месяцев. С другой стороны, более гибкая методология здесь тоже не подходила. Ответственность за корректную и стабильную работу системы настолько высока, а объем кода и модулей внутри системы настолько велик, что никак нельзя обходиться минимумом документации и хаотичной разработкой — дальнейшая поддержка всего этого хозяйства очень скоро стала бы невозможной (почти так и было, когда я пришел в эту программу).

Что же делать? Как управлять проектами, где из-за высокой сложности, объема, ответственности системы перед заказчиком и величины возможных последствий из-за простоя/поломки, требуется водопад (minimum agility), а из-за частых изменений бизнеса у заказчика требуется что-то вроде scrum’а (maximum agility)? И я нашел решение!

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

Ответственность за согласие или отказ

Добрый день, коллеги.

Поговорим сегодня про ответственность, но под довольно неожиданным углом.

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

Для визуализации задания, представьте, что задача: «нарисовать 7 красных линий, все перпендикулярны друг другу, три — зеленым цветом и две — прозрачным, а одну —  виде котенка«. Шикарное видео про эту ситуацию можно найти на YouTube по запросу «Профессионалы (семь красных линий)«.

Читать далее Ответственность за согласие или отказ