IT-Lady

Задача декомпозирована до соплей… и все равно не работает.

В эту субботу я променяла sales club на Opentalk Взрыв мозга

Ну и что там было? Не могу точно сказать, что там было. Дима поставил цель взорвать мозг слушателям, что было успешно выполнено. Могу рассказать, что из услышанного я поняла=)

Для управления проектом менеджеры обычно составляют план. Через некоторое план начинает трещать по швам: мы не укладываемся в сроки, потом не укладываемся в бюджет, потом … Здесь у каждого своя история, с общей темой «План разработан, план не сработал»

Как мы дошли до такой жизни? Почему план не работает?

  • Обычно план — это бюрократический документ.
  • Ни разработчики, ни менеджеры не умеют правильно пользоваться планом (нет знаний, нет навыков, не опыта)
  • Рядовой разработчик не понимает своего места в глобальном процессе (развития компании, развития проекта и т.д.)
  • План используется как средство устрашения («кнут»).
  • Мы пытаемся обхитрить самих себя и используем двойные стандарты. Мы планируем поездку, планируем работы по ремонту своей квартиры, но не хотим придерживаться плана в своей профессиональной деятельности.
  • Часто план используется как средство отчетности, а средство отчетности не может быть живым инструментом.

Итого: план не любят => план не живет => план не является инструментом.

Что обычно мы включаем в план?

  • Бюджет
  • Сроки
  • Приоритеты
  • Задачи(субъекты планирования)
  • Риски(ответственный человек, схема минимизации и т.д.)

Как обычно мы составляем план?

Обычно мы думаем таким образом: «что бы нам такого добавить в проект?» После чего наш план превращается в большую бочку, в которую мы запихиваем фичи, задачи, риски… «Я придумал еще один риск, запихну-ка я его в наш план.»

Первоочередная задача, которую мы ставим для себя — как уложиться в сроки и в бюджет? И после этого начинаем«игры с задачами в сетке времени». Как будто заказчик пришел к нам и сказал: «ребята, я бы хотел с вашей помощью потратить $$$ c 4 марта по 28 октября. Сможете?».

Заказчик может простить флуктуации по времени и по бюджету в пределах 20%. А что такое флуктуация по качеству в 20% ? Пятая часть проекта не работает?

Еще одна  проблема – это реакция на риски. Когда нам начинать применять план Б? Когда риск уже случился? А может тогда, когда риск «собирается» случится? А как определить, что риск собирается произойти?

Дмитрий Ефименко аkа Damiano предлагает следующий концепт решения:

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

Полный и подробный концепт читаем здесь.

Я очень люблю собирать цитаты у рассказчиков, поэтому держите:

«Задача декомпозирована до соплей»

«И вот садятся аналитик с менеджером проекта и решают: это баг или фича? И как срубить бабла с заказчика, если это багофича?»

«Прежде показывать заказчику схему классов в ядре, приготовьте двух уборщиц, которые после презентации прийдут оттирать мозги от белой доски»

Отдельно порадовала история про разработчика:

Через 5 месяцев после начала разработки. Программист думает: «Эх, вот сейчас я бы эту задачу сделал совсем по-другому» — и решает переписать кусок кода.До дедлайна еще целая неделя, а неделя – это ведь ого-го? В понедельник он садится и к вечеру понимает, что за неделю ему не успеть, но ведь уже начал? Поэтому во вторник он применяет google-driven development. Google-driven development не помог, поэтому в среду используется friend-driven development. Если и friend-driven development не помог , тогда в четверг применяется overtime- driven development. И вот он приходит в пятницу, в день дедлайна с красными глазами и видом «можете меня убить, но я сделал все, что мог».

Ну, а историю про дочку, которая перетягивает коврик-паззл в родительскую комнату по кусочкам, Дима расскажет вам сам.

Увидимся на следующем Opentalk =)

В рубриках: Профессионально, 1:34 пп, 28 Фев 2011 в 1:34 пп.

Отзывов: 5

Отзывов: 5

  1. Dmitriy Efimenko 28 Фев 2011

    Ну вот, а говорила, что мозг взорван :) Все верно. Все в точку. Расскажи потом, как повлияло на мировосприятие.

  2. Prince2 Вам в помощь.

  3. Webby Laddy 19 Мар 2011

    2Dmitriy

    Повлияло очень. Дало направление «куда думать», несмотря на то, что ПМ у меня не основной вид деятельности.

    2MK
    Вот это сюрприз, увидеть твой коммент )
    Спасибо за совет. С методологией ознакомлюсь (правда первая возникшая ассоциация была c Prince of Persia =)


Ваш отзыв