Один день в Одесі, або WebCamp 2014. Project Day

23 липня 2014 року. Один день, присвячений питанням, пов’язаним з управлінням проектами. На конференцію поїхали втрьох — Олег Антонюк, Діма Коваленко та Ігор Федун. Вісім годин в потягу, і привітна Одеса зустрічає нас теплим сонечком та безхмарним небом.

Відстань до місця проведення конференції була приблизно 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) необов’язкові;
• Ітерації необов’язкові.

Для впровадження методології Kanban необхідно мати дошку з трьома колонками: зробити, робиться, зроблено. За потребою додаються інші колонки. Можна використовувати як фізичну (з наклейками і маркерами), так і віртуальну (Trello або інше програмне забезпечення) дошки. Учасники команди самі вирішують, хто і що робить. Менеджер лише виставляє пріоритети. Завдання потрапляють у колонку «зроблено» тільки за умови, що все протестовано і викладено у виробниче середовище. У випадку знаходження помилок старе завдання не повертається у першу колонку, а створюється нове.



Наша команда по розробці мобільних ігор вирішила використати Kanban при розробці Galaxy Recon (Android) і Nizam. Обрали сервіс Trello.com і розширення Scrum for Trello. Оцінюємо завдання за складністю, проводимо щоденні зустрічі зранку з усіма учасниками команди, працюємо безперервно (без ітерацій і спринтів). В порівнянні із Scrum ми витрачаємо набагато менше часу на поточне планування і підготовку до нових спринтів. Говорити про порівняння ефективності поки зарано, потрібен час.

Мотивація – погляд з точки зору IT

Тема, яка цікавить всіх менеджерів та директорів компаній. Але все вже давно сказано і розписано, і ця доповідь була не винятком. Основним інструментом для аналізу мотивації в колективі є піраміда Абрахама Маслоу.



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

Окремо можна виділити креативний підхід до реалізації певних пунктів, а саме побудова процесів у компанії в формі гри.

П’ять шляхів збільшити вашу продуктивність за допомогою розподілених команд

Розподілені команди — це команди, учасники яких працюють в різних місцях (наприклад, декілька офісів або деякі працівники працюють віддалено). Як компанії приходять до розподілених команд? Зазвичай вони проходять через три етапи:

1. Один головний офіс;
2. Декілька офісів із координацією центрального;
3. Декілька офісів із самоуправлінням.

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

Чому компанії переходять на розподілені команди? Основна причина — міжнародний ринок талантів. У нашій студії також працюють віддалені співробітники. Щоб покращити ефективність роботи з розподіленими командами, було запропоновано:

• Структурувати спілкування між командами;
• Створювати і використовувати карту контактів;
• Працювати і спілкуватись у певному ритмі (зранку спілкуємось, вдень працюємо і не відволікаємось);
• Впроваджувати «тихий» час (ніхто не відволікає, команда зосереджена на виконанні важливих завдань);
• Розвивати спілкування і довіру в команді (придумати «план» приходу нового співробітника).

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

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

Доповідач виділив такі корисні поради для покращення якості комунікації:

• узагальнюйте контекст і виділяйте базові домовленості;
• швидкий дзвінок (замість переписки) економить багато часу;
• потрібен постійний канал відеозв’язку;
• якщо немає можливості спілкування online, то знімаються відео;
• правильні інструменти комунікації: Skype, Google Hangouts, Lync, Webex, Mural.

Ідеальна команда: утопія чи реальність

Доповідачем була директорка рекрутингового агентства Indigo Аня Стеценко. Всі ми розуміємо, що є певні оцінки роботи співробітника, і кожна організація вибирає свою схему роботи. Основною схемою є робочий тиждень з п’яти або шести днів, відповідно 40 або 48 годин. В цій ситуації виникає запитання: чи можна створити такі умови праці, коли немає фіксованого робочого часу і при цьому клієнту гарантуються певні строки виконання робіт, а співробітники отримують гідну оплату праці.

Аня розповіла про ті умови, які вона створила у себе на фірмі. Її співробітники працюють за вільним графіком, отримують досить непогані гонорари та дозволяють собі йти у відпустку, коли їм заманеться. Ця схема виглядає досить утопічно, і у слухачів, звичайно, виникло багато запитань.

Якщо підсумувати всі факти, можна сказати досить чітко — ідеальної команди не існує. Так, до такої схеми роботи потрібно прагнути, але все одно потрібні певні точки контролю співробітників. Аня використовує метод ранкових stand up для цього. При вільному виборі часу відпустки у багатьох виникають певні складнощі з вільним часом, і людина починає витрачати його на власні потреби. В результаті це призводить до звільнення співробітника. Деякі люди просто не можуть працювати в настільки вільних умовах.

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

Приховані резерви команди

