8 методов, с которыми ты точно оценишь срок проекта


Оглавление (нажмите, чтобы открыть):

МЕТОД «ТОЧНО В СРОК»

В последнее время в некоторых отраслях промышленности в производственном процессе все шире применяется так называемый метод управления товарно–материальными запасами по принципу точно в срок.

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

Таким образом, философия управления по методу JIT сосредотачивает специалистов на «протягивании» товарно–материальных запасов через производственный процесс «по мере надобности», а не на «проталкивании» их по принципу «по мере выпуска». Для такого подхода требуется очень точная информационная система в сфере производства товарно–материальных запасов, максимально эффективная закупочная система и система обработки запасов, а также предельно надежные поставщики. Конечно, запасы сырья, товаров и материалов в пути ни при каких условиях не могут достичь нулевого уровня, но, несмотря на это, понятие «точно в срок» представляет собой один из наиболее эффективных путей сокращения товарно–материальных запасов. Однако цель JIT не ограничена исключительно их сокращением, она состоит еще и в повышении производительности и гибкости производства, а также в улучшении качества выпускаемой продукции.

Факторы, определяющие метод «точно в срок»:

1.Концентрация по географическому принципу. Если предприятие–покупатель стремиться получать нужные детали по принципу «точно в срок», необходимо, чтобы перевозка грузов с завода–поставщика на завод–потребитель выполнялась за относительно короткое время: менее одного дня. Так, например, подавляющее большинство заводов–поставщиков японской компании Toyota расположено на расстоянии не более 60 миль от его предприятия.

2.Надежное качество. Компания–потребитель обязательно должна иметь уверенность в том, что получает от своих поставщиков только качественные материалы и товары. Японская концепция заключается в том, что каждый производственный процесс должен рассматривать последующий процесс как своего конечного клиента. Мероприятия по контролю качества направлены на контроль самого производственного процесса, а не на то, чтобы отсеивать брак в результате проверки качества.

3.Управляемая сеть поставщиков. Внедрению системы «точно в срок» способствует максимальное сокращение количества поставщиков и заключение с ними долговременных контрактов. Большинство японских автомобилестроительных компаний имеет не более 250 поставщиков комплектующих. Для сравнения скажем, что в компании GeneralMotorsCorp. только сборочное производство сотрудничает с 3500 поставщиками.

4.Управляемая транспортная система. Кратко выражаясь, основой для этого является создание надежных транзитных маршрутов между поставщиками и пользователями. Так, японские автомобилестроительные компании используют для доставки деталей только грузовые автомобили (свои или работающие по контракту). Поставки комплектующих от каждого поставщика осуществляются по несколько раз в день в соответствии с заранее составленным графиком.

5.Гибкость производства. На заводе процесс поставок должен «уметь» быстро реагировать и оперативно предоставлять участку–потребителю любые необходимые детали. В данном случае очень важным является возможность быстрой смены инструментов. Так, например, в Японии одно автоматическое прессовочное оборудование может быть заменено другим в течение 6 минут.

6.Небольшие партии поставок. Большинство автомобилестроительных японских компаний использующих систему «точно в срок», требуют, чтобы размер партии не превышал 10% от ежедневного расхода деталей или материалов. В идеале они стремятся достичь такого порядка, когда партия будет состоять из одной единицы продукции с тем, чтобы по мере сборки машины специально выпускалась и каждая деталь для нее.

7.Эффективная система приемки материалов и погрузочно–разгрузочных работ.Большинство японских компаний вообще отказалось от формальных операций по приемке. Все части заводов используются в качестве приемочных зон, и детали и комплектующие доставляются как можно ближе к месту назначения. Благодаря применению погрузочной техники особой конструкции японцы избавились от необходимости в специальных отстойниках для нее.

8.Настойчивое стремление управляющего персонала к внедрению системы «точно в срок».Система «точно в срок» должна охватывать все подразделения завода. Управленческий персонал отвечает за обеспечение компании ресурсами, необходимыми для эффективного использования этой системы. Он должен твердо придерживаться намеченной цели в период перехода к системе «точно в срок», который нередко бывает довольно сложным и длительным.

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

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

Метод красной линии.Одна из крупнейших систем контроля называется методом красной линии (red–linemethod) и заключается в том, что внутри ящика, в котором хранятся запасы, проводится красная линия. Когда запасы израсходовали до этой линии, т. е. она стала видна, размещается заказ на новую партию.

Метод двух ящиков.Другой пример – метод двух ящиков (бункеров) (two–binmethod). B данном случае, запасы хранятся сразу в двух ящиках. Сначала материалы расходуются из первого, а когда он становится пустым, размещается заказ на новую партию и материалы начинают брать из второго ящика. Эти методы основаны на практических наблюдениях и применимы в производстве, связанном с большим количеством мелких деталей, а также в ремонтных мастерских.

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

Однако, чтобы модель оптимального размера заказа работала, необходимо соблюдение следующих допущений:

1. объём продаж должен быть идеально спрогнозирован;

2. продажи равномерно распределяется в течение всего года;

Оценка сроков

Самая сложная и неприятная часть планирования — оценка сроков выполнения проекта. Дать точную оценку сложно, и большинство из нас справляются с этой задачей плохо. В данном случае необходимо осознать, что, как бы ни были хороши точные оценки, все же не стоит стремиться к совершенству. Неточности неизбежны, поскольку речь идет о прогнозе на будущее. Стремясь к совершенству, вы потратите на оценку больше времени, чем на все остальные задачи вашего проекта. Оценка — не только наука, но и искусство, которое приходит с опытом. Если у вас уже есть опыт ведения проектов, вам будет проще оценить сроки.

Теперь необходимо уточнить, что, собственно, вы рассматриваете. Вам надо оценить трудоемкость решения задачи, а не срок, в который вы рассчитываете ее завершить. Небольшое, но важное различие. В первом случае речь идет о времени, которое уйдет на выполнение задачи, во втором — о времени, за которое можно ее выполнить. Скажем, чтение отчета может занять час, но если вы начнете читать, затем отложите работу и в течение 4-5 часов станете заниматься чем-то другим, а потом вернетесь к чтению, то общее время, которое уйдет у вас на эту работу, составит пять или шесть часов. Но при планировании важно знать только то время, которое уйдет на чтение, — это один час. Удобство планирования в том, что продолжительность проекта становится ясна, как только вы рассмотрите последовательность действий, которые необходимо выполнить.

Также обратите внимание, что оценивать нужно время, которое обычно уходит на решение задачи. А в какие сроки это реально можно сделать? В зависимости от условий решение разных задач потребует разного времени. Например, в среднем вы тратите на чтение книги не более двух дней. При этом одну книгу вы прочтете за полдня, а на чтение другой может уйти и все четыре. Но если я спрошу у вас, сколько времени вам надо, чтобы прочитать сотню книг, вы, скорее всего, назовете срок в диапазоне от 50 до 400 дней. При планировании обычно исходят из среднего варианта (два дня на книгу), т. е. 100 книг за 200 дней. Но вдруг вы не уложитесь в срок? Такой риск существует, но эта проблема решается при помощи резервирования, о чем мы поговорим позже. На самом деле люди склонны называть максимальные сроки решения той или иной задачи. Но в этом случае сроки окажутся слишком растянутыми, и, скорее всего, вы выполните проект быстрее.

В чем будут выражаться ваши оценки, зависит от масштаба проекта. Речь может идти о часах, днях, неделях, месяцах или годах. Единицами измерения могут выступать также человеко-часы, человеко-дни, че- ловеко-недели, человеко-месяцы и т.д., где человекочас — это объем работ, который может выполнить за час один человек, а человеко-неделя — соответственно объем работ, выполняемый за неделю, и т.д. На самом деле для проектов любого масштаба обычно достаточно оценки в человеко-днях. Оценка в человеко-часах, как правило, лишь создает видимость точности, а реально означает, что вы, скорее всего, злоупотребляете деталями при декомпозиции задач. Даже при крупных проектах речь может идти только о человеко-неделях или о человеко-месяцах. Однако человеко-годы, как правило, свидетельствуют о недостаточном планировании!

