Я хочу зробити все технічно правильно, але роботодавець цьому перешкоджає

[toxi]

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

Чому бізнес не прагне реалізувати «ідеальне» технічне рішення, а погоджується на тимчасові обхідні механізми, часткові або компромісні варіанти? Логіка часто проста: «працює — і добре; коли перестане працювати — тоді й будемо вирішувати».
Зазвичай у цьому звинувачують керівництво — мовляв, воно надто економить, не має достатньої технічної експертизи та не розуміється на ІТ.
Проте насправді ситуація інша — просто варто подивитися на неї з позиції бізнесу, який оперує зовсім іншими категоріями.

Бізнес-логіка
Мета будь-якого бізнесу — отримання прибутку, а не технічна досконалість інфраструктури. Відповідно, компанія завжди прагне збільшити дохід і мінімізувати витрати.
ІТ-відділ у більшості компаній — це центр витрат (cost center), а не центр прибутку. Безпосередньо дохід він не генерує. Тому фінансування ІТ, як і інших витратних підрозділів, відбувається за принципом економічно обґрунтованого мінімуму.
Як визначається цей мінімум? Не технічними показниками — керівництво може не знати їх і не зобов’язане знати. Основний критерій — фінансовий.
Якщо проблему можна вирішити грошима, то з точки зору бізнесу це не «проблема», а витрати. І керівництву зазвичай відомий граничний обсяг одноразових витрат, які компанія може собі дозволити. Найчастіше цей показник корелює з операційним прибутком — тобто виручкою мінус постійні витрати.

Чим вищий цей показник, тим більше ресурсів можна спрямувати на мінімізацію ризиків.

Фінансова оцінка ризику
Ситуація виглядає приблизно так:
Адміністратор пропонує впровадити певні технічні рішення. Вони обґрунтовані, відповідають best practices і галузевим рекомендаціям.

Керівництво запитує:
- Що станеться, якщо цього не зробити?

Адміністратор описує можливі наслідки: простій, втрата даних, зниження продуктивності тощо.

Наступне запитання:
- Яка ймовірність цього сценарію? Як часто подібне вже траплялося?

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

Комплексний підхід
Існують також ризики, де інвестування лише в ІТ не має практичного сенсу.
Наприклад, адміністратор просить кошти на нові джерела безперебійного живлення (UPS), щоб сервери працювали годину замість 15 хвилин.

Бізнес ставить зустрічне запитання:
— Навіщо забезпечувати годину автономної роботи серверів, якщо робочі місця вимкнуться через 15 хвилин?

З точки зору компанії, це буде витрата без реальної бізнес-цінності.

Ризики маніпуляцій
Можна, звісно, перебільшити ризики й домогтися фінансування. Але якщо прогнозована критична подія відбудеться, і фактичні наслідки виявляться менш значними, ніж очікувалося, керівництво зробить висновки.
Можливо, формальних дисциплінарних заходів не буде, але подальші бюджети можуть скорочуватися або проходити через «внутрішній понижувальний коефіцієнт».
Ще гірший сценарій - коли кошти виділено, подія сталася, але задекларований рівень захисту не спрацював. Тоді виникають серйозні питання щодо обґрунтованості витрат і компетентності відповідальних осіб.

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

Технічна правильність важлива. Але в корпоративному середовищі вона має бути економічно обґрунтованою.