Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Затем руководство режет нам этот срок вдвое.
Как то безапелляционно… Вы считаете что везде такой дурдом?
Это не всегда дурдом, далеко не всегда идиотизм руководства и не всегда в два раза. Есть целый класс проектов, очень интересных проектов, в которых обстоятельства вынуждают вменяемых многоопытных руководителей идти на такие шаги или на несколько более мягкие шаги. С другой стороны, есть большое количество компаний, в которых такое случается крайне редко, и целый госсектор с его э… неторопливостью.
Оценка сроков и рисков — это не компетенция разработчиков. Есть метод FP, есть требования. Ну и есть логически обоснованные интересы: разработчику выгоднее взять срок с запасом, по этому нет смысла давать ему на оценку — должно быть две стороны. Т.е. должно быть разделение: оценивает сроки/риски один а делает другой. Точно так — делает один а тестирует другой.
В вашем случае, как вы сами написали, разработчик хоть и оценил, но с его оценкой все-равно не считаются. Так зачем же ему вообще тратить время на оценку, если с его оценкой не считаются? На тот случай, если ошибочно не учтет нюансов и сделает заниженную оценку — можно будет повесить всех собак?
Гораздо более интересный момент — оценка уже проделанной работы. Т.е. если сроки были сорваны и заняло больше времени — то как определить кто виноват — оценщик, который дал неверную оценку, или исполнитель, который работал слишком медленно?
Конечно, когда оценщик и исполнитель одно лицо — вопросов с «навешиванием собак» вроде бы не возникает. Но, с другой стороны, хороший исполнитель может быть плохим оценщиком. Т.е. работал быстро, но оценку изначально сделал ошибочную. Равно как и обратный вариант — изначально сделал оценку с большим запасом и потом работал по 2 часа в день, понимая что его труд никто не сможет оценить.
В вашем случае, как вы сами написали, разработчик хоть и оценил, но с его оценкой все-равно не считаются. Так зачем же ему вообще тратить время на оценку, если с его оценкой не считаются? На тот случай, если ошибочно не учтет нюансов и сделает заниженную оценку — можно будет повесить всех собак?
Гораздо более интересный момент — оценка уже проделанной работы. Т.е. если сроки были сорваны и заняло больше времени — то как определить кто виноват — оценщик, который дал неверную оценку, или исполнитель, который работал слишком медленно?
Конечно, когда оценщик и исполнитель одно лицо — вопросов с «навешиванием собак» вроде бы не возникает. Но, с другой стороны, хороший исполнитель может быть плохим оценщиком. Т.е. работал быстро, но оценку изначально сделал ошибочную. Равно как и обратный вариант — изначально сделал оценку с большим запасом и потом работал по 2 часа в день, понимая что его труд никто не сможет оценить.
Корень проблемы в том, что маленькие сроки социально ожидаемы, а называя большие как правило столкнёшся с неприятной реакцией спрашивающего. Это сдвигает оценку в меньшую сторону по чисто психологической причине, причём оценивающий этого может даже не осознавать. Иногда сроки принимают как есть, хотя всё равно видно реакцию. А иногда за сроки вообще ведутся торги, как будто можно родить ребёнка за 7 месяцев, а не за 9, если сильно постараться. Как правило это ведёт просто к урезанию функционала и «ребёнок» получается недоношеный, без руки/ноги и с багами. Часто реальные сроки и так понятны, но многие не хотят их видеть. По своей практике хорошо показал себя следующий подход, давать три оценки, оптимистичную, пессимистичную и наиболее вероятную. Если руководство завязывается на внешние контректы или маркетинговую активность — используем пессимистичную оценку. Если на план на неделю — наиболее вероятную. А если на мотивацию и чувство героизма — оптимистичную.
Особенностью данного способа подсчёта является известный факт: чем мельче дробить работы для оценки срока проекта, тем менее точной оказывается оценка. Хотя по теории должно быть ровно наоборот.
Немного странно считать известным фактом то, что детальная декомпозиция работ ухудшает точность итоговой оценки.
Вы правильно отметили, что теория (тот же PMBoK) рекомендует детальную декомпозицию для оценки, и исходя из своего опыта пары десятков проектов я соглашусь здесь с рекомендациями методологии.
Наоборот, когда в проекте есть участки, которые нельзя разбить на детальные задачи (к примеру, из-за нечетких требований, новой предметной/технологической области), начинается неточность в оценках затрат проекта.
Декомпозиция улучшает оценку только если эта декомпозиция качественная. А чтобы сделать качественную детальную декомпозицию нужно затратить достаточно много времени. Вот только зачастую на оценку проекта просто не выделяется достаточно времени, в результате декомпозиция делается «на глазок», отсюда и получается, что излишняя детальность при декомпозиции ведёт к ухудшению качества оценки.
Вообще, меня всегда поражало, когда менеджеры на полном серьезе считали что можно нормально оценить проект объём которого измеряется в человекогодах за день-два.
Вообще, меня всегда поражало, когда менеджеры на полном серьезе считали что можно нормально оценить проект объём которого измеряется в человекогодах за день-два.
менеджеры на полном серьезе считали что можно нормально оценить проект объём которого измеряется в человекогодах за день-два
Рассчет на то, что вам не хватит времени для учета всех нюансов, вы дадите заниженную оценку и потом можно будет перевесить на вас всех собак.
Анализ требований/декомпозиция/исследования занимают 15-20% от общего времени. За это время нужно разработать базовую архитектуру проекта, так как без нее оценка не возможна. Т.е. выделить основные сущности системы, разбить на модули/сервисы, определить контракты, рассмотреть существующие библиотеки (и предварительно проверить), выделить технически сложные части и т.д.
Если эту работу не проделать, то могут быть сюрпризы. К примеру, вы рассчитываете что некая сторонняя библиотека реализует нужный вам функционал, рассчитываете ее купить и сэкономить 2 недели времени. А оказывается что эта библиотека реализует не все что вам нужно, но на этапе планирования у вас не было времени это проверить.
В теории декомпозиция улучшает точность за счёт того, что у нас получается много слагаемых, много мелких оценок сроков, которые мы якобы можем более точно оценить. На практике же декомпозиция позволяет лучше понять состав работ и выявить подводные камни, а иногда и целые айсберги, а дальше идёт экспертная оценка по срокам не для каждой отдельной задачи, а для всего пула задач — и она при достаточном опыте обычно весьма точная.
Пример из личной практики. Когда-то у меня бывали небольшие проекты, в которых я, как ведущий разработчик, оценивал сроки разработки новой подсистемы, защищал их и потом сам же реализовывал. Месяцев на 3-5 работы. При этом при оценке сроков отдельных задач я прекрасно знал, как буду делать каждую из них — был богатый опыт. Зная теоретическое обоснование Брукса, хотелось сразу умножить сроки на три. Далее оценивал на взгляд весь объём работы — успею или нет в целом и за сколько — и умножал в зависимости от реалистичности получившейся оценки всего проекта в полтора-два раза. В итоге, еле вписывался в свои же сроки, но вписывался всегда. И это, замечу, идеальные условия для оценки: оценивает эксперт, который знает, как долго делается каждая задача, и сам же потом делает весь проект.
Пример из личной практики. Когда-то у меня бывали небольшие проекты, в которых я, как ведущий разработчик, оценивал сроки разработки новой подсистемы, защищал их и потом сам же реализовывал. Месяцев на 3-5 работы. При этом при оценке сроков отдельных задач я прекрасно знал, как буду делать каждую из них — был богатый опыт. Зная теоретическое обоснование Брукса, хотелось сразу умножить сроки на три. Далее оценивал на взгляд весь объём работы — успею или нет в целом и за сколько — и умножал в зависимости от реалистичности получившейся оценки всего проекта в полтора-два раза. В итоге, еле вписывался в свои же сроки, но вписывался всегда. И это, замечу, идеальные условия для оценки: оценивает эксперт, который знает, как долго делается каждая задача, и сам же потом делает весь проект.
При этом при оценке сроков отдельных задач я прекрасно знал, как буду делать каждую из них — был богатый опыт.
Опыт разработки и опыт оценки/рисков — это разное. Хороший исполнитель не всегда хороший оценщик, равно как и наоборот.
В итоге, еле вписывался в свои же сроки, но вписывался всегда.
Нужно учесть, что темп работы бывает разным. Мог успеть за счет полного истощения, так что после проекта еще несколько недель а то и месяцев — просто не сможешь полноценно работать.
Если ты заграл себя в психологичекую ловушку, т.е. подписался под сроками и взял все риски на себя — то вероятность выгореть — очень высока. По 12 часов в день будешь работать и т.д. Т.е. нельзя назвать это нормальной жизнью, потом будешь платить чем-то более дорогим (здоровьем).
Гораздо более интересен момент оценки уже проделанной работы — это база. Сразу можно сказать — была ли плановая оценка верной, соответствует ли ей проделанная работа. Но, как правило, никто не обладает такой компетентностью. Все только привыкли «играть в карты», торговаться и пр. — не обладая реальной тех. компетентностью.
Немного странно считать известным фактом то, что детальная декомпозиция работ ухудшает точность итоговой оценки.
Сколько времени вам нужно на оценку проекта, который будете делать в течение 3-х месяцев? Считается что на детальный анализ — нжуно около 20% времени. Т.е. если проект примерно на 3 мес., то 13 раб. дней уйдет на детальный анализ требований и декомпозицию.
Если же на работу, которая должна занимать 2 недели, вам в приказном порядке выделят 1 день или, хуже того, 4 часа — то это явная манипуляция и попытка перевесить собак на исполнителя за неверную оценку. Рассчет на то, что вы не учтете многих нюансов.
Гораздо более интересен вопрос оценки уже проделанной работы. Да, оценить то что еще не сделано — сложно, ведь многого не видно. Но вот когда выясняется, что оценить уже сделанную работу не могут — вот тут и проявляется некомпетентность в чистом виде.
В материале есть несколько неозвученных допущений. В частности, нет ничего про изменение требований. На практике не встречал ни одного проекта, чтобы заказчик не менял требований. А это уже работа по управлению изменениями, что делает задачу нелинейной. Так же просматривается допущение, что мы как-то можем влиять на сроки проекта. Вероятно, в продуктовом мире это так и есть, но в деливери-мире после заключения контракта сроки проекта уже зафиксированы, и всё, чем мы можем управлять — это технологии и команда. И тут остаётся только верить, что на этапе оценки были учтены все риски, а руководитель проекта грамотно разрулит все запросы на изменения.
Хочу сказать спасибо автору за статью. К сожалению срок голосования прошел. Все правильно стандартная Гауссиана для оценки вероятности в прогнозировании проектов не подходит и это обосновывает то, что при прогнозировании люди интуитивно закладывают значительно больше подстраховки, чем надо. При декомпозиции на каждый отдельный элемент закладывается своя подстраховка. В результате суммарная подстраховка очень большая. При этом проекты чаще заканчиваются не в срок, чем в срок. Вопрос очень актуальный. Почитайте книгу «Критическая цепь» И.Голдратта. Там он раскрывает все нюансы и причинно следственные связи значительно глубже, и в принципе даются практические рецепты. Однако при большой степени неопределенности любые прогнозы не будут работать. Тут вопрос гибкости. Скрам отчасти их решает, но только отчасти и в ущерб эффективности. Очень большая тема. Еще раз автору спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оценка срока проекта. Почему она почти всегда сильно занижена и что с этим делать