• 10 истин проджект менеджмента

    Posted on April 26th, 2009 Александр Орлов 10 comments

    1. Одна и та же работа при одних и тех же условиях будет оценена по-разному десятью разными людьми. Или одни и тем же человеком, который сделает это десять раз.

    2. Любой проект может быть оценен точно (когда он закончен).

    3. Самое важное и самое редко используемое СЛОВО в словаре проджект менеджера – это “НЕТ”.

    4. Самая важная и самая редко используемая ФРАЗА в словаре проджект менеджера – это “Я не знаю”.

    5. Нет ни чего невозможного для человека, который не должен это делать.

    6. В сердце любого большого проекта есть маленький проект, который пытается оттуда выбраться.

    7. Никогда нет времени, чтобы сделать все правильно с первого раза, но всегда есть время начать сначала и все переделать.

    8. Чем раньше вы начнете писать код, тем позже вы закончите.

    9. Нет хороших проджект менеджеров, есть только удачливые.

    10. Чем больше вы планируете, тем более удачливым вы становитесь.

    P.S. На самом деле, истин, конечно, гораздо больше. По-английски они написаны вот тут. :) Спасибу Майку Хардинг Робертсу за подборку!

    Fun
     

    10 responses to “10 истин проджект менеджмента”

    1. 7-я истина, к сожалению, объективная реальность.

      Часто нужнее и полезнее выпустить что-то быстрее, пусть и не идеально спроектированное и реализованное, и успеть в рынок. Чем качественно спланировать и реализовать, но все продолбать, т.к. конкуренты опередили.

      А вот если успел, то потом можно поискать время переписать по правильному :)

      Опять же далеко не всегда сразу понятно, как правильно…

    2. 8й пункт – в корне не согласен.

      По своему опыту и глядя на ситуацию в разных компаниях:

      I) Чем раньше вы дадите “неофициальный старт” своей команде, и не будете ждать сверху официальной отмашки – на сетапе проекта можно выиграть недели а то и месяцы – тем больше вы выиграете у “дедлайна”. А он может быть довольно жестким.

      II) за это время
      -толковая команда напишет пяток прототипов, -лиды прикинут архитектуру
      -топ перформеры уже напишут какой-то код в прототипе – напишут, а затем
      а) сами предложат идеи как заюзать технологию Х лучше, и дойти до цели меньшей кровью.
      б) почувствуют себя “авторами” кода – и уже далее будут более интересоваться судьбой собственных солюшенов в проекте.

      я редко видел команды которые делают идентичный проект в 10й раз,
      всегда есть новые библиотеки\решения\архитектура.
      Это уже “технологический риск”, т.е. на мой взгляд опыт надо предварительно “кешировать” в головах разработчиков.

      Саша?

    3. @Igor A.

      Писать код, пропустив или минимизировав предварительный анализ и проектирования, конечно, можно. Более того, почти все так и делают. Но умные люди предупреждают о таких опасностях на этом пути:

      “Когда код написан, очень трудно его выбросить. Подобно писателям, влюблённым в свою прозу, программисты привязываются к своим алгоритмам на эмоциональном уровне… Руководителю ещё труднее выбросить код, потому что он дорого заплатил за его создание и хорошо понимает, что замена обойдётся ещё дороже.”

      Алан Купер. Психбольница в руках пациентов

      “Разработка по принципу «напишем и исправим» продолжает применяться, потому что такой подход привлекателен по двум причинам. Во-первых, это позволяет коллективу разработчиков немедленно увидеть продвижение: можно начать передвижение глыбы на 10 метров в первый день, пока более разумный коллектив пилит деревья для катков, ровняет дорогу для надёжного движения и ещё не сделал никаких видимых достижений в перемещении глыбы. Второй аспект привлекательности этого подхода состоит в том, что не требуется никакого обучения.”

      Стив Макконнелл. Профессиональная разработка программного обеспечения

    4. 2 Igor A., Greesha. Я так думаю, есть правда в обеих точках зрения. :) Зависит все от ситуации.

      Пара примеров из жизни.

      Пример №1. “Спроси юриста как можно раньше”. Большой проект. Пишется большое количество библиотек (размер проекта – сотни человеко-лет). Когда часть библиотек написана, приходят юристы и говорят: “Так. То, что именно эти люди писали эти библиотеки, является юридическим риском для компании. Эти библиотеки должны переписать другие люди с нуля.”

      Садятся другие люди и переписывают. Потери по затратам времени – около полутора человеко-лет.

      Пример №2. “Не пишите одно и то же”. Большой проект. :) Пять тестовых команд. В одной за день написали скрипты автоматизации тестовых прогонов. В другой команде написали в тот же день аналогичные скрипты. После чего начались страшные обсуждения, чью скрипты оставлять. В итоге мержили их примерно месяц. :)

      Я все это к чему. Сначала подумать, потом делать. Igor, то, что Вы написали, этому, кстати, и не противоречит. Это, на мой взгляд, как раз про “подумать”.

    5. > 2. Любой проект может быть оценен точно (когда он закончен).
      Но большая часть проектов может быть оценена с точностью в 10% до написания первой строчки кода. Просто нужны специалисты хорошего уровня. (см. Макконела “Остаться в живых”)

    6. 3,4 мега знакомы) Умение отказывать наверное появляется с опытом.. Ещё за собой замечал что иногда занижаю сроки. Ну правда не сам а по просьбе начальников в стиле
      - ты можешь это сделать до конца недели?
      - Нет
      - Почему?
      - Ну у нас есть вот тот этот и ещё вот тот проект
      - Но если ты его не сделаешь то затянется вступление в срок приказа N. А этого нельзя допустить!
      - Ну я подумаю.
      - Не оно должно быть сделано к концу недели.
      (мысль – ну если вот том проекте недоделать пару фич, а в другом пока не писать отчетность то успеем)
      - Ладно мы постараемся..

    7. 2 salar. И ты прав. :) Хотя мне вот везло на проекты, где оценить с точностью 10% сложно…

    8. 2 fly-fire-fox. Проблема нумер 3 – моя любимая. :)

    9. @Greesha,

      > Писать код, пропустив или минимизировав
      > предварительный анализ и проектирования,
      > конечно, можно. Более того, почти все так и
      > делают. Но умные люди предупреждают о таких
      > опасностях на этом пути:

      .. я писал не совсем так:

      ключевые мысли:

      “прототип” – это не то что мы будем поставлять, а то что покажем топ’ам как концепт если вдруг попросят, например наработать опыт в технологии если его нет; потом можно и выкинуть.

      “прикинуть архитектуру” – это не отсутствие документации, это посадить толковых людей и развязать им руки как можно раньше, плюс использовать наработки прототипа.

      Основная идея – не ждать формального старта, фаз итп. Чем больше менеджмента наверху – тем более тормознутая система принятия решений, в идеале нужно ее опережать просто чтобы быть на хорошем счету.

    10. @Igor A.

      > Основная идея – не ждать формального старта,
      > фаз итп. Чем больше менеджмента наверху –
      > тем более тормознутая система принятия
      > решений, в идеале нужно ее опережать просто
      > чтобы быть на хорошем счету.

      Хорошо, если вы можете себе это позволить.

      Если все и так загружены текущими проектами, то работает другой принцип: “не спешите выполнять приказание, его могут отменить”.

      Часто срабатывает, кстати. Поток идей от “менеджмента наверху” может превышать все разумные пределы.

    Leave a reply

    You must be logged in to post a comment.