Як часто проджект-менеджери опиняються між молотом і наковальнею, намагаючись знайти баланс між усіма вимогами та термінами замовника і ментальним здоров'ям усієї команди? Скільки нюансів потрібно врахувати, щоб з обох сторін відповідальності був мир і порядок? Як зрозуміти, чи ти хороший менеджер, чи тобі терміново варто підтягнутися по всіх фронтах? Як визначити, в яких аспектах саме ти, як ПМ, відстаєш, а де ти молодець і умничка? Саме про це йшла чергова конференція Code’n’Coffee.
Сергій Нємчинський підняв важливе питання — тема його доповіді була «Між замовником і розробником. ПМ в тисках реальності».
Жива форма подачі, багато гумору і легко засвоювані тези про те, як врахувати вимоги замовника і при цьому зберегти команду мотивованою і готовою до нових звершень до кінця проекту.
Найбільш запам'ятовувані тези:
- поняття цікавого проекту: завжди потрібно чітко визначати що, а головне ЗАЧЕМ ви розробляєте. Не завжди те, що цікаво реалізовувати програмісту, буде потрібно замовнику в даному проекті. Не на кожен проект потрібно впроваджувати нові технології, підвищуючи ризики проекту, іноді простіше і швидше — найправильніший варіант.
- постійні дедлайни шкодять якості проекту і знижують мотивацію команди: часті дедлайни — це вічні компроміси між тим, як правильно, але довше, і не зовсім правильно, але швидше. Будь-який хороший програміст не любить робити свою роботу «хоч як-небудь», і навіть якщо такі варіанти погоджуються з замовником або навіть виходять від замовника, це завжди йде в мінус мотивації розробника. (Найкраща теза з конференції, яка тепер висить у мене як нагадування!)
- тільки ПМ відповідає за якість проекту! Не програміст і навіть не тестувальник! Код може бути 100% покритий тестами, виглядати ідеально, але робити зовсім не те, що потрібно замовнику.
- бажання програмістів рефакторити код — це нормальне бажання кожного програміста, але це зовсім не означає, що проект дійсно вимагає рефакторингу. Ніколи не має сенсу рефакторити без завдання. Для цього можна використовувати правило «третього разу» Мартина Фаулера (книга «Рефакторинг. Поліпшення існуючого коду»). А от на необхідність оптимізацій варто звертати увагу.
- підтримання скоупа і пріоритетів залежить ТІЛЬКИ від ПМ. Зменшення або збільшення скоупа — відповідальність проектного менеджера. Якщо скоуп виявився непомірним за термінами для програмістів — це недолік ПМ. Розумний обсяг робіт — основне завдання ПМ в даному аспекті його роботи.
- оцінки часу виконання завдань можуть дати ТІЛЬКИ програмісти, не ПМ і тим більше не замовник. Фраза від клієнта: «Внесіть цю фічу в скоуп, там всього 5 хвилин» — на ПМ повинна зупинятися!
Ми отримали від Сергія близько 40 слайдів корисної інформації та близько 12 живих прикладів з особистого досвіду, і інформації залишалося ще на 2 таких доповіді. Було дуже цікаво.
Тарас Ляпун підняв тему про риси хорошого менеджера.
Він нагадав про те, що ПМ в першу чергу завжди повинен тримати фокус на бізнес-цілях проєкту. Тобто, вся діяльність ПМа повинна бути спрямована на те, щоб відповідь на запитання «Чи вирішує дана дія, дана фіча (і т.д.) проблему замовника?» — була завжди «ТАК». А значить, ви завжди повинні тримати в голові, яку мету розробки ви переслідуєте в даному проєкті.
Вміння оцінити масштаб і ціну помилки — безцінне. Сюди ж у розділ можна включити роботу з ризиками. (Воркшоп по ризикам з Анною Лавровою Km CNC проводив в травні).
Проджект менеджмент — це історія постійного розвитку і зростання. В ключі даного аспекту Тарас згадав про таке течію японської культури як Ikigai і тест DISC, на які варто звернути увагу.
Ікигай допоможе з власним покликанням і балансом в житті, що є запорукою внутрішнього рівноваги менеджера.
А тест DISC допоможе визначити власний стиль управління, ваші сильні і слабкі сторони. Знаючи результати тестів, можна правильно підбирати рішення складних питань, відштовхуючись від своїх сильних сторін, і не намагатися впроваджувати те, що не підходить вам і те, що ви зовсім не зможете підтримувати через свої особливості управління. Тарас нагадав про те, що швидкість системи визначається швидкістю найповільнішого елемента, а значить, що швидкість розробки повинна визначатися швидкістю найповільнішого процесу.
Тарас дотримується думки, що у кожного хорошого ПМ повинен бути технічний бекграунд. Розповсюджена думка і точка спору ПМів з наявністю і відсутністю технічного досвіду)) Багато ПМ довели, що цей аспект необов'язковий, але важко спростувати той факт, що розуміння технічної сторони розробки значно полегшує життя будь-якому проджект менеджеру.
По закінченню івенту зовсім не було зрозуміло, куди поділося час. Ми що, вже закінчили? Може ще трохи послухаємо?)
Дякуємо Code’n’Coffee за івент і за можливість отримати інформацію для порівняння зі своїм досвідом, переглянути деякі підходи і задати собі необхідні питання!
