Як проводити sync з командою на ремоуті: девелопери vs адмінстаф

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

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

Синки з девелоперами: що робити і як проводити

Вам подобається ходити на синки? А проводити?

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

1. Поспілкуватись з колегами і відчути, що ви не одні (у нас майже всі на ремоуті)
2. Дізнатись про новини і стадії вирішення поточних задач
3. Посилити слабкі місця: завчасно попередити спад ефективності, змінити процес, якщо видно його недосконалості.

Є базова культура синків, яка додає команді дисципліни:

1. Менеджер, який проводить синк, приходить вчасно.
2. Учасники синку приходять вчасно і не затримуються довше, ніж на 2 хвилини.
3. У час очікування команда може трохи потеревенити на особисті теми.
4. Є послідовність говоріння: всі знають, хто за ким ділиться новинами.
5. Є уточнюючі питання від менеджера по роботі кожного девелопера.
6. Є час повідомити про проблему і запитати в менеджера, як її вирішити.
7. Якщо щось змінюється в плані (дедлайн, скоуп, робочий час девелопера), це повідомляється відкрито.

І ще є три важливих менеджерських принципи:

1. Ми не сваримо на синках (і взагалі не сваримо публічно)
2. Ми хвалимо на синках (публічна похвала дуже мотивує)
3. Якщо у девелопера є проблема, її потрібно вирішити у зв’язці меджер+девелопер

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

1. Повторення задачі. Коли одна людина пояснила задачу, у якій задіяні інші, попросіть тих інших повторити, як вони зрозуміли, і одразу вкажіть на неточності.
2. Крок назад у бізнес-процес. Коли є різне бачення для рішення, варто повернутись до того, яку взагалі задачу ми маємо і як відбувається процес, для якого вона створена. Часто девелопери фокусуються на конкретних задачах, наприклад, підсвітити рядок червоним, якщо умова не виконана. Краще йти від більш загального процесу до конкретніших задач — дедуктивно, як Шерлок Холмс.
3. Follow-up email. Коли на синку про щось домовились, варто продублювати це емейлом, скоротиши його текст до мінімуму. Якщо ви більше спілкуєтесь в месенджерах, можна закинути фоловап туди, а не на пошту. Обов’язково вказуйте терміни виконання домовленостей.
4. 1-2-1 з девелопером. Ми можемо тільки здогадуватись, з ким ми працюємо, адже усвідомити іншу людину ще важче, ніж себе. 1-2-1 мітинги раз на місяць чи квартал, де менеджер просто говорить з девелопером, допоможуть краще зрозуміти один одного. Звертайте увагу на те, як людина формулює думку, яка її мотивація, що її надихає, а що втомлює, де її слабкі місця, у які моменти вона бреше. Все це допоможе пояснювати задачі майже мовою цієї людини.
5. Нічого особистого. Будуйте атмосферу в команді так, щоб підкреслено розділяти особисте і робоче. Якщо людина нафакапила в коді,вкажіть на це, але згадайте на синку, що в неї чудові фото з дитиною з вихідних. Покажіть людині, що ви не засуджуєте її як людину, коли вказуєте на помилки її як працівника. Ніколи не формулюйте своє недаловолення роботою команди в стилі «ви нічого не вмієте і знущаєтесь з мене». Використовуйте «я-повідомлення», наприклад не «ти зіпсував код», а «я незадоволений якістю твого коду».

Синки з адмінстафом: в чому відмінність

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

Синки з ними потрібні для того, щоб команда тримала темп. Натомість, коли ви говорите з девелоперами, їх не завжди варто перевантажувати даними в стилі «нам потрібно заробити в цьому кварталі стільки».

А може, зменшити кількість мітингів?

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

Це питання масштабу. Якщо ваша компанія налічує 30 програмістів, половина з яких — друзі, не обов’язково впроваджувати систему регулярних синків три рази на день. Якщо ви виходите на масштаб, ризики людського ресурсу починають зростати геометрично, тобто умовно одна помилка менеджера коштує $10 — коли у вас один проект, $20 — коли їх два, і $500 000 — коли проектів двадцять. На масштабі необхідно знижувати ризики, пов’язані з людьми. Синки, а до них летучки, наради, ради і т.д. в печерний соціум — інструмент для безпеки вашої системи.

Масштабуєтесь — синхронізуйтесь.