Досить цікава доповідь, що показує системний підхід до завдання та певні рамки, які люди створюють самі для себе. У доповіді Михайло Попчук із Ciklum розповідав про реальний проект, в якому було дві команди — одна досить досвідчена із кваліфікованим керівником, і знаходилась вона в Європі, а другу формували вже в Україні. Завдання було створити проект на Unity3D із запланованим релізом на протязі 4-х місяців. Проблема була з підбором розробників на проект та складністю самого завдання. Коли стало зрозуміло, що організувати необхідну команду розробників у повному обсязі буде неможливо, менеджер проекту запропонував використати технологію управління Agile. Це призвело до супротиву зі сторони більш досвідченої європейської команди, адже вони завжди використовували звичайні методи роботи і вибирали собі завдання з власного розсуду.

Для того, щоб не призводити до конфлікту, було вирішено керувати командою розробників в Україні за допомогою Agile і не чіпати устрій команди в Європі. Першим кроком були сформовані завдання, розбиті на основні групи за критерієм важливості. Спланований перший спрінт та заплановано перше демо. Для проведення демо було організовано конференц-зв’язок, де були присутні всі люди, які мали використовувати це програмне забезпечення. І саме це демо призвело до необхідного прориву у розробці, що в результаті допомогло зробити проект вчасно. Коли команда почала проводити демо, по коментарям стало зрозуміло, що потрібно змінити вже, а що навіть не потрібно реалізовувати. Ось переваги:

1. Це зберегло час на переробку функціонала;
2. Це зменшило загальну кількість завдань;
3. Результат формувався більш очікуваним для користувачів;
4. Розробники разом з користувачами змінювали User Stories за новими вимогами і кінцевий продукт ставав більш технологічним.

Більш того, певна критика зі сторони працівників замовника спонукала розробників робити все краще та швидше.

Проект був завершений на протязі 2,5 місяців, замість 4-ох. Це настільки шокувало замовника, що він вирішив обов’язково запровадити технологію Agile і в європейській команді.

Вся ця історія показує, як за допомогою простого підходу до керування проектом в команді розкрились певні приховані ресурси, які до цього не використовувались взагалі.

Як не потерпіти невдачу і зрости у перші 3 роки. Досвід розвитку компанії регіонального рівня

Дуже цікава доповідь була прочитана керівником компанії ADS group Дмитром Сусловим. Він в деталях розповів, як проходив розвиток і з якими проблемами зіткнулась його команда. Дмитро виділяє такі поради для підвищення ефективності компанії:

• Впроваджувати систему прямих продажів, використовувати холодні дзвінки;
• Ціль — успіх клієнтів (виправдання очікувань)? і ця ціль є спільною для кожного учасника команди;
• Відкритість — будь-які побажання, коментарі, зауваження від кожного учасника команди вислуховуються і обговорюються з клієнтом;
• Усі учасники команди рівні, незалежно від віку, досвіду роботи і т. д.;
• Анкетування для виявлення потреб і проблем в команді. Проводиться кожен місяць. Також практикуються бесіди керівника студії з кожним учасником один на один;
• Формувати позитивну атмосферу в команді і загальну ціль.

Найголовніше, що виділяє доповідач — це формування правильних очікувань у клієнта. Краще пообіцяти трохи довше, а зробити швидше — радить Дмитро.

Окремо потрібно виділити відношення до віддалених працівників (так званий freelance). Такі працівники не можуть бути повноцінними членами команди. У них просто немає мотивації працювати ефективно. Рішення просте: повністю відмовитись від послуг таких спеціалістів.

Під кінець доповіді Дмитро підсумував, які кроки необхідні для подальшого розвитку і підвищення ефективності компанії:

• Підвищення кваліфікації команди;
• Автоматизація всього, що тільки можливо;
• Впровадження CRM-системи;
• Прагнути до довготривалих відносин з клієнтом.

Переконання або як зробити клієнтів слухняними

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

• Говори словами клієнта;
• Кажи йому те, що він хоче почути;
• Довідайся, що саме йому потрібно;
• Спочатку слухай, потім говори;
• Пропонуй вибрати з двох вигідних тобі варіантів.

Цікавий лікбез для менеджерів з продажу. А почути його з вуст Анастасії Берестової вдвічі приємніше.

Якщо зробити загальний підсумок цього дня, то можемо сказати напевне — відбудеться багато змін в нашій роботі. Багато речей, які ми почули, вже були нам відомі, але, як завжди, їх впровадження в реальне життя відкладалось на потім. Agile, Kanban — це прості методи керування проектом, які стовідсотково потрібно навчитись використовувати і навчити цьому наші команди. Один з головних висновків — зміни потрібно починати з себе. Саме менеджер може досить невимушено змінити підхід до нових та вже існуючих проектів, вивевши їх на нову ступінь якості.