QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

PM эстимейтит проект

Господа, хочу узнать Ваше мнение по этому поводу, нормально ли это? Были ли у вас такие случаи?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Маловато деталей.
Если ПМ эстимейтит ПРОЕКТ в целом — то это часть его работы. Прикидывать сроки и согласовывать их с заказчиком. Потому что время = деньги. И эстимейт всего проекта зависит не только от того, как быстро его напишут девелоперы. Тем более что ИТ проект — это не мост через реку, который или устоит или рухнет. В ИТ проекте вполне может половина фичеров «отвалиться» в процессе разработки, требования поменяются и в результате вместо моста получится тоннель.
Девелоперы априори не могут эстимировать на месяц а тем более год вперед. Они могут давать более-менее точные эстимейты на конкретные ближайшие задачи. Вот эти эстимейты должен просить ПМ.
А уже потом его работа сопоставить эти эстимейты от девелоперов с реальным перфомансом тима, посмотреть статистику аналогичных проектов, проанализировать риски, прокоммуницировать с начальством, заказчиком, HRрами, применить свой опыт и интуицию, добавить немного хитрости...
Главная беда нашего ИТ в том, что у нас обычно повременная оплата для заказчика и для девелоперов (ставка), а значит время = деньги. И если в другом случае ПМ мог бы говорить с заказчиком на языке денег, а команда бы определяла сколько нужно времени, то тут свободы нет. Варьировать можно только качество — и то до разумных пределов.
Поэтому да — в этом случае ПМ часто «навязывает» время выполнения задачи. Потому что оно определяется «жадностью» заказчика. А девелоперу приходится делать «тяп-ляп» только бы успеть. Разумеется потом накапливается «технический долг» и проект постепенно загнивает. Но, зачастую, заказчика это не волнует. Редкие проекты в ИТ сейчас делаются с прицелом на годы. В моде — ширпотреб, «одноразовый» софт.
Что можно посоветовать девелоперам? Если вы работаете в шаурменной на базаре — то глупо сетовать на качество продукта и грубого хозяина. Из дворовых собак деликатесов не получится, а клиенты и хозяин наверняка не будут интеллигентами и гурманами. Ждать никто не будет. Поэтому опытному шеф-повару нечего делать в шаурменной, он будет выбирать ресторан где оценят его таланты.

Утром реквайренменты — вечером эстимейты.

— а можно наоборот?
— можно, но эстимейты — вперёд!

Всё зависит от ситуации в вашей компании и проекта.
Это хорошо если:
1. Если это типовой проектик с неблольшим объемом работ. ПМ берет метод оценки «по аналогии» учитывая ошибки предыдущего опыта.
2. Если у Вас мелкая контора, и Вам жизненно необходим этот заказ. Тогда ПМ может дать такую оценку заказчику, которая позволит как можно больше заработать, завев проект в Вашу компанию. Это может не совпадать с эстимейтом команды, но она должна это понимать и быть согласна. Выставив высокий эстимейт на заказчика будете без проекта голодные сидеть.

В остальных случаях плохо)))

все ок пока команда в них попадает
да были, пришлось расстаться тк у руководства не было понимания почему это не правильно

Вообще для оценки проектов есть не только методики, но и целый комплекс шагов, и если у вашего PMа есть соответствующий бекграунд почему бы и нет, а вот если он делает оценку проекта тыкая пальцем в небо, это хуже. В идеале действительно это должен делать BA + профильные спецы, учитываются также риски, и особенности сферы, множество нюансов. Еще, даже имея опыт оценки проектов, точные цифры вы не получите, это будут примерные оценки, отклонения будут.

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

В идеале — эстимейтит команда \ ТЛ, а ПМ уже добавляет риски. Ну, и организовывает сам процесс эстимации.
Я часто кастомеру могу дать ROM-estimate. Банальная ситуация. Скайп-колл с заказчиком из США, разница во времени. Команда уже не на работе, все отдыхают. А у меня спрашивают стоимость фичи. Имея предыдущий опыт разработки + тех бекграунд я могу дать ту самую грубую оценку (отклонение до 50%), заранее предупредив, что для точных цифр — нам надо обсудить это с командой.