Что делать, если вы не знаете, сколько времени нужно на решение той или иной задачи? Существует много способов это выяснить, но, по сути, все они сводятся к пяти вариантам:

  • 1. Узнайте у того, кто знает. Это — оптимальный вариант. Опыт, как известно, самая лучшая основа для оценки.
  • 2. Сделайте приблизительные расчеты. Например, если на установку компьютера на рабочем столе уходит в среднем 1 час 15 минут, один работник, по-видимому, сможет установить за день 6 машин. Тогда установка 100 компьютеров займет у него примерно 17 рабочих дней.
  • 3. Выполните расчеты по аналогии. Если вы не знаете никого, кто делал такие расчеты, подумайте, не приходилось ли вам самому выполнять нечто похожее? Сколько времени это заняло?
  • 4. Разбейте задачу на более мелкие, срок выполнения которых вы сможете оценить. Такой подход уместен, если более подробная разбивка помогает внести ясность. Однако если по завершении декомпозиции у вас получается серия мелких задач, выполняемых за час-два, то вы явно переусердствовали. Конечно, дробя задачу на более мелкие, вы, как правило, упрощаете оценку. Тем не менее оценка десяти мелких задач по определению не может быть точнее оценки одной большой!
  • 5. Прикиньте, сколько времени вам может понадобиться. На данном этапе вы просто предполагаете, сколько времени вам понадобится на решение конкретной задачи. Если ничего другого не остается, придется воспользоваться этим вариантом.

Расписав все свои действия и оценив сроки, вы получаете черновой вариант плана. Но что делать, если вы опасаетесь, что ошиблись в подсчетах, и считаете, что в действительности все пойдет совершенно иначе? В таких случаях оставляют некий резерв средств и времени, на которые можно рассчитывать в самом крайнем случае. Величина резерва зависит от уровня риска вашего проекта и опыта решения подобных задач. Для проектов с низким уровнем риска обычно достаточно 10%-ного резерва времени и средств. Для проектов с большим уровнем риска желательно заложить 20-25%-ный резерв, а для очень рискованных проектов, требующих выполнения совершенно не известных вам задач, — резерв может даже превышать 50%. Замечу, что подобную предусмотрительность не следует считать признаком некачественного планирования. Скорее, это характеризует вас с лучшей стороны. Хороший менеджер проектов знает, что не может абсолютно точно предсказать будущее, особенно в условиях высокого риска.

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

Как оценить задачу в проектном менеджменте и не ударить в грязь лицом?

Идеолог качества, экономист Джозеф Джуран подчеркивал, что 85% проблем качества в компаниях происходит из-за системы менеджмента, и только 15% — по вине исполнителей. Другой американский ученый, Эдвард Деминг утверждал, что менеджеры ответственны за 96% факапов, а исполнители — лишь за 4%. Получается, что в большинстве проблем виноват менеджмент.

Улучшить неутешительную статистику помогает правильная оценка проектов. Один из трендов на западном рынке, который постепенно становится все более популярным и в наших IT-компаниях — оценка задач в Story Points. Вместе с Agile Project Manager Юрием Кукой разбирались в методах оценки проектов и принципах работы в Story Points.

Динамика за пять лет показывает, что из всех проектов успешны только 30%. Остальные 70% либо остаются незаконченными, либо же на выходе не соответствуют ожиданиям заказчика.

Основной причиной факапов является то, что команда неправильно оценила свои усилия, соответственно, не вложилась в дедлайн и бюджет. Предсказать будущее невозможно, но основываясь на своем опыте и исторических данных (yesterday weather), ты можешь дать определенную экспертную оценку (forecasting), которая поможет избежать провалов.

Какие бывают методы оценки задач?

Существует пять методов оценки: экспертная, сравнительная, параметрическая, оценка по трем точкам и оценка “снизу-вверх”. Важно уметь комбинировать их в зависимости от ситуации.

На графике мы видим две шкалы. Первая показывает, насколько оценка быстрая и “грязная”, вторая — насколько ожидание соответствует реальности.

1) Экспертная оценка


Самая быстрая и неточная. Мы собираемся командой и спрашиваем специалиста в определенной области: “Сколько времени займет данный проект?”. Он отвечает, например: “Месяц” или “Полгода”. На основе полученной информации мы строим графики и road maps. Экспертная оценка позволяет получить грубый эстимейт (от — 25 до +75), но давать прогноз заказчику на его основе не стоит.

2) Оценка по трем точкам

Более точная и сложная. Вычисляется по формуле. Наиболее вероятную оценку реализации проекта умножаем на 4, складываем с оптимистической и пессимистической оценкой. Полученный результат делим на 6. Далее определяем коэффициент отклонения: вычитаем из пессимистической оценки оптимистическую и делим на 6.

Что такое оптимистическая и пессимистическая оценки? Рассмотрим на примере твоей дороги на работу. Оптимистическая оценка: если все светофоры будут гореть зеленым, ты доберешься до офиса за 20 минут, наиболее вероятная — 30 минут, пессимистичная — если в городе пробки, произошло ДТП или перекрыто движение — 50 минут. По вышеуказанной формуле получаем среднее значение — 31,6 минут и коэффициент отклонения — 5 минут. Таким образом, с вероятностью 68% ты приедешь на работу в диапазоне 31,6 ± 5 минут. Если умножить коэффициент отклонения на 2, то вероятность попадания — уже 95,4%, но и диапазон увеличивается и теперь составляет 31,6 ± 10 минут.

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

3) Сравнительная оценка

Разберем на примере. Допустим, ты находишься на последней станции красной ветки киевского метро “Академгородок”. Тебе звонит друг и спрашивает: “Через сколько ты будешь на Крещатике?” Но ты не частый гость в Киеве, поэтому твоя экспертная оценка будет размытой: “Через 1 час”. Но проехав одну станцию, ты узнаешь, что отрезок из пункта «А» в пункт «Б» поезд преодолевает за 4-5 минут. Соответственно, если перед тобой еще 9 таких отрезков, с учетом своего прошлого опыта ты сможешь дать более точную оценку: дорога займет 45 минут, а не час.

4) Параметрическая оценка

Распространена в строительстве. Допустим, ты делаешь ремонт на кухне и хочешь постелить линолеум. Ты знаешь площадь пола и размер линолеума, который нужно купить, стоимость услуг мастера и т.д. Соответственно, заложив определенные риски (кусок линолеума, например, может порваться), можешь рассчитать точную оценку стоимости укладки линолеума на кухне. Формула простая — разделить объем работы на производительность.

Однако в IT объем работ постоянно меняется, потому что нельзя предвидеть все нюансы. Производительность разработчика определить также практически невозможно из-за меняющейся эффективности работы (час работы в понедельник утром не равен часу работы в пятницу вечером) и внешних факторов (не выспался, перепил, заболела кошка и т.п.). Получается, что мы одно неизвестное делим на другое, добавляем к результату 20% рисков и продаем заказчику. Так оценивать задачи крайне не рекомендуется.

Самый точный и ресурсозатратный метод. Смысл в том, чтобы разбить крупные задачи на мелкие. К нам зашел проект, структурно в нем должен быть frontend, backend, веб-админка для администрации проекта. Дальше разбиваем front на главную страницу, регистрацию, back office. Разбиваем регистрацию: по e-mail, по телефону, по соцсетям. В задачах есть front, back, тестирование. Прорабатываем эту цепочку и оцениваем задачи, начиная от самой мелкой, постепенно двигаясь вверх. В конце все суммируем и получаем определенный эстимейт.

