@Trihlorid6 авг 2024 в 10:24

Сколько раз в неделю – норма? О производственных совещаниях

Средний

5 мин

990

Управление разработкой *

Мнение

-1

Комментарии 10

@TIEugene 6 авг 2024 в 10:44

Вопросов возникает много, но обычно они решаются за 10-15 минут, не более того.

~~"Неправильно ты бутерброд ешь, дядя Федор..."~~ Немного не так.
Например я с утра покурил кофе, развернул IDE, отфильтровал багтрекер, спланировал работу на сегодня.
Потом согласно задачам на сегодня просмотрел код и разбил на микрозадачи.
Итого - загрузил "кеш" в моске. Оперативный кеш. Держится только в моске и только сегодня.
_Внезапно_ кому-то захотелось ~~потарахтеть~~ созвониться.
Если просто "как дела, чо-как, что сделано" - неприятно, но недорого. Cache L1 улетает в Cache L2, восстановление займет покурить 1 кофе.
Если по текущим задачам - ппц. Весь кеш слетает в ноль, По итогам "поговорить" - внести изменения в задачи, пересобачить приоритеты, перепланировать текущий день, перезагрузить моск. Пара часов.
Плюс 10-15 минут, ога.

@Trihlorid 6 авг 2024 в 10:59

Это так, состояние потока нарушается, как раз планировал обсудить порядок таких мелких созвонов в следующей статье.

@TIEugene 6 авг 2024 в 11:21

Там всё просто:
1. Созвоны не нужны. Разработчикам, по крайней мере. Все задачи ставятся в багтрекере и документации.
2. Если источник задачи не может внятно поставить задачу - ок, созвоны нужны. Раз в неделю, пол-часа, не более. Плюс письмо начальству "манагер не смог сформулировать, 2 часа потрачено в никуда".
3. "мелкие созвоны" - ну, я не знаю... "Мелкие созвоны" вышибают разработчика на пол-дня минимум. Какому-то манагеру захотелось потарахтеть - оно позвонило. Потарахтело 10 минут. И как потом доказать, что вышибло пол-дня работы? А никак. "Оно просило" - "не помню такого". Штраф.
4. Среди меня считается, что "созвон" - ни о чем. Потарахтеть можно. Только не долго и не каждый день. Все принятые задачи при созвоне должны быть зафиксированы "на бумаге" - багтрекер/электропочта. Источником беспокойства.

@Trihlorid 6 авг 2024 в 11:28

У всех всегда всё просто. А ошибки в программных продуктах из-за намеренного саботажа:))

@TIEugene 6 авг 2024 в 12:25

Отнюдь.
Начальник: Сколько надо для решить задачу?
Разработчик: Неделя
Н: Почему так долго??? Я это нарисую за 15 минут!
Р: я нарисую за 10. Но:
- тестирование
- dev => stage => prod
- документирование
- выдержка
Н: Ой, всё... 1 день, кароч
Р: как скажете

Да, саботаж. Заказчиком.

@drdim 7 окт в 18:45

Есть еще особенность разработчиков рефачить свой код каждые полгода. И каждый раз просить много времени, покрывать тестами, а через полгода говорить что сделана ерунда и все нужно бежать переделывать))) конечно не у всех и не всегда. И тут на помощь приходит тим лид и архитектор, и учат как минимальными усилиями переделать и так идеальный код. В целом количество созвонов тормозят рабочий просцесс. Я себя понял что больше 4 часов в день мозг не может эффективно кодить, но если правильно его организовать, эффективность как недельной работы. Кодить 8 часов невозможно. Считаю что встречи где обсуждаются схемы реализации, Дейли, обсуждение архитектуры можно включить в этот график.

Обычно с утра статус. Уточнение требований или обсуждение непонятных вопросов текущих задач и дальше работа. Скрам мероприятия выносятся в отдельные дни планирования и в середине спринта обсуждение беклога и его корректировка.

Обычно если укладываться до 2 часов суммарно все встречи - легче команде заниматься тасками.