Коли справа стосується людей та повторюваних дій завжди виринає “проблема процесів”, особливо в продуктовій та сервісній ІТ-розробці. Деяки учасники кажуть, що “правильні процеси” є ключом до ефектиної праці. Дехто апелює до того, що “правильна комунікація” передує процесам і є запорукою успішності. Треті доводять, що “правильна структура” колективів визначає і процеси, і комунікацію і результуючу ефективність їх роботи. Свідомо чи не свідомо, але ми все одно обираємо свою суміш процесів-комунікації-структури до якої і прикипаємо.
Інколи здається, що ми вже все знаємо і давно робимо речі єдиним правильним способом. В нас є досвід та приклади, є відповіді навіть на незадані питання, а резюме на лінкедіне так взагалі ого-го!
Але одного ранку ми починаємо ходити по колу, навіть не помічаючи цього, бо стали заручниками свого досвіду* (Джидду, ми все памʼятаємо) – і нічого нового вже з нами не трапляється, цікавість роботи тьмяніє, а результативність дрібнішає. Все як завжди – погодження вимог, каскадування задач, планування спринтів, милиці тут, трохи батога там, а на ретроспективі спробуємо не заснути. Гірше трапляється, коли наші правильні підходи не спрацьовують в нових колективах чи компаніях, але ми наполеглево продовжуємо їх практикувати.
Цей блог про речі, які допомогли мені якісно, а десь і кардинально поліпшити іт-розробку та ефективність командної роботи. Може вони і вам стануть у нагоді.
*найскладніше – це помітити ходіння колами, але коли вже усвідомив даремність, то вважай половина справи вже зроблена, допитливий далі сам розбиреться…
-
Компанії прагнуть розробляти класні Продукти, але покладаються на логіку розділяй-та-контролюй. Через це губляться сенси та затягується реліз продукта. Компаніям не потрібні кращі плани, їм потрібна спільна мова.
-
Оцінювання – містична командна практика, якої неможливо навчитися по книгах, лише між своїх колег та за сприятливих умов. Щоб вміти планувати, треба володіти доменом, мати досвід спільної роботи, сміливість щиро спілкуватись та відчуття власної приналежності до продукта(проєкта). Тоді може і спалахне між людьми та містична іскра, яка все осяє та склеїть, а команда почне легко влучати з оцінками.
-
Скрам Майстерство – це легка атлетика, а Аджайл Коучінг – одна з її спортивних дисциплін. Бо роль Скрам Майстра є основою професії, базовим поглядом на світ, на який намотуються менеджмент, коучінг, фасилітація.
-
Командної відповідальності не існує, проте існують конкретні фахівці з їх проблемами. Слід зосереджуватись на покращенні умов праці, збільшенні ресурсів та спроможні фахівців виконувати їх роботу, а ніж на пошуку винуватців та осуді. Замість відповідальності створюйте умови
-
1-2-1 (one-to-one, один на один), робоча зустріч, яка може рухати цілі команди. Задача зустрічі – допомогти вийти з професійного чи карʼєрного тупіка. Також такий формат допомагає фахівцям у профілактиці професійного вигорання, розвитку фахових навичок та вирішенню складних робочих конфліків. Запропонована техніка проведення 1-2-1 – пісковий годинник особистого та професійного. Задча ведучого – опитати героя та скласти комплексне враження про проблему. По закінченню вправи герой 1-2-1 самостійно сгенерує перелік дій, які допоможуть йому просунутись. Вмотивований фахівець просувається сам та рухає за собою команди.
-
Результатом воркшопа є чітко сформульована цінність фічі та пріорітезований план розробки. Розробники зможуть сфокусуватись на чітких пріорітетах та належно розпочати рефайменти, прототипування UI та підготовку до спринітв.
-
Просте моделювання складних ІТ-систем. Event Storming дає єдину мову для бізнеса та розробників, а формат онлайн воркшопа залучає всіх зацікавлених технарів, гуманітаріїв, домених експертів та менеджерів.
GRINCHY COACH - перезбираю продуктову розробку 