Як уникнути скриньки Пандори. Плануємо реалізацію в розробці

Привіт! Мене звати Артур, я Associate Director у продуктовій студії Railsware. Більше п’яти років тому ділився з вами тут порадами щодо підготовки implementation plan, який зібрав чимало переглядів та фідбеку.

Відтоді ми провели ще більше детальних планувань і отримали нові інсайти. Як ви знаєте, процес реалізації в розробці ніколи не буває ідеальним — завжди можуть виникати нові виклики та помилки.

Тому нижче поділюсь нашими вивченими уроками. Вони можуть бути корисними як тим, хто роками використовує ці плани та готовий їх оптимізувати, так і тим, хто лише починає свій шлях у цій галузі й прагне уникнути помилок від самого початку. Зосереджусь на найчастіших викликах, які можуть виникати в спринтах, зокрема, через недоліки планування. Але спочатку нагадаю...

Що таке implementation plan

Якщо вам ліньки або бракує часу прочитати мою попередню статтю, ось коротко її суть. Створення implementation plan (aбо ж просто «імплану») — покрокової інструкції для кожної задачі — ключовий етап для структурування та спрощення процесу розробки. Перш за все, важливо чітко оцінити, які user stories команда планує реалізувати в наступному спринті та їхню ефективність. Зокрема, визначити можливі питання, труднощі та потенційні рішення.

Наступним кроком є створення детального плану дій. Основні завдання розбиваємо на підзадачі, встановлюємо строки виконання та призначаємо відповідальних. Це дозволяє простіше відстежувати прогрес і своєчасно реагувати на можливі відхилення від плану. Наприклад, на нашому продукті Mailtrap ми особливо зосереджуємося на послідовності виконання завдань, і імплан використовується саме для цієї структурованості.

16-17 травня, Київ. Квитки тут!👇

Також враховуємо ресурси, необхідні для реалізації проєкту: бюджет, персонал, інфраструктурні вимоги. Ідентифікуємо критерії завершення, які допоможуть оцінити результати планування.

Зрештою, ефективна комунікація та регулярний моніторинг є невід’ємними частинами успішного плану. Це забезпечує своєчасне інформування всіх зацікавлених сторін про прогрес та дозволяє вчасно вносити необхідні корективи. Чеклісти, управління невизначеністю, оцінки та аналіз — звучить в теорії просто, на практиці зазвичай складніше.

З цими складнощами й розберемося.

Як підходити до tech spike

У процесі планування ви зіткнулися з задачею нового типу — і вам потрібно поекспериментувати та потестувати новий підхід чи технологію. Тобто, маєте tech spike — невеликий дослідницький етап чи «розвідку боєм». Утім, він може швидко вийти з-під контролю, коли обсяг роботи виявляється більшим, ніж спочатку передбачалося. Тому навіть досвідчені команди можуть недооцінити складнощі, що призводить до втрати часу та ресурсів.

Наприклад, нещодавно наш інженер планував оновити велику бібліотеку. Це здавалося простим завданням на два тижні. Проте коли вже почали роботу, непередбачені проблеми створили ланцюгову реакцію — кожне виправлення тягнуло за собою нові зміни. У результаті замість 14 днів задача затягнулася на два місяці.

Щоб уникнути подібних ситуацій, ось кілька порад:

Заздалегідь домовляйтесь про час і цілі. Встановіть чіткий часовий ліміт для tech spike. Зазвичай це від трьох днів до тижня. Домовленість щодо часу повинна включати всіх учасників процесу, включно з продакт-менеджером. Тоді часові межі допоможуть уникнути ситуацій, коли технічне дослідження перетворюється на тривалий процес без визначеного завершення. Наприклад, на Mailtrap команда дійшла спільної згоди, що «спайки» мають займати лише день або два, що дозволяє швидко отримувати результати й рухатися далі.

Фіксуйте результати. Документуйте досягнуте в процесі роботи. Це допомагає краще оцінити реальний прогрес та усунути зайві «гілки». Якщо застосовуєте цей підхід на ходу, а не по завершенню, зможете швидше виявити кращий варіант розв’язання проблеми. А також, вірогідно, його можливі наслідки.

Фокусуйтеся на одній конкретній меті. Під час tech spike важливо уникати постановки задач «заради задачі». Всі дії мають розв’язувати конкретну проблему, що приносить business value для продукту. Це дозволяє зберігати фокус на суттєвих аспектах і не витрачати ресурси даремно.

