Как повысить КПД разработки, используя теорию ограничений

[NGS_Shahimat]

Посоветую, если, внезапно, не знакомы с дальнейшими книгами Голдратта

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

Кроме того, критическая цепь, читать строго после цели-2, она чисто менеджероориентированная, весьма удачная книга, в ней вы будете оптимизировать не просто критический путь, но и критическую цепь! Без спойлеров, крайне годная литература, советую в принципе всем)

[Hardened]

В части D пусть бизнес оценивает upsale или изменение вероятности оттока в результате сдеданой / несделаной хотели. Дельта по риску на ARPU или LTV и даст вам оценку задачки D

[AndreyStrelnikov]

Спасибо, погуглим в эту сторону

[Hatifnatt]

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

[bondeg]

По сути эти задачи ничем не отличаются от остальных. Так же необходимо измерить эффект от изменений. Например, рефакторинг позволит делать типовые задачи на N часов быстрее, в беклоге X задач. Экономия Z человокочасов.

[bondeg]

*человеко-часов

[LarexSetch]

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

[AndreyStrelnikov]

Надо было начать с чего-то понятного и простого. Эффект от внедрения данной технологии планирования достаточно неожиданный — большинство заказчиков не могут рассчитать экономический эффект от реализации задачи. Соответственно, их задачи получают метку «Someday», и ждут. Далее, некоторые достаточно масштабные вещи (условно 100+ ч/ч), которые требуют предоставить в кратчайший срок, по факту экономят в год 30К рублей. Итого имеем проход, равный 0,3. И рядом задача с проходом 100. И все, никто ничего не может возразить. Эскалируют на руководство, руководство заворачивает :) Технические задачи оставил на третий этап внедрения, сейчас занимаемся категорией D — оценкой клиентских хотелок.

[diamFC]

Добрый день. Мы договорились с бизнесом на то, что 20% спринта тратим на задачи тех.долга. И бизнес вполне понимает эту необходимость.

[sshmakov]

пересекается с идеей nmivan https://habr.com/ru/post/466685/

[Valchuk]

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

[AlexeyPalatkin]

Идея очень похожа на подход к приоритетам по WSJF. Можно тут почитать jo.my/wsjf