🎯 Как решать проблемы на корню, чтобы сэкономить на лечении симптомов
В работе над любыми проектами возникают проблемы. Не всегда получается все сразу учесть, иногда меняются условия рынка, иногда подводят люди.
Часто получается так, что когда находят какую-то проблему, то ее не решают, а ей начинают "управлять", поддерживать. Поддерживать проблемы неэффективно и никогда не выгодно в долгосрочной перспективе.
Сегодня я расскажу про ключевые подходы к решению проблем, которые я вывел из кучи проектов, на которых я побывал.
🚫 Что мешает решать проблемы
Лечение симптомов вместо причин
Кейс: В команде разработки в Delivery Club изначально пытались повысить эффективность разработчиков, не замечая, что узким местом является тестирование.
Страх задавать неудобные вопросы
Пример: В IT-компаниях часто игнорируют вопросы о реальной стоимости ошибок на поздних этапах разработки. Часто вместо этого начинают действовать в лоб: команда не успевает, деньги есть — расширяем штат.
✅ А вот что помогает
Системный подход и документация
Чем больше документов, тем легче понять, как все устроено. Чем больше есть понимания, тем проще отличить симптомы от причин.
Визуализация
Строить диаграммы и карты причинно-следственных связей помогает разобраться в документации процессов и еще лучше понять связи между всеми сущностями. Какое-то научное исследование это подтверждает.
Теория ограничений
Если коротко, то вся производительность системы определяется ее самым слабым звеном. Почитайте книгу "Цель", "Цель 2", "Критическая цепь": после них взгляд на работу любой организации делится на до и после.
🛠 Как решать любые проблемы?
Диагностика всегда идет первой.
Вначале любой работы важно понять, какая у организации цель. Ведь если цели нет, то и работу делать смысла нет. Затем опросить команду, чтобы узнать субъективное мнение каждого, что мешает для достижении цели. После этого нужно провести небольшую аналитику.Сначала из полученной информации нужно выделить симптомы, то есть что конкретно эмоционально напрягает в работе каждого сотрудника.
После того как все симптомы есть на руках, нужно их собрать в аля семантические кластеры по типу возможной проблемы. Обычно на IT проектах почти сразу вырисовываются 2 крупных кластера "приходится переделывать по нескольку раз" и "не хватает ресурсов". Каждый кластер — это проблема, которая влечет за собой симптомы. Вот на этом этапе критично важно не останавливаться, а копать до корня.
🧪 Мы протестировали это внутри IT компании — работает на ура
В Delivery Club было продуктовые команды по 10 человек, ну и такой типичный Scrum с двухнедельными спринтами. QA-инженер один на команду. Спринт заполняли задачами, опираясь на оценки от разработчиков.
Какие проблемы из этого получались:
- Задачи на тест приходили большой пачкой в последнюю неделю спринта, а первую неделю тестировщик простаивал
- QA тратил 70% времени на вникание в контекст
- Разработчики подолгу ждали фидбека от QA из-за его пиковой неравномерной загрузки
Как мы это решили
1. Сблизили QA и разработчиков
- Подготавливали тест кейсы на этапе проработки бизнес требований для задачи
- Ввели предварительную оценку времени на тестирование задач на этапе планирования спринта
2. Ввели чеклисты готовности к тесту
- Полные и валидные бизнес требования
- Описанные тест кейсы с ожидаемыми результатами, возможными альтернативными поведениями
- Запускаемый билд приложения
Правило простое: не соблюдено хоть одно из условий — задача не идет в тест.
Результаты через 2 спринта после внедрения:
- Время на вникание в задачи у QA сократилось минимум в 2 раза
- Тестирование стало быть ориентированным на выявление корнер кейсов, безопасность и автоматизацию
- Команда стала закрывать 85-90% спринта против изначальных 50-60%
🧠 Главное, что нужно запомнить
По теории ограничений не нужно оптимизировать всю систему сразу. Не хватит ни времени, ни денег, да и смысла в этом никакого нет. На это можно смотреть, как на цепь: прочность всей цепи определяется ее самым слабым звеном. Соответственно, чтобы укрепить всю цепь — нужно укрепить только одно правильное звено. Еще аналогию часто проводят с бутылочым горлышком. Найдите свое бутылочное горлышко (или звено цепи) и оптимизируйте только его. Тогда все стальные элементы автоматически подчинятся. Работоспособность системы повысится и будет предсказуемой, и вся команда будет счастлива.
Также помните важные правила
- Все проблемы по итогу сводятся к одной корневой причине. Иногда она бывает сильно глубоко фундаментальной, но она точно всегда будет одна.
- Визуализация всегда помогает в принятии сложных решений
- Системный подход дает всегда дает больше эффекта в долгосроке, чем точечные решения.
- Надо не тупить и не лениться
Я надеюсь, что эта статья поможет вам понять, как находить корневые проблемы и повышать показатели бизнеса. У меня есть телеграм канал, где я делюсь прочими подобными вещами, которые могут быть полезны владельцам и управленцам бизнеса.