Да не за что, было интересно

#welcome Привет, меня зовут Данил! Работаю консультантом по бизнесу в банковской сфере.

Добрый вечер!
Поделитесь, пожалуйста, опытом: учитываете ли вы фокус-фактор при планировании работ? ФФ не только команды, но отдельного разработчика в частности. Нашла такое описание: "Такая метрика описывает, сколько времени потратит идеальный человек на исполнение реальной задачи в идеальных условиях. ".  Если да, то насколько это полезно/оправданно? Чем пользуетесь при оценке ФФ (расчет/экспертная оценка)? Не приводит ли это к ситуации, описываемой в некоторых источниках:
"Итак, опираясь на фокус-фактор, Вы рано или поздно придете к:
Пониманию людей как ресурсов
Падению продуктивности
Падению прогнозируемости
Медленной поставке ценности
Нежеланию членов команды учиться и развиваться
Отсутствию креативности в команде

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

фокус фактор в физике можно посмотреть как вот этот опыт «Воронка деминга»
https://youtu.be/K0E8Tvb0qY8

https://deming.pro/deming-funnelexperiment.html вот хорошая статья про это

а я указывал про вот такие подходы https://kanbanguide.ru/resources/video-category/prognozirovanie/ (осторожно английский)

Нифига как все может быть заморочено... А если просто, по-крестьянски, посчитать Cycle time для задач определенного типа и выйти на SLA?

Лидтайм лучше считать (время от поступления запроса до предоставления клиенту. Цикл тайм это время одного или группы этапов работ.

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

Спасибо! Практика видимо нужна для понимания контекста, тяжело идёт.

Скорее теория, тогда и практика легче идёт. Спрашивайте, подскажем.

А ФФ, поддержу, сейчас уже не применяют. Наработаны методы получше.

Подскажите тогда, пожалуйста, чем будете руководствоваться вы, если задача звучит примерно следующим образом. Есть очень большое количество задач, оцененных разработчиком в часах с той или иной погрешностью. Задачи - в рамках одного проекта, могут иметь блокировки (одну задачу нельзя делать, пока не будет закончена другая). Суммарная оценка, скажем, в районе 5тыс. часов. Есть команда разработчиков. Достаточно большая по численности (около 10 чел), но разбитая на подкоманды для гибкости и более эффективного взаимодействия. Задачи нужно выполнить к определенному сроку (для конкретики, конец года). Просрочка недопустима, перенос срока невозможен (это b2g🤷🏿‍♀️).  Есть большое количество факторов, влияющих на процесс, которые могут возникнуть с той или иной вероятностью, навскидку много набежит, в реальности больше. Например:
1)Отпуска    
2)Больничные    
3)Текучка    
4)Инциденты    
5)Стабилизации    
6)Внутренние работы по улучшению стабильности продукта (написание новых тестов, починка старых)    
7)Неотложные работы, инициируемые Заказчиком (скрипты, выгрузки, срочные улучшения)
8)Аттестации (включение времени на аттестационные задачи, работа аттестующих)    
9)Контроль сборок    
10)Работы по оценке задач    
11)Консультации аналитики, специалистов девопс    
12)Внутренние обучения    
13)Затраты времени, связанные с вовлечением новых разработчиков в рабочий процесс (помощь, обучение)    
14)Риски, связанные с оценкой задач    
15)Риски, связанные с изменением постановки задач (аналитика, пожелания Заказчика)    
16)Ожидание ответов от второй стороны в задачах по интеграции.
Вопрос: как максимально точно определить, потянет ли команда в текущем составе столь большой объем задач к указанному сроку? Причем определить надо здесь и сейчас - т.е. не поэтапно, а сейчас сказать заранее, потянет, или нужно принимать какие-то меры.  Понимаю, что гибкостью тут не пахнет. Но, возможно, есть что-то полезное и для такой проблемы.

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

Команда частично обновлена, причем в значительной части, 4 из 10 - новые ребята, пришли в теч. месяца.

Вы несколько не там спрашиваете. Вам нужна инкрементно-итеративная разработка на базе UP (унифицированного процесса). У вас проект должен быть разбит на инкременты, между ними нужно заложить буферы под уточнение требование и срабатывание рисков. Так же вам следует выделять отдельный поток на решение инцидентов/ошибок, его стоит оценивать просто в виде процента от общего времени. Еще крайне желательно применить критическую цепь, либо на крайний случай метод критического пути.

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

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

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

Если не сложно, поясните, пожалуйста, по waterfall. Что будет?

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