Kyiv Project Management Day: щоденник конференції

28 жовтня 2017р. Lemberg Tech Business School провів масштабну конференцію Kyiv Project Management Day, присвячену проектному менеджменту.

Програма складалася з 3 блоків панельних доповідей і 1 блоку майстер-класів. Доповіді були розділені за темами: «PM-моделі», «PM-практики» і «Product Management».

Ділимося ключовими тезами деяких доповідей і своїми спостереженнями.

У блоці «PM-моделі» Сергій Немчінскій говорив про свій досвід та уроки, які він отримав. Так, наприклад, Сергій вважає дивним, якщо IT проектом керує PM не з IT. Але якщо вже так і сталося, то PM-у треба бути гранично чесним зі своєю командою: «Я не вмію, але ви вмієте! Я буду захищати ваші інтереси перед замовником, а ви будете виконувати … ». Важливо намагатися залучати експертність співробітників, показувати, що ви їм довіряєте і вірите в них! І ще одне спостереження від Сергія: найчастіше причини провалу проекту … це перипетії в особистому житті! Або робота з родичами.

Артем Биковець розповів, хто такий Scrum Master, окреслив основні його функції. На думку Артема, це: фасилітація, навчання і наставництво, спостереження, коучинг (командний / індивідуальний) та мотивація. Важливо, щоб Scrum Master не був нянькою-секретарем у команди. Людей не потрібно робити щасливими, їх потрібно робити ефективними! Ось основне «призначення» Scrum Master.

Наталія Науменко, кажучи про побудову ефективної команди, порекомендувала PM-у використовувати палітру моделей: рольову модель Белбін, модель кар’єрних якорів і теорію спіральної динаміки. Причому починати діагностику потрібно з себе: яку роль по Белбін я зараз виконую, який у мене зараз кар’єрний якір, до якого кольору я себе відношу (співвіднесення цінностей моїх і компанії). І тільки після цього приступати до підбору співробітників – будувати свою ефективну команду.

Євген Полозюков дав рекомендації, як бути гнучким в проектних комунікаціях:

  • Завжди давати зворотний зв’язок
  • Використовувати активне слухання
  • Бути тут і зараз
  • Проблеми обговорювати 1 на 1
  • Цікавитися особистими справами своїх співробітників
  • Практикувати ненасильницький спосіб спілкування (не переходити на особистості, намагатися зрозуміти потреби співрозмовника, чути і слухати)
  • Об’єднувати команду за допомогою різних інструментів
  • Аналізувати проблемне поле (SWOT-аналіз, 5Why, діаграма Ішикави)
  • Навчити команду вмінню вирішувати конфлікти, але заохочувати до «керованих конфліктів» – ведення діалогу

Дмитро Лук’янов наголосив на тому, що в чистому вигляді будь-яка методологія не може бути використана для управління проектом протягом усього його життєвого циклу. Особливо якщо дивитися на проект, розширивши межі, а саме: «від появи ідеї до отримання результатів використання продукту проекту». Тому термін AgileFall перестав бути грою слів, а став самостійним підходом, в якому проект розглядається з різних перспектив, і створення продукту проекту командою фахівців – це тільки одна з перспектив. На думку Дмитра, для того щоб бути успішним в реалізації проектів, PM-у треба бути різнобічно підкованим, вивчати різні підходи і вміти бачити і «водоспад», і «скрам» в проектах, а також розуміти, як вони можуть взаємодіяти і взаємодоповнювати один одного.

У блоці «PM-практики», Павло Якименко представив своєрідний зворотний зв’язок HR-менеджерам, провівши власний аналіз запитів роботодавців українського ринку в 2017 році. В результаті виявилося, що українські компанії шукають не реального кандидата, а такого собі супермена / супервумен, неіснуючого в природі. Особливо Павла бавлять деякі тестові завдання, які даються кандидатам. Наприклад, такі: «напишіть branching strategy», або «дайте відповідь на RFP «хочу аналог skype », або «виправте всі неточності в нашому ТЗ». Виникає відчуття, що компанія не хоче брати кандидата на роботу, але хоче, щоб він зробив частину проекту. Щоб вибрати гідну і відповідну саме тобі компанію-роботодавця, Павло радить звертати увагу на: стиль менеджменту, рівень зрілості і корпоративної культури. Це можна оцінити за підсумками спілкування з HR менеджером, в т.ч. за процедурою проведення підбору, надання зворотного зв’язку та ін.

Костянтин Коптєлов заінтригував тим, чому Agile у нас не працює і, найімовірніше, не запрацює. Костянтин говорив про те, що у Agile є 2 аспекти: органічний і технічний. Органічний – це люди, комунікації, взаємовідносини і т.д.), технічний – це системи, документи, інструменти, техніки і т.д). Так ось найпоширеніша помилка при впровадженні Agile – це концентрація на технічному аспекті і відсутність належної уваги органічному аспекту. А органічний куди важливіше! Також Костянтин звернув увагу, що перш ніж впроваджувати Scrum, потрібно виростити потрібні навички в людях (або знайти людей з такими навичками):

  • Визначення MVP
  • Розбивка його на User Story
  • Оцінка завдань
  • Проведення власної самооцінки
  • З’єднання частин в ціле
  • Планування
  • Уміння синхронізуватися
  • Проведення нарад
  • Надання зворотного зв’язку

У блоці «Product Management» Олександр Краснов роз’яснив, хто ж такий Product Manager. В першу чергу, це така роль в Scrum. А також він:

  • Розробляє Product Backlog
  • «Грумить фічі» з development командою
  • Допомагає Marketing команді
  • Активно працює зі Sales командою
  • Показує команді Customer Success
  • Аналізує фінансові показники
  • Та багато іншого…

Олександр також поділився корисними для Product Manager підкастами:

  • Inside Intercom Podcast
  • Cto cast
  • This Week in Google

Андрій Мандрика показав реальність можливості злиття бізнесу і IT.

Звичайно, є складнощі:

  • відсутність прозорості
  • нерозуміння і недовіра один до одного
  • різні цілі
  • опір змінам.

Але є і шляхи вирішення:

  • Ставити єдині цілі для Operations і Developers. Донести до кожного бачення бізнесу і його цілей, показати «чумацький шлях».
  • Ознайомитись з роботою колег. Наприклад, влаштовувати екскурсії в сусідні відділи або поміняти співробітників з різних відділів місцями на 1 день.
  • Розмовляти на одній мові. Наприклад, створити глосарій термінів.
  • Заслужити довіру реальними результатами. Якщо щось конкретно пообіцяв – обов’язково виконай обіцянку.
  • Ідентифікувати і усунути 8 видів втрат по Lean:
    o Перевиробництво = розробка непотрібного бізнесу функціоналу
    o Зайві запаси = частково виконана робота
    o Транспортування = передача роботи іншому виконавцю
    o Пересування = перескакування між завданнями
    o Очікування = затримки за погодженням вимог і прийняттям рішень
    o Дефекти = баги, особливо ті, які виявлені в production, а не в тестуванні
    o Зайві процеси = додаткові, непотрібні кроки при розробці та впровадженні
    o І 8-й вид втрат – невикористаний потенціал = відкидання ідей від бізнесу і від своїх співробітників.

Головний посил виступу Андрія – не бути лебедем, раком і щукою!
Успішних вам проектів, друзі!