… то маю на увазі не те, що Вам необхідно неодмінно звільнити QA, DevOPS, PM чи ще когось. Я маю на увазі те, що ці позиції існують аби приховати проблему, а не вирішити її. Такий підхід може достатньо довго працювати і задовільняти Вас. В решті решт хто сказав, що бізнес має існувати вічно? Бізнес має існувати лише допоки є попит на товари чи послуги, які він надає. Якщо Ви плануєте чи вже заробляєте на хайпі, то Вас це не має хвилювати. Закривайте цей таб у браузері.
Якщо ж у Ваших планах побудова чогось довготривалого (> 3 років), то Вас необхідно зрозуміти дві прості речі:
- Проблема у Вашому підході до людей.
- Ви не маєте бездумно копіювати бізнес-моделі, організаційне структури, технології, тощо.
Проблема у Вашому підході до людей
Більшість розробників не розуміють бізнес. Вони не розуміють пріорітетів бізнесу. Вони не розуміють часових обмежень. Вони не розуміють, що багато де якість не хвилює бізнес та те, що вони насправді не можуть суттєво вплинути на якість/складність.
Більшість розробників не хвилює бізнес. Розробники отримують фіксовану зарплатню в обмін на свій час, а не на свою зацікавленність. Вони не мають, як то кажуть “skin in the game”. Якщо компанія буде знищена критичним багом, або великою кількістю багів та нестабільною роботою інформаційної системи, то розробникам усього лише доведеться змінити місце роботи, скоріше за все ще й прибавку отримають.
Ви коли приховуєте інформацію від розробників і не інвестуєте у їх навчання – не робите собі краще і не захищається. Ви в такий спосіб лише створюєте собі багато проблем, для вирішення яким Вам будуть необхідні додаткові працівники, які в решті решт будуть коштувати Вам ще дорожче і це вже не кажучи про те, що усі процеси ускладняться та сповільняться, то також відобразиться на вартості розробки.
Ви коли не зацікавлюєте розробників материально, то і не отримуєте ніякої лояльності та зацікавленності з їх сторони. Гроші, які Ви зекономили, запропонувавши середньоринкову зарплатню – це ніщо у порівняння з витратами на пошук нових розробників, їх ознайомлення з проєктами та процессами у компанії, та все одно глибоке розуміння історії розвитку та рішень буде значною мірою втрачене, нові розробники не будуть розуміти коду написаного до них та будуть постійно жалітися і у власних помилках звинувачувати попередників.
Генрі Форд платив інженерам, що займалися обслуговуванням обладнання лише за той час, коли обладнання працювало, а самі відповідальні за нього працівники – відпочивали. Як результат, працівники були дуже зацікавлені у тому, аби обладнання працювало безперебійно, благовійно ставилися до нього та такого відношення вимагали від його операторів. Розробників можна порівняти з творцями того обладняння, інженерів, що відповідали за його обслуговування та повернення у робочий стан з SRE чи т.з. “DevOpsами“. При цьому я не чув, аби хтось повторював цю розумну тактику Форда з SRE. Їм, майже як і усім, платять фіксовану щомісячну зарплатню.
Ви не маєте бездумно копіювати бізнес-моделі, організаційні структури, технології, тощо
Запозичення, безумовно, можуть бути дуже корисними, але перш за все вони мають бути необхідними, добре вивченими та адаптованими для Ваших реалій. Усе інше буде служінням культу вантажу та лише нашкодить.
Починайте з tabula rasa і ускладнюйте процесси лише за необхідності, для вирішення реальних проблем з якими стикаєтеся. Навіть не так! Вирішуйте реальні проблеми з якими стикаєтеся через вирішення їх першопричин. Лише у крайньому випадку, коли проблема повторюється і першопричина не може бути ліквідована – створюйте процесс для її обходу.
Є шлях навпростець і є процес як обхідний, більш безпечний шлях. Спочатку треба з’ясувати, що шлях навпростець є небезпечним і чим саме, оцінити цю небезпеку та розрахувати, чи не несе запропонований новий шлях більших витрат, аніж сама небезпека. Велика кількість процесів наносить більше збитків, аніж проблеми, які за їх допомогою намагаються вирішити.
Залишити відповідь