Засуньте этот эстимейт ПМ-у в какое-нить место, а потом пусть заэстимейтит нормально ваш тимлид.

А лучше тот, кто делать будет.

Техлид ...
заэстимейтит от фонаря,
и почувствуйте разницу.

Если нет реквайрментов и аксептанс критериев (а добывать их — дело рук непосредственных исполнителей), то мало того, что объём работ не понятен, так ещё и переделывать придётся.
Вопрос\проблема не в должности эстимирующего, а в методике, процессе и подходе.

норм. проект можно сдать или не сдать в любой конфигурации :)

видишь там в слове пм сокращение от проэкт, тоесть ПМ рулит всем включая и эстимейшн. Проект проекту рознь, но если у компании это не первый проект то легко можна по аналогии заэстимейтить сроки и стоимость. в других случаях вам могут дать ограниченное время но неограниченный бюджет и тогда пм просто говорит — мы наймем еще 5 контракторов что бы уложиться в сроки. Иногда прожект это бывший тех лид который эстимейтит все проекты и все только рады что он не мучает их митингами для эстимейшн.

Частенько такое встречаю. Но тут важно понимать, что кто сделал estimate, тот за него и в ответе. Если мне подсовывают задачи с чужими estimate, то я делаю эти задачи по своему estimate.

Если кто-то считает, что может сделать быстрее, то он садится и делает.

У ПМа может быть опыт управления разработкой аналогичных проектов и на этапе пресейла он своим экспертным мнением может дать понять клиенту, что бюджет проекта будет от ХХ до ХХХ, но никак не yyy. Тогда ценнейшее время техспецов не будет израсходовано на оценку того клиента, который изначально не понимал, насколько долго/дорого может делаться такой проект.

Другое дело, если ПМ говорит, что «вот это» надо сделать к ХХ числу. Тогда уже возникают вопросы, откуда у ПМа уверенность, что его команда успеет сделать «вот это» к ХХ числу.
В таких случаях, если ПМ у вас адекватный, вы ему можете смело сказать «мы тут подумали, „вот это“ к ХХ числу никак, в лучшем случае к ХУ»
В случае, если ПМ не адекватный...ну...ну что уж тут... тут дальше размышлять нет смысла.

Случаи разные бывают... Мое мнение: это допустимо только тогда, когда жестко поставлена дата старта проекта в продуктиве. Вот должен проект стартовать 01.09.2016 — и точка. Это не обсуждается. Правда, при таком подходе обсуждается реализуемый функционал: это успеем, это не успеем, это костылем закроем и потом переделаем и т.д.

Но в любом случае: детальные оценки частей проекта дают лиды, задача PM в этом случае — правильно и разумно распределить эти эстимейты...

Если контора не на два прихлопа три притопа, то обьективную оценку по времени кодинга даст техлид или архитектор, всё остальное от лукавого.
Если пм постоянно режет эстимейты то это сигнал что в команде уже не всё в порядке.

PM эстимейтит проект
Это ужасно, особенно если PM — девочка-бывший QA.

На начальных этапах в помощь sales-у привлекается заинтересованный технический специалист (везде по разному называется), который потом проект пилить не будет, соответственно estimate-ы бывают разные в зависимости от того как их мотивируют. А потом уже эстимейты на проект/релиз всегда спускаются сверху даже для самого PM-а.

А команда уже устраивает «тараканьи бега» в манеже «Agile», которые ничего не меняют по сути.

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

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

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

Best practice — эстимейт принадлежит команде, в идеале — тому, кто будет делать задачу.

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

нормально
до первого раза пока вы не вложитесь в его эстимейт :))
ПС — я про балпарк)

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

