Здавалось би - правильно організований процес за scrum дає нам швидкі результати. Поставка мінімально життєздатного продукту [MVP] дає можливість бізнесу почати свої кампанії раніше, вносити корективи, коли це ще “не боляче” ні продукту (дев команді з актуальними архітектурами), ні бізнесу.
Але, на жаль, ми всі живемо не в ідеальному світі. І ще частіше бізнес намагається “пропихнути” свої очікування по датам поставок продукту не дивлячись на логічні зауваження і коментарі від девелопмент команди: “9 жінок за місяць дитину не народять”. Що робити, коли все-таки треба народити за місяць? Жертвувати правильністю для швидкості.
Треба дізнатись що особливого саме в тій даті, які так сильно нав”язує замовник. Презентація хепі-пас? Просто скріни платформи для маркетинговий активностей? Від цього залежить ваш план і пропозиції для замовника, як зробити і йому добре, і вам не погано :).
Погоджуємо чим можна ще пожертвувати. Наприклад, забиваємо на респонсів, чи кількість мов, чи якийсь функціонал. Фактично відрізати шматочки від планованого MVP, робимо його як міні MVP.
Відміняємо всі мітинги, які можна відмінити (тут ПМ-и мабуть зараз читають це з тіпаючим оком). Як приклад, частково можна скіпати дейліки, забути про щоспрінтові ретроспективи, мітинги планування спрінта. Робимо фундаментальний мітинг для всіх членів команди, щоб спланувати активності, спланувати взаємозв”язок між задачами у беклозі та майлстоуни готовності для поставок.
Планувати рефакторінг та розуміти що треба буде розгрібати технічний борг. Швидкість = костилі. І інколи ці костилі мають право на життя.
Ну, і не забуваємо, що це додатковий стрес на команду, і на ПМ-а особисто, тому будьте готові до великої кількості конфліктів, до того що всі ваші процеси і церемонії будуть посунуті дуже далеко на задній план. І, як показала моя практика, у частині проектів швидкість насправді є важливішою за якість на первій ітерації делівері.
