П’ять порад молодим проектним менеджерам ІТ індустрії від Царя Мар’яна

[ Мар’ян Цар – ІТ професіонал, експерт з 10+ років комерційного досвіду у розробці програмного забезпечення та менеджменту. Пройшов шлях від веб-розробника та QA інженера до R&D директора. Більше 30+ проектів та стартапів, в обидвох напрямках – як аутсорсинг так і продукт. Додатково до основного роду діяльності, тісно працює зі стартапами (консультування/стратегія/процеси).
Активний контрибютор в PM та Agile спільноти, спікер локальних та міжнародних конференцій. Холдер наступних професійних сертифікатів: PMP, CSP, KMP, CSM, CSPO, ICP, ISTQB та ін. ]

Technical Background
Технічний бекграунд являється так званими “hard skills” і зачасту може відігравати дуже важливу роль в роботі менеджера. Хоча є чимало випадків, де проектні менеджери впевнено та доволі якісно керують проектами без нього, його наявність добавляє великий “+” в карму. В першу чергу, він дозволяє розуміти інженерів та говорити з ними на “одній” мові. А при вході в новий проект, знання і розуміння технологій та інструментів розробки добавляє декілька пунктів “кредиту довіри” зі сторони технічних спеціалістів. По друге, хороший технічний бекграунд, особливо зв’язка процесів розробки з хорошим розуміннями методології управління, можуть стати запорукою успішного ведення проекту.
Тому, якщо є шанс отримати технічні навики до початку кар’єри менеджера, чи навіть в процесі – не цурайтеся, лишніми вони ніколи не будуть.
Англійська мова
PM без англійської – скоріше поодиноке виключення, чим правило. Чим вільнішим буде рівень англійської, тим простіше менеджеру знайти хорошу позицію та розвиватися в компанії. Більшість компаній в Україні, так чи інакше, працює на зовнішній ринок та з іноземними клієнтами. У великих компаніях команди розробки при цьому, можуть бути розподілені та знаходитися в різних країнах, тому англійська для комунікації – що на усному, що на письмову рівні – має бути дуже хорошою. ІТшна англійська нічим не відрізняється від англійської звичайного пересічного громадянина, за виключенням сотні-другої специфічних слів та термінів, притаманній індустрії. На них варто звернути уваги, бо велика частина з них вимовляється зовсім не так, як до цього привикли кругом – наприклад слова archive [ˈɑrkaɪv] (“аркайв”, а не архів), error ([ˈɛrər], “ерер”, а не ерор) та ін.
Люди – не ресурс
Не важливо де ви працюєте, аутсорс, аутсаф, продукт – люди – не ресурс. Ними не можна оперувати як у випадку з комп’ютерами чи бездушними атрибутами – одним більше, одним менше. Самий крутий менеджер з усіх – не вартий абсолютно нічого без команди. Навіть при дуже специфічній культрі компанії, до колективу потрібно відноситися з максимальною повагою, незважаючи на рівень authority, яким вас наділено. Проекти закриваються, люди виростають та змінюють компанії – а ви як були “булшітним менеджером” для них, так і залишитеся. Репутація поганого менеджера серед інженерів шириться швидше, чим репутація поганого інженера серед менеджерів (с). Завжди давайте команді максимум того, що можете дати поза формальними обов’язками переглянути ЗП чи провести зміну позиції. Вітайте своїх людей з днем народження, діліться з ними знаннями, досвідом, позитивним настроєм. Завжди старайтеся залишитися в хороших стосунках, навіть якщо людина покине ваш колектив – хто зна, можливо саме зі старих працівників ви колись сформуєте нову команду?
Best practices
Не зважаючи на підхід, фреймворк чи методологію які використовується для управління у вашому проекті, – ніколи не цурайтеся використовувати найкращі практики індустрії, якщо вони можуть оптимізувати процес та принести додаткові бенефіти проекту чи бізнесу. Робіть ретроспективу з командою через певні відрізки часу, щоб визначати як можна покращувати “болючі точки”; використовуйте синхронізаційні зустрічі (daily standup, sync meeting) щоб бути в курсі того, що відбувається на проекті; робіть one-to-one мітинги зі своїми людьми, щоб тримати руку на пульсі команди; проводьте brainstorming’и; працюйте зі списком ризиків; користуйтеся root cause аналізом; не забувайте про матрицю Ейзенхауера та модель Такмана; теорії мотивації X та Y Дугласа Макгрегора чи фактори гігієни Герцберга.
Навчання, навчання, і ще раз навчання.
Пам’ятайте, що вчитися в ІТ середовищі потрібно постійно. 24 години в добу, 7 днів на тиждень. Величезна конкуренція, неймовірно швидкий розвиток стеку технологій, агресивний ринок. Кожен проект буде привносити нові випробування, з якими у вас ще нема досвіду. Сьогодні – відповідальність за stakeholder менеджмент, завтра – формування проектного бюджету, після завтра – інтеграція зі зовнішніми командами. Сьогодні у вас waterfall, завтра scrum, після завтра – custom “on flight” solution. Тренінги, конференції, воркшопи, дискусійні клуби, блоги, книги – все це буде необхідними елементами розвитку та професійного росту. Навчання вимагатиме як значних фінансових так і часових витрат. Якщо вам хочеться спокою та неспішної роботи з використанням лише одноразово набутих знань, тоді шлях РМ’а далеко не оптимальний вибір.