Чи існує коефіцієнт зв'язку між часом зустрічі та економією часу на розробку?

Я працюю над проектом, і ми проводимо регулярні (як правило, щотижневі) неофіційні зустрічі, де ми обговорюємо стан проекту та GUI його.

Я єдиний розробник там, інші 4-5 людей мають не ІТ-досвід.

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

Але оскільки ми про це говорили і заздалегідь виявили помилку, я можу її досить швидко змінити.

Роздумуючи над цим, я запитав себе, чи є фактор між часом зустрічі, коли йдеться про економію часу на розробку?

Наприклад, 1 хвилина часу зустрічі може заощадити X хвилин часу на розробку.

Якщо так, то це допоможе визначити, як часто і як тривати наші зустрічі.

(Просто для уточнення: я не хочу робити кращі зустрічі, навіть маючи змогу визначити приблизно тривалість зустрічей необов’язково. Мене найбільше цікавить, ЯКЩО існує зв’язок між часом зустрічі та часом розвитку! Моя причина запитати: цікавість! )

"Поки вони повинні бути, і більше не будуть".

Тут потрібно усвідомити, що час зустрічі до заощадженого часу на розробку аж ніяк не лінійний. Для вашої команди, для вашої компанії на цю тему 1 годину зустрічей може заощадити 2 години роботи на розробці. Якщо у вас 10 годин зустрічей, ще одна година зустрічей може заощадити 0 розробки. Пекло, це може врятувати вас -2 години роботи на розробці через перебої або вплив на мораль.

Врешті-решт, вся суть зустрічей полягає в тому, що спілкування та співпраця допомагають вам вчинити. Якщо зустрічі не допомагають вам зробити справи, їх слід вбити.

Не зовсім.

Розуміння замовника / зацікавленої сторони може заощадити час на розробку. І розмови повинні бути досить довгими, щоб полегшити розуміння. Але обговорення функції, яку ви вже передбачаєте зрозуміти, не обов'язково покращить ваше розуміння.

Якщо ніхто в кімнаті не має жодних підозр на нерозуміння або помилкові припущення, залиште приміщення. Штучне продовження "дискусії" з надією, що час зсуву і тиск виштовхне конфлікт і створить гармонію, безнадійно і деморалізує.

І пам’ятайте, що спілкування - це поєднання майстерності та удачі; дискусія не обов'язково передбачає спілкування (взаєморозуміння). У вас все буде краще, якщо ви будете висловлювати погані припущення, чим довше працюватимете в цій галузі, і тим довше працюватимете разом.

Тим часом "Спритність" може бути корисною.

Тримайте зустрічі "короткими" та впроваджуйте грубі інтерфейси користувача або макети якнайшвидше після кожної зустрічі - задовго до того, як ви навіть підозрюєте, що маєте повне розуміння. Ваші інтерфейси / макети слугуватимуть матеріалом для роз’яснення непорозумінь. Час між зустрічами допоможе кожному розжатитися та поміркувати над сказаним. І якщо ви реалізуєте свої матеріали, які показують і розкажіть у коді , ви також фактично почали розробку. (І ваш клієнт / колеги будуть в захваті від цього!)

І найгірший випадок, коли ви реалізували невеликий шматок видимого коду: Ви абсолютно не знаходяться на базі і ви викидаєте його. Але, якщо ви присвятили лише невелику кількість часу, інвестиції окупаються великими для роз'яснення грубих непорозумінь.

І пам’ятайте, що компанія не піклується про час розвитку ; це просто піклується про людину-час . (Як засіб обчислення загальної вартості , пам’ятайте, що ви.) Отже, вам потрібно шукати баланс, у якому час людини обмежений; не витрачений час на написання коду.

Я не вірю, що існує якась кореляція, яка може бути застосована загалом. Це дійсно залежить від зустрічі та того, що ти робиш там, які стосуються розвитку.

У ситуації, яку ви описуєте, за кілька хвилин ви перейшли від поганої або погано зрозумілої вимоги до кращої. Ми знаємо, що наявність хороших вимог безпосередньо впливає на час розробки.

Але що робити, якщо ваша зустріч була чимось на зразок зустрічі зі статусом компанії. Ви ділитесь хорошою інформацією, щоб ви знали, як працює компанія, знаєте про інші речі тощо. Але, здебільшого, це не вплине на час розробки вашого проекту. Весь цей час "витрачається" на його погляди з точки зору розвитку.

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

TL / DR: Залежить від наради, людей та цілей наради.