Комментарии 16
Много хочется оставить комментариев и вопросов, но начну с малого:
Диаграммы выглядят симпатишно. Какой инструмент Вы использовали для них? Давно искал что-нибудь подобное для себя. Надеюсь, что пригодится.
Почему на рисунках 6 и 7 указана связь между размером/количеством бэклогов и объёмом WIP (по крайней мере, я так её понял)? Ведь наиболее популярные фреймворки типа Scrum/Kanban имеют механизмы для блокировки этого перехода. Пускай в бэклоге 100500 задач, но в спринт попадут только те, что влезли в лимит по SP, а про остальные мы можем до поры до времени позабыть (в идеале). Можете пояснить этот переход?
По моему субъективному опыту, возможным блокером на пути эффективной взаимопомощи в команде может выступать прессинг со стороны "максимальной утилизации рабочего времени". Вася, может, и рад был бы помочь Пете - вот только тогда он не успеет продвинуться по свооим задачам, которых ему самому накидали под завязку. Будь у них некий запас времени, они могли бы помочь друг другу в сложных местах и справиться вместе быстрее, чем по отдельности. Но под прессингом "утилизации" это становится более рискованно, и объём взаимопомощи начинает стремиться к нолю. Как Вы относитесь к этому вопросу?
Miro я использую ) Оригинальные диаграммы выглядят вот так https://miro.com/app/board/uXjVOPLM6Bc=/?invite_link_id=869342936762. Просто потом их забрал дизайнер и перевел на свой, на дизайнерский )
И в Kanban, и в Scrum действительно есть механизмы, позволяющие ограничить количество работы. В Kanban это WIP-лимит. В Scrum не так явно, но в качестве такого ограничителя используется Velocity. Однако, и WIP-лимиты, и Velocity действуют в рамках одной очереди. И если очередей много, то и задач, находящихся в работе, тоже много. WIP-лимиты, что Velocity не могут повлиять на количество очередей. Только на количество задач в очереди. Чтобы ограничить очереди нужно что-то большее. Например Whole Product Focus. При этом WIP-лимиты и Velocity так же могут применяться в качестве ограничителя работы но на другом уровне
Тут надо просто для себя решить, что важнее. Если важнее по максимуму утилизировать рабочее время, вам не нужны ни кросс-функциональные команды, ни Whole Product Focus. Если же важна скорость - не надо гнаться за высокой утилизацией ) Есть прекрасная метафора, объясняющая это - автострада. Когда автострада утилизирована на 100%, машины на ней стоят. Хотя занято все пространство. Когда автострада полупустая, машины проезжают по ней очень быстро. Просто решите что важнее для вас - быстро ехать и иметь полупустую автостраду или стоять, но зато все пространство использовано )
> прочитав эту цитату Кони Бюрера, который работал в Rational Software ...
это сразу зацепило (clasp), статья приятная, чувствуется личный опыт, также прочитал Ваше интервью 30.03.2022, тоже интересно, если позволите вопрос по мотивам вашей статьи:
Не строите ли Вы тем самым новую систему Тейлора в программировании?
Много разумного о скорости создания ценности, но не заметил ничего про творчество.
Я же менеджер. Конечно я смотрю на Тейлора если не как на икону, то уж точно с глубоким почтением :)
Что же касается творчества... Прекрасно, когда творчество находит себе место в инженерии. Но если смотреть на программную инженерию как на инструмент бизнеса, то постановка творчества во главу угла, на мой взгляд, может привести к краху этого бизнеса
спасибо, примерно такой ответ ожидался, на основе личного опыта попробую объяснить возможную проблему, типа мысленный эксперимент, предположим Вам дали достаточно большой бюджет (абстракция), и предложили построить серьезный бизнес с нуля (скажем уровня Rational Software), типа carte blanche, но поработав на подобных принципах (Тейлора), вероятно наиболее способные и ценные люди быстро уйдут, это касается и инженеров и менеджеров, типа двинут свои системы изобретать, полагая что сделать это могут не хуже Вас, это довольно реальная ситуация (хотя возможно не для России), в компании останется средний уровень, сможете ли Вы быть конкурентоспособным (за счет организации) без своих наиболее талантливых сотрудников?
ps
одно возможное решение мне известно
Сложно без талантливых людей.
Впрочем, и тейлоризм, раз уж туда понесло, и современные подходы к организации производства превозносят такие штуки как эмпирический контроль и лучшие практики. Может быть, таланты направить в эту строну? Иначе непрерывное улучшение невозможно. А кто, если не самые талантливые, способны привнести эти самые лучшие практики? Вот пусть и занимаются :)
что приходилось видеть это массовые H1B визы, примерно так еще у Henry Ford было, поток эмигрантов вертит привод экономики, imho если в us компания делает много H1B, это всегда должно настораживать, в России конечно условия другие, поэтому не берусь судить, но вероятно выгорать люди будут, обычно далеко не худшие, к сожалению все (мне известные) современные подходы к разработке sw имеют эту особенность
ps
если хотите совет - подымите все что найдете в части управления большими разработками в IBM, mitre, и пр. начиная с "mythical man month", уровень сложности сравнимый
.
Хочу сказать спасибо за статью и за сервис "Золотая корона".
В текущей ситуации - сильно выручает.
:-)
Собственно, большАя часть рекомендаций — а-ля, взаимопомощь, широкие компетенции и т.д. — это же в чистом виде Голдраттовский посыл расшивать критические участки. Иначем мы действительно не производим ценность, а хороним ресурсы в незавершенном производстве.
Причем, если для материального производства — эти похороненные детали и полуфабрикаты еще можно надеяться достать, отмыть и пустить в работу — то в программировании прогаженное время вернуть нельзя никаким способом!..
Я не знаю почему. Учитывая что компонентный состав бэклога меняется, степень загрузки ресурсов меняется следом, у меня то через одних критический путь проходит, то через других.
Я выстраиваю найм, видя где густо, но понимаю что с точки зрения того же системного мышления это Quick Fix.
А системного решения у меня нет, кроме тишэйпа и по компонентам, и по областям требований.
Таким образом, можно закомплектовать цепочку производства таким образом, чтобы узким местом были, например дизайнеры. И дальше — мы уже не бегаем и не добавляем дизайнеров — а строим вокруг них все по книге: буфер перед, барабан-веревка. Либо, например, бэкэнд — и тогда уже строим все вокруг него… Ну или юристы…
Потому что если мы будем бесконечно бегать и расшивать — то рано или поздно мы упремся в ресурс на который не можем воздействовать: емкость рынка, количество свободных денег, и т.д. Пусть лучше уж проблема будет в известном месте, чем каждый раз за ней гоняться!
А у T-shape есть другая проблема — и она в «Критической цепи» упомянута. Чем больше у людей будет T-shape, тем больше у руководителей будет соблазна устроить им мультитаскинг. И тогда вместо трех решенных задач стоимостью 1 человеко-месяц при последовательном решении — будет три нерешенных за те же три календарных месяца. И уж вот этот эффект я готов лично подтвердить как доказанный!
Интересно что в статье не вижу никаких упоминаний о влиянии на качество результата и работы с рисками.
По моему мнению, в больших командах многие процессы замедляются из-за размытия отвественности за качество и/или риски. И чтобы принять на себя ответсвенность за какаую-то часть работы я буду 100500 раз перепроверять входящие запросы и уточнять детали.
Именно поэтому PoC, MVP и т.п. создаются небольшими командами быстро. А через 5 лет жизни продукта, компания вырастает в сотни подразделений и проблемы не решаются годами.
Возможно, связь между узлами «Количество задач в работе» и «Cycle Time» покажется контринтуитивной. Однако теория массового обслуживания объясняет, почему данная связь верна [13].
В данном случае это не совсем верно потому что несколько команд, каждая из которых работает по своему бэклогу — это не одна система, а несколько (хотя внутри каждой системы все будет верно).
Вторая причина почему закон Литтла будет применим на масштабе компании только ограниченно — он применим только для стационарных систем. Иными словами только для системы, в которой все задачи, которые попадают в бэклог будут обязательно выполнены и именно в том порядке, в котором они попали в систему.
При этом он отлично применим для количества задач, над которыми команда работает в каждый отдельный момент времени, или для общего бэклога, про который говорится в статье.
Но сама по себе идея общего бэклога очень интереснас, спасибо за статью!
Вы правы, в случае когда у команд свои бэклоги, любые попытки оптимизации системы в целом имеют неиллюзорные шансы на провал. Согласно принципу эмерджентности. До тех пор, пока мы не начнем оперировать одним бэклогом. Это сложно, но оно того стоит.
По второму комментарию - да, возможны ситуации, когда второй элемент бэклога будет выпущен раньше первого, просто потому, что там работы меньше... Думал-думал что с этим делать, и решил, что и черт с ним. Освободившаяся команда либо поможет побыстрее выпустить первый, либо возьмет следующий по приоритету. На практике (в моем бизнесе) первые 10 элементов бэклога, обычно, имеют +- одинаковую ценность
Заметки о (не)эффективности