Коли я була зеленим-зеленим менеджером я думала так: “Ну нічого, що техніку не знаю, головне - це софт скіли і комунікації, а тут я в виграшному положенні.” І, зізнаюсь, це дуже добре працювало.
На кожен проект заводився свій розділ у моєму величезному блокноті, справи на день/нагадайки/важливі і підвішені питання. Все це у мене в голові і у блокнотику. Технічні документи (якщо і були) знаходились десь там, у містичних сховках архітектора і ко. Бізнесові і організаційні розкидані на столі і в думках. Для маленьких проектів (а саме такі часто дають початківцям) було б норм, чи, точніше, було як у відомому мемчику:
Проект робиться - клієнт задоволений - грошики капають, а що ще треба?
ТРЕБА.
Треба спочатку визначити, чому цей підхід не працює:
Інформація не може міститись у закритому доступі у однієї людини. Це робить людину “важкозамінною”. Тут прикладами може бути і зміна робочого місця, і зміна проектів, і відпустка чи лікарняний. Всі зацікавлені особи проекту мають мати доступ до загальної інформацій та вибіркової, згідно специфіки роботи і зацікавленості.
Відсутність структурованої документації не дає гнучкості проекту. Відсутній Статут проекту (Project charter) не дасть змогу оперувати винятками, затримками через допущення, залежностями. Відсутність матриці відповідальності може привести до помилок (навіть катастрофічних) якщо ви забули щось з кимось погодити/поінформувати та ін. Не будемо розбирати усі документи, адже кожен з них виконує свою функцію і є важливим (додатком) для ефективного управління проектом.
Ускладнює Onboarding нових людей у проект, який вже розпочато. Після того, як в один проект прийде з десяток нових людей (кожен звісно окремо в рандомний період часу) починаєш втомлюватись розповідати одне й те саме. І тут не тільки документи, які регламентовані, точніше сказати summarized в PMBoK, а і інструктажі, специфіки роботи проекту, домовленості та ін має бути зафіксоване у відповідному документі і загальнодоступному просторі.
Ну що, любий мій читачу, вже занудився? А уяви як би ти занудився аби тобі треба було кожні 2 тижні протягом 4-х місяців розповідати новому сусіду де що стоїть на кухні і коли прибирання/виніс сміття. І якщо ти не розповіси чи розповіси погано, то вас чекатиме безкінечні суперечки, непорозуміння і, як висновок, завжди брудна і смердюча кухня. Не дуже класно, ге? От проект - це твоя кухня. І всі люди на ній мають розуміти що де стоїть, коли повар (девелопер) доготує суп, шеф перевірить його на смак (архітектор), а офіціант (куа) переконається, що клієнту буде віддаватись саме гороховий суп, а не шашлик. І за цим всим слідкує адміністратор ресторану (менеджер).
Мені подобається порівняння проекту з кухнею. Бо у кожного свій підхід до приготування страв, прикрашання та видачі. І свої внутрішні правила (коли прибирання, коли інвентаризація та ін.). Та ніде шеф чи адміністратор не буде з новим поваром чи офіціантом сидіти і розповідати йому усно що готується на цій кухні, як і чому. Є меню, є внутрішній інструктаж з техніки безпеки та посадові обов”язки. Цим не варто нехтувати і в усіма нами залюбленому айті.
Поки я до цього не дійшла, великі проекти для мене були як біганина з одного кінця стадіону до іншого. Onboarding людей чи підготовка звітів займали дуже багато часу. Постійні пошуки “першочергових домовленостей” після 27-ої правки, завжди забутий відділ маркетингу, якому знову не сказали про плановані “фічі” для анонсів. Стільки всього було, і не перелічити. Сумно, що такі прості істини здобувались помилками і шишками. Коли я проходила навчання на Project Manager-а і в університеті і, пізніше, на додаткових курсах, мені розповідали про всі ці документи, що писати і кожному з них. Та, на жаль, мені не розповіли чому важливо робити ці документи. Яких проблем можна уникнути, жодного прикладу і ситуації, де документ допоміг - ніхто мені не розказав. Більше було про ті самі “комунікації” з першого абзацу.
Звичайно, я не створюю всі відомі мені документи від проекту до проекту. Кожен проект індивідуальний, і я, виходячи з мого досвіду, вже знаю що мені точно потрібно буде, що ні. І фінальний список документів залежить від багатьох критеріїв. Наприклад, чи працювали вже з цим замовником/командою/відділом, чи робили схожі проекти і т.д. Я тут лишу своїх “фаворитів”, тобто документи, що я створюю завжди:
Статут проекту (Project Charter)
Реєстр стейкхолдерів (Stakeholder register)
План управління комунікаціями (Communication management plan)
Журнал Змін (Change log)
Внутрішні правила та домовленості
інструкції на кожну роль у девелопмент команді - QA, designer, developer etc.
опис внутрішніх процедур (процедура передачі задачі в розробку, DoR/DoD etc.)
Інші важливі внутрішні домовленості (наприклад, коли важливо лишати коментарі з задачах у баг-трекерах і у якій формі)
І далі цей список доповнюється чи редагується в залежності від ситуації. І більшість моїх “організаційних мітингів” чи як модно говорити “сінків” відпали. Команда собі спокійно працює, ми
Тому, і молоді і досвічені ПіЕм-чики, не нехтуйте документами. Пишіть їх, тренуйтесь писати, коли у вас є така нагода. Ментори, розповідайте, чому важливо це робити і знати як робити і коли робити. Це все ваші сходинки до нових можливостей і розвитку.
А щоб легше було “поглинати знання”, то можна скористатись PMBoK, який офіційно перекладений украхнською. Безкоштовно скачати з сайту українського чаптеру PMI https://pmiukraine.org/pmbok7
Сподіваюсь було корисно і цікаво!
Успіхів вам, друзі!
