У сучасних технологічних компаніях кордони між ролями стрімко розмиваються. У розмові на каналі The Pragmatic Engineer творці Pi та Flask — Маріо Цехнер і Армін Ронахер — обговорюють тенденцію, коли продакт-менеджери, маркетинг і навіть сейлз-команди безпосередньо втручаються в інженерні процеси: від правок на сайті до фактичних pull request’ів у репозиторій продукту.
Коли «не-інженери» заходять у код
Те, що ще кілька років тому виглядало б екзотикою, стає нормою:
– продакт-менеджери надсилають pull request’и;
– маркетингова команда самостійно змінює сайт;
– команда продажів збирає демо-функціонал, якого формально не існує в продукті.
Це вписується в популярну ідею «кожен може робити все» — коли доступ до інструментів спрощується, а бар’єр входу в технічні процеси знижується. З одного боку, це прискорює експерименти й дозволяє швидше реагувати на потреби ринку. З іншого — створює новий рівень ризиків.
Показовий приклад: сейлз-команда збирає демо-функцію, якої немає в основному продукті, і «ніхто не помічає». Це означає, що технічна й бізнес-реальність можуть почати розходитися — і не завжди в контрольований спосіб.
Чому «усі можуть усе» без процесів — погана ідея
Ключова проблема не в тому, що до коду торкаються неінженери, а в тому, що це відбувається без чітких запобіжників. Коли до розробки долучаються люди з інших функцій, зростає потреба в:
- Прозорих правилах внесення змін. Хто має право змінювати продакшн, а хто — лише демо чи тестові середовища.
- Рев’ю та валідації. Навіть якщо pull request створює продакт-менеджер, остаточне слово має залишатися за технічною командою.
- Синхронізації очікувань. Якщо сейлз показує клієнтам демо-функцію, має бути зрозуміло, чи й коли вона з’явиться в реальному продукті.
Без цього «участь усіх у всьому» перетворюється на хаос. Формально кожен може внести свій вклад, але немає механізму, який би гарантував цілісність продукту й передбачуваність його поведінки.
Нові ролі, старі принципи
Участь неінженерів в інженерних процесах — не тимчасовий тренд, а новий робочий стандарт. Проте базові принципи розробки залишаються незмінними:
- Процеси важливіші за ентузіазм. Навіть найкращі наміри можуть призвести до проблем, якщо зміни не проходять через узгоджений процес.
- Відповідальність має бути визначена. Якщо маркетинг змінює сайт, а сейлз збирає демо, все одно має бути команда або людина, відповідальна за технічну цілісність системи.
- Гнучкість не скасовує контроль. Можна дозволити ширший доступ до інструментів, але водночас посилити контроль якості, рев’ю та тестування.
Фактична участь продакт-менеджерів у коді — це логічний крок у бік більш інтегрованих команд. Але без чітких «рейок» процесу така інтеграція швидко виходить за межі керованості.
Джерело
YouTube: Mario & Armin: Product managers are now sending pull requests