TGTGInsightаналитика telegramLIVE / telegram public index
← Системный сдвиг
Системный сдвиг avatar

TGINSIGHT POST

Post #468

@systemswing

Системный сдвиг

Просмотры3,880Количество просмотров
Опубликован10 сент.10.09.2024, 11:54
Содержимое поста

Содержимое

В обсуждении списывания времени проскочило совсем дикое сообщение, что в некоторых компаниях запрещают списывать время на совещания и созвоны. Как при этом набрать 8 часов, я не представляю. А те, кто это придумал, видимо, очень далеки от реальности, и уж точно не читали "Мифический человеко-месяц", с его клёвыми фразами типа "программирование — это не сбор хлопка, эту работу нельзя произвольно делить на любое количество частей, и не общаться в процессе". Вопросы синхронизации и изучения требований требуют времени. Возьмем строгий фреймворк, например Scrum, который обещает выполнение вдвое большей работы за половину времени (это так книга Сазерленда называлась, 'Scrum: The Art of Doing Twice the Work in Half the Time', это название даже испугались на русский переводить, перевели скромно как "Революционный метод управления проектами"). Вот смотрите, что говорит Scrum Guide для спринта длиной в месяц: 8 часов на планирование спринта; 5 часов на дейлики (15 минут в день * 20 дней); 4 часа — спринт ревью; 3 часа — ретро; 16 часов (10% спринта) — Backlog Refinement, совместная проработка требований всей командой (у вас вообще такое есть? Вы про эту практику слышали?..) Получается 124 часа в месяц, т.е. 6,2 часа в день на работу. Ну, в хороший день у меня тоже так и получается, и это, наверное, максимум, что можно выжать — реальной работы, я имею в виду. На самом деле, что означает 15-минутный дейли? Это значит, что про зависшую задачу ты успеваешь сказать, что она зависла, и тебе нужно обсудить её с тем-то и тем-то ➡️ назначается встреча для решения. Мы же не думаем, что вне ритуалов scrum люди между собой не общаются? Допустим, мы эти встречи тщательно таймбоксим, и их не бывает больше часа в день (ха!). Ещё к этому нужно приплюсовать (или вычесть) время на персональное развитие (1:1, составление планов, выбор конференций/обучения, планирование отпуска и т.п.), кофе и всякую текучку — отведем на это ещё час. Получается примерно 4 часа, что, по моей практике, выглядит уже довольно реалистичным. Не то чтобы это было хорошо. Но иногда и этих 4 часов нет — например, когда вам дали стажеров или нужно готовить выступление на конференции/внутреннем митапе. В том же скраме, раз мы про него говорим, такими вещами должен заниматься скрам-мастер — убирать из времени команды всё, что мешает (то мебель нужно в новом офисе расставить, то должностную инструкцию себе написать, то распланировать график отпусков на год — всегда есть, чем заняться). Но знают ли об этом люди, которые берутся трекать время? Мне кажется, первый шаг в любом деле — признание реального положения вещей. Ну не производят люди код или аналитические документы 5 дней по 8 часов. Вон и Scrum говорит — максимально теоретически возможное время — чуть больше 6 часов, к нему нужно стремиться. И это нормально. При объяснении теории ограничений (ToC) приводят такую аналогию, мне она очень понравилась: как быстрее всего вылить воду из бутылки? Просто перевернуть — вода будет булькать, выходить толчками, т.е., процесс будет регулярно останавливаться и перезапускаться. Если вы раскрутите бутылку и сделаете воронку — вода выльется почти вдвое быстрее, хотя в центре будет пустота — горлышко не будет заполнено. Можно вставить соломинку — горлышко ещё сильнее сузится, но в бутылку будет поступать свежий воздух, и поток станет равномерным. Если в соломинку ещё и подуть — скорость ещё увеличится. Парадокс: чтобы скорость была выше, часть горлышка должна оставаться свободной. Так и в управлении: ваша цель ведь не в том, чтобы загрузить работников на 100%, а чтобы работа делалась быстрее. Чем равномернее будет поток — тем быстрее получим результат работы. Да, для этого нужно дать приток свежего воздуха 😉 И не занимать полностью весь доступный ресурс. Всё равно не получится, будут остановки и перезапуски. Так не лучше ли это признать с самого начала, и сфокусироваться на гладкости и скорости потока, а не на загрузке людей?