У першій частині ми розглянули класичні проблеми маленької команди під час стрімкого росту. Будь-який процес грунтується на декількох елементах - це інженерні практики, правильна конфігурація команди розробників для покращення їхньої взаємодії(внутрішня комунікація), якісна комунікація із замовником, беклог менеджмент, мотивація команди. Інженерні практики - це тема для окремої серії статей, тому тут ми не будемо їх досліджувати. Більш детально зупинемось на конфігурувавнні команди, покращенні комунікації із замовником і беклог менеджменті.
Починаємо покращувати процес
Перш за все потрібно розібратись з проблемою неоднорідності команди.
Звичайно, команді з 15 розробників добре мати наступну конфігурацію: 3 - 4 Senior Developer, один з яких бере на себе роль ліда, близько 5-ти Middle Developer - фактично це кістяк команди, спеціалісти, які беруть на себе велику частину роботи. Однак решта, як правило, це Junior Developers. Описана мною конфігурація - це просто приклад. Дуже часто навіть у команді з 15-ти розробників є 1-2 Senior, 2-3 Middle, а всі решта - це Junior розробники.
Таку команду слід розділити на умовні під-команди, у яких старшими розробниками будуть сіньйори і сильні мідли. Весь функціонал і завдання можна розділити між цими під-командами найоптимальнішим способом з мінімальною кількістю перетинів.
Оскільки найближчим часом команда виросте з 5-ти до 10-ти людей, давайте розглянемо потенційну конфігурацію такої команди:
Якщо раніше всю комунікацію на собі тримав Тім лід, то виникає нова проблема - як переконати сторону замовника комунікувати не з однією людиною, а відразу з декількома? Це складне питання і тут все залежить від менеджерських навичок Тім ліда.
Давайте попрацюємо з беклогом
Потреба у вирішенні цієї проблеми прийде сама собою - тепер у нас є декілька під-команд, які працюють одночасно і
хочуть мати хоча б один таск на перед. Таким чином ми приходимо до потреби підготовки списку завдань - беклогу.
Тепер Contact Person повинен виділяти певний час для того, щоб описувати завдання заздалегідь і виставляти
пріоритети завдань.
Тепер старші програмісти можуть обговорювати завдання з CP на крок вперед, що забезпечує постійну зайнятість команди.
Комунікації
Важливим елементом в роботі є налагодження якісної комунікації як всередині під-команд, між командами, між командами і
замовником. Ефективна комунікація - це завжди ключ до успіху.
Пам’ятайте, що можливість обговорити питання онлайн, використовуючи в тому числі і веб камеру - це найкращий і
найефективніший метод комунікації, і команда повинна обов’язково його мати.
Те, що замовник уникає мітінгів по скайпу(чи будь-якому іншому сервісу голосового і відео зв”язку), як правило не означає,
що він взагалі не хоче говорити з вами, скоріше за все у нього обмежений графік і він не хоче часто витрачати час на
розмови, а воліє вирішувати питання в чаті, чи в імейлах(він це може робити під час інших своїх обов”язкових зустрічей).
Постарайтесь переконати проводити хоча б один дзвінок в тиждень - скоріше за все замовник погодиться виділити 30 хв
в тиждень.
Є ще один дієвий метод - проявіть ініціативу, заплануйте дзвінок(попередньо погодивши день та час), зіславшись на те,
що у вас є питання, які довго описувати, і краще обговорити. Повторіть це декілька разів і побачите, що це ввійде у норму.
Якщо ж замовник з легкістю йде на контакт - використовуйте це по повній, старайтесь проводити статус мітінги і тримайте
зв’язок як лиш можна часто.
Чат і імейл повинні використовуватись не лише для задавання запитань. Цей інструмент можна використовувати і для
статус сесій - старайтесь кожного дня інформувати замовника про поточний статус роботи - таким чином ви попередите
багато проблем і запитань.
Трошки про мотивацію
Чого ми досягли?
Отже, давайте переглянемо, чого ми вже досягли. Ми маємо команду, що має хорошу незалежну структуру і яка може функціонувати без прямого втручання тім ліда. Ми маємо беклог, в якому для кожного дева є мінімум один таск, який можна брати в розробку, крім того є виставлені пріоритети. І є налагоджений процес комунікації, який дозволяє обговорювати беклог і поточний статус розробки. Як все це об'єднати в єдину систему - про це ми поговоримо в третій частині статті.
Можлива і будь-яка інакша конфігурація, головне, щоб велика команда була розділена на менші. Таким чином старші
розробники відповідають за розробку і комунікації у під-командах, Сіньйор-розробники можуть бути як старшими
розробниками, так і бути поза командами (тех лідами, чи окремими одиницями), а Тім лідер відповідає за команду
в цілому.
розробники відповідають за розробку і комунікації у під-командах, Сіньйор-розробники можуть бути як старшими
розробниками, так і бути поза командами (тех лідами, чи окремими одиницями), а Тім лідер відповідає за команду
в цілому.
Чим це добре? Уявіть, що у джуніор розробника виникає певна проблема, він не піде одразу до Тім ліда, він звернеться
до старшого розробника. Якщо старший розробник не зможе допомогти, він звернеться до Senior розробника, чи тім
ліда. Таким чином, швидше за все, до Тім ліда будуть доходити лиш найскладніші питання.
до старшого розробника. Якщо старший розробник не зможе допомогти, він звернеться до Senior розробника, чи тім
ліда. Таким чином, швидше за все, до Тім ліда будуть доходити лиш найскладніші питання.
Під-команди стають відповідальними за цілі блоки функціоналу і всі взаємозв”язки будуть вирішуватись всередині
команди, тобто будуть накопичувати знання всередині команди, що краще, ніж якщо цими знаннями володіє лиш одна
людина. Насправді ми ще не повністю вирішили проблему з кількістю автобусів, тому, що завдання все ще отримують
окремі розробники, а не команда в цілому, однак ми вже на вірному шляху.
команди, тобто будуть накопичувати знання всередині команди, що краще, ніж якщо цими знаннями володіє лиш одна
людина. Насправді ми ще не повністю вирішили проблему з кількістю автобусів, тому, що завдання все ще отримують
окремі розробники, а не команда в цілому, однак ми вже на вірному шляху.
Створення під-команд дає можливість кожному члену команди займатись своєю роботою і це дуже важливо.
Як переконати замовника у необхідності змін?
Якщо раніше всю комунікацію на собі тримав Тім лід, то виникає нова проблема - як переконати сторону замовника комунікувати не з однією людиною, а відразу з декількома? Це складне питання і тут все залежить від менеджерських навичок Тім ліда.
Найкращим підходом є відкритість - описати всі ці проблеми і запропонувати своє рішення. Це можливо зробити
спочатку у режимі онлайн мітінгу, де Ви продемонструєте презентацію - слід не полінуватися і зробити гарну презентацію
зі слайдами і схемами і пояснити свою позицію і думку, а потім відправити email з повним описом. З таким підходом і
наполегливістю скоріше за все з вами погодяться. Команда і Contact Person(s) починають працювати за новими
правилами і здобувати новий досвід.
спочатку у режимі онлайн мітінгу, де Ви продемонструєте презентацію - слід не полінуватися і зробити гарну презентацію
зі слайдами і схемами і пояснити свою позицію і думку, а потім відправити email з повним описом. З таким підходом і
наполегливістю скоріше за все з вами погодяться. Команда і Contact Person(s) починають працювати за новими
правилами і здобувати новий досвід.
На мою думку всі проблеми слід вирішувати по черзі і пам”ятати, що не варто поспішати з наступними кроками. Тому не
поспішайте вирішувати наступні проблеми, попрацюйте в новому режимі хоча б місяць, звикніть до нових реалій,
придивіться до нових проблем. Процес адаптації дуже важливий і принесе купу нових ідей і досвіду.
поспішайте вирішувати наступні проблеми, попрацюйте в новому режимі хоча б місяць, звикніть до нових реалій,
придивіться до нових проблем. Процес адаптації дуже важливий і принесе купу нових ідей і досвіду.
Давайте попрацюємо з беклогом
Потреба у вирішенні цієї проблеми прийде сама собою - тепер у нас є декілька під-команд, які працюють одночасно і
хочуть мати хоча б один таск на перед. Таким чином ми приходимо до потреби підготовки списку завдань - беклогу.
Тепер Contact Person повинен виділяти певний час для того, щоб описувати завдання заздалегідь і виставляти
пріоритети завдань.
При виставленні пріоритетів зачіпається ще одна сторона - бізнес. Дуже часто команда замовника повинна поспілкуватись
зі своїми замовниками для розуміння вимог. В цей момент з’являється ще одна проблема - кінцевий замовник захоче
поцікавитись коли буде готовий функціонал. Тобто ми стикаємось з потребою в плануванні.
На цьому етапі можливе таке вирішення проблеми - CP готує завдання, TL надає приблизні естімейти, і на основі потреб
зі своїми замовниками для розуміння вимог. В цей момент з’являється ще одна проблема - кінцевий замовник захоче
поцікавитись коли буде готовий функціонал. Тобто ми стикаємось з потребою в плануванні.
На цьому етапі можливе таке вирішення проблеми - CP готує завдання, TL надає приблизні естімейти, і на основі потреб
кінцевих замовників і естімейтів робиться пріоритезація.
Вуаля, ми маємо пріоритезований, проістімейчений, зрозумілий беклог.
Тепер старші програмісти можуть обговорювати завдання з CP на крок вперед, що забезпечує постійну зайнятість команди.
Однак ми все ще обговорюємо завдання для кожного окремого розробника і при потребі(якщо немає достатньої кількості
завдань для розробників на крок вперед).
завдань для розробників на крок вперед).
Все, що нам залишається зробити - це забезпечити безперервну підготовку беклогу, його обговорення в незалежності від
завантаженості розробників.
завантаженості розробників.
Комунікації
Важливим елементом в роботі є налагодження якісної комунікації як всередині під-команд, між командами, між командами і
замовником. Ефективна комунікація - це завжди ключ до успіху.
Дуже класно, якщо замовник(тут і далі під словом замовник я буду розуміти не Замовника, як власника бізнесу, а контактну
персону, людину, яка відповідає на питання, менеджить розробку зі сторони вашого клієнта) легко йде на контакт, легкий у
спілкуванні і може без проблем переписуватись в чатах, проводити онлайн дзвінки, тощо. Однак бувають ситуації, коли вся
комунікація ведеться виключно в офіційній манері по електронній пошті і без можливості дзвінків, онлайн дискусій.
персону, людину, яка відповідає на питання, менеджить розробку зі сторони вашого клієнта) легко йде на контакт, легкий у
спілкуванні і може без проблем переписуватись в чатах, проводити онлайн дзвінки, тощо. Однак бувають ситуації, коли вся
комунікація ведеться виключно в офіційній манері по електронній пошті і без можливості дзвінків, онлайн дискусій.
Пам’ятайте, що можливість обговорити питання онлайн, використовуючи в тому числі і веб камеру - це найкращий і
найефективніший метод комунікації, і команда повинна обов’язково його мати.
Те, що замовник уникає мітінгів по скайпу(чи будь-якому іншому сервісу голосового і відео зв”язку), як правило не означає,
що він взагалі не хоче говорити з вами, скоріше за все у нього обмежений графік і він не хоче часто витрачати час на
розмови, а воліє вирішувати питання в чаті, чи в імейлах(він це може робити під час інших своїх обов”язкових зустрічей).
Постарайтесь переконати проводити хоча б один дзвінок в тиждень - скоріше за все замовник погодиться виділити 30 хв
в тиждень.
Є ще один дієвий метод - проявіть ініціативу, заплануйте дзвінок(попередньо погодивши день та час), зіславшись на те,
що у вас є питання, які довго описувати, і краще обговорити. Повторіть це декілька разів і побачите, що це ввійде у норму.
Якщо ж замовник з легкістю йде на контакт - використовуйте це по повній, старайтесь проводити статус мітінги і тримайте
зв’язок як лиш можна часто.
Чат і імейл повинні використовуватись не лише для задавання запитань. Цей інструмент можна використовувати і для
статус сесій - старайтесь кожного дня інформувати замовника про поточний статус роботи - таким чином ви попередите
багато проблем і запитань.
Трошки про мотивацію
Питання мотивування команди - це досить обширна і складна задача, яка потребує залучення великого арсеналу методів. Великою мірою - це задача ресурс менеджменту. Однак мотивація команди багато в чому залежить від практик які використовуються у процесі роботи, від їхньої ефективності і доцільності.
В загальному, ми будем опиратись на те, що всі члени команди достатньо мотивовані і роблять все для досягнення результату. Звичайно, що це ідеальний і дуже наближений світ, однак без цього неможливо побудувати систему.
Чого ми досягли?
Отже, давайте переглянемо, чого ми вже досягли. Ми маємо команду, що має хорошу незалежну структуру і яка може функціонувати без прямого втручання тім ліда. Ми маємо беклог, в якому для кожного дева є мінімум один таск, який можна брати в розробку, крім того є виставлені пріоритети. І є налагоджений процес комунікації, який дозволяє обговорювати беклог і поточний статус розробки. Як все це об'єднати в єдину систему - про це ми поговоримо в третій частині статті.
Comments
Post a Comment