Ефективні зустрічі команди

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

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

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

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

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

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

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

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

У retros , де я працюю, ми будемо мати три колонки на дошці, як правило , поставивши смайлик, Хутро та сумне обличчя у верхній частині, наприклад :), :|і :(. Тоді члени команди мають помістити на дошку все, про що вони хотіли б поговорити з усією групою.

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

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

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

Після того, як всі записують запропоновані теми на дошці, мені подобається коротко переглядати кожну тему і дозволити її автору дати пояснення 10–30 секунд. Цей розділ наради легко зірвати, так що вам доведеться бути обережними, щоб люди не були на темі - наприклад, хтось скаже, що Х виникла проблема, а хтось ще починає говорити про вирішення проблеми; рішення не слід обговорювати до голосування. Вводячи теми, ви можете знайти способи групування кількох, тісно пов'язаних між собою тем.

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

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

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

Ласкаво просимо у світ середнього менеджменту!

Ви збираєтесь знайти такий тип проблем, які трапляються багато!

У вас є 3 варіанти:

Big Stick Зробіть це, або вас звільнили - ніколи не виходить. Не робіть цього.

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

Говоріть невисловлене З того, що ви сказали, всі нудьгують - тоді чому б не запитати у них? Тобі нудно ? / Це ​​марнотрата часу тощо. Чому ми чуємо? Яка цінність у цьому?

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

Спробуйте надати розробникам більше цінності на ваших зустрічах. Кілька прикладів може бути:

• короткі демонстрації, що демонструють нові функції, розроблені в недавньому спринті. (представлено всіма)
• дискусія, засвоєна уроками, в якій вони мають шанс змінити спосіб роботи команди та вдосконалитись (дискусія привела вашу праву руку в команду, і ви там, щоб обґрунтувати свої управлінські рішення. Подібно до сеансу вентиляції 1 на 1 але більший)
• лекція про новий проект з відкритим кодом, який може бути актуальним або іншою мовою кодування, наприклад функціональною Lang або Golang, або зеленими нитками в python. (можливо, представлена ​​одним із молодших розробників або у вигляді інтернет-відео)
• дискусія під керівництвом інженера з продажу опису жахливо складної інженерної проблеми, яку намагається вирішити його клієнт. (така ж угода з менеджером із підтримки / послуг, який намагається зменшити витрати на підтримку, покращивши зручність використання продукту)
• управління, яке розкриває різні стратегічні альтернативи, які компанія могла б прийняти, і як це вплине на інженерію з огляду на конкурентний ландшафт.
• зовнішній радник, який проводить консультаційні сесії з технологій, які ви вже використовуєте, але не до максимуму (зазвичай nosql, cep, RDBMS, мережа, безпека, моніторинг ...)
• проходження коду, в рамках якого кожен може дізнатися нові кодування чи налагодження чи тестувати поради щодо продуктивності (від того розробника, який має 10-кратну продуктивність).
• сеанс кодування, де миша не дозволена. Дізнайтеся про ярлики IDE дуже цікаво.
• розмова бухгалтера з грошей 101 пов'язані питання пенсія, інвестиції
• поговоримо про соціальне програмування та кар'єру (обмін стеками, щебетання, github, особисті блоги, LinkedIn, зустрічі у вашому регіоні)

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

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

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

• Нехай ваші зустрічі будуть короткими
• Використовуйте програмне забезпечення для управління проектами
• Тримайте це особисте, цілеспрямоване та зв’язуйтесь із емоціями та цілями
• Вирішення проблеми у фокус-групах, а не на форумах
• Отримайте відгуки від однолітків

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

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