единственное что можно добавить, ПМ должен поставить сам процесс эстимации

Бывает ИМХО всякое. В норме ПМ раскидывает оценки на лидов и творчески суммирует их. В случае форс-мажора, если заказчик насилует его орально, вербально и пр. методами, как говорил один опытный чувак, оценивает сам, умножает оценку на два и добавляет период , т.е. если сначала показалось два дня, в итоге должно получиться за 4 недели :8)

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

«Разраб» оценивает свой конкретный кусок работы, но никак не проект (как стоит в вопросе) или спринт. Причем зеленого джуна, по моему мнению, сие не касается; за него и с ним вместе это делает таки лид. Далее, с рядового исполнителя оценку снимает его лид, интегрирует по всем подопечным и передает вышее, ПМу. В идеале риски разработки/тестировки/документирования/доставки уже должны быть заложены опять-таки соответствующим лидом (но это может быть и ПМ, если он допустим отвечает за деливери), чиста в силу его компетентности. ПМ (из практики) добавляет не столько вышеупомянутые риски, сколько учитывает циклы разработки (которые ессно не 100% и не 0% перекрываются) и почти всегда — риски «высокой политики» типа пожелания любимага клиента, бизнес-нужды и пр.

Например, я сейчас для своей команды оцениваю с разрабами, умножаю на 2 и прибавляю 20%.
Но это только по поводу естиммейтов :)

клиент, наверное, счастлив.

Та не, ему пофиг — лишь бы в срок.
А разрабы довольны — даже если всплывают проблемы, это не катастрофа.

Боже, как я хочу такую работу. Умножил на 2, прибавил 20 %. Пошел домой смотреть дурь типа интернов и вышивать крестиком.

я обобщила что бы подчеркнуть правоту ПМ из родительского комментария.
А такую работу как вы описываете — и я не прочь иметь )

То бишь у тебя работа в стиле выточить на токарном станке 10 более нименее одинаковых болванок за смену, на уровне токаря 3-его разряда?

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

а оплата — fixed price или Time&materials?

Зависит от проекта.
Например клиент покупает уже готовый продукт по фиксированный, а все доработки проходят по Time&materials.

А вы деталей больше дайте, какой проект, какой квалификации PM. Что значит,

эстимейтит
?

Типа сказал, что команда сделает его за 2123,58 человекочаса?

PM тому явно нехрен делать. А закончиться всё просто: народ от него будет сваливать и он сам за всех подчиненных и программировать будет. Ну и понятно все время будет в мыле, а через лет 5 такой работы у него крыша съедет.
Так что сразу советую тому PM уже сейчас подускивать себе психиатра на будущее.

Ну а тебе, как подчиненному не пофиг-ли? Будет сильно напрягать свалишь на другую контору с нормальным PM. Вероятность того, что свалишь близка к 1.

Будет сильно напрягать свалишь на другую контору с нормальным PM. Вероятность того, что свалишь близка к 1.
А потом будут хрюши не пропускать резюме, чуть только увидят, что работал где-то 3-5-8 месяцев. Так что лучше бежать чем скорее, тем лучше и не задерживаться.

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

Теперь в резюме пробел и все этим пробелом и шестимесячной записью мне мозг выносят.

Якщо це чорновий, попередній естімейт і у нього відповідний бекграунд, то ок. Якщо ні — то ок в якості розваги :)

та пусть естимейтит, а потом вкладывается в свои естимейты

Поддержку Антона, есть разные ПМы.
Если чувак вырос в ПМ с хардового разраба, то почему бы и нет?

тут другой случай, ПМ не был разрабом, но в случае даже если и был, скажем ios-dev’ом разве может он нормально провести эстимейт проекта скажем бекенда на NodeJS?

Ну тут практика такова:
1-ПМ может точно оценивать проект если имеет прошаренный тех. бекграунд конкретно по проекту.
2-ПМ может примерно оценивать проект если имеет статистическую базу в которой уже есть данные естиммейта практически идентичного проекта.
3-ПМ настолько гуру нострадамус и знает команду как облупленную и шарит, хоть и поверхностно, в коде.

