Післяпроектна зустріч марно?

В моєму місці роботи у нас були серйозні болі в зростанні. Ми перейшли від команди розробників від 3 до 10, а сама компанія зросла на 30% за останній рік. За більшістю вимірювань у нас добре. На жаль, якість нашого програмного забезпечення постраждала.

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

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

Отже, моє запитання: я бачу, що цінність зустрічей після проекту, але він цього не робить. Чи є підтверджені документально підтверджені зустрічі після проекту, які допомагають заощадити час та гроші в довгостроковій (або короткій) перспективі? Інтуїтивно я думаю, що це буде / хотілося б, але він, очевидно, більше переживає невелику кількість часу, що не підлягає оплаті, від 5 людей, які там повинні бути.

Озирнувшись назад, Погляд вперед був би близьким до документального підтвердження ідеї. Проект "Посмерм": цінним інструментом для постійного вдосконалення буде публікація в ньому.

У Art Of The Post-Mortem є така ідея щодо ідеї:

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

Ваш менеджер не розуміє поняття Технічний борг .

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

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

Це, по суті, огляд після дій , який особливо корисний у багатьох різних контекстах, а не лише у військових.

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

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

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

Хоча це спеціально не документація, огляд процесу (під час або після його завершення) є головним компонентом майже кожної системи менеджменту якості, заснованої на стандартах, особливо CMMI та Lean 6 Sigma.

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

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

Однією з причин того, що якість може страждати, є те, що спілкування між 10 людьми набагато більша проблема, ніж спілкування між 3 людьми: 3! << 10 !. Незважаючи на те, що ви, мабуть, зможете поспішати на деякий час, вам, зрештою, доведеться внести деякі зміни, щоб сприяти кращій комунікації серед розробників та переконатися, що принципи, встановлені оригінальними 3 розробниками, поширюються на новіші люди та оновлені, щоб добре працювати у вашій новій більшій групі. Проекти посмертних зустрічей - це один із способів цього зробити; періодичні огляди коду - ще одне. Не завадить зазначити, що післяпологові зустрічі є важливою частиною поліпшення якості в галузях від медицини до виробництва.

Важко уявити, що ваш менеджер вважає, що він може розширити свою команду з розвитку, просто найнявши додаткових людей. Повинні бути певні інвестиції в тренування та побудову команди; без цього ваша організація розвалиться під власною вагою. Якщо ви зачекаєте трохи часу, ваша організація може почати відчувати певні конкретні проблеми, безпосередньо пов'язані з поганим спілкуванням. У цей момент ваш менеджер, ймовірно, скаже: "Ми мусимо всіх вивести на одну сторінку! Заплануйте зустріч з усіма розробниками!" І якщо, здається, це допоможе, він, мабуть, скаже: "Ми повинні робити це після кожного проекту!" ;-)

Отже, будьте терплячі, але будьте наполегливі.

Я підірву тенденцію: я згоден з менеджером.

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

Найбільш настійно рекомендую періодичні ретроспективи, виконані під час проекту. Раз чи двічі на місяць команда розмовляє про те, що пройшло добре, а що не вдалося; що робити більше, що робити менше. Зробіть це під час проекту, щоб ви могли негайно застосувати пропозиції та побачити, наскільки вони добре працюють.

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

Запросіть вас на зустріч (попросіть його головувати / поміркувати), розіслати порядок денний та мати конкретні результати. Як менеджер, він може побачити цінність на нараді.

Ми використовуємо, і я рекомендую процес огляду "6 капелюшків мислення" де Боно ( див. Wikipidia ). Результатом є декілька (2 або 3) пунктів дій, які зустріч визначає як найбільш важливий досвід. Перші кілька разів у нас виникають проблеми з виходом із стартових блоків, але коли ми звикли до цього, ми не повернемося.

Невиконання огляду після проекту прирікає вас робити ті самі помилки, які ви робили в попередньому проекті.