Есть ли взаимосвязь между временем встречи и экономией времени на разработку?

Я работаю над проектом, и у нас есть регулярные (обычно еженедельные) неформальные встречи, где мы обсуждаем состояние проекта и его графический интерфейс.

Я там единственный разработчик, остальные 4-5 человек имеют не ИТ-образование.

Эта встреча заняла гораздо больше времени, чем обычно, но однажды один из моих коллег спросил о некоторых полях в программе и о том, как они заполняются. Я ответил, и в ходе дискуссии я заметил, что я совершенно неправильно понял процесс.

Но так как мы говорили об этом и нашли ошибку заранее, я могу довольно быстро ее исправить.

Размышляя об этом, я спросил себя, есть ли фактор между временем встреч, когда речь идет об экономии времени на разработку?

Например, 1 минута встречи может сэкономить X минут времени разработки.

Если это так, это поможет определить, как часто и как долго должны проводиться наши встречи.

(Просто для пояснения: я не хочу проводить более качественные встречи, даже возможность определить приблизительную продолжительность встреч не является обязательной. Меня больше всего интересует, есть ли связь между временем встреч и временем разработки! Моя причина спросить: любопытство! )

«До тех пор, пока они должны быть, и больше нет».

Здесь нужно понять, что время встречи с сэкономленным временем разработки не является линейным. Для вашей команды, для вашей компании, по этой теме, 1 час собраний может сэкономить 2 часа работы разработчика. Если у вас есть 10 часов собраний, еще один час собраний может сэкономить 0 разработчиков. Черт, это может сэкономить вам -2 часа работы разработчика из-за перерывов или влияния на мораль.

В конце концов, весь смысл встреч в том, что общение и сотрудничество помогают вам добиться цели. Если собрания не помогают вам что-то сделать, их следует убить.

Не совсем.

Понимание клиента / заинтересованного лица может сэкономить время на разработку. И разговоры должны быть достаточно длинными, чтобы облегчить понимание. Но обсуждение функции, которую вы уже предполагаете понять, не обязательно улучшит ваше понимание.

Если ни у кого в комнате нет подозрений на недопонимание или ложные предположения, покиньте комнату. Искусственно затягивая «дискуссию» в надежде на то, что время сдвига и давление вытолкнут конфликт и создадут гармонию, это безнадежно и деморализует.

И помните, что общение - это сочетание мастерства и удачи; обсуждение не обязательно подразумевает общение (взаимопонимание). Вы будете лучше выявлять неверные предположения, чем дольше вы работаете в поле и тем дольше вы работаете вместе.

В то же время, «ловкость» может быть полезным.

Сделайте встречи короткими и внедрите грубые интерфейсы или макеты как можно скорее после каждой встречи - задолго до того, как вы даже заподозрите, что у вас есть полное понимание. Ваш пользовательский интерфейс / макеты будут служить материалом для выяснения недоразумений. Время между встречами поможет каждому расслабиться и обдумать сказанное. И если вы реализуете свои показательные материалы в коде , вы также фактически начинаете разработку. (И ваш клиент / коллеги будут рады услышать это!)

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

И помните, компания не заботится о времени разработки ; это просто забота о времени человека . (Как средство расчета общей стоимости , имейте в виду.) Итак, вам нужно искать баланс, при котором человеко-время минимизируется; не время, потраченное на написание кода.

Я не верю, что есть какая-то корреляция там, которая могла бы быть вообще применима. Это действительно зависит от встречи и того, что вы делаете там, что связано с развитием.

В ситуации, которую вы описываете, через несколько минут вы перешли от плохого или плохо понятого требования к лучшему. Мы знаем, что наличие хороших требований напрямую влияет на время разработки.

Но что, если ваша встреча была чем-то вроде встречи статуса компании. Вы делитесь хорошей информацией, чтобы знать, как дела в компании, знать о других событиях и т. Д. Но, по большей части, это не повлияет на время разработки вашего проекта. Все это время «теряется», если смотреть на него с точки зрения развития.

После того, как вам приходилось ходить на достаточное количество собраний, вы начинаете понимать, что некоторые из них действительно продуктивны (например, взять небольшую команду разработчиков и хороший набор требований и начать доску архитектуры. Вы можете сделать многое, если сосредоточитесь .). Вы также найдете некоторые из них, которые вообще не являются продуктивными или даже имеют отрицательную производительность (однажды у клиента было 15-минутное обсуждение между несколькими из них относительно того, должна ли страница входа говорить «Вход» или «Вход». Конец этому никто не знал и это надо было подать на потом).

TL / DR: зависит от встречи, людей и целей встречи.