По второму пункту. Даже если ПМ с овер н лет опыта, и у него были похожие проекты, он может только в голове прикинуть эстимейт, конечный и точный эстимейт всегда за разрабом, если проекты абсолютно одинаковые — нет никакой гарантии, что у них будет одинаковый эстимейт. В первом случае проект могли писать матерые синьйоры, а в другом случае новоиспеченные миддлы. Эстимейт, как анализ должен проводиться индивидуально под проект, нельзя гребсти все под одну гребенку и ставить похожие эстимейты по принципу конвейера.

А вы заметили формулировку?)

2-ПМ может примерно оценивать
Это раз :)
Два — тут идет речь о организованной статистической базе, с подробным описанием технологий, задач, команды, сроков, рисков и проблем.

В первом случае — если ПМ прошаренный, и как ПМ и как Тех. тогда он в принципе не может быть настолько днищем что бы для команды мидлов оценивать проект как для синьйоров )

конечный и точный эстимейт всегда за разрабом
«Точный эстимейт» это оксюморон, более того, «примерный эстимейт» тоже не имеет смысла: www.oxforddictionaries.com/...finition/english/estimate
Эстимейт, как анализ должен проводиться индивидуально под проект, нельзя гребсти все под одну гребенку и ставить похожие эстимейты по принципу конвейера.
Большая часть бизнеса именно так и делает: использует статистические данные. Причина лежит не в инженерии, а в суровых реалиях бизнеса. Вообще на эту тему есть великолепная книга www.amazon.com/...r-Practices/dp/0735605351 которая описывает ошибки со стороны бизнеса и разработчиков, объясняет что имели в виду одни и другие, рассказывает как правильно оценивать и т.п.

Есть ещё вариант «ПМ» пофиг, ему главное продать это всё заказчику на начальном этапе — дальше хоть трава не расти. Не попадание в естимейт «ПМ» ПМ потом свалит на команду, а с него взятки гладки.

Был у нас один персонаж — работал на предпродаже, давал эстимейты, приходил к команде (к незнакомой ему вообще) со словами «Данные мной эстимейты мы не обговариваем. Это реально, это жестко, но так надо, так работает». И ничего, вот уже много лет работает, растет по карьерной лестнице и неплохо так себя чувствует :)

Это неважно. Все люди разные и на одну задачу у каждого может уйти разное время по куче причин. Посему эстимэйт должен делать тот, кто будет реализовывать.
А вот если эта оценка кажется завышенной или заниженной — это требует обсуждения.

Хорошо, как ты будешь делать оценку, если заказчик потребует запилить ему цирк с конями? Или если на суппорт свалится чудо-проект без документации, подобный тому, который достался Бобру? Там ты ему, помнится, советовал всеми правдами и неправдами отбояриваться от оценивания именно по этой причине — если не уложишься в собственную оценку (а в подобных случаях, скажу честно, не знаю как оценивать), то тебя потом будут жестко обсуждать.

Именно отбрехиваться и буду, а точнее пошлю с таким проектом к индусам. Их много и они всегда говорят «Да».
А цирк с конями — таких заказчиков посылаю лесом в бодишопы. Там их на хорошие бабки опустят и отправят по итогу голеньким восвояси.

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

не, это значит что у вас плохой ПМ, либо ПМ совмещает в себе ТЛ, но тогда эстимейтит ТЛ

Или некомпетентная команда.. часто программисты бояться эстимейтить. Брать на себя эту ответственность )) кто-то же должен.

ПМ должен организовать процесс эстимации. в вашем случае это должен делать либо ТЛ вместе с дев-ом, либо здравствуй planning poker

есть разница между должен и как есть на самом деле )

ну как бы результат потом может быть очень плачевный и в этом будет вина ПМ, а не девов

Подписаться на комментарии