Приклад конкретної мети: «Оцінити, чи існуючий delivery-механізм може бути оптимізований для підвищення швидкості доставки транзакційних мейлів, зосередившись на обробці bounce-повідомлень і кастомізації заголовків листів».

Тут задача має чіткий напрямок і конкретну користь: покращення ключових метрик сервісу. Це дозволяє зрозуміти, як зміни вплинуть на якість послуг і чи є доцільність впровадження оптимізації.

Варто уникати неконкретні формулювання на кшталт: «Дослідити можливості нового delivery-провайдера».

Чому це проблема? Такі задачі не несуть чіткої мети й можуть призвести до витрат часу на аналіз того, що не має безпосереднього значення для продукту.

Плануйте наступні кроки після кожної фази. Після завершення spike оцініть отримані результати та заплануйте подальші дії. Наприклад, після завершення spike у Mailtrap, ми вже точно розуміємо масштаб задачі та обов’язково обговорюємо висновки з продакт-менеджерами. Це допомагає прийняти зважене рішення щодо подальших кроків.

Якщо завдання виявляється надто складним, це сигнал, що щось іде не так. У таких випадках варто переглянути підхід — можливо, оновити план або навіть переосмислити саму задачу. Такий підхід дозволяє уникнути тривалих затримок і забезпечити ефективне управління складними процесами.

Як швидко та якісно зрозуміти складність завдань

Часто складно оцінити завдання не через його складність, а через неправильне форматування чи недостатню деталізацію. Тож спробуйте розбити великі задачі на менші та реалізувати через окремі pull request (PR). Чим менші завдання, тим легше їх перевіряти через PR, що покращує процес рев’ю.

Як це виглядає на практиці? Коли ми впроваджували агрегацію даних (нову функцію для клієнтів) на Coupler.io, ми розбили одне велике завдання на 14 pull requests, які були поділені між двома окремими репозиторіями. Кожен PR був окремим етапом — від налаштування базової структури до тестування продуктивності та впровадження нових метрик:

Завдяки цьому підходу ми змогли:

• перевірити кожен крок і переконатися, що всі зміни працюють належним чином;
• безпечно інтегрувати нову функцію, не перевантажуючи систему.

Радимо не забувати, що:

• Рефакторинг і загальні покращення виконуються окремо від змін логіки та нових функцій.
• Зміни в UI-бібліотеці варто впроваджувати окремо, дотримуючись принципу «одна логічна зміна — один PR». Це дозволяє зменшити складність рев’ю, полегшити тестування та прискорити доставку. UI-оновлення зазвичай не потребують значних змін в основному коді, але можуть суттєво впливати на вигляд і взаємодію з користувачем. Відокремлення таких змін також допомагає зберегти стабільність логіки роботи програми.

Як уникнути непорозумінь в команді

Часто клієнти запитують: «Чому реалізація цього етапу займає два тижні, якщо ми сподівалися завершити його за один?» Це абсолютно зрозуміле питання, адже, на перший погляд, багато задач виглядають простішими, ніж вони є насправді.

Зазвичай ці питання вирішують продакт-менеджери. Важливо документувати всі етапи, щоб була прозорість і чіткість у комунікації. Це допомагає продакт-менеджерам зрозуміти, що саме стало причиною затримок. Потім цю інформацію можна пояснити замовнику, що допомагає зменшити його занепокоєння.

Як досягнути цієї прозорості:

• Документуйте. Завжди фіксуйте цілі, терміни й виконані завдання. Коли клієнт бачить, що кожен крок має своє призначення, він краще розуміє, чому це забирає стільки часу.

  

• Пояснюйте, що планування — це економія. Наголошуйте, що чим більше часу витрачається на підготовку, тим менше проблем виникне в процесі реалізації. Оновити кілька пунктів у чеклісті або Google Docs набагато дешевше, ніж переписувати код чи тести. Крім того, легше виявляти залежності між задачами та компонентами.
• Робіть планування частиною процесу. Це не має бути одноразовою дією — це частина робочого циклу. Клієнти повинні знати, що це частина вашого процесу і ви знаєте, як зробити його ефективним.
• Прогнозуйте реалістично. Розбивайте завдання на невеликі частини з короткими оцінками часу. Невеликі задачі, наприклад, з оцінкою в пів дня, дозволяють точніше прогнозувати та знижують ризики порівняно з великими задачами, що займають тиждень. Такий підхід допомагає швидше виявляти проблеми, ефективніше управляти процесами та уникати затримок і необхідності додаткових пояснень.

Як бачити та оцінювати зміни

