Парадоксально, але коли ми довго варимося в якомусь процесі, то втрачаємо об’єктивність. Як рибки в акваріумі.
Будучи поза акваріумом, ми також не до кінця об’єктивні, адже не маємо плавників.
Ідеально було би поваритися в різних котлах, щоби оцінити картину повніше, але то не завжди можливо. То що ж робити?
Глянемо на доволі надокучливі штуки: рефакторинг та legacy code.
Ці речі оцінюються зовсім по-різному джуном, техлідом і проджект-менеджером.
Умовний джун, через відсутність досвіду, ще не може оцінити legacy. Ну, є код, в ньому треба розібратися.
— А чому так?
— Due to historical reasons.
— Йой, най буде ©️
З рефакторингом ще цікавіше: сьогоднішній джун часто є необхідністю рефакторити в майбутньому 😁
Техлід вживає меш цензурну лексику щодо legacy та щодо необхідності рефакторингу. Він часто має непогані аргументи:
- Рефакторинг сьогодні скоротить витрати на розробку нового функціоналу завтра.
- Вартість підтримки зростає (в гіршому випадку — нелінійно).
ПМ часто погоджується з цими аргументами. А деколи не погоджується, бо бачить ще щось за межами акваріуму:
- Нового функціоналу особливо не планується.
Why try harder?
- Проект закриють наступного року.
Або ж віддадуть на аутсорс, а команді дадуть нові задачі. - Вартість рефакторингу суттєво перевищує потенційну вигоду.
Сюди ж — емпіричні дані: вартості попередніх рефакторингів втричі перевищили заплановані. Ніколи такого не було, і ось, сука, знову… - Непряма вартість такої роботи зараз неприйнятна.
Напр., втрата темпу розробки нового функціоналу ⇒ ризик віддати нішу конкурентам.
При цьому, не факт, що ПМ також об’єктивно оцінює вартість (особливо, якщо взяти до уваги демотивацію команди та потенційні проблеми з майбутнім наймом Cobol та банківський сектор).
Виходячи з презумпції необ’єктивності (бо в ПМа “немає плавників” 🙂), я бачу необхідність говорити і доносити свою думку до інших рівнів організації. При цьому, важливо слухати, бо це принесе в акваріум щось нове.
Я не маю яскравої success story на цю тему. Проте, бачу, що розмови допомагають. Бачу, як команда змінює думку, почувши (досі невідомі) аргументи “ззовні”. Бачу, як менеджмент корегує пріорітети після нарад з командою.
Важко оцінити, що було би, якби кожен стояв на своєму. Але, якщо ви знайомі зі скейт-, чи зі сноубордом, то пам’ятаєте: щоби рухатися вперед треба балансувати між “направо” і “наліво”.