@Eugene_Lymar:
Не придирки ради. Не могли бы Вы расширить Ваше утверждение о невозможности двигать таблички по Kanban доске внутри спринта?
Физики, чтоли:
Hz = Гц?))
так а где-же подробней можно почитать:
1) Размер взноса и реквизиты?
2) Форма заявочного листа?
3) Формат турнира?
4) Дополнительные требования?
Воу-воу-воу! Палехче!:))
Не было на месте пару дней, уже забросали какашками:)
Ну что ж, давайте буду отбиваться одним постом от всех.
General:
Мне кажется, что не все правильно поняли дилемму в сабже. Если её перефразировать, то я получаю следующий вопрос: Нужны ли глубокие знания и/или опыт в разработке для современного PM’а в SWD? Мой тезис для холивара — НЕТ.
Разъясняю:
Роль PM — это не про предметную область, это про процессы и людей, это про эстимейты и выполнение их, это про коммуникацию с Заказчиком и командой.
Глубоки знания или опыт в разработке — это круто, но они имеют несколько существенных минусов:
1) Как бы это было не обидно, но знания и скиллы устаревают со временем. А времени на поддержание их в актуальном состоянии не будет
2) Применение этих знаний и скилов неосознанная попытка оценить проект, проверить компетентность кодера/тестера/"коготоещё" основываясь на собственном опыте будет приводить как к ошибкам, так и к демотивации команды.
3) Попытка погрузится в subject domain будет нести ущерб процессам, коммуникациям и остальным обязанностям РМ’а
Другими словами, два РМ’а (один с опытом разработки, другой без) будут одинаково эффективно вести проект, т.к. знания не где будет применить. Для применения знаний есть команда со своим тимлидом.
Теперь попробую тезисно ответить на отдельные выпады (обобщённо):
1) Запуск миссии на Марс/Строительство моста/подготовка и полёт на Луну.
Тут многие забрасывали мне предложения поруководить проектами разными и всем я отвечал — Да. Я способен реализовать эти проекты при наличии адекватного спонсора и реальной связки бюджет-срок-объём.
На вопрос как оценивать бюджет-срок-объём: объём — с Заказчиком; срок -с командой; бюджет — согласно установленных правил и опираясь на предыдущие два пункта.
В подтверждение своих слов, я могу привести вам один пример из жизни, когда мы ввязались в проект по построению ВКС для досудебных следствий. Кроме прочего, в проекте присутствовал такой кусок, как Поставка вандалостойких Видеотерминалов с определёнными параметрами (если вкратце — моноблок; металический корпус; калёное стекло; согласованная связка ВКС и централизованное управление). Эти терминалы сейчас стоят в большинстве СИЗО Украины. Это было даже круче строительства моста или полёта на Луну, ведь мосты строили, а на Луну уже летали (если верить NASA:)), а такого опыта ни у кого в Украине не было. Более того, под этот кусок уже был понятен бюджет, больше которого нельзя выделить. Но мы справились, вложились в бюджет и сроки. Естественно архитектуру и дизайн рисовала команда с привлечением меня для декомпозиции, координации и планирования. После создания демообразца и утверждения его был запущен процесс очень схожий с Waterfall’ом, но модифицированный в виду жёстких сроков и низких требований к документации. Параллельно работало несколько команд (производители корпуса; закупка, сборка, инсталляторы). На выходе — у меня, в качестве кейса, есть успешный проект по HW Development’у и да, я не имел и не имею глубоких знаний в предметной области как металла, так и совместимости компьютерных комплектующих.
2) Теперь по поводу:
Ну и на кой ляд такой нужен? Что он будет заказчикам говорить? А разрабам? Заказчики закажут за 3 дня полет на Луну сделать, не понимая, он согласится. Что разрабам скажет? Рисуем и полетели?Ну глобальный вопрос на кой ляд нужен РМ — это ближе к философии. Но тогда придётся задаться вопросом и об остальных не разработчиках: тестеры, бухгалтеры, уборщицы и т.д.
Им с 3 короба наврешь и делай с ним, что хошьНу если опустить отсутствие ответа на мой вопрос Зачем это делал Виктор, а взять этот тезис за истину, которая широко распространена, отвечу — как команде с РМ’ом, так и РМ’у с командой надо дружить. Проверить враньё в эстимейтах или занятости очень просто (пообщаться с «обманщиком» и, потратив время, попытаться с ним декомпозировать его обещания до простых и доступных всем вещей, чтобы иметь возможность оценить реальность его эстимейтов. Или обратиться за помощью к тим-лиду/другому РМ с предположением, что сроки завышены, и просьбой подтвердить их...да множество способов). Так вот вопрос: как дальше работать команде с человеком, который намеренно филонит и завышает эстимейты?
4) Ну и вроде последний вопрос: Что должен делать PM на этапе Design (из SDLC).
Давайте согласуем, что дизайн это этап, который начинается после согласования и осознания требований Заказчика и заканчивается документом (иногда на бумажке :)) с описаниями как продукт будет выглядеть и как будет работать.
Так вот, на этом этапе, задача РМ запланировать и провести одно/ряд совещаний с требуемыми участниками последующих процессов для достижения результата (иногда на бумажке:)).
Вроде никого не упустил, если кому не ответил — напомните о своём вопросе, будем дискутировать дальше ;-)
З.ы. я понимаю, что в
99% наших контор — PM, это одновременно и тим-лид и архитектор и сеньор девелопер.....я думаю, что цифра существенно завышена, такого быть не должно и эти «монстры» (я про PM’о-лидо-архитекторо-кодеров) будут отмирать и либо квалифицироваться во что-то одно, или будут востребованы только в «шарашко-лавках», менеджмент которых не может/понимает/хочет платить за экспертов.
З.ы.ы. я считаю, что каждый должен быть профессионалом в своём деле. А профессионал — это понятие широкое: и знание предметной области, и уважительной отношение к пересекающимся областям, и желание делится знаниями с «младшими», и совместное стремление в достижении целей компании/дирекции/команды, да и много ещё чего.
Витя, прошу прощения, но с каких пор при прохождение этих этапов PM выступал в роли отличной от администратора (координатора)?
Причем мы видим классический водопад, а нынче в ходу итерации
все итерации (читай Agile) это тот же водопад, только без бумажек)
Внутри каждой итерации проходят всё те же этапы, но быстрее и короче.
Вы про это:
Допустим, Ахиллес бежит в десять раз быстрее, чем черепаха, и находится позади неё на расстоянии в тысячу шагов. За то время, за которое Ахиллес пробежит это расстояние, черепаха в ту же сторону проползёт сто шагов. Когда Ахиллес пробежит сто шагов, черепаха проползёт ещё десять шагов, и так далее. Процесс будет продолжаться до бесконечности, Ахиллес так никогда и не догонит черепаху.
Так это про рекурсию, а не про деление на кусочки (декомпозиция по-умному)
чегойнто?:)
Да что ж вы всё про
лапши на уши навешают!?!?
Да не везде так! поверьте!:)
а про великолепного разработчика, помните, что его знания очень быстро теряют актульность и, иногда, знания конкретного разработчика будут выступать шорами для него.
Вот Вы тут шутки шутите, а всё движется именно в эту сторону. Хоть Ваш дедушка и утрировал ситуацию, но потребность такая есть...Вы, в примере, замените клизму на укол и поймёте, что куда ставить — назначает врач; а как — решает медсестра :)
Любой самый объёмный и неосязаемый проект можно оценить:
чтобы съесть слона — нужно разрезать его на мелкие кусочки.
А в каких проектах у Вас ПМ делал эстимейт на проект самостоятельно без подключения команды?
Как только согласован объём с Заказчиком можно планировать. Как только появился эстимейт в «попугаях» его легко перенести на срок и бюджет. Это если вкратце:)
Вы ответили только на первый вопрос..
С другой стороны, давайте обсудим для чего Вы это делали?
Дмитрий,
мне кажется, что я понял, к чему Вы клоните:)
Нет никаких скрытых затрат!
Давайте всё-же копнём чуть глубже- в какой части проекта, по Вашему, ПМу потребуются знания/умения разработчика? (мы ведь это подразумеваем, когда говорим ПМ с техническим бекграундом?)..
посмею себе напомнить об основных этапах:
Постойте, почему это в сторону!? :)
Разве профильный ПМ, в Вашем понимании — это не ПМ с опытом разработки? или откуда тогда ему «профильному» взяться?
с другой стороны:
Давайте представим типичного Dev’а, который уже «вырос из штанишек» разработчика и решил, что ему пора занять высоченный пост «дирекХтора» (читай РМ’а)..он побежал прослушал 2 он-лайн курса и один 2х дневный оффлайн...и вот он готов!!
На первом же проекте он начинает сходить с ума от того, что многопотоковость задач сильно отличается от разработок, более того, он часто спешит подсказать/помочь/посоветовать разработчикам как им жить кодить. А тут ещё и со спонсорами надо дружить и держать их подальше от команды, убеждая что «we are on the line!»....
кстати, вот отличная статья на эту тему: http://megamozg.ru/post/1762/
Странно, у меня ссылка работает. но нашли правильный комментарий.
В общем:
Если я говорю о РП из строительства, который хочет сменить сферу, то я ни в коем случае не подразумеваю узколобого спеца, который не в состоянии разобраться в терминологии..
В частности:
— любое описание scope/требований, изобилующее техническими подробностями, потребует «переводчика»здесь можно разобраться самостоятельно...
— чтобы адекватно «фильтровать» рассказы участников проекта или заказчиков в случае конфликтных ситуаций нужен «переводчик»переводчиком с языка Заказчика на язык участников проекта и назад выступает PM.
Можно взять ПМ-а без опыта, и (если он зеленый), то с большой вероятностью будет делать вид, что все понимает (и прощелкает что-то важное), либо будет пытаться разобраться, и задолбает всех участников процесса.если под «зелёный» Вы подразумеваете молодого-неопытного — то это весьма реалистичный сценарий, в ином случае не соглашусь. РП без фундаментальных знаний в нужной сфере всегда сможет построить общение и ведение проекта таким образом, чтобы все были на одной волне. Просто, Вы, почему-то, рассматриваете ситуацию, в которой у команды есть цель «завалить» PM’а и ткнуть его носом в его-же некомпетентность..Вероятно у меня просто не было такого опыта, т.к. в большинстве проектов мои команды были сфокусированы на один результат и осознавали значимость каждой роли в команде...
Ну и последнее:
они построят у него в голове кривую картину мира — то ховайся в житограмотный PM всегда будет перепроверять информацию и не допустят подобной ситуации.
Виктор, а такие руководители ни разу не ловили Вас (за Ваши
С другой стороны, давайте обсудим для чего Вы это делали?
Антон,
ну как можно проводить параллели между 40 летним строителем с зарплатой в $200-400/месяц и молодым «синьёром» 23 лет отроду со ставкой $3-4k, который активно учавствует в топике Где встретить девушку на dou-форуме!?:)
Эквивалент-то да; но сравнивать это действительно нельзя, т.к. базовые потребности слишком сдвинуты и искажены у второго; хотя методы воздействия остаются теми же, но «с поправкой на ветер»:)
на счёт Тим Лида — спорно....всё-таки это разработчик (если мы про команду девелоперов говорим), а вот «наш PM» — может быть очень успешным!
Верб в себя! :) cs409731.vk.me/...
Очень обобщённая ситуация. Для конкретных советов неплохо было бы уточнить ситуацию или проблему.
но если в общем — то НЕТ, это не нормально.
PM должен организовать оценку, подсказать/показать команде варианты оценивания (например Planning Poker) и учесть все риски, после чего, согласовав с командой окончательную оценку, выдавать её на кастомера.