Её можно использовать в любых инструментах

Нормочасы на обслуживании авто, например

Яркий пример такой таблицы

Прощу прощения, в любых единицах

Хоть в выкуренных слесарем сигаретах))

Как это "никак"? Ещё как влияет. Отрицательно, естественно.

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

В запутанных доменах можно посмотреть на EBM метрики - https://www.scrum.org/resources/evidence-based-management.

Часть из них как раз сводятся к возможности быстро придумывать и проверять гипотезы в запутанном домене.

Доброго времени суток. Относительно недавно вручили должность "тимлид".
Как бы организовать структуру it отдела.
Имеются на данный момент 3-4 основных проекта.
По штату 3 человека и все фуллстаки.
1)Первое предложение было в том,чтобы набрать специалистов (фронт\бэк),а не фуллстаков и давать им таски с разных проектов.(условно 2 одновременных проекта)
2)Либо Закрепить за проектом фуллстака(ответственного) и под ним уже будут фронт\бэк на поддержке
Или как правильнее организовать эти моменты? 🤔

Попробуйте обсудить с текущими сотрудниками предпочитаемую ими форму работы

Чтобы не оказалось, что кому-то из них не хочется никаких за ним закрепленцев

Или переключаться между проектами - это не то, о чем они мечтали

А еще можно предложить им ротироваться с некотрой периодичностью. Условно раз в 2 - 3 месяца, в зависимости от сложности проектов. Каждый в этот период отвечает за конкретный проект, таски по этому проекту для него являются приоритетными, если загрузки на текущем проекте нет, но есть проблемы на соседнем, то подключаться туда.
В зависимости от стабильности проектов можно варьировать приорит багов над фичами. Вплоть, до того, что пока есть баги никто не пилит фичи в проектах. Мы так живем и мне как рядовому разработчику такой подход нравится. Опять же снижается "автобусный фактор".

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

Чем компания занимается?

изначально как "веб студия"
Но есть свои проекты,приходят со стороны.
В целом разработка ИС. 🌚

Каждому фулстеку по проекту, на выбор.

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

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

звучит здраво