Почему оценка в часах не работает?

Оценивать задачи можно в следующих единицах:

  • время (часы, деньги, недели, месяцы);
  • деньги (доллары, евро, гривны, рубли и т.д.);
  • Story Points.

Оценка в часах, как правило, необъективна и не учитывает эффективные часы работы. В такую оценку не закладывают:

  • социальные сети;
  • звонки по телефону;
  • перекуры, кофе;
  • общение с коллегами;
  • походы в туалет;
  • прокрастинацию.

Реально из 8-часового рабочего дня эффективно человек работает 4-5 часов. Таким образом, из 720 доступных в спринте часов, реальное capacity (количество идеальных часов, доступное в следующем спринте) составляет 504 часа, при этом 216 часов являются неэффективными. Исходя из среднего рейта 10 долларов в час, 216 часов — это 2160 потерянных долларов за спринт, либо 4320 потерянных долларов в месяц.

Таким образом, становится ясно, что оценка в часах — лживая.

Мастер Йода рекомендует:  Запускается WhatsApp Business — приложение для общения компаний с клиентами

Как оценивать в Story Points?

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

Большинство из озвученных проблем решает сравнительная оценка Story Points, которая показывает “размер” задач относительно друг друга и помогает команде планировать на долгосрочную перспективу. Такой метод позволяет достаточно точно оценить задачу.

Story Points — эфемерная оценка (оценка в “попугаях”), которая не имеет физических единиц измерения. 1 SP — это оценка потраченных усилий всей команды (разработчики, верстальщики, QA) на реализацию самой простой задачи (выход на live). Оценивается не длительность задачи, а ее размер относительно другой.

Оценка в Story Points будет эффективной, если будут выполнены следующие условия:

  • состав команды не меняется;
  • один и тот же продукт;
  • velocity (средняя скорость команды, количество закрытых SP за спринт);
  • задачи выполняются только в спринте;
  • крупные задачи декомпозируются на мелкие;
  • оценивает вся команда и все задачи;
  • задачи сравниваются между собой.

Что используют для оценки в SP?

Чаще всего для оценки в Story Points используют шкалу Фибоначчи (правда, с некоторой корректировкой), в которой значение числа равняется сумме двух предыдущих.

Вторая по популярности — оценка задач в трех осях (объем, риски, сложность). Объем задачи — время, которое уйдет на ее реализацию. Иногда бывает что задача достаточно объемная, но по сложности очень легкая и тривиальная. Бывает наоборот — задача небольшая, но сложная, требующая анализа и несущая определенные риски.

Соответственно, по этим критериям формируется табличка по задачи для каждого отдела (разработчики, дизайнеры, QA). Оценивать объем, сложность и риски можно от 1 до 3, либо от 1 до 5. Команды голосуют по этим критерии, суммируют и определяют “вес” задачи в Story Points.

Некоторые команды используют другой подход — оценку задач в футболках. Самая простая и маленькая задача команды обозначается размером XS. Относительно этой задачи сравниваются все последующие (S, M, L, XL, XXL). Соответственно, так команда может планировать, сколько больших, средних и крупных задач может сделать за спринт.

Аналогичная оценка — оценка в буквах (A, B, C, D, E), где A — самая мелкая задача, E — самая крупная.

Как определить скорость своей команды?

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

Зная динамику своей команды, ты можешь рассчитать, сколько SP она выполняет за спринт (например, 100 SP) с учетом прокрастинации и других внешних факторов. Корректно брать усредненное значение по последним пяти спринтам.

На графике ниже мы можем увидеть, что гарантированная динамика команды на протяжении девяти спринтов составляла 9-10 SP. Не гарантированная при благоприятных обстоятельствах — 12-15 SP. Если повезет — 20-30 SP. Эти метрики нужно снимать и анализировать.

Стоит учитывать, что Velocity одной команды не равно Velocity другой. Если одна команда закрывает 100 SP, а другая — 1000 SP, это не значит, что первая работает хуже. Каждая команда берет за эталон свою конкретную задачу, поэтому сравнивать эти значения между собой некорректно.

Как переходят на SP?


С точки зрения японской философии Кайдзен, переходить на SP нужно плавно. Вначале давать оценку задачам в часах, потом начать дополнительно оценивать в SP Через три спринта, собрав статистику и рассчитав velocity, начать отказывать от часов в пользу SP.

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

8 методов, с которыми ты точно оценишь срок проекта

Всем привет. Меня зовут Владимир Завертайлов, я — руководитель студии интернет-решений «Сибирикс».

Часто ли вам приходится отвечать на вопрос «Сколько стоит сайт?»? Как много наводящих вопросов вы задаете, чтобы прийти к какой-то сумме и озвучить ее? Нужно ли ее озвучивать, если не ясны детали ТЗ? Что делать с потоком заявок — оценивать каждое ТЗ индивидуально или использовать шаблонные оценки? Довольны ли разработчики заложенными сроками, а клиенты — суммой бюджета?

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

Сегодня, при возросшем объеме заявок, трудозатраты на оценки составляют около 20 минут в день, причем большую часть из них делают менеджеры проектов (не технические специалисты), при этом точность значительно выросла. И сегодня я бы хотел рассказать о простых и эффективных методах, которые мы применяем каждый день:

1. Самый простой и правильный способ сделать оценку — это не делать ее. Звучит странно? — Но работает. Нужно напрямую выяснить бюджет проекта у клиента.

Почему это может сработать?

Во-первых, у клиента все равно есть бюджет, который он планирует потратить. Слишком сильно он не станет за него заходить при любом раскладе.

Во-вторых, при этом может оказаться, что бюджет у клиента значительно ниже того, что вы обычно берете за такого рода проекты. Тут нам на помощь приходит всем известный принцип Парето — 80/20. Суть в том, что основные полезные, нужные и приносящие прибыль функции проекта составляют, как правило, около 20% (правда, есть лидер по невостребованным функциям — программа MS Excel, где постоянно используется около 4%). Зная этот принцип, вы должны обсудить бизнес клиента, помочь ему определить, какие функции для него будут ключевым и принесут максимальную отдачу, и при этом вам, скорее всего, удастся вписаться в бюджет.

Почему это может не сработать? По разным причинам. Довольно распространенная — клиент просто мониторит рынок и ищет самую низкую цену (у вас когда-нибудь просили сделать скидку от цены, которую вы назвали как “ОТ”, и причем с потолка?).

2. Второй способ подойдет для быстрой, но неточной оценки толстых фолиантов ТЗ или какой-то рутинной работы. В качестве метрики будет использоваться. ScrollBar. В чем смысл? — Допустим, вам прислали материалы для набивки каталога товаров, несколько сотен листов в Word и пачку неотсортированных фотографий. С ходу понять, сколько займет времени вбить этот каталог, довольно сложно. Берем, начинаем вносить товары, и замеряем время. Вбили несколько штук — по тому, как сместился scroll-бар в документе, примерно видим наш прогресс (в процентах). Дальше — дело техники, перемножить два числа.

В случаях с оценками ТЗ — вы берете и выборочно оцениваете пару страниц, умножаете на количество страниц, коэффициент вашей невезучести и коэффициент корпоративной жадности. Все, оценка готова. Прекрасно работает на больших, детальных, однородных ТЗ, которые нужно оценить быстро. Иногда дает серьезные сбои, если где-то на предпоследней странице через запятую перечислены десятки модулей без детализации. Упс.

3. Третий способ подойдет для быстрой оценки коротких ТЗ, в которых просто перечислены основные функции. Все просто: надо представить каждую функцию проекта, как она будет работать, и одеть на нее «майку» размера S, M, ну или L.

