Эволюция эстимейта.

День 0

Менеджер: Дайте грубую оценку (хотя бы порядок) времени который это займет (просто, чтобы я ориентировался)?
Сколько? 5-6 месяцев? А почему так долго?

День 15

Менеджер: Как мы обсуждали это может занять порядка 150 дней.

День 30

Менеджер: Это займет около 150 дней.

День 45 (начало проекта)

Менеджер: Вот план, который я составил, с разбиением на этапы. Как и планировалось, мы вкладываемся в 150 дней (даже запас остается). Естественно мы будет постоянно следить насколько план реалистичен и в случае необходимости мы обновим план.

День 90

Менеджер: Ребята, мы отстаем от плана. Обязательно нужно поднажать.

День 150

Менеджер: Мы обязаны выполнить наш коммитмент. Все сроки уже давно озвучены высшему менеджменту, продукт ожидают заказчики.

День 210

Менеджер: Блин. Мы вылезли уже из всех сроков, а у нас дай бог готова 70%. Что будем делать? У кого есть какие идеи?

День 240

Менеджер: После совещания с остальными менеджерами, было принято решение — сдвинуть сроки. Мы ДОЛЖНЫ закончить проект через 80 дней. Но на этот раз нам нужно дать твердый коммитмент.

День 300

Менеджер: (Радостным голосом) Идем по плану, буквально с небольшим отставанием.

День 320

Менеджер: (молчит и напряженно барабанит по клавиатуре)

День 360

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

18 комментариев to “Эволюция эстимейта.”

  1. ха-ха-ха. самое грустное, что так обычно всегда и происходит.

  2. iHunter:

    После просьбы менеджера о грубой оценке не хватает фразы: «А почему так долго?»

  3. Виктор, здраствуйте.

    Насколько я понимаю, есть несколько методик управления проектами. В некоторых случаях даже невозможно сказать, сколько тот или иной проект займет времени, потому что он или очень сложный, или есть столько неизвестных параметров, когда просто невозможно оценить их влияние на проект. Но от менеджеров проектов начальство требует сроки, менеджер проекта требует предоставить ему(ей) грубую оценку, сколько времени этой займет 🙂 К сожалению, начальству некомфортно жить с формулировкой: «это займет столько времени, сколько займет» 🙂

    С уважением,
    Рустам.

    • Victor Ronin:

      Добрый день, Рустам

      Да, верхнего начальству некомфортно жить с такой формулировкой. И я понимаю почему. К выпуску проекта/продукта всегда привязаны реальные деньги. И получается, что им говорят — расходы неизвестны и доходы неизвестно когда. Я тоже бы в таком случае нервничал бы.

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

  4. ну ты же понимаешь, что всё это меркнет в сравнении с http://www.curtis.lassam.net/comics/estimation_smaller.gif

    (я к тому, что ПМ же просто так давит)

  5. Я лет 10 работаю в IT, в основном программистом, последние пару лет совмещал c Project Managment.
    Так вот проблема планирования как была так и остаётся для меня самой большой/загадочной.
    Под управлением хорошего менеджера мне не удалось поработать, я работал в основном в гос. структурах, и там были просто сроки, когда была комиссия, и к комиссии ты должен был всё сделать, и всегда делали.
    Когда я руководил проектом, сроки также выставлялись в виде «к августу». Так и делали к августу, но, конечно, потом ещё допиливали пару месяцев, потому что в гос. структурах всегда есть такое понятие как «тестовая эксплуатация» в течении которой всё и допиливается (кстати, допиливается помимо наших багов ещё из-за того, что заказчики начинают только понимать, чего они хотели на самом деле — но это скорее проблема того, что в гос. структурах обычно используется каскадная модель разработки).
    На данный момент, я работаю в небольшой команде и заказчик очень заинтересован в конечном продукте, поэтому мы движемся небольшими шагами используя scrum — и в этом случае точность планирования достаточно высокая.
    Ваш пост относится больше к корпоративной отрасли, там да, сложнее. Всё видимо зависит от опыта менеджера — он должен хорошо знать команду, хорошо разбираться в технологиях, хорошо понимать проект, хорошо понимать риски, тогда, возможно, точность планирования можно улучшить.

    • Victor Ronin:

      Пост действительно больше относится к корпоративной отрасли, хотя эти проблемы цветут и пахнут во всем IT.

      Опытность менеджера безусловно плюс, но есть множество вещей, которые влияют на план и которые невозможно предсказать и спланировать.

      Scrum (или другая Agile методика) безусловно помогают. Ключеое в них то, что вместо попытки спланировать на год вперед, активное планирование ведется на 2-4 недели (что гораздо более реалистично). Тем не менее, agile методики, не могут ответить на вопрос «А когда будет готово все целиком»?

      • «Тем не менее, agile методики, не могут ответить на вопрос «А когда будет готово все целиком»?»» — я знаком с одним pm-ом из Москвы, они практикуют scrum и как-то отвечают на этот вопрос. 🙂 Хотя, может быть они и выходят за сроки и бюджет, не знаю (кстати, поитерационная оплата позволяет клиенту в любой момент сказать — «всё! продукт готов»).

        • Victor Ronin:

          Ключевое слово в этом случае «как-то». Scrum не заточен на планирование далекого будущего. Даже точнее сказать, agile методологии чаще всего говорят, что все настолько изменчиво, что планировать далекое будущее бысмысслено.

          Поитерационность — действительно, в идеале дает возможность быть близким к выпуску продукции. Но все таки стоит отличать качество кода близкое к готовности выпуска и уже реализованность бизнес функциональности, которая делает продукт продаваемым.

  6. Anna:

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

  7. Now a lot of business is not good