Дайджест "Як розпізнати та зупинити саботаж в середині компанії"

Всім привіт! Мене звати Дмитро Руденко. Я з основних спільноти SaaS Founders. Допомагаю власникам ІТ-компаній знаходити нових великих клієнтів за допомогою ліди-генерації в LinkedIn. Сьогодні ми проговоримо про таку незвичайну річ, як саботаж всередині компаній. Давайте спочатку проговоримо про термінологію. Що ми маємо на увазі під саботажем? Термін simple sabotage запозичений з світу диверсійної діяльності і означає використання прихованих методів для підриву продуктивності організації. В контексті розробки програмного забезпечення це означає застосування різних хитромудрих прийомів з метою уповільнення випуску оновлень, доставки цінності клієнтам та загального прогресу проєктів. За даними Дослідницького інституту програмної інженерії, у 2022 році через складність інфраструктури та процесів продуктивність розробників в середньому знижувалась на 23%. Що, власне, є причиною саботажу технологій? Ну, по-перше, це ускладнення архітектури та інфраструктури. 64% опитаних у цьому дослідженні Інституту програмної інженерії скажуться, що в їхних проектах забагато зайвих компонентів, шарів та інтеграцій. Наприклад, у корпорації Oracle лише за останній рік Кількість мікросервісів в середньому зросла з 210 до 340 на один великий проєкт. І все це, звичайно, у складнію розробку, тестування та підтримку. 71% опитаних організацій каже, що існує складній процес управління змінами. Наприклад, в великих компаніях це значна проблема. Наприклад, в тому же Apple через бюрократію підготовка нової фічі до реалізу в середньому займає 98 днів проти 62 у Google. Тобто Google розвивається набагато швидше і набагато швидше вводить на ринок свої новинки. Також саботаж технології проявляється у перешкоджанні автоматизації та оптимізації процесів. 57 відсотків ореспондентів відзначають складність снесення змін через бюрократію. Наприклад, через це у Майкрософті, через обов'язкові код-рев'ю та апрувал, скількість релізів зменшилася за рік з 48 до 28. Це на 40 відсотків в середньому нижче, менше, ніж у конкурентів. Отже, саботаж технології процесів є поширеною проблемою, що істотно гальмує продуктивність. І її вирішення потребує оптимізації архітектури, інфраструктури та багатьох внутрішніх процесів всередині компанії. Приклади. Ну, наприклад, компанії забагато витрачають часу та зусиль на планування замість того, щоб, в принципі, робити релізи. Це перша проблема. Друга проблема, вона звичайна. Ігнорування потреб користувачів, що призводить до того, що велика кількість продуктів та фіч, вони створюються, вони не використовуються тими, хто, в принципі, має, для кого цей продукт розроблений. Ну і, звичайно, менеджери часто дискредитують корисні метрики. Що я маю на увазі під цим питанням? Те, що менеджери часто замовчують незручні факти та показники, які демонструють реальні проблеми. І навпаки намагаються показувати ті показники, де все добре, все якісно, все працює чудово. Ну і все, в принципі, призводить до ігнорування недоліків та знижує ефективність команд. Наприклад, якщо ми говоримо про саботаж команди, демотивація ключових фахівців. Що тут має на увазі? Що за даними Гелаб у 2022 році лише 33% працівників почуваються завантаженими на роботі. Тобто фактично 67% вони не дезавантажені. І це фактично приводить до того, що люди не розуміють, чим вони займаються, вони не використовують свій робочий час максимально ефективно. І це приводить до плинності кадрів і до того, що компанії не можуть фокусуватися на тому, що є цікаво, то досягати певної мети. Крім того, є така проблема, як штучне роздування кадрів. Багато керівників наймають зайвих менеджерів та архітекторів для збільшення своїх повноважень. Звичайно, це приводить до великої кількості непродуктивних нарад, уповільнення процесів і до мотивації команди через бюрократію. В принципі, оптимальне співвідношення менеджерів до інженерів — це десь 1 до 10. 1, умовно, до 8-12. В середньому 1 до 10. Якщо у вас більше менеджерів на розробників, інженерів, то, можливо, то зайві менеджери. Крім того, ускладнюється процес ухвалення рішень. Тобто, в принципі, в ІТ рішення мають прийматися досить швидко. Наприклад, Лесян каже, що оптимальний час ухвалення рішень в ІТ до двох днів, в ідеалі кілька годин. Інакше процеси бюрократизації загальмують процеси прийняття рішення, ну і все це призведе до того, що команда буде працювати неефективно. Такий спосіб, тихий саботаж, який природнім чином виникає, якщо на нього не звертати увагу, істотно знижує мотивацію команди, продуктивність та швидкість розробки. І щоб уникнути цього, потрібно будувати прозору орг структуру, чіткі цілі та ефективні процеси. Отже, простий саботаж істотно гальмує роботу над продуктами, знижує ефективність команд та якість програмного забезпечення. Щоб уникнути таких тихих подвідривних дій, варто фокусуватися на простоті і цінності для користувача, прозорості процесів та даних. Отже, якщо та тема була цікава, напишіть, ми з радістю заглибимося далі. Будемо вивчати проблематику, яка важлива для фаундерів компаній-порозробців. Всім гарного дня, підписуйтесь на соціальних мережах та бажаю вам великих контрактів та продуктивної роботи всередині команди. Дякую, гарного дня.