Комментарии 32
Есть же проверенный способ, который никогда не подводит, - взять срок, который Вы, по внутреннему ощущению, считаете реалистичным, и умножить на три :) К бюджету проекта это, кстати, тоже относится.
Но константа может варьировать. У меня меньше 5 никогда не выходит. А вот 10 запросто. :D
Просто один раз на 3.14 умножает тимлид, и еще раз - менеджер. 3,14*3,14 = 9,85.
Умножайте сразу на g. Кстати, п^2 как раз близко к g из-за старого определения секунды
Вот простое объяснение: Можно ли объяснить то, что ускорение свободного падения и квадрат числа пи примерно равны (или же это просто совпадение)?
В одном из старых выпусков "Кванта" тоже была статья на эту тему с теми же выводами.
Вот, я как-то тоже дошёл до *3...
Это называется управление рисками. А эта вот магическая константа 3 — это как пить дать, всего лишь результат вероятностной оценки срока выполнения. И вообще говоря, все это сто раз описано в литературе. Скажем, почитать Де Марко и Листера явно стоит.
Вот что меня удивляет реально — люди пишут статьи про оценку сроков (я не конкретно про эту, таких было с десяток минимум). И при этом даже не упоминают диаграмму Ганта, как будто у них все задачи в проекте делаются строго последовательно. И MS Project хоть раз бы упомянули, ну или другой инструмент, помогающий решать задачи планирования, без которого планировать реально человек на 10 практически лишено смысла. Причем не знаю как нынче, а в мое время нас этому просто учили в ВУЗе.
К бюджету проекта это, кстати, тоже относится.
Ну еще бы. Если сроки умножить на три — все зарплаты тоже можно и нужно.
Конечно, чтение дополнительной литературы - это всегда плюс. Про диаграмму Ганта, конечно, тоже хотела упомянуть. Но это уже в глубокое исследование если заходить. На первых этапах Гант будет таким же неточным, как и более простой способ оценки. Я думаю, что Ганта стоит составлять, если есть уверенность, что команда и задачи не изменятся. А значит планировать с ним где-то на этап, одну итерацию.
Важно, чтобы Гант опирался на реальные данные, а не брал оценки с потолка. В Ганте также сложно планировать по участникам в масштабе задач. Мало ли кто заболеет или уволится. И план от этого, возможно, сильно поплывёт
Вот конус неопределённости для вас, видимо, на 3 как раз работает. Если верить Макконнеллу, то на 4 можно умножать в условиях неопределённости
А раньше было плюс полгода, а теперь умножить на три :)
Как узнать дату завершения любого проекта? А никак. И в общем-то вся статья ровно об этом и говорит.
Как работник, бойтесь менеджеров, которые требуют придумать жёсткие сроки и вписаться в них. Как менеджер, бойтесь работников, которые готовы выдумывать сроки и вписываться в них. Как заказчик... Ну, вы поняли логику.
В статье как раз упоминается конус неопределённости. Т.е. дату-то рассчитать можно. Но она сначала может в 4 раза ошибаться, затем меньше и меньше. Вписываться в жёсткие сроки - это всегда риск. Если есть возможность поставить срок на какой-то квартал или хотя бы месяц, то будет вероятность уложиться. Тем более если такой срок получен на основе пары итераций работы
Исключительно опыт, иначе никак! Все эти формулы разбиваются от внешних факторов в проекте в пух и прах. У каждого эти факторы они свои! Большие проекты как правило затрагивают несколько сторон это заказчик, эксплуатант и исполнитель ( еще могут быть соисполнители) и чем больше сторон тем больше внешних факторов. Как их предусмотреть формулами? А если мы опустимся до системы, которую нужно обследовать, чтоб понять возможность внедрения новый функций? Там вообще темный лес. Это все риски, хорошо если есть человек (эксперт), знающий систему, в которую предлагается внедрять новые функции иначе как слепые котята!
Всегда смотрел на планирование сроков сложного проекта как на мистификацию. Я понимаю как считать, например, ремонт квартиры, имея полный проект. Там очень много типовой, однородной работы. Можно добиться довольно высокой точности, хотя не 100% конечно.
Но как посчитать создание нового програмного продукта, где нужен поиск пути реализации и могут встретится непредвиденные, например, аппаратные сложности?
Вот есть тут PM который умеет считать проекты, которые ранее не выполнял, с точностью хотябы процентов 80? Чтобы без "прикину как могу и умножу на 3".
Я вообще-то знаю как, но эту методику сочтут негуманной в 75% стран мира.
Хороший PM должен и умеет считать с вероятностью 95% - см. методику PERT, например.
Только есть нюанс — среди всех PM в мире таких ребят от силы 5% )))
В общем, всё сводится к опыту, знаниям и т.п. Не каждый инженер может построить ракету-носитель. А если и сможет, то не факт, что она взлетит выше 30 км. Хотя при этом есть ракеты, которые вполне себе летают уже много лет без особых проблем.
Театр в Сиднее когда строили, то бюджет и сроки в разы превысили. Но опять же, есть примеры больших строек, закончившихся в срок и даже с опережением.
При этом всегда успешных проектов мизер по сравнению с "обычными".
И это не погрешность измерений или статистики, а закономерность, которая складывается из опыта и знаний проектной команды.
- Оценить сложность каждой задачи
Ну мы же не дом строим по чертежу, правда? Периметр стен умножаем на толщину стены и получаем объем кладки.
Мыж программы клепаем. Одна из задач например — изучить апишечку, вторая — по изученной апишке наклепать интерфейсный модуль. Что же может пойти не так?
Пример из жизни. Делаем бота-привратника в телеге в дополнение к боту-помощнику. Тот уже написан, с рестом телеги все знакомы, сиди да пили.
Задачка простая: упорядочить работу с корп чатами.
Алгоритмы/юзкейсы:
- Храним список рабочих чатов в таблице
- Храним сотрудников и их рабочие места (точнее получаем из 1С)
- Сотрудник (проверяем по номеру телефона) может получить список чатов, которые ему нужны
- Уволившихся (и вообще случайных левых) нужно убирать из контролируемых (есть еще и "для друзей" развлекательные, там тусят все кому хочется) корп чатов
Пункты 1, 2, 3 — без проблем. 4 — в целом тоже, бот легко может выгнать кого угодно.
Вот только он не может узнать, а кто в чате. Только админов.
И вот здравствуй вместо часа на обвязку очередного рест-вызова и выполнения команды + 2 часа на протестировать и показать всем заинтересованным — не понятно сколько. Так как вместо ТелеграмБотАпи берем ТелеграмАпи, которого нет на языке проекта, со своими приколами авторизации, получения-отправки кодов и прочая мишура ради одной команды — дай список пользователей вот этого чата.
При большом количестве задач ошибки форсмажорные автоматом нивелируются.
Задачи нужно оценивать качественно, а не количественно.
При оценке в сторипойнтах или "попугаях", описанных проблем гораздо меньше.
Например, в приведённом выше примере оценка в 1 сторипойнт включает в себя разброс фактического времени, потраченного на задачу, - от получаса до 8 рабочих часов.
В общем, если считать в часах, то и точность должна быть в часах, т.к. измерение должно попадать в погрешность размерности шкалы. А точность до часа в управлении проектами не нужна. Но если требовать оценивать в часах (потому что у ПМа "программа только так считает") - то и получаем саботаж планирования. Даже может быть неумышленный.
Никогда разработчик не знает точно в часах. Зато может и должен знать на уровне "простая, сложная, очень сложная, и нифига непонятно как это вообще делать". Если не знает, то надо звать старшего)
Дальше уже задача тимлида или ПМа не допустить в план задач с оценкой выше "сложная" или "простая". Для этого существует проектирование, декомпозиция и ещё куча других способов.
В итоге останутся относительно простые задачи, где вероятность, что что-то пойдёт не так, уже сильно меньше. Плюс должна быть культура обратной связи. Это когда разработчик должен своевременно оповестить заинтересованных, что у него не получается, а не зарываться на неделю с задачей, которую сам же оценил в 1 час.
Также не помешает упомянуть про разные уровни зрелости организаций. Например, в организациях 4-5 уровня (из 5) вопросы, затронутые в статье и в комментариях вообще не возникают))
Так что ещё один способ борьбы с проблемами планирования и управления проектами — развиваться. Там уже человечество всё давно придумало и решило. Останутся только решения на уровне бизнеса, которые могут запороть красоту инженерную.
Только вот в итоге попугаи по 100500 задачам, пусть даже не превращаясь в часы должны превратиться в календарные даты майлстоунов. В клинических случаях — в даты выполнения задач.
И задачи класса " нифига непонятно как это вообще делать" естественно не лечатся декомпозированием. Они лечатся задачами на исследование (опять же, без сроков, но возможно с бюджетом времени), что тоже не внушает оптимизма в вычислении календарного срока завершения проекта.
Верно. Самое сложное - это декомпозировать, а если невозможно, то исследовать такие задачи, про которые ничего неизвестно.
Такие задачи можно изучать так:
1. Берем Х часов (обычно достаточно 1-2 часа) на исследование. Гуглим, ищем источники
2. По результатам Х-часового исследования возвращаемся с полученной информацией и более чётким планом. В этот момент у руководителя и команды уже достаточно данных, чтобы принять решение о приоритете и дальнейших шагах по этой страшной задаче, которая после исследования может быть и не такая уже и страшная
Подобный анализ можно делать и наоборот от точки В (заказчик или начальство хочет получить продукт) к точке А — начало разработки. Так даже аргументированее получается.
Существуют несколько специальных алгоритмов и техники для расчетов сроков производства, этому обучают в вузе.
Один из них - нужно разбивать все на задачи, каждую задачу декомпозировать на подзадачи, пока оценка станет не очевидной.
На каждую подзадачу дается 3 оценки: оптимистическая, песиместическая и медиана.
Все задачи группируется и распаралеливаются для командной работы. Вычисляется среднее время по самой длинной ветки.
А вот сроки для разработки всегда одни - до дедлайна. Разработка - не производство.
Это PERT метод, один из самых эффективных https://ru.wikipedia.org/wiki/PERT
В статье про это упомянуто в целом про "Способ 3. Расчётный".
К сожалению, этот способ практически не используется в большинстве проектов, особенно в модных "гибких".
Так что да, это самый точный способ (независимо от методики), но самый затратный
Это грубо говоря вообще не способ. Так как к тому времени, когда вы разбили весь [софтварьный] проект на простые задачи и устранили все неопределенности, и точно знаете, кто и что будет делать — вы потратили 100-150% времени от того, что вы насчитали (т.е. 50-80% от общих временных затрат на проект). Если конечно это проект в смысле PMBoK, а не лендинг пейдж очередной, стереотипный.
В разработке ПО проектирование в худшем случае занимает 30% времени. И это уже полностью закрытый этап эскизного и технического проекта. Обычно достаточно 10% Не сомневаюсь, что можно раздуть и до 150%-1500% от времени фактической реализации))
В итеративной разработке (читай Agile) в абсолюте на спринт это 1 день из двух недель на планирование.
Есть, конечно и форс-мажоры и другие обстоятельства. Но в организациях уровня развития выше 3 по CMMI так и работают. Время - деньги.
Согласен, что делать по книжкам очень сложно, особенно, когда нет поддержки со стороны руководства и команда не верит в теорию и чужой опыт)
Разные организации находятся на разных уровнях развития. Мы за то, чтобы помогать развиваться всем, кому можем (с учётом нашего уровня развития) и самим тоже развиваться.
Нет ничего плохого, если постепенно команда будет тратить меньше времени на проектирование и меньше ошибаться в сроках, используя проверенные методики.
Планирование — копейки. но для проекта АКА "временное предприятие, направленное на создание уникального продукта, услуги или результата" выполнение всех исследовательких задач (их последовательностей) как раз добавится к 10-30% на проектирование и добьет до 50-80%.
Более того, если у вас цепочка
- Задача 1 простая
- Задача 2 простая
- задача 3 исследовательская
То решение задачи 1, 2 тоже войдет во время оценки — так как без них не делается задача 3, а пока мы ее не сделали мы не декомпозировали до конца некое требование.
И значит не закончили оценку по расчетому методу.
Нисколько не спорю, что расчётный метод самый сложный и трудоёмкий из всех. Это не панацея и не лёгкая прогулка и к ней нужно готовиться.
И вы правы, можно переборщить в погоне за точностью и получится перерасход ресурсов.
Я шёл по пути от простого к сложному. На данный момент успешно использую все перечисленные методы в зависимости от сложности проекта и нужной точности расчётов. Но мы не делаем голый аналитический расчёт сразу. Первый - всегда прикидочный экспертный. Дальше по мере появления декомпозированных задач, которые мы в состоянии оценить, то мы их оцениваем качественно (легкая / сложная / очень сложная) и планируем в спринт только относительно простые задачи. Сложные отправляются в бэклог для уточнения / проработки. Если проект - это продукт, то такие задачи могут вообще до реализации не добраться. А для заказов берём время на исследование из пула на исследования.
Из приятного - такой подход с качественной оценкой вместо количественной оказался точнее в итоге. Процесс оценки (планинг-покер) проходит очень быстро, никто не расстраивается, что оценил задачу в 1 час, а делал её 8, потому что 1 сторипойнт у нас - это от 1 часа до 1 дня как раз.
Мотивация не падает, все довольны. И руководитель проекта и разработчики перформят и намного чаще укладываются в свою оценку.
Про сроки и дедлайн.
В идеале - это когда расчетный срок учитывается при выставлении дедлайна.
Если так случилось, что дедлайн уже выставлен, а никакой расчёт не проводился, то можно только пособолезновать такому мертворождённому проекту)
В таких случаях режут функциональность обычно. Бывают попытки увеличить скорость команды за счёт найма и т.п., но такие решения приводят к уменьшению скорости команды, потому что не учитывается теория управления про издержки управления.
Как узнать дату завершения любого проекта. Метод путешественника