Один день в Одесі, або WebCamp 2014. Project Day
23 липня 2014 року. Один день, присвячений питанням, пов’язаним з керуванням проектами. На конференцію поїхали втрьох — Олег Антонюк, Діма Коваленко та Ігор Федун. Вісім годин в потягу, і привітна Одеса зустрічає нас теплим сонечком та беcхмарним небом.
Відстань до місця проведення конференції була приблизно 2 кілометри, але ми прибули у місто досить піздно і вирішили поїхати на маршрутці. Те, що ми не місцеві, всі зрозуміли одразу, коли я намагався оплатити проїзд прямо при вході. В Одесі спочатку стільці, а потім вже гроші :).
Конференція проходила в HUB Odessa. Це унікальне місце для коворкінга. Доповіді проходили у два потоки і розташовувались відповідно на другому та третьому поверсі. Ми пройшли реєстрацію, випили кави та провели ранішній Stand Up, розподіливши хто і куди йде, щоб не залишити поза увагою жодну доповідь.
Коротко оглянемо кожну доповідь.
World of Agile: Kanban
Паралельно із методологією Scrum існує ще одна досить цікава система під назвою Kanban. Основна ідея полягає в ощадливому і вчасному виробництві. Вона починає свою історію з заводу Тойота, де з метою оптимізації виробництва планування відбувалось по картках, на яких писались поточні замовлення, необхідні для безперебійного складання автомобілів. Щоб зрозуміти ідею, розглянемо спрощений приклад: майстер по збірці має в цеху 10 дверей. Коли залишається лише 5, то він пише на картці замовлення ще на 10 дверей. Таким чином, коли в нього закінчуються всі двері, йому підвозять нову партію — виробництво не припиняється. Тобто в кожен момент часу в цеху має бути рівно стільки деталей, щоб забезпечити безперебійне складання автомобілів.
Система Kanban з часом стала дуже популярною і впроваджувалась у різних галузях, включаючи IT. Розглянемо основні відмінності від Scrum:
- Kanban більше орієнтується на якість, ніж на оцінку часу. Замість годин використовуються бали складності. Junior-розробник і middle-розробник можуть виконати завдання на 5 балів за 2 і 1 день відповідно, але складність буде одна;
- Спрінти необов’язкові – менеджер оцінює доцільність їх використання. Для розмежування важливих етапів розробки можна використовувати, наприклад, версії;
- Оцінка завдань необов’язкова;
- Щоденні збори (stand up) необов’язкові;
- Ітерації необов’язкові.
- Один головний офіс;
- Декілька офісів iз координацією центрального;
- Декілька офісів iз самоуправлінням.
- Структурувати спілкування між командами;
- Створювати і використовувати карту контактів;
- Працювати і спілкуватись у певному ритмі (зранку спілкуємось, вдень працюємо і не відволікаємось);
- Впроваджувати «тихий» час (ніхто не відволікає, команда сконцентрованна на виконанні важливих задач);
- Розвивати спілкування і довіру у команді (придумати «план» приходу нового працівника).
- узагальнюйте контекст і виділяйте базові домовленності;
- швидкий дзвінок (замість переписки) економить багато час;
- потрібен постійний канал відеозв’язку;
- якщо немає можливості спілкування online, то знімаються відео;
- правильні інструменти комунікації: Skype, Google Hangouts, Lync, Webex, Mural.
- Це зберегло час на переробку функціонала;
- Це зменшило загальну кількість завдань;
- Результат формувався більш очікуваним для користувачів;
- Розробники разом з користувачами змінювали User Stories за новими вимогами і кінцевий продукт ставав більш технологічним.
- Впроваджувати систему прямих продажів, використовувати холодні дзвінки;
- Ціль — успіх клієнтів (виправдання очікувань)? і ця ціль є спільною для кожного учасника команди;
- Відкритість — будь-які побажання, коментарі, зауваження від кожного учасника команди вислуховуються і обговорюються з клієнтом;
- Усі учасники команди рівні, незалежно від віку, досвіду роботи і т. д.;
- Анкетування для виявлення потреб і проблем в команді. Проводиться кожен місяць. Також практикуються бесіди керівника студії з кожним учасником один на один;
- Формувати позитивну атмосферу в команді і загальну ціль.
- Підвищення кваліфікації команди;
- Автоматизація всього, що тільки можливо;
- Впровадження CRM-системи;
- Прагнути до довготривалих відносин з клієнтом.
- Говори словами клієнта;
- Кажи йому те, що він хоче почути;
- Довідайся, що саме йому потрібно;
- Спочатку слухай, потім говори;
- Пропонуй вибрати з двох вигідних тобі варіантів.
Для впровадження методології Kanban необхідно мати дошку з трьома колонками: зробити, робиться, зроблено. За потребою додаються інші колонки. Можна використовувати як фізичну (з наклейками і маркерами), так і віртуальну (Trello або інше програмне забезпечення) дошки. Учасники команди самі вирішують, хто і що робить. Менеджер лише виставляє приорітети. Завдання потрапляють у колонку «зроблено» тільки за умови, що все протестовано і викладено у виробниче середовище. У випадку знаходження помилок старе завдання не повертається у першу колонку, а створюється нове.
Наша команда по розробці мобільних ігор вирішила використати Kanban при розробці Galaxy Recon (Android) і Nizam. Обрали сервіс Trello.com і розщирення Scrum for Trello. Оцінюємо завдання за складністю, проводимо щоденні зустрічі зранку з усіма учасниками команди, працюємо безперервно (без ітерацій і спринтів). В порівнянні із Scrum ми витрачаємо набагато менше часу на поточне планування і підготовку до нових спрінтів. Говорити про порівняння ефективності поки зарано, потрібен час.
Мотивація – погляд з точки зору IT
Тема, яка цікавить всіх менеджерів та директорів компаній. Але все вже давно сказано і розписано, і ця доповідь була не винятком. Основним інструментом для аналізу мотивації в колективі є піраміда Абрахама Маслоу.
Відповідно до цих критеріїв потрібно і підходити до мотивації працівників. Якщо немає нижнього рівня, то реалізація вищого не дасть необхідного результату.
Окремо можна виділити креативний підхід до реалізації певних пунктів, а саме побудова процессів у компанії в формі гри.
П’ять шляхів збільшити вашу продуктивність за допомогою розподілених команд
Розподілені команди — це команди, учасники яких працють в різних місцях (наприклад декілька офісів або деякі працівники працюють віддалено). Як компанії приходять до розподілених команд? Зазвичай вони проходять через три етапи:
Весь матеріал подавався на прикладі двох команд, які мали протилежні підходи щодо спілкування і взяємодії з іншими замовниками — Віларіба і Вілабаджо (по аналогії з селами у відомій рекламі). Перша команда майже не спілкувалась з клієнтом вживу і мала великі проблеми, а інша навпаки — робила все, щоб бачити і взаємодіяти із замовником кожен день.
Чому компанії приходять до розподіленних команд? Основна причина — міжнародний ринок талантів. У нашій студії ми також маємо віддаленних працівників. Щоб покращити ефективність роботи з розподіленими командами, було запропоновано:
Оскільки команди розподілені, то основний наголос потрібно робити на покращенні спілкування: впровадження постійного відеозв’язку, щоденні зустрічі команди із замовником. З кращою комунікацією буде можливо раніше виявляти проблеми і доносити їх до замовника.
Дуже сподобалась думка про те, що існує феномен «козлів»: якщо команда більше неділі не спілкується з іншою командою або замовником, то вона автоматично вважає їх винними у всіх проблемах і взагалі козлами :).
Доповідач виділив такі корисні поради для покращення якості комунікації:
Ідеальна команда: утопія чи реальність
Доповідачем була директор рекрутингового агенства Indigo Аня Стеценко. Всі ми розуміємо, що є певні оцінки роботи працівника, і кожна організація вибирає свою схему роботи. Основною схемою є робоча неділя з п’яти або шести днів, відповідно 40 або 48 годин. В цій ситуації виникає запитання: чи можна створити такі умови праці, коли немає фіксованого робочого часу і при цьому клієнту гарантується певні строки виконання робіт, а працівники отримують гідну оплату праці.
Аня розповіла про ті умови, які вона створила в себе на фірмі. Її працівники працюють за вільним графіком, отримують досить непогані гонорари та дозволяють собі піти у відпустку коли їм заманеться. Ця схема виглядає досить утопічно, і у слухачів, звичайно, виникло багато запитань.
Якщо підсумувати всі факти, можна сказати досить чітко — ідеальної команди не існує. Так, до такої схеми роботи потрібно прагнути, але все одно потрібні певні точки контролю працівників. Аня використовує метод ранішніх stand up-пів для цього. При вільному виборі часу відпустки у багатьох виникають певні складнощі з вільним часом, і людина починає витрачати його на власні потреби. В результаті це призводить до звільнення працівника. Деякі люди просто неможуть працювати у настільки вільних умовах.
Цікавим є факт, що вона допускає помилку працівника, навіть вважає її необхідною для того, щоб сформувати певні навички і створити комунікацію на фірмі. Вона допомогає в робочому процессі тільки тоді, коли людина сама підходить і просить про це.
Приховані резерви команди
Досить цікава доповідь, що показує системний підхід до завдання та певні рамки, які люди створюють самі для себе. У доповіді Михайло Попчук із Ciklum розповідав про реальний проект, в якому було дві команди — одна досить досвідчена із кваліфікованим керівником, і знаходилась вона в Європі, а другу формували вже в Україні. Завдання було створити проект на Unity3D із запланованим релізом на протязі 4-х місяців. Проблема була з підбором розробників на проект та складністю самого завдання. Коли стало зрозуміло, що організувати необхідну команду розробників у повному обсязі буде неможливо, менеджер проекту запропонував використати технологію управління Agile. Це призвело до супротиву зі сторони більш досвідченої європейської команди, адже вони завжди використовували звичайні методи роботи і вибирали собі завдання з власного розсуду.
Для того, щоб не призводити до конфлікту, було вирішено керувати командою розробників в Україні за допомогою Agile і не чіпати устрій команди в Європі. Першим кроком були сформовані завдання, розбиті на основні групи за критерієм важливості. Спланований перший спрінт та заплановано перше демо. Для проведення демо було організовано конференц-зв’язок, де були присутні всі люди, які мали використовувати це програмне забезпечення. І саме це демо призвело до необхідного прориву у розробці, що в результаті допомогло зробити проект вчасно. Коли команда почала проводити демо, по коментарям стало зрозуміло, що потрібно змінити вже, а що навіть не потрібно реалізовувати. Ось переваги:
Більш того, певна критика зі сторони працівників замовника спонукала розробників робити все краще та швидше.
Проект був завершений на протязі 2,5 місяців, замість 4-ох. Це настільки шокувало замовника, що він вирішив обов’язково запровадити технологію Agile і в європейскій команді.
Вся ця історія показує, як за допомогою простого підходу до керування проектом в команді розкрились певні приховані ресурси, які до цього не використовувались взагалі.
Як не потерпіти невдачу і зрости у перші 3 роки. Досвід розвитку компанії регіонального рівня
Дуже цікава доповідь була прочитана керівником компанії ADS group Дмитром Сусловим. Він в деталях розповів, як проходив розвиток і з якими проблемами зіткнулась його команда. Дмитро виділяє такі поради для підвищення ефективності компанії:
Найголовніше, що виділяє доповідач — це формування правильних очікувань у клієнта. Краще пообіцяти трохи довше, а зробити швидше — радить Дмитро.
Окремо потрібно виділити відношення до віддалених працівників (так званий freelance). Такі працівники не можуть бути повноцінними членами команди. У них просто немає мотивації працювати ефективно. Рішення просте: повністю відмовитись від послуг таких спеціалістів.
Під кінець доповіді Дмитро підсумував, які кроки необхідні для подальшого розвитку і підвищення ефективності компанії:
Переконання або як зробити клієнтів слухняними
Всі менеджери з продажу мріють про слухняного і багатого клієнта :). Але це тільки мрії. Які інструменти і які тактики потрібно використовувати для того, щоб клієнт працював саме з Вами та погоджувався на ті умови, які вигідні Вам?
Цікавий лікбез для менеджерів з продажу. А почути його з вуст Анастасії Берестової вдвічі приємніше.
Якщо зробити загальний підсумок цього дня, то можемо сказати напевне — відбудеться багато змін в нашій роботі. Багато речей, які ми почули, вже були нам відомі, але, як завжди, їх впровадження в реальне життя відкладалось на потім. Agile, Kanban — це прості методи керування проектом, які стовідсотково потрібно навчитись використовувати і навчити цьому наші команди. Один з головних висновків — зміни потрібно починати з себе. Саме менеджер може досить невимушено змінити підхід до нових та вже існуючих проектів, вивевши їх на нову ступінь якості.