Таким образом сразу наглядно виден ее приблизительный «вес». Тут нет нужды в точности (не нужно одевать полмайки или четверть майки). Сколько каждая маечка будет занимать часов — это уже дело опыта оценщика. Оценки будут заведомо не очень точные. Зато очень быстро можно сделать предварительную оценку для очень большого списка функций.

4. Очень хороший способ сделать оценку — “Planning Poker”. Команда, которая будет работать непосредственно над проектом, собирается вместе и начинает обсуждать каждую фичу проекта. Каждому члену команды выдается набор из 13 карт разного номинала. После того как ведущий объяснил, как должна работать конкретная фича, все члены команды должны положить карты со своими оценками рубашкой вверх. После этого карты вскрываются.

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

Цифры на картах , в зависимости от обстоятельств, могут означать часы, дни или «Story point». При оценке в «Story point» мы выбираем самую маленькую фичу в проекте и считаем ее эталоном. Все остальные фичи оцениваются относительно выбранной.

В колоде кроме цифр есть специальные карты — “перерыв на кофе/пиво“, “. ” (используется новыми разработчиками, которые затрудняются дать оценку), “0” (если фича готова или делается за минуту).

Процесс довольно длительный, занимает час-два или больше, в зависимости от опыта команды и объема проекта. Идеально подходит для крупных проектов, в которых команда работает по scrum и набирает себе задач на ближайшие две-четыре недели (спринт). Дополнительный плюс — проект и детали реализации становятся понятны всем, а за сделанные оценки появляется чувство ответственности.

Я рекомендую всегда делать оценки сроков по всем проектам, неважно, по внутренним проектам студии или проектам для заказчика — какими бы маленькими они не казались. (Зачем? про это можно почитать и посмотреть в нашем блоге или погуглить по запросу “Закон Паркинсона”).

Мы применяем все четыре способа (не оцениваем, скролл-бар, майки и покер — в зависимости от ситуации), и они дают прекрасные результаты. С опытом команды скорость и точность выполнения оценок возрастают. Надеюсь, эти способы помогут и вам.

7 трюков для тех, кто хочет принять верное решение

Ребята, мы вкладываем душу в AdMe.ru. Cпасибо за то,
что открываете эту красоту. Спасибо за вдохновение и мурашки.
Присоединяйтесь к нам в Facebook и ВКонтакте

Легко определиться с выбором, когда один из вариантов очевидно лучше / выгоднее / перспективнее. И мучительно сложно, когда на чашах весов представлены равноценные альтернативы.

AdMe.ru попробует вернуть вам здоровый сон и душевное спокойствие. Предлагаем вашему вниманию 7 способов выйти из ступора и принять правильное решение.

1. Дать совет другу

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

Такой прием помогает отбросить эмоции, которые затуманили ваш разум в муках выбора, и более трезво взглянуть на суть вопроса.

2. Отключить информационный шум

Нам кажется, что чем большим количеством сведений мы располагаем, тем объективнее способны оценить ситуацию. Однако бесконечный информационный поток только усиливает напряжение и запутывает наш мозг. Мы начинаем придавать излишнюю важность незначительным фактам и упускаем из вида существенное.

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

3. Отрицать очевидное

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

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

4. Взять у себя интервью

Прежде чем окончательно определиться с решением, задайте себе 3 вопроса и отвечайте на каждый в течение 10 минут. Итак, если вы пойдете по выбранному пути, то:

  • Как вы будете себя чувствовать через 10 дней?
  • Как вы будете себя чувствовать через 10 месяцев?
  • Как вы будете себя чувствовать через 10 лет?


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

5. Поиграть в эпитеты

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

А теперь попробуйте употребить эти описания по отношению к себе. Какое подходит вам больше? Это крайне важно: делая любой выбор, вы всегда в той или иной степени определяете свое будущее.

4 метода для оценки затрат проекта

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

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

Методы оценки проекта

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

Затем уже можно браться за оценку. Она важна не только для определения стоимости, но и для других параметров, к примеру, для определения даты завершения. Описанные приемы могут применяться в любой методологии, будь это Каскадная модель (ее еще называют модель «Водопад» — калька с английского названия Waterfall model), либо же Гибкая методология (англ. Agile).

Ниже приведены 4 метода оценки. Менеджерам их желательно знать так же, как и советы для управления проектами.

1. Метод по аналогу

На английском он называется Analogous estimate. Метод используется в случаях, когда о проекте недостаточно информации или документации.

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

Пример

Есть задача – разработать 5 новых маркетинговых посадочных страниц. Ваша команда уже имела дела с похожими задачами, и заняло это у них 5 рабочих дней. Соответственно, вы берете такое же количество дней и для оценки новых задач. Поэтому, если у вас в разработке 10 лэндингов, умножайте 5 дней на 2 и получайте 10 рабочих дней на задачу, и т.д.

Преимущества: быстрый подсчет; не требуется много документации.

Недостатки: не точная оценка по сравнению с другими методами.

Точность: наиболее низкая.

2. Параметрическая оценка

На английском – Parametric estimate. По своей сути этот метод очень похож на предыдущий. Но в некоторых случаях он дает больше точности за счет того, что весь проект разбивается на части. В свою очередь определяются непосредственно влияющие на проект части, которые можно измерить.

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

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

Пример

Опять возвратимся к примеру с лэндингами. Чтобы провести оценку проекта, необходимо найти схожие. Ищем, к примеру, в интернете и находим, что с большего разработка одного подобного лэндинга требует 10 часов. Нам же нужно разработать 5. Поэтому умножаем 10 на 5 и получаем 50 часов.

Преимущества: быстрый подсчет; возможен быстрый поиск информации.

Недостатки: невысокая точность (но выше, чем в случае с первым методом).

Точность: выше, чем у метода по аналогу.

3. Оценка по 3 пунктам

На английском этот метод называется 3-point estimate. Так же можно встретить Project Evaluation and Review Technique, сокращенно PERT.

Здесь, так же как и в следующей технике, используется структура декомпозиции работ (Work Breakdown Structure), что подразумевает разбивку на более мелкие задачи. Менеджер и его команда затем их оценивают и определяют риски.

Почему в названии упоминаются 3 пункта? Так происходит оценка. Есть лучший ход событий, который называется оптимистичный (назовем сокращенно О), наиболее вероятный (М) и худший – пессимистичный (Р). Очевидно, что М имеет наибольший вес.

Не углубляясь в детали, отметим, что оценку можно производить по 3 формулам.

Самая простая: (О+М+З)/3

Более точная: (О+4M+P)/6

Показывающая стандартные отклонения: (Р-О)/6.

Пример

На примере лэндинга покажем наиболее простой вариант событий. Итак, чтобы разработать посадочные страницы по оптимистичному сценарию (О), нам надо 40 часов. По наиболее вероятному (М) – 45. Пессимистичный сценарий дает нам 55 часов.


По расчетам второй формулы получается (40+4*45+55)/6 = 46 часов.

Преимущества: считается одной из наиболее точных техник; позволяет убрать из оценки наиболее оптимистичные и наиболее длительные по времени сценарии.

Недостатки: требует много времени для оценки задач по трем параметрам.

Точность: очень близко к наивысшей точке.

4. Метод снизу-вверх

На английском он называется Bottom-up estimate. При оценке применяется Иерархическая структура работ (упомянутая выше Work Breakdown structure, Структура декомпозиции работ). Здесь проект или задача разбиваются на более мелкие задачи до тех пор, пока не появится возможность оценивать каждую в отдельности.

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

Метод требует много времени, но дает наиболее точные результаты.

Пример

Снова наши лэндинги. Разбиваем весь процесс на меньшие части. Если не углубляться в детали, то для этого понадобится написать текст, разработать дизайн, интерфейс и другое. После этого следует суммировать оценку всех задач, что и даст оценку всего проекта.