Після внесення змін у процес планування команда може покращувати точність оцінок задач і підвищувати ефективність їхнього виконання з кожним новим спринтом.

Однак варто пам’ятати, що ідеальне планування — це скоріше виняток, ніж правило. Навіть після ретельної підготовки реальні терміни можуть не відповідати початковим оцінкам. У таких ситуаціях важливо памʼятати, що з часом точність прогнозів зростає, і команди вчаться уникати повторення помилок.

Тож ось наші поради щодо вимірювання змін:

1. Зафіксуйте основні кроки. Перед оцінюванням будь-яких змін важливо спочатку визначити, які саме кроки потрібні для досягнення мети. Це дозволить уникнути неточностей і забезпечить чіткість у плануванні.

Для простих задач можна скористатися методом light implementation. Це спрощений підхід, який може стати результатом tech spike, наприклад, у вигляді списку задач після дослідження. Або ж light implementation може бути передумовою для spike — як перелік ризиків, напрямів і варіантів рішень, які потрібно вивчити.

Коли справа стосується складних задач, доцільно використовувати tech spikes. Вони допоможуть заглибитися в проблему, оцінити ризики та побудувати повну картину ситуації. Це критично важливо для уникнення неправильних чи розмитих оцінок через відсутність ключових даних.

2. Встановість стандарти оцінювання. Стандарт допоможе уникнути розмитості у плануванні та забезпечить, що кожна задача буде достатньо конкретною, матиме зрозумілий обсяг роботи та чіткі критерії прийняття. Це не лише підвищує точність оцінок, але й полегшує процес тестування, рев’ю та доставку результатів.

3. Відкрита комунікація. Оцінки задач можуть відрізнятися серед членів команди, тому важливо досягти узгодженості. Для цього досвідченим спеціалістам варто проявляти ініціативу:

• Обґрунтовувати свої оцінки. Пояснення допомагають усім членам команди зрозуміти логіку та цінність оцінки.
• Розбивати задачі на зрозумілі частини. Це дозволяє зменшити складність і полегшити розуміння для всієї команди.
• Забезпечувати прозоре обговорення. Оцінка має бути прийнята всіма учасниками, щоб уникнути непорозумінь під час виконання.

4. Оцінюйте прогрес через ретроспективи. Регулярне проведення ретроспектив дозволяє виявити не лише проблеми, а й позитивні зміни, які відбулися з часом. Це дає можливість зрозуміти, як зміни в плануванні впливають на загальний процес і якість роботи. Не забувайте залучати всю команду до обговорення, щоб отримати різні перспективи. І, знову ж таки, документуйте свої висновки.

5. Фокусуйтеся на оцінках задач. Якщо команда демонструє стабільну точність у своїх оцінках, це свідчить про ефективність планування. Якщо ж точність залишається низькою, важливо проаналізувати, де були допущені помилки, і вжити заходів для їх виправлення. Це може включати:

• перегляд попередніх задач з подібними оцінками;

Визначте задачі, схожі за обсягом чи складністю, і перегляньте їхні оцінки та фактичний час виконання. Це допоможе команді базувати оцінки на досвіді і реальних даних, а не тільки на припущеннях.

• залучення більш досвідчених колег до оцінювання;

Якщо у команді є фахівці з більшим досвідом, залучіть їх до оцінювання нових задач. Їхній досвід допоможе точніше передбачити потенційні ризики і специфічні деталі, які можуть вплинути на терміни.

• покращення взаємодії між командою та продакт-менеджером;

Часто неточність оцінок виникає через недостатнє розуміння задач. Забезпечте відкриту комунікацію з продакт-менеджером, щоб всі колеги розуміли цілі задачі та контекст, що допоможе точніше оцінювати час і зусилля.

6. Мотивуйте команду. Якщо команда відчуває незадоволення процесом (наприклад, нудьга або труднощі з розумінням завдань), важливо виявити корінь проблеми. Чи пов’язано це з неправильною постановкою задач? Можливо, планування було занадто складним або не враховувало важливих деталей? Обговорення таких моментів може призвести до позитивних змін, які підвищать мотивацію і продуктивність.

Implementation plan — фундамент для успіху

Ефективний implementation plan— це не лише про терміни та обсяг завдань, але й про здатність адаптуватися до змін і зберігати прозору комунікацію. Коли команда працює як єдине ціле, навіть найскладніші виклики стають можливими.

Памʼятайте, що успіх — це не тільки результат, а й якість процесу, який нас до нього веде. Будьте готові до змін, підтримуйте один одного та зберігайте відкритість до нових ідей.