Насамперед нам потрібно визначити, що таке «проєкт», тому що без нього нам не потрібен менеджер. Простими словами: проєкт – це те, що має обмежені ресурси, обмежений час і, як результат, унікальний продукт.
Якщо продукт не є унікальним, нам просто потрібна людина, яка може керувати виробництвом однотипних речей. Наприклад, нам потрібен PM для створення нового смартфона, але щоб виробляти їх тисячами - ні.
Треба визнати, що старий «водоспадний» метод розробки програмного забезпечення залишає бажати кращого. Традиційний PM покладався на етапи у чіткій послідовності, які не можна переставити місцями. Agile методологія, навпаки, — це підхід до розробки програмного забезпечення, орієнтований на людей та результат: гнучкий, швидкий і спрямований на постійне покращення якості, використовуючи такі інструменти, як Scrum. Цьому легко навчитися та впровадити на практиці; ми бачимо прогрес студентів на курсі «Project Managment в ІТ» у Beetroot Academy. Вони отримують достатньо знань протягом чотирьох місяців, щоб пройти тест і мати міжнародний сертифікат Scrum-майстра від Scrum.org
PM працює разом із клієнтом (або замовником), командою DevOps та компанією, яка займається аутсорсингом/аутстафінгом. Кожен з них по-різному бачить свої ролі та ролі інших. Це проблема, яку потрібно вирішити РМу.
DevOps — це набір практик, який поєднує розробку програмного забезпечення та ІТ-операції.
Аутсорсинг компанії несе відповідальність за всю підтримку проєкту .
Компанія аутстафінгу відповідає за найняття і підтримку команди розробників програмного забезпечення.
Як технологічна компанія зазвичай бачить розробників? Вони як марафонці: наполегливо працюють, щоб «фінішувати» з найкращими результатами.
Яким компанія бачить проджект-менеджера? Як людину, яка розслабляється 80% часу і витрачає гроші компанії.
Як почуваються розробники всередині компанії? Ніби ніхто не цінує їхню працьовитість.
РМ розуміє сприйняття всіх трьох сторін і може представляти кожну точку зору під час переговорів. Менеджер проєкту — це та людина, яка може пояснити, чим кожен займається, максимально ефективно донести цінність і знайти спільну мову з компанією, командою та клієнтом.
Так ми оцінюємо, успішний проєкт чи ні. Є кілька хитрощів, щоб відповідати цим критеріям і налагоджувати належні відносини з клієнтом. Краще завершити проєкт на 2 дні раніше терміну, виконати одне додаткове завдання або навіть заощадити гроші клієнта. Заплануйте ці хитрощі, і це додасть цінності вашій роботі.
Глобальна мета РМа – дати кожному те, чого він хоче. Зазвичай клієнт хоче отримати проєкт за найнижчою ціною і з найдешевшими технологіями. Найдешевші технології дозволяють легко підтримувати проєкт. Чого хоче команда? Їй завжди хочеться чогось цікавого, нових можливостей і технологій, що сьогодні є найпопулярнішими й відповідно дорожчими. Досить важко балансувати, намагаючись знайти якесь рішення, щоб задовольнити їх усі. Найважливіше, що проджект-мннеджери, як справжні лідери, повинні робити з самого початку – це говорити правду клієнтам та команді. Емпатія – запорука успіху.
Повсякденна рутина, яку РМ зазвичай виконує на своєму робочому місці, — це коли приходить до розробника і просить його щось додати/змінити, виправити помилки чи виконати додаткову роботу. Здебільшого отримає відповідь “Ні!”. Тобі як РМу потрібно навчитися працювати із запереченнями та конфліктами. Перш за все, слід з’ясувати, яка справжня причина, і розв'язати проблему. Можливо, він/вона чогось боїться, або інтроверт, або людина, яка не хоче більше часу проводити на роботі, а хоче піти в бар чи з друзями.
Також важливо переконатися, що люди відкриті та відверті, щоб працювати з ризиками. Іноді розробники переоцінюють або недооцінюють себе. Приємно бачити результати раніше встановленого терміну. Але кожен нервує, якщо нічого не робиться, за винятком 5 останніх днів наприкінці другого місяця.
Одна з найскладніших речей, коли щось йде не так, — це перемикнути увагу клієнта, керівництва від звинувачень розробників. Тому РМ повинен залишатися зосередженим і шукати рішення, а не звинувачувати когось. Шукати винного - неконструктивно, а пошук рішення показує твою відповідальність і готовність досягти мети.
Завжди виникає питання, хто краще: проджект-менеджер з технічним досвідом чи без? Час від часу технічні менеджери проєктів можуть писати код, виправляти помилки або навіть прикривати розробників. Менеджери нетехнічних проєктів, Scrum-майстри нічого не знають про програмування, але знають психологію, можуть керувати командами та налагоджувати процеси. Обидва мають однакові шанси працювати в технологічних компаніях, але уміння, яке потрібно опанувати обом - це бути свого роду перекладачем з нетехнічної мови на технічну і навпаки.
Якщо у тебе немає технічної освіти, розпочати кар’єру в ІТ у розробці – не єдиний шлях. Можна кодувати, а можна керувати. Курс «Project Managment в ІТ» у Beetroot Academy навчить тебе організовувати команди, будувати складні процеси, працювати з принципами agile і бути таким інтерпретатором.
PM збирає вимоги, оцінює завдання, пише документацію, ставить завдання, здійснює контроль якості, слідкує за термінами та презентує продукт клієнту. Але...досить часто PMи займаються продажами й обговорюють ціну з клієнтом, або працюють і QA, який тестує проєкт, щоб переконатися, що все зроблене належним чином, або трохи маркетологи чи дизайнери. РМ також може бути бізнес-аналітиком, який розраховує прибуток, або навіть HR-спеціалістом, щоб переконатися, що людина підходить команді.
Тож... зустрічайте ідеального PM — це Супермен. Він/вона є комунікатором (перекладачем), психологом, перемовником, лідером, тайм-менеджером та технічним спеціалістом одночасно.
Так виглядає РМ на практиці, а не в теорії. Це складна, але захоплива робота. Якщо ти прочитав цей текст і надихнувся, а не злякався, пройди швидкий тест, щоб переконатися, що твоє найближче майбутнє — бути проджект-менеджером.
Якщо так, приєднуйся до курсу ««Project Managment в ІТ» у Beetroot Academy 30-го листопада.