Преимущества: наивысший уровень точности; разбивка на мелкие части позволит не упустить детали при оценке.

Недостатки: требуется наибольшее количество времени в сравнении с другими техниками.

Точность: наивысшая.

Много информации? Доверьтесь автоматическому планированию

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

К примеру, в сервисе GanttPRO включите функцию «Трудозатраты». После этого у вас в основном окне вашего плана появится еще один столбец, где вы в любой момент узнаете информацию по каждой задаче.

Подведем итог

Описанные выше методы широко применяются при оценке проекта. Для лучших результатов желательно владеть всеми техниками. Так же можно довериться инструментам для управления проектами.

Как правильно оценивать сроки проекта на примере веб-студии

В чем сложность

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

  • Разработка программ — это процесс интеллектуальной деятельности. Есть типовые задачи, которые уже делались раньше, оценить такие не составляет труда. Но есть и нестандартные задачи. У нас таких обычно 20-30% работ по проекту. Эти задачи невозможно оценить, потому что неизвестно сколько они займут времени и какие могут возникнуть проблемы при их разработке. Простой пример: попробуйте ответить на вопрос: «Сколько времени займет путь из Москвы до поселка Заполицы на автобусе? И сколько стоит такая поездка?». Вряд ли вы вообще были там раньше, поэтому для вас эта задача нестандартная, сходу и не скажешь сколько. С примером просто — позвонил на автовокзал, узнал цену и продолжительность поездки. Но даже здесь есть риск застрять в пробке. А заказчик будет звонить вам и трясти результат. И правильно сделает: пообещали — выполняйте.
  • Требования заказчика. Практически в любом проекте в ходе реализации меняют первоначальные требования. Заказчик мог что-то забыть или появились новые хотелки уже после старта проекта.
  • Еще одна проблема, вытекающая из того, что деятельность интеллектуальная — это квалификация разработчика. Профессионал может выполнить задачу в разы быстрее новичка.
Мастер Йода рекомендует:  Qiwi кошелек - регистрация и использование 1

Эти три причины я написал в порядке убывания их проблемности.

Как мы их устраняем

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

Следующие две проблемы посерьезнее. Начну со второй — меняющиеся требования заказчика.
Мы пользуемся двумя вариантами построения процессов разработки: Scrum и НЕScrum.

С нескрамом проще: с заказчика собираются требования, составляется ТЗ и смета, и начинается работа строго по ТЗ. Такой подход используем при разработке простых проектов: лендинги, корпоративные сайты.

Но все в ТЗ описать невозможно, поэтому в ходе проекта всегда образуются спорные вопросы. Например, это происходит там, где заказчик ожидал чего-то де-факто, а для нас это трудная (или долгая) задача и на нее требуется время. Портить отношения с заказчиком не хочется, поэтому приходится либо тратить время менеджера на обсуждение этой проблемы, либо тратить время программиста для решения задачи, либо тратить время менеджера + время программиста для придумывания альтернативной задачи и ее решения. В этом случае мы обычно выбираем вариант, который принесет наибольшую пользу бизнесу заказчика (ведь «хотелки» часто не имеют под собой серьезного обоснования, и, порой, даже вредят).

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

Как делается в скраме?

Для проекта составляется большой список задач — backlog. Он отсортирован по приоритетам, как хочет заказчик. Команда набирает себе задач из этого списка на 2 недели работы. После двух недель, заказчик получает полностью готовую и протестированную часть функционала. Но что самое интересное, если за эти две недели что-то у заказчика меняется, то он может спокойно выкинуть какую-нибудь из задач в проекте. Или поставить новую. Или поменять приоритет. Таким образом, в следующие две недели в работе будет то, что хотел заказчик. В этом и состоит гибкость. Есть одно НО: заказчик не может менять, убирать или добавлять задачи к тем, что уже в работе, т.е. в этих двух неделях.

Работа с заказчиком организована в трелло.

А работа команды организованна в youtrack’е.

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

Последняя проблема — оценка длительности нестандартных задач. К слову, стандартные задачи оцениваем по этой же методике. То, что я буду описывать — это часть скарама, оценка методом покер-планирования. Задачи по очереди берутся из Backlog’а. Оценку проводит вся проектная команда, члены которой, (внимание!) должны прийти к единому решению. Если хотя бы один из них не согласен, то обсуждение задачи будет продолжено. Оценивают в условных единицах, мы их называем story points (s.p.). Эти условные единицы представляют из себя часть последовательности Фибоначчи: 0,1,2,3,5,8,13,21. Задачи, оценка которых выше 21, обязательно разбиваются, чтобы избежать грубой оценки.

Сам процесс оценки проходит так: первым говорит тот, кто непосредственно реализует данную задачу: делали мы такое или нет, как это будет программироваться, где могут возникнуть проблемы, с какой вероятностью они возникнут — все, что может помочь при оценке сложности задачи. Затем высказываются остальные, задаются вопросы. У каждого есть 8 карт с числами Фибоначчи 0,1,2,3,5,8,13,21 (используется специальная колода карт). Когда все готовы голосовать, каждый выкладывает одну карту рубашкой вверх. Когда все карты выложены, они переворачиваются, и все видят оценки.

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

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

«Когда будет готово?»: как оценить время на выполнение сложных задач Материал редакции

Руководитель студии «Сибирикс» Владимир Завертайлов написал для vc.ru колонку о том, как давать оценку времени, которое нужно для выполнения сложных задач.


Большинство людей не умеют адекватно оценивать сроки выполнения задач. Порой это заставляет понервничать. Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.

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

Самый ненавистный вопрос

Выступая на десятках конференций, я часто спрашивал людей в зале: «На какой вопрос вы больше всего не любите отвечать?». И всегда ответом было: «Когда будет готово?!». Вопрос волнует и вызывает эмоции. Вот прямо сейчас подойдите к вашему коллеге и спросите его, когда будет готово. Знаете, что вы скорее всего услышите?

Нет, не обязательно вам укажут направление и пожелают доброй дороги. Все же кругом много культурных людей. Зато почти наверняка человек начнет рассказывать о своих проблемах. Понимаете? На вопрос «Когда?» — отвечают рассказом о проблемах. Так делает почти всё человечество.

Еще пример — для тех, кто помнит университетский курс программирования. Какой тип данных должна вернуть программа на запрос «Когда?». DataTime или что-то типа того. Человек же на это стабильно выбрасывает Exception. Да не один, а много, желательно с General Protection Fault. Это реально баг в прошивке практически всех людей.

Что за гадость такая? Почему люди так сильно не любят оценивать сроки? Ведь всё просто:

Длительность работ = Объем работ / Производительность

Неопределенность бьёт по башке

Корневая причина в том, что, оценивая объем работ, мы сталкиваемся с неопределенностью. Мы вынуждены предсказывать будущее — строить прогноз и нести за него ответственность. Начальники и клиенты требуют этого от нас, а мы — от своих подчиненных.

Но прогнозы нужны нам как опора. Как попытка отгородиться от неопределенности. Как попытка удовлетворить главное желание. И я не про секс, голод и сон, а про желание управлять реальностью. Каждый день. О, как велико в этот момент искушение спихнуть контакт с неопределенностью на другого.

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

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

«Судя по всему, даже Бог подчиняется принципу неопределённости, и не может одновременно знать положение и скорость частицы», — Стивен Хокинг.

Это вопрос философский, технического решения не имеет

Вернёмся к формуле. Она, в принципе, верная. Пакость в том, что ни числитель, ни знаменатель этой дроби не известны. Хотя бы потому, что:

  • Подпись заказчика (кровью) под техническим заданием не гарантирует, что документ описывает именно тот объем работ, который реально нужен. Она даже не гарантирует, что заказчик читал ТЗ. Реальный объем работ вы узнаете только после приёмки проекта.
  • Любая постановка задачи гарантированно содержит «дырки», которые можно трактовать двояко. Чем толще постановка — тем больше таких мест.
  • Производительность людей (особенно программистов) может отличаться в разы и зависит от столь большого числа факторов, что учесть влияние всех просто невозможно.

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

С определенной долей вероятности можно спрогнозировать дату завершения задачи или проекта, если:

  • у вас стабильная, сработавшаяся команда исполнителей;
  • работы выполняются для одного и того же клиента, который дает стабильную обратную связь (читай — генерирует прогнозируемое количество «правочек») и демонстрирует стабильные требования к качеству;
  • команда уже работала с подобными задачами;
  • рабочий процесс, технологический стек и окружающая среда — неизменны;
  • сам проект укладывается в головах команды;
  • устраивает оценка в относительных, а не в абсолютных величинах (никаких тебе рублей и часов!);
  • уже есть опыт работы в таких же условиях и данные, полученные в предыдущих итерациях; либо клиент готов работать итеративно и получать прогнозы, исходя из реальных замеров производительности предыдущих этапов.

Хуже всего дела обстоят у сэйлов, которые вынуждены делать вид, что все эти условия выполнены (хотя как раз наоборот). Но мы попробуем проникнуться этой галлюцинацией. В этом случае можно допустить, что вероятность завершения задачи к определенному сроку соответствует нормальному распределению Гаусса.

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

Итак, если возникает вопрос: «Какая там вероятность уложиться в оценку?» — можно ответить — «Нормальная» — и показать этот график.

Посередине колокола — наиболее вероятная трудоёмкость. Но поскольку мы работаем с величинами, подверженным случайностям — нам нужно делать допуск на величину рассеивания значений случайных величин (по-умному — среднеквадратичное отклонение или σ). Проблема в том, что если мы берем диапазон в +/- 1σ — вероятность, что мы уложимся в наш интервал оценки, всего 68%. В оставшейся трети случаев нас обвинят в некомпетентности и поставят в угол.

На величину 2σ — вероятность будет 95%, но сам интервал получится до неприличия большой. Тут уже ваш заказчик скажет: «Фу-фу, вы не можете мне сказать точные оценки, а конкуренты сказали. Вы — упыри. До свидания». Пять процентов — это не так то мало, если у вас много задач, и за срыв сроков по каждой из них мучительно бьют.

3σ — 99,7% вероятности попадания в нужный нам интервал. Если клиент спрашивает «К какому сроку вы гарантированно закончите проект» — ответ никогда будет математически правильный. Даже в этих синтетических условиях математика против вас.

Торги и манипуляции

К сожалению, для оценки задач Гауссово распределение использовать некорректно. Если компания аккуратно собирала данные по прогнозам и реальным срокам, скорее всего, график распределения вероятностей будет выглядеть примерно так:

Это больше похоже на распределение Пуассона (похоже, да не оно). От нормального распределения Гаусса отличается тем, что сначала какое-то время имеет значение 0, затем начинает расти (в этой точке оценки дают оптимисты), быстро доходит до пика (это точка, в которой дают оценки реалисты) и имеет длинный хвост справа (там сидят все факапы и сработавшие риски).

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

Для нас важно иметь возможность давать вилки на проекты с разбросом от реалистичной оценки до наиболее вероятной, например, 80%. А клиенту может быть интересна именно оптимистичная оценка. Но назвать её одну вы не можете, потому что не знаете, какие риски могут сработать с этим человеком. Поэтому сообщаете вилку.

Клиент может отреагировать на неё крайне резко (особенно если он — бывший программист). Ему не понятно, почему появилась вилка — задача ведь известна. Сказать клиенту в лоб, что «Вилка появилась потому, что мы еще не знаем, насколько ты адекватный» — конфликтный вариант. Проще объяснить, что вилка нужна для подстраховки.

Более веселые математические модели (PERT-анализ, логнормальное или устойчивое распределение) годятся только для изысканных понтов на конференциях. Но не особо помогают при общении с клиентом, который просит «не грузить этой фигней, а четко сказать, сколько стоит и когда будет».

Тем не менее, ознакомить своих сотрудников с азами этих моделей очень полезно. Ознакомить и попросить действовать адекватно, не грузить этой фигней и четко говорить, сколько стоит и когда будет готово.

Адекватная модель

Под адекватной моделью я понимаю такую, которая дает приемлемую для практической деятельности точность.

Я считаю, что нужно приучить людей жить с неопределенностью. Да, математика и бытие сильно против нас. Но нужно заставлять себя давать оценки с хорошей долей вероятности (скажем, 80% или 90% в зависимости от сферы), оставшиеся риски брать на себя. В случае, если они возникли — извиниться (перед клиентом), поулыбаться и замять конфликт или сделать профакапленное за свой счет (не уходя в отрицательную прибыль).


Про буферы, подстраховку и закон Мёрфи

Клиента нужно приучить к вилкам и к тому, что в них заложена подстраховка. Это не обман, а реальность. Мы можем быть уверенными только в одном: здесь работает закон Мёрфи. Если он бьёт часто, буферы должны быть больше. Проверить частоту Мёрфи можно итеративно.

Если клиент категоричен и не хочет видеть вилки — просто уберите нижнюю границу. Но важно не только закладывать адекватные буферы, но и пристально контролировать их расход.

Если буфер съеден на треть, а работа еще не готова — это повод начать экспедирование и проталкивание. В сфере веб-разработки мы используем burndown chart, чтобы визуализировать расход.

Экспедирование и проталкивание при отлаженных процессах должны занимать не более 5% всей работы. Если меньше — значит, у вас есть запас мощностей. Если больше — у вас проблема. На сложных проектных цепочках наибольший контроль должен быть на выявлении бутылочного горлышка проекта и контроле его питающих буферов.

Принципы адекватой оценки

Есть всего два способа делать оценки:

  • опираясь на свою картину мира в прошлом (свой опыт и исторические данные);
  • продлевая свою картину мира в будущее (экспертные оценки и интуиция).

На начальном этапе, когда человек еще не приучен давать точные оценки, ему надо рассказать, зачем они нужны. И не бить, если что-то пойдет не так — это вредно, т.к. будут перезакладывать, а потом сработает закон Паркинсона, затем закон Мёрфи и тенденция факапить и затягивать будет прогрессировать. Но бить, если исполнитель не проэскалировал при возникновении проблемы.

Задача руководителя — приучить оценивать свою работу. Не просто давать задачу и смотреть, как человек с криками «Бляха-муха!» бежит ее делать. А убедиться, что нужный объем работ проанализирован.

Опора на прошлое

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

Опора на прошлое имеет ряд недостатков, которые влияют на точность оценки.

1. Человек, делающий повторно одну и ту же (или очень похожую) операцию, начинает делать её быстрее.

С мастерством растет скорость. Поэтому нельзя сказать, что одна и та же задача у одного и того же человека займет одинаковое время.

К тому же, мы не в Японии и не в Германии. Мы — в России. А для нас характерно творческое отношение ко всему. В том числе к регламентам и правилам. Иногда это хорошо, но сильно вредит на конвейерном производстве.

Творческое отношение приводит к тому, что в какой-то момент делать однотипные вещи становится скучно. И, если мы вынуждены ими заниматься, пробуем делать их другим способом. А это значит, что качество работ и время, на них затраченное, изменятся. Возрастёт опасность ошибок и провала по срокам.

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

2. Мы склонны забывать детали, нюансы и мелочи тех операций, которые выполняем редко.

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

3. В противовес забывчивости в мелочах мы хорошо помним, если ранее больно получили за превышение сроков на похожей задаче.

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

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

Продление картины мира в будущее

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

Мастер Йода рекомендует:  Как создать фильтр результатов поиска в WordPress

Картина мира может быть неадекватной — тогда в процессе работы мы сталкиваемся с неожиданностями. Там, где мы не хотим разбираться в мелочах и вникать в детали, мы хотим просто закинуть много подстраховки. У программистов есть формула «Оцени, а затем умножь либо на π (3,14. ), либо на e (2,71. )». Немаленькие множители, да и разброс большой. Но в итоге факапим даже с ними. Всё дело в невнимательности к мелочам, лени разбираться или отсутствии адекватных ресурсов на изучение нюансов.

Да, оценка требует ресурсов, иногда — серьезных. Если задача новая, процесс оценки должен быть разбит на стадии.

  1. Постановка задачи, анализ и предварительная оценка (оценивается срок получения сроков).
  2. Фаза ресерча.
  3. Уточненная оценка, начало работы, фиксация оценки (именно после ресерча и небольшого куска реальной работы).
  4. Выполнение задания. Дальнейшее изменение оценки возможно только как форс-мажор или косяк, и должно происходить по принципу “уперся-сообщи». В длительных задачах — согласованные контрольные точки.

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

Секретные методики мира ИТ

В ИТ все сильно заморочены по поводу точности оценок, сроков и ресурсов. В других отраслях такой щепетильности не наблюдается. У ИТ-шников это возведено в культ. Впрочем, как и работа по фактически затраченному времени и фокусы с умножением на e и на π.

Многообразие методов говорит только о том, что ИТ-шники много думали, как решить проблему. Ниже — пара техник, которые помогают людям втянуться в оценки.

Абсолютные и относительные оценки

Человеку сложно оценивать абсолютные величины. А вот с относительным проблем меньше. Какой размер у Юпитера? Руками не показать, словами не описать — цифры слишком большие для понимания маленьким земным мозгом.

А теперь скажите, какой размер у Юпитера по сравнению с Землёй, используя аналогии. Здесь уже проще: Земля размером с горошину, а Юпитер — с арбуз. Земля носит маечку размера S, а Юпитер — XXXL.

Мозг лучше воспринимает относительные величины — используйте это в оценке задач. Одну большую разбейте на десяток поменьше и дайте оценку каждой в отдельности. Сравнивайте подзадачи между собой: какая носит футболку XS, а какая L? Футболки даже не обязательно переводить в часы — вы уже поймёте примерный объём работ.

В ИТ при правильно воспитанных заказчиках допустимо делать оценки задач не в абсолютных, а в относительных величинах. Новые задачи оцениваются относительно какой-то простой и всем известной. Кроме того, оценка в относительных величинах позволяет компенсировать естественные погрешности в самих оценках и в формулировках задач (так как на проекте количество корявых задач и кривых оценок будет примерно одинаковым от этапа к этапу).


К сожалению, автору неизвестно, применяется ли где либо еще на практике относительные оценки. Всем подавай точные сроки и деньги.

Planning Poker

Если маечки и прочие сравнения вам не подходят, переходите на Planning Poker. Это способ в игровой манере вытянуть из исполнителей все мелочи процесса и возможные проблемы. И в итоге получить оценку задачи, близкую к реальности. В колоде покера — карты с цифрами (вот это поворот!), которые обозначают часы: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

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

Если цифры одинаковые или немного различаются — записывайте в план общее арифметическое. Если есть значительная разница — уточните у отличившихся, почему они оценили задачу так. Кто-то не учёл длительную доставку деталей из другого города? Или забыл про инновационное ПО, которое установили на прошлой неделе? Всплывут новые подробности, и оценка станет точнее. Не давите, чтобы в сроки, которые вы получили в покере, всё было сделано — закон Мёрфи никто не отменял. На этот случай менеджер должен закладывать подстраховку.

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

Декомпозиция

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

Декомпозиции нужно обучать. Если рассматривать на примере ИТ — примерно так. Сначала берется готовый проект, который разбирается на составляющие — чтобы человек, который должен дать оценку, понял, в чём суть и что от него хотят.

Постепенно задача усложняется: для декомпозиции дается проект, в котором есть только прототип. Затем — стандартное техническое задание, потом — плохое и сложное ТЗ.

Человек должен научиться готовый цельный проект или ТЗ делить на этапы и составляющие. И каждому давать оценку. Когда научится — его оценки станут адекватными, приближенными к идеальному проценту вероятности и без необъяснимых буферов.

Как научить людей делать оценки

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

Если эти скилы уже есть, далее воспитывайте его по схеме:

  1. Покажите математические модели распределений и объясните, что слиться с оценок не получится.
  2. Расскажите, что понимается под адекватной оценкой, как она будет использоваться и почему вам нужна именно она. Расскажите, что вам нужна оценка без перезаложенных в 100500 раз подстраховок.
  3. Покажите, как строится планирование потока работ всей компании на основе этой оценки или как ее будет использовать ваш клиент. Не держите людей за идиотов — если им рассказать правду и реальные потребности, большинство из них будут стараться делать наиболее точные прогнозы.
  4. Приучите к принципам «уперся — сообщи» и «любая задача должна быть проанализирована и оценена».
  5. Заставьте оценивать людей все свои задачи самостоятельно.
  6. Дайте изучить статистику организации (сметы и реальные расходы по проектам).
  7. Приучите к принципу «не знаешь, что делать — декомпозируй». Дайте несколько проектов на декомпозицию. Проверяйте и ищите дыры и нестыковки. Долго и нудно беседуйте по поводу найденных нестыковок.
  8. Дайте оценивать реальные ТЗ. Проходитесь по итоговой оценке строчка за строчкой, спрашивайте, как пришел к ней. Проверяйте на полноту и непротиворечивость. Показывайте дыры в оценках, куда может улетать время.

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

Ошибка 404 — страница не найдена

Эксперт по управлению проектами, консультант, бизнес-тренер Консалтинговой группы «Здесь и Сейчас» Максим ЯКУБОВИЧ:

Начиная вести этот блог, я ставлю себе целью освещать лучшие практики в управлении проектами, про которые узнаю через свой опыт или от других профессионалов в управлении проектами.

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

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

Быстрая и точная оценка проекта

Быстрая оценка проекта — как фастфуд. Дешево, вредно, но порой необходимый атрибут профессиональной жизни.

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех).

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

В этой статье я не даю 100%-ный способ оценки любых проектов за пару минут. Я рассматриваю проекты средней длины — от полугода до года. И даю только первоначальную оценку проекта. Что-то, что вы можете предоставить вашему сейлз-менеджеру быстро, и не потерять при этом спокойный сон.

Требования к оценке проекта

Дядя Боб сделал замечательное видео об эффективных оценках. И он подчеркнул 3 главных качества хорошей оценки проекта:

Честность

Как можно измерить честность оценки? Честность — что это вообще значит?

Честность в первую очередь перед самим собой.

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

Прецизионность

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

Убедитесь, что ваши цифры не противоречат друг другу и не вызывают сомнений в вашем профессионализме и здравом уме. Страничка с контактами не может занять дольше, чем главная страница вашего сайта. Простой RESTFull сервис не должен занять больше, чем самообучаемый AI сервис аналитики.

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

Точность и условия оценивания проекта

Оценка сроков выполнения проекта должна быть точной. Это значит, что разница между предсказанным и реальным сроком выполнения проекта должна быть минимальной. Если вы говорите, что проект займет 3 месяца, то крайне желательно, чтобы это было 3 месяца. А не полгода. Или год.


И точность оценки — это очень крепкий орешек. В основном это вызвано:

  • Временным ограничением. У вас обычно очень мало времени на оценку проекта. Особенно если вы работаете напрямую с сейлз-командой. Этим ребятам нужно все и сразу. Без исключений.
  • Недостатком информации. У вас нет полной информации о списке функционала, целевой аудитории и т. д. Иногда все, что у вас есть, — это полпараграфа текста. А временами и исписанная вашим боссом салфетка из бара напротив. GoogleIT© может помочь. Но в основном вам придется работать в условиях крайне ограниченной информации о проекте.

А чтобы получить больше информации, вам нужно больше времени. Которого у вас нет.

Добавьте к этому следующее:

  • Точность оценки в зависимости от трудозатрат растет логарифмически.
  • Трудозатраты на повышение точности оценки проекта растут экспоненциально.

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

Вероятностная сущность оценки сроков проекта

Это приводит нас к вероятностной сущности оценки сроков проекта.

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

Оценка срока реализации проекта — величина вероятностная.

Честный, прецизионный и точный способ представления оценки проекта звучит примерно так: «Проект займет 6 недель с вероятностью успеха 95 %. Или он займет 4 недели с вероятностью уложиться в срок 65 %». Можно еще представлять оценку проекта в виде диапазона значений с учетом 95 % вероятности успеха: «Скорее всего, проект займет от 4 до 6 недель».

Единица измерений

Перед тем как идти дальше, давайте определимся с единицами измерений сроков проекта. Довольно часто используется человеко-день, то есть сколько дней один человек будет делать задачу.

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

Как следствие, в этой статье я буду использовать Average Working Day (AWD) как единицу измерения.

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

Вдобавок мы обычно не работаем в одиночку. Мы работаем в команде. И существует вековая проблема масштабирования команды согласно ожидаемого/желаемого срока разработки проекта. См. «9 женщин не могут родить ребенка за 1 месяц» и закон Брукса.

Но для простоты мы опустим эти детали и будем считать, что 2 человека могут справиться с задачей на 2 AWD за 1 день, 4 — за полдня и т. д.

Расчет диапазона срока выполнения проекта

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

Трехкратный метод

Идея проста: чтобы оценить проект, разбиваете его на задачи и даете оценку каждой задаче с помощью 3 величин:

  • B — best case (оптимистическая) оценка срока, 95 % вероятности не уложиться в срок.
  • N — nominal (номинальная) оценка срока, 50 % вероятности уложиться в срок.
  • W — worst case (пессимистическая) оценка срока, 5 % вероятности не уложиться в срок.

Считайте, что уложиться в оптимистичный срок можно, только если сам Один сядет за лэптоп и всей своей мудростью и силой затянет проект прямо в Вальхаллу. Оптимистичная оценка — это минимально необходимое время для реализации проекта при наилучших обстоятельствах. Задача наверняка будет выполняться дольше, чем рассчитано по best case. Также можете считать это вашей Big-Omega оценки срока.

Номинальная оценка — наиболее реалистичный срок. Это самое важное значение, так как оно имеет наибольший вес в дальнейших расчетах. Эта оценка должна быть умеренно оптимистичной при ваших обычных условиях работы. Считайте, что у вас есть 50%-ная вероятность не уложиться в номинальный срок. Также можете считать это вашей Big-Theta оценки срока.

Пессимистическая оценка дается исходя из того, что все пойдет не так. Ваш ноут утащила в нору офисная крыса. Ваш дизайнер оказался мартышкой-наркоманом. Вас призвали в армию за день до релиза. Это наихудшая оценка, которую вы можете дать задаче. И у вас только 5%-ный шанс не уложиться в этот срок. Также можете считать это вашей Big-O оценки срока.

Ваша пессимистическая оценка не может быть меньше номинальной. Извините.

Давайте рассмотрим трехкратный метод на примере.

Пример требований к проекту


The web-service should allow a user to log in to an existing account.
Buy the product from the predefined list of commodities.
And review its purchase history.

Предположим мы разбили требования на 3 задачи:

Work Item Name
1 User Login
2 Purchase Commodity
3 Purchase History

Пример трехкратной оценки задач

Work Item Name B N W
1 User Login 10 30 100
2 Purchase Commodity 15 40 150
3 Purchase History 2 10 20

Все величины приведены в AWD

Расчет СКО и среднего арифметического взвешенного

Среднее значение срока выполнения задачи (mean) рассчитывается как:


M = (B + 4N + W)/6

Почему коэффициент 4 для номинальной оценки? Потому что она наиболее реалистичная. И мы хотим выделить ее по сравнению с другими оценками. Почему именно 4, а не 6 или 8? Потому что Rocket Science.

Для вычисления общей средней продолжительности проекта мы суммируем среднюю продолжительность каждой задачи.

Work Item Name B N W M
1 User Login 10 30 100 38
2 Purchase Commodity 15 40 150 54
3 Purchase History 2 10 20 10
Project Total Mean 102

Все величины приведены в AWD, округлены до целых

Теперь давайте рассчитаем СКО (Standard Deviation) для каждой задачи:

S = (W — B)/6

И общее СКО для всего проекта:

Project Standard Deviation = SQRT(SUM(S)^2)

Для нашего проекта имеем:

Work Item Name B N W M
1 User Login 10 30 100 38
2 Purchase Commodity 15 40 150 54
3 Purchase History 2 10 20 10
Project Total Mean 102
Project Standard Deviation 40.5

СКО показывает вариативность вашей оценки. Чем оно больше — тем больше будет диапазон вашей оценки. Не говорите об СКО проекта людям с гуманитарным образованием 🙂

Эти значения нам понадобятся для аппроксимации наших данных с помощью бета-распределения. Что в свою очередь даст возможность получить вероятностное значение сроков выполнения проекта.

Бета-распределение

Для получения вероятности успешного выполнения проекта в оцененный срок я использовал бета-распределение. Потому что его применяли в PERT.

Детальное описание использования бета-распределения с трехкратным методом приведено здесь.

В общем мы рассчитываем вероятность успеть в срок исходя из среднего значения и СКО проекта.

Для нашего проекта получаем следующую функцию распределения:

Читается график так: «Проект будет завершен за 177 AWD с 95 % вероятностью».

Вот небольшая табличка шансов проекта на успех:

Chance of Success Effort (AWD)
95 % 177
70 % 122
50 % 98

Если вы сравните со средним значением продолжительности проекта (102 AWD), то поймете, почему не следует просто использовать среднее.

Вот мы и получили вероятностную оценку срока выполнения проекта.

Диапазон оценки

Если вы не уверены во всей этой вероятностной кухне, можете просто давать диапазон значений для срока выполнения проекта, пользуясь следующим правилом:

The 95 % confidence interval for the true project work time is approximately: Project Total Mean ± 2 × Project Standard Deviation

Коэффициент 2 основан на правиле 68-95-99.7.

Для нашего проекта получаем: «Проект займет от 21 до 183 дней».

Можем опустить нижнюю границу диапазона и сказать: «Проект займет от 102 до 183 дней».

Конечно, можно использовать коэффициент 1, получая:

Project Work Time = Total Mean ± 1 × Project Standard Deviation

Но следует учитывать, что в этом случае мы говорим о вероятности окончания проекта в срок, равной 68 %.

Excel Workbook для проекта

Здесь находится Excel Workbook с примером расчетов для нашего проекта. Юзайте с миром 🙂

Дополнительные требования

Постарайтесь разбивать проект на максимально независимые задачи. Рекомендуется использовать около 20 и более задач для получения более точного результата.

Вывод

Оценка проектов в мире IT далека от точной науки. И так будет продолжаться еще долго. Методология использования трехкратного метода с бета-распределением не идеальна. Но она может дать вам больше уверенности в ваших оценках. Уверенность поможет добиться доверия к вашим словам, а на доверии и держится весь процесс оценки проектов.

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

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

Так как же оценивать проекты, чтобы получить верифицируемый результат? Хороший вопрос. Выше я описал несколько вариантов. Также здесь есть пару идей. Но для меня это все еще открытый вопрос.

Добавить комментарий