Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
Head of pre-sales division в IT-Solutions
  • PM эстимейтит проект

    Очень обобщённая ситуация. Для конкретных советов неплохо было бы уточнить ситуацию или проблему.

    но если в общем — то НЕТ, это не нормально.

    PM должен организовать оценку, подсказать/показать команде варианты оценивания (например Planning Poker) и учесть все риски, после чего, согласовав с командой окончательную оценку, выдавать её на кастомера.

  • Что такое Канбан

    @Eugene_Lymar:
    Не придирки ради. Не могли бы Вы расширить Ваше утверждение о невозможности двигать таблички по Kanban доске внутри спринта?

  • Турнір з футзалу серед IT-компаній DOU IT-Cup 2016

    Физики, чтоли:
    Hz = Гц?))

  • Турнір з футзалу серед IT-компаній DOU IT-Cup 2016

    так а где-же подробней можно почитать:
    1) Размер взноса и реквизиты?
    2) Форма заявочного листа?
    3) Формат турнира?
    4) Дополнительные требования?

    Підтримав: Ryzhov Oleksandr
  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Воу-воу-воу! Палехче!:))
    Не было на месте пару дней, уже забросали какашками:)
    Ну что ж, давайте буду отбиваться одним постом от всех.

    General:
    Мне кажется, что не все правильно поняли дилемму в сабже. Если её перефразировать, то я получаю следующий вопрос: Нужны ли глубокие знания и/или опыт в разработке для современного PM’а в SWD? Мой тезис для холивара — НЕТ.
    Разъясняю:
    Роль PM — это не про предметную область, это про процессы и людей, это про эстимейты и выполнение их, это про коммуникацию с Заказчиком и командой.
    Глубоки знания или опыт в разработке — это круто, но они имеют несколько существенных минусов:
    1) Как бы это было не обидно, но знания и скиллы устаревают со временем. А времени на поддержание их в актуальном состоянии не будет
    2) Применение этих знаний и скилов неосознанная попытка оценить проект, проверить компетентность кодера/тестера/"коготоещё" основываясь на собственном опыте будет приводить как к ошибкам, так и к демотивации команды.
    3) Попытка погрузится в subject domain будет нести ущерб процессам, коммуникациям и остальным обязанностям РМ’а
    Другими словами, два РМ’а (один с опытом разработки, другой без) будут одинаково эффективно вести проект, т.к. знания не где будет применить. Для применения знаний есть команда со своим тимлидом.

    Теперь попробую тезисно ответить на отдельные выпады (обобщённо):
    1) Запуск миссии на Марс/Строительство моста/подготовка и полёт на Луну.
    Тут многие забрасывали мне предложения поруководить проектами разными и всем я отвечал — Да. Я способен реализовать эти проекты при наличии адекватного спонсора и реальной связки бюджет-срок-объём.
    На вопрос как оценивать бюджет-срок-объём: объём — с Заказчиком; срок -с командой; бюджет — согласно установленных правил и опираясь на предыдущие два пункта.
    В подтверждение своих слов, я могу привести вам один пример из жизни, когда мы ввязались в проект по построению ВКС для досудебных следствий. Кроме прочего, в проекте присутствовал такой кусок, как Поставка вандалостойких Видеотерминалов с определёнными параметрами (если вкратце — моноблок; металический корпус; калёное стекло; согласованная связка ВКС и централизованное управление). Эти терминалы сейчас стоят в большинстве СИЗО Украины. Это было даже круче строительства моста или полёта на Луну, ведь мосты строили, а на Луну уже летали (если верить NASA:)), а такого опыта ни у кого в Украине не было. Более того, под этот кусок уже был понятен бюджет, больше которого нельзя выделить. Но мы справились, вложились в бюджет и сроки. Естественно архитектуру и дизайн рисовала команда с привлечением меня для декомпозиции, координации и планирования. После создания демообразца и утверждения его был запущен процесс очень схожий с Waterfall’ом, но модифицированный в виду жёстких сроков и низких требований к документации. Параллельно работало несколько команд (производители корпуса; закупка, сборка, инсталляторы). На выходе — у меня, в качестве кейса, есть успешный проект по HW Development’у и да, я не имел и не имею глубоких знаний в предметной области как металла, так и совместимости компьютерных комплектующих.
    2) Теперь по поводу:

    Ну и на кой ляд такой нужен? Что он будет заказчикам говорить? А разрабам? Заказчики закажут за 3 дня полет на Луну сделать, не понимая, он согласится. Что разрабам скажет? Рисуем и полетели?
    Ну глобальный вопрос на кой ляд нужен РМ — это ближе к философии. Но тогда придётся задаться вопросом и об остальных не разработчиках: тестеры, бухгалтеры, уборщицы и т.д.
    А в вопросе об испорченном телефоне — это не совсем так. Действительно грамотный РМ никогда не даст эстимейт, не согласовав его с командой! Ведь какой бы технически подкованный не был РМ, в любом случае делать команде. Есть тим-лид, есть команда, есть этап инициации проекта, на котором все потенциальные участники или, если проект большой, руководители структурных единиц собираются и грубо оценивают объём работы и затраты. После этого совещания начинается магия PM’а, который сводит это всё в сложные проектные документы и выдаёт своё решение на Заказчика.
    Но есть ещё другое утверждение, это не совсем к РМ’у, это ближе к продажам — Нет ничего не возможного. И на Луну можно улететь за три дня (достаточно купить уже готовую к старту ракету, вопрос только в деньгах), и мост можно построить за три дня (по-крайней мере, инженерные войска готовы под этим подписаться).
    3) @Viktor Chyzhdzenka, почему-то постоянно ссылался на то, что РМ’у без релевантного опыта (мы вроде как согласовали, что это опыт разработки) можно
    Им с 3 короба наврешь и делай с ним, что хошь
    Ну если опустить отсутствие ответа на мой вопрос Зачем это делал Виктор, а взять этот тезис за истину, которая широко распространена, отвечу — как команде с РМ’ом, так и РМ’у с командой надо дружить. Проверить враньё в эстимейтах или занятости очень просто (пообщаться с «обманщиком» и, потратив время, попытаться с ним декомпозировать его обещания до простых и доступных всем вещей, чтобы иметь возможность оценить реальность его эстимейтов. Или обратиться за помощью к тим-лиду/другому РМ с предположением, что сроки завышены, и просьбой подтвердить их...да множество способов). Так вот вопрос: как дальше работать команде с человеком, который намеренно филонит и завышает эстимейты?
    Если честно, я всё-равно, никак не могу понять, как команда, работающая в проекте, может быть не заинтересована? Люди, которые приходят отсиживать свою ставку в офисе, кроме того, что отравляют коллектив (ведь соседям то виднее), так ещё и начинают деградировать (ведь вряд ли находясь в офисе и имитируя огромную загрузку, человек будет заниматься самообразованием)

    4) Ну и вроде последний вопрос: Что должен делать PM на этапе Design (из SDLC).
    Давайте согласуем, что дизайн это этап, который начинается после согласования и осознания требований Заказчика и заканчивается документом (иногда на бумажке :)) с описаниями как продукт будет выглядеть и как будет работать.
    Так вот, на этом этапе, задача РМ запланировать и провести одно/ряд совещаний с требуемыми участниками последующих процессов для достижения результата (иногда на бумажке:)).

    Вроде никого не упустил, если кому не ответил — напомните о своём вопросе, будем дискутировать дальше ;-)

    З.ы. я понимаю, что в

    99% наших контор — PM, это одновременно и тим-лид и архитектор и сеньор девелопер...
    ..я думаю, что цифра существенно завышена, такого быть не должно и эти «монстры» (я про PM’о-лидо-архитекторо-кодеров) будут отмирать и либо квалифицироваться во что-то одно, или будут востребованы только в «шарашко-лавках», менеджмент которых не может/понимает/хочет платить за экспертов.

    З.ы.ы. я считаю, что каждый должен быть профессионалом в своём деле. А профессионал — это понятие широкое: и знание предметной области, и уважительной отношение к пересекающимся областям, и желание делится знаниями с «младшими», и совместное стремление в достижении целей компании/дирекции/команды, да и много ещё чего.

    Підтримав: Alexandr Podkorytov
  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Витя, прошу прощения, но с каких пор при прохождение этих этапов PM выступал в роли отличной от администратора (координатора)?

    Причем мы видим классический водопад, а нынче в ходу итерации

    все итерации (читай Agile) это тот же водопад, только без бумажек)
    Внутри каждой итерации проходят всё те же этапы, но быстрее и короче.

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Вы про это:
    Допустим, Ахиллес бежит в десять раз быстрее, чем черепаха, и находится позади неё на расстоянии в тысячу шагов. За то время, за которое Ахиллес пробежит это расстояние, черепаха в ту же сторону проползёт сто шагов. Когда Ахиллес пробежит сто шагов, черепаха проползёт ещё десять шагов, и так далее. Процесс будет продолжаться до бесконечности, Ахиллес так никогда и не догонит черепаху.

    Так это про рекурсию, а не про деление на кусочки (декомпозиция по-умному)

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    чегойнто?:)

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Да что ж вы всё про

    лапши на уши навешают
    !?!?

    Да не везде так! поверьте!:)

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

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Вот Вы тут шутки шутите, а всё движется именно в эту сторону. Хоть Ваш дедушка и утрировал ситуацию, но потребность такая есть...Вы, в примере, замените клизму на укол и поймёте, что куда ставить — назначает врач; а как — решает медсестра :)

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Любой самый объёмный и неосязаемый проект можно оценить:
    чтобы съесть слона — нужно разрезать его на мелкие кусочки.

    А в каких проектах у Вас ПМ делал эстимейт на проект самостоятельно без подключения команды?
    Как только согласован объём с Заказчиком можно планировать. Как только появился эстимейт в «попугаях» его легко перенести на срок и бюджет. Это если вкратце:)

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Вы ответили только на первый вопрос..

    С другой стороны, давайте обсудим для чего Вы это делали?
  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Дмитрий,
    мне кажется, что я понял, к чему Вы клоните:)
    Нет никаких скрытых затрат!

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

    посмею себе напомнить об основных этапах:

    • Requirements
    • Design
    • Implementation
    • Testing
    • Maintenance
  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Постойте, почему это в сторону!? :)
    Разве профильный ПМ, в Вашем понимании — это не ПМ с опытом разработки? или откуда тогда ему «профильному» взяться?

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    с другой стороны:
    Давайте представим типичного Dev’а, который уже «вырос из штанишек» разработчика и решил, что ему пора занять высоченный пост «дирекХтора» (читай РМ’а)..он побежал прослушал 2 он-лайн курса и один 2х дневный оффлайн...и вот он готов!!

    На первом же проекте он начинает сходить с ума от того, что многопотоковость задач сильно отличается от разработок, более того, он часто спешит подсказать/помочь/посоветовать разработчикам как им жить кодить. А тут ещё и со спонсорами надо дружить и держать их подальше от команды, убеждая что «we are on the line!»....

    кстати, вот отличная статья на эту тему: http://megamozg.ru/post/1762/

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Странно, у меня ссылка работает. но нашли правильный комментарий.

    В общем:
    Если я говорю о РП из строительства, который хочет сменить сферу, то я ни в коем случае не подразумеваю узколобого спеца, который не в состоянии разобраться в терминологии..

    В частности:

    — любое описание scope/требований, изобилующее техническими подробностями, потребует «переводчика»
    здесь можно разобраться самостоятельно...
    — чтобы адекватно «фильтровать» рассказы участников проекта или заказчиков в случае конфликтных ситуаций нужен «переводчик»
    переводчиком с языка Заказчика на язык участников проекта и назад выступает PM.
    РМ всегда может задать вопрос в команде или лично, если он действительно где-то может разобраться..для этого есть ТимЛиды + 1001 ресурс.
    Можно взять ПМ-а без опыта, и (если он зеленый), то с большой вероятностью будет делать вид, что все понимает (и прощелкает что-то важное), либо будет пытаться разобраться, и задолбает всех участников процесса.
    если под «зелёный» Вы подразумеваете молодого-неопытного — то это весьма реалистичный сценарий, в ином случае не соглашусь. РП без фундаментальных знаний в нужной сфере всегда сможет построить общение и ведение проекта таким образом, чтобы все были на одной волне. Просто, Вы, почему-то, рассматриваете ситуацию, в которой у команды есть цель «завалить» PM’а и ткнуть его носом в его-же некомпетентность..Вероятно у меня просто не было такого опыта, т.к. в большинстве проектов мои команды были сфокусированы на один результат и осознавали значимость каждой роли в команде...

    Ну и последнее:

    они построят у него в голове кривую картину мира — то ховайся в жито
    грамотный PM всегда будет перепроверять информацию и не допустят подобной ситуации.
  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Виктор, а такие руководители ни разу не ловили Вас (за Ваши 16-то лет стажа) на «лжи» или некомпетентности в естимейтах?

    С другой стороны, давайте обсудим для чего Вы это делали?

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    Антон,
    ну как можно проводить параллели между 40 летним строителем с зарплатой в $200-400/месяц и молодым «синьёром» 23 лет отроду со ставкой $3-4k, который активно учавствует в топике Где встретить девушку на dou-форуме!?:)

    Эквивалент-то да; но сравнивать это действительно нельзя, т.к. базовые потребности слишком сдвинуты и искажены у второго; хотя методы воздействия остаются теми же, но «с поправкой на ветер»:)

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

    на счёт Тим Лида — спорно....всё-таки это разработчик (если мы про команду девелоперов говорим), а вот «наш PM» — может быть очень успешным!

  • А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

← Сtrl 123 Ctrl →