Найпоширеніша причина провалу ІТ-проєктів — це не баги, не погані девелопери і навіть не токсичні клієнти. Це нечіткі, неповні або розмиті вимоги. Те, що на старті здається «ну ми ж домовились», перетворюється на нескінченні доопрацювання, зіпсовані стосунки й відчуття, ніби ти постійно щось не врахував. Формально все є: зустрічі, нотатки, документи. Але реальність — зовсім інша. Клієнт незадоволений, команда демотивована, а ти не можеш чітко пояснити, чому все виглядає не так, як «очікували».
У цій історії розповідаємо, як один PM потрапив у цю пастку — і як йому вдалося з неї вибратись.
Як PM навчився збирати вимоги так, щоб більше ніхто не писав «це не те, чого ми очікували»
Сашко працює проєктним менеджером у невеликій аутсорс-компанії вже другий рік. Наче все добре: проєкти є, клієнти є, команда працює. Але кожен старт нового проєкту викликав у нього тривогу. Занадто знайоме відчуття, коли ти запускаєш спринт, здаєш першу демо — і клієнт пише:
«Це не те, чого ми очікували. Чому ви не запитали раніше?»
І далі — усе по колу: правки, мітинги, фоллоу-апи, команда на межі, клієнт — у розпачі. Саша намагався все фіксувати у Google Docs, створював Confluence-сторінки, але цього вистачало рівно до моменту, коли клієнт згадував: «Ми ж говорили, що буде по-іншому».
«У якийсь момент я почав боятися стартів нових проєктів, бо знав: щось точно піде не так», — згадує Саша.
Одне забуте обговорення — і контракт на межі зриву
Один із клієнтів, великий e-commerce зі Штатів, на другому тижні розробки висловив «глибоке розчарування» через те, що їхній ключовий флоу виглядав не так, як обговорювалося. Проблема була в тому, що це обговорення взагалі не було задокументоване. А Саша покладався на свої нотатки й пам’ять. Клієнт пригрозив припинити контракт, і лише швидкий rescue call зі сторони CTO врятував ситуацію.
Це був той самий момент, коли Саша ввечері пішов гуглити «як правильно збирати вимоги у проєктах». Так він натрапив на курс PM Hard Skills: Planning.
Навчання, яке змінило гру
На сайт IAMPM програма курсу розписана досить детально. Але після того, як Олександр залишив заявку, із ним зв’язалась менеджерка. Саша думав, що вона просто розповість про вартість, коли проходять лекції, що треба підготувати. Але спочатку менеджер виявила ключові проблеми та переконалась, що курс дійсно може їх закрити.
«Ми поспілкувались десь хвилин 8. Я хоч і готовій був одразу купувати курс, мені було приємно, що менеджер дізналась про мої потреби, та лише підсилила фактами, що навчання вирішить мої проблеми».
На курсі Саша одразу потрапив у середовище практиків. Ніякої води — лише кейси, шаблони і живі ситуації.
Особливо йому запам’ятались такі теми:
- Stakeholder Map + Project Brief. Тепер кожен проєкт він починає з карти стейкхолдерів і затвердженого бріфу, де фіксує цілі, KPI, обмеження й критерії успіху.
- Business Case vs User Stories. Він чітко розділяє, що важливо бізнесу, а що — користувачам. І не змішує це в одну вимогу «десь в чаті».
- Discovery checklist та інтерв’ювання клієнта. Тепер у нього є скрипт, як грамотно провести першу розмову з клієнтом і витягнути максимум потрібної інформації.
- WBS + Scope Baseline. Навчився декомпозувати фічі і фіксувати обсяг, а головне — погоджувати його до старту робіт.
- І, звісно, шаблони. Понад 25 готових документів, які можна взяти і одразу заповнювати — без біганини по інтернету у пошуках прикладів.
Що змінилось на роботі
Через 3 тижні після старту курсу Саша почав використовувати шаблони у реальному проєкті з новим клієнтом. На демо вони показали те, що було узгоджено в Scope Baseline. Клієнт сказав:
«Я відчуваю, що ми з першого дня на одній хвилі».
Замість емоційних правок — конкретні коментарі до конкретних User Stories. Замість «ви не так зрозуміли» — посилання на Project Brief. Замість паніки — структура і контроль.
«Я вперше відчув, що можу керувати очікуваннями, а не бігти за ними», — каже Саша.
Висновок
Олександр починає кожен проєкт з Discovery Checklist, stakeholder-аналізу і фіксації scope. Він став тією людиною, яка знає, що і навіщо вона робить — і нарешті не чує фрази «це не те, що ми хотіли».
Якщо ви теж не хочете гадати, чого насправді хоче клієнт — можливо, настав час пройти PM Hard Skills: Planning. Хочете бути PM, який «сподівається, що все вийде», чи PM, який будує процес? Вибір за вами.