Comments 40
Извините, заметил опечатку. Отправил бы в личку, но с iPad в личку скрины не вставить (ну, вы знаете слабость Хабра, что у них разный редактор сообщений на разные разделы сайта? )))
Hidden text
Изначально предполагалось, что данную воздушную гавань удастся построить за 5 лет и 2 000 000 000 € . Не удалось. В итоге бюджет и сроки выросли в три раза – до 14 лет и 6 000 000 000 €. И это не говоря про дату открытия, которую успели перенести аж 5 раз!
"Дед мой говорит: бери оценки и умножай на 3.1415" (c) Юноша. В этом смысле они уложились.
а почему вообще взят как пример уникальный случай, (ибо все знают что этот аэропорт Бранденбург - феерический факап, случающийся раз в 100 лет) , а не типичный аэропорт, в котором внезапно все не так плохо??
Согласен, что этот кейс - самый эпичный, фееричный факап, про который даже инопланетянам будет стыдно рассказывать, когда они прилетят на Землю))
Он был взят для примера, чтобы подсветить всю сложность работы с неопределенностью, которая возникает при оценке сроков и бюджетов.
Есть еще достаточное количество уникальных случаев провальных проектов:
- в США, штат Техас, в 1980-х решили построить Сверхпроводящий Супер Коллайдер, для которого в 1991 году Конгресс одобрил $4,4 млрд., что к 1993 году превратилось в $12 млрд. Как результат, проект закрыли с чистыми потерями порядка $2 млрд.;
- в Австралии в 1955 году правительство объявило архитектурный конкурс, позже реализовавшийся в известный на весь мир сиднейский оперный театр. При первоначальных оценках 7 млн. австралийских долларов и 4 лет на строительство, его окончательный бюджет возрос до 102 млн. а.д. и 14 лет.;
- между Францией и Великобританией еще в 1881 году был начат проект строительства тоннеля под Ла-Маншем. Если не брать в расчет историко-политические аспекты и, следовательно, сроки, то плановый финансовый бюджет был превышен почти вдвое (около 10 млрд. фунтов стерлингов);
- те же Франция с Великобританией провалили по финансовому бюджету проект сверхзвукового самолета "Конкорд". План: около 160 фунтов стерлингов. Факт: около 1 млрд.
Метод pi отличный. Уверен, что он работает - для определенных частных случаев. Однако он не помогает решать фундаментальную проблему неопределенности.
Рассмотрим 2 примера:
Пример 1: Разработчик, релиз менеджер, руководитель проекта - каждый на своем уровне перестраховывается на 3,14. И заказчик отказывается сотрудничать по такой смете.
Пример 2: Заказчик от кого-то услышал, что «хитрые айтишники» практикуют тригонометрию при оценке задач, режет смету на 3,14 и категорически отказывается вести переговоры по срокам и смете. Хорошо, если речь идет о смете, составленной «хитрым айтишником» из примера 1. Он худо-бедно сможет выйти хотя бы в ноль.
В худших условиях будет добросовестный исполнитель, который посчитал реалистичные сроки и смету.
В результате возникает мир кривых зеркал, взаимных недовольств и обид.
Изначально данная статья родилась из наблюдения за некоторыми руководителями, которые давали обещания ИЗ ГОЛОВЫ. И результат из головы, умноженный хоть на 10 pi, может быть недостаточным для реализации задачи.
режет смету на 3,14 и категорически отказывается вести переговоры
Так это такая же проблема, как и "обещания из головы". Этот заказчик решил, что он умеет лучше планировать в ит, чем вы. То, что вы предлагаете - это заняться образованием заказчика до тех пор, пока его квалификации хватит понять, что его собственная картина планирования ничего общего с реальностью не имела.
На это "образование" может уйти порядочно времени. И мне очень интересно, а как вы оплату с заказчика за него возьмете? (ведь сам проект вполне может быть отклонен и заложить в него допзатраты невозможно).
«Образование заказчика» - это управление ожиданиями клиента. И да, это работа, которую нужно проводить.
А со стороны исполнителя эта работа должна проводиться только совместными усилиями руководителей на различных уровнях: Release Manager —> Project Manager —> Руководитель разработки. Если не будет согласованности и приверженности одним и тем же принципам, то вероятность успеха кратно снижается.
Не забываем, что у исполнителя всегда есть опция - не заключать контракт с конкретным заказчиком, который им не подходит. Но адекватных заказчиков в корпоративном мире много. Поэтому важны и первичные переговоры и выстраивание доверительных отношений в процессе работы. Т.е. Вы объяснили человеку как будет, вы взяли на себя ответственность в исполнении этих обещаний, вы должны их исполнять. Тогда отношения укрепляться и к вам не будет придирок и вопросов.
Так все-таки, как вы эти затраты на "образование" учитываете и как их заказчик оплачивает?
Заказчик оплачивает готовый продукт. «Образование» - это просто диалог, внутри которого происходит обсуждение рабочих вопросов и требований.
Часы менеджера относятся к расходам проекта. Они учитываются в его смете, наряду с часами разработчиков, а также прочими косвенными расходами.
Итого имеем схему, где есть существенный кусок затрат, который возникает до проекта (подписанного заказчиком). В каких-то случаях эти затраты можно прикрепить к будущему проекту, в каких-то нет - просто потому что заказчик не согласился на проект (хотя и тут у меня сомнения: если вы "хитрому" клиенту прозрачно напишете: вот смотри, тут мы дообразовывали твою хитрость и теперь смета на 5ч больше - сомневаюсь, что он это оплатит.).
А потому как менеджеру все равно оплатить это время придется, то, предположу, что эта оплата закладывается в повышенную цену или другими словами эти издержки оплачивают все клиенты. Обычные клиенты платят за "хитрых". Не уверен, что это устраивает обычных клиентов.
В портфеле любой компании заказной разработки обычно всегда лежат несколько проектов.
Эти проекты, во-первых, могут быть на разных этапах разработки (пред-договорные отношения, юридическое оформление, согласование ТЗ, согласование результата, оплата), а во-вторых, часть из них будут оплачены по fixed price, а другая часть - по time & materials.
Ситуация, что какие-то проекты в моменте «кормят» другие проекты, - вполне распространенная.
Ситуация, что исполнитель потратил свое время, а заказчик выбрал другого, - тоже обычная.
Мне кажется, ваш комментарий выходит за рамки темы статьи. Это больше вопрос бюджетов, тарифных ставок и в целом экономики проекта.
И заказчик отказывается сотрудничать по такой смете
Некропосты заказывали?)
Ну может это и не так плохо, если заказчик отказывается. Он ведь после этого пойдёт, походит по рыночку. И вариантов тут будет три.
Он найдёт свою команду, он найдёт свой коллектив. Ну например ребят, которые недавно закончили что-то очень близкое, знают риски и имеют готовые наработки. Ну чтобы не сказать "продать код одного заказчика другому".
Он найдёт тех, кто прогнётся под его требования. В итоге смета и сроки всё равно вырастут в ×3, но отвечать за это будете не вы и нервы трепать будут не вам.
Заказчик урежет осетра и вернётся с более адекватными требованиями и готовностью договариваться, а не стучать кулаком по столу.
Добавив данные в таблицу загрузки специалистов, мы смотрим, где теперь проходит пересечение линий. Как и предполагалось, благодаря появлению двух разработчиков пересечение кривых сдвинулось к пятой неделе. Соответственно, для реализации этого проекта за пять недель нам потребуются дополнительные разработчики на backend и frontend.
Отличные расчеты. А потом 1 или 2 человека заболевают, например, тот самый Азамат, без которого остальные не могут начать делать свою часть работы. Или в ходе работы вылезают грабли, которые нельзя было предвидеть до начала работы. Поэтому, если у вас всё в идеале вырисовывается к пятой неделе, закладывать надо минимум 10 недель.
Очень точное замечание! Спасибо! В данном конкретном примере при заболевании системного аналитика команда не сможет начать свою работу.
Для того, чтобы команда была не заблокирована, мы стараемся в своей работе:
Во-первых, формировать гэп по аналитике хотя бы на 1 рабочую неделю.
Во-вторых, следим, чтобы в бэклоге технического долга всегда были задачи, которыми могут заниматься разработчики.
В-третьих, всегда можно попросить помощи соседних команд.
План - это всегда только план. Изначальный план - это проекция возможного будущего на основе текущих допущений и вводных. Которые, естественно, могут измениться.
А любое изменение на проекте, будь то болезнь, либо новые проблемы, - это будни руководителя. И в его обязанности входит задача передоговориться с заказчиком в связи с изменениями. А если вам удалось выстроить доверительные отношения, то он отнесется с пониманием и вы сможете удачно передоговориться.
Дочитал до места, где Азамат онбордит Оксану. Отложил чтение, нужно успокоиться.
Оценку производительности по спринтам или по неделям вы делаете?
Что важно заметить, разница между медианными и средневзвешенным показателями является довольно существенной. Это говорит о высокой неопределенности на проекте, а потому нам для расчетов лучше взять средневзвешенные показатели, а не медианные, поскольку в противном случае проект может занять в два раза больше времени, чем планируется.
Не соглашусь с вашим выводом. Разница между медианным и среднеарифметическим показывает, что внутри "больших" задач есть крайне высокие значения (относительно "малых" задач). В статистике для этого смотрят по средниеарифм по каждому из 4х перцентилей (0,25,75,100) - на графике будет наглядно виден резкий рост средней в одном из них.
Причин же может быть сколько угодно: например, один менеджер нарезал на маленькие задачи, а другой на ооочень большие. Следует ли из этого, что нужно брать медиану или среднеарифметическое? Прямо не следует, ну, кроме очевидного, что если взять цифру побольше, то шансы попасть в нее повыше. Я бы думал об этом, как о гауссовом распределении и брал бы всегда за базу среднеарифм + сколько-то сигм (между 2 и 3мя).
Большая беда в том, что среднестатистический человек не умеет работать с вероятностной природой оценок. И, думаю, большинство заказчиков как раз из них. Поэтому рассказывать им, что ваша оценка - это 95% шанса, что затраты будут не выше - можно, но в голове у них отложится "100% обещали за эту сумму сделать". Отсюда лично мое мнение, что пессимистичные оценки должны бОльший вес иметь в конечном результате, потому что будут восприняты как 100%ные.
Читаю и плачу. Наш релизный менеджер и 5 процентов из этого не умеет. Из навыков только отсасывать у руководителя(которые его и притащил)
Вопрос: кем заказчик будет доволен?
Встречный вопрос: Кого заказчик выберет в начале?
Спасибо за интересную статью! Несколько вопросов:
Теперь мы с этим списком идем к профильным специалистам (системному аналитику, QA-инженеру и т.д.) и спрашиваем, сколько нужно времени для реализации каждой из функциональностей.
Оценка трудозатрат осуществляется только по упомянутому списку или есть на руках доп.материалы (к примеру, бизнес-требования от заказчика)? Если на руках только список, то это, конечно, лучше, чем просто название эпика, но все-равно "плюс-минус километр"
Мы будем исходить из гипотезы, что каждый специалист может эффективно работать не более 32 часов в неделю. Это говорит не о том, что остальное время он бездельничает, а о том, что он занят коммуникацией со своими коллегами, заказчиком и т.д.
Хорошо, что в таблице учитывается отсутствие специалистов, но имеет смысл, наверное, учитывать и последовательность работ? Первую-вторую неделю будет активно работать СА, и активность его будет снижаться ближе к окончанию разработки, а вот QA точно появится не сразу. Или на этом этапе расчетов в этом нет такой необходимости?
На основе полученных данных мы можем определить срок работ. Для наглядности все отображено на графике ниже.
Как-то не сходятся трудозатраты из таблички с получившимся графиком. Точно график и таблица коррелируют друг с другом?
тогда как для этапа тестирования и стабилизации необходимо 126 часов.
Не совсем понятно, как можно сделать такой вывод, основываясь на таблице и графике? Или есть еще вводная информация, которая была упущена в статье?
С этими цифрами мы производим трехточечную оценку и получаем результат, что выполнение одной задачи по фронтенду занимает 24 часа.
Есть ли другие варианты подсчета? Мой опыт мне подсказывает, что если я выгружу 100 задач по фронту в Джире, то разбег между ними будет просто колоссальный ( Буду признателен за подсказку.
Оценка трудозатрат осуществляется только по упомянутому списку или есть на руках доп.материалы (к примеру, бизнес-требования от заказчика)? Если на руках только список, то это, конечно, лучше, чем просто название эпика, но все-равно "плюс-минус километр"
Верно! Подход идеально подойдет для простой функциональности (например, без интеграции со сторонними модулями), либо если у вас сработанная команда на знакомом проекте и новый эпик из вашей доменной области.
При разделение процесса на Discovery и Delivery, этап согласования бизнес-требований будет выполнен на первом этапе. Будем считать, что наша команда «Дрим тим» - это Delivery.
Хорошо, что в таблице учитывается отсутствие специалистов, но имеет смысл, наверное, учитывать и последовательность работ? Первую-вторую неделю будет активно работать СА, и активность его будет снижаться ближе к окончанию разработки, а вот QA точно появится не сразу. Или на этом этапе расчетов в этом нет такой необходимости?
Согласен, последовательность важна. Как я уже отвечал в другом комментарии, мы формируем гэп по аналитике. Соответственно, у нас СА всегда идут впереди. А вот для QA у нас всегда есть работа. Поскольку мы разрабатываем несколько функциональностей параллельно.
Доля условности в показанных расчетах есть. Однако вы можете под себя гибко адаптировать расчет через коэффициент загрузки специалиста. Но не заигрывайтесь))
Я обычно использую данный подход, когда приходит большой кусок работы. Если фича на 40-60 часов, решаю это в уме.
Как-то не сходятся трудозатраты из таблички с получившимся графиком. Точно график и таблица коррелируют друг с другом?
778 часов + 20% (резерв на непредвиденные ситуации) = 934 часа
Не совсем понятно, как можно сделать такой вывод, основываясь на таблице и графике? Или есть еще вводная информация, которая была упущена в статье?
Грубо округлим объем работ по SA, FE и BE, получается по 200 часов.
По QA - 100 часов.
На системном анализе у нас 2 специалиста (200 / 2 = 100), на FE,BE по 1 специалисту. Следовательно очевидно, что по FE и BE необходимо усиление.
Есть ли другие варианты подсчета? Мой опыт мне подсказывает, что если я выгружу 100 задач по фронту в Джире, то разбег между ними будет просто колоссальный
Да, если задачи в Jira можно кластеризировать на Small, Medium, Large, то статистика по кластерам будет вполне репрезентативна.
Хорошая статья, сам на бэке сейчаc и порой приходится самому оценки делать. В целом, по своему скромному опыту, скажу, что подобных подходов контроля загрузки и ресурсов, хорошо нам знакомых по работе с Airbus, в IT не хватает. Шутки про ПМДБ не будет (вдруг ты уже забыл её ;) ).
Александр, спасибо за статью! Очень полезная для менеджеров любого масштаба!
В проектном управлении ещё с прошлого века есть с десяток техник оценивания и составления расписания...
Замесц одно в ваших расчётах и составлении расписаний для заказчика не учитываются зависимости, а разработке ПО их отсуствие это прямо нонсенс)
В проектном управлении ещё с прошлого века есть с десяток техник оценивания и составления расписания...
Само по себе наличие техник не спасает от того факта, что многие проекты проваливаются и руководители дают обещания из головы.
Согласитесь, есть с десяток техник, позволяющих похудеть.
Но практика - критерий истины. Руководитель, у которого в арсенале несколько инструментов, которые он активно применяет в своей каждодневной работе, будет эффективнее руководителя, который знает множество техник, но не использует их.
Замесц одно в ваших расчётах и составлении расписаний для заказчика не учитываются зависимости, а разработке ПО их отсуствие это прямо нонсенс)
Верно! Важно учитывать зависимости, особенно это критично при проектировании микросервисов. Но это следующий уровень осознанности руководителя))
Отличная статья, спасибо!
Как не давать пустых обещаний себе, команде и заказчику