Умение эффективно формулировать проблемы помогает сократить страдания как свои, так и окружающих. Хорошая формулировка снижает количество эмоциональных споров, сводит к минимуму лишние предположения и субъективизм, не даёт свести решение к единственному варианту и не вызывает желания оправдываться или обвинять других.
«На рынке кадровый голод».
«У заказчиков завышенные ожидания».
«Срочные запросы от руководства».
«Очень плохо сформулированы задачи»
«Слабая коммуникация между командами из разных областей»
«Вечно изменяющиеся потребности»
«Плохо работающее ПО, нестабильные интеграции».
«Сотрудники покидают компанию из-за зарплаты ниже рынка».
«Конкуренция в регионе на рынке труда возросла, так как Москва предлагает удалёнку с лакомыми зарплатами. Труднее удерживать старых и привлекать новых сотрудников».
«Нет единой системы управления целеполаганием»
«Отсутствие документации на существующие бизнес-процессы и код»
«Отсутствие автоматического тестирования»
«Глупые пользователи, тимлиды, аналитики, разработчики, РП».
«Отказ от ответственности или перекладывание её на других. Как у коллег, так и клиентов».
«В случае проблемы ищут виноватого, но не себя».
— «Сложно перевести видение фаундеров в конкретные проекты и задачи на разработку»
— И чё?
— «Нет стратегии на уровне топов, либо она плохо доносится»
— И чё?
— «Идеи про светлое будущее так и остаются идеями»
— И чё?
- Проблема регулярно повторяется. Даже если редко, но регулярно — годится.
- Мы можем на это повлиять. Какова ценность формулировки проблемы, которую невозможно решить?
- Не является субъективным утверждением. Важно, чтобы у нас была возможность проверить её существование, договориться и отследить изменения.
- Не является завуалированным решением. Формулировка, предлагающая одно решение, сужает спектр возможных действий.
- Не содержит обвинение. Проблему стоит искать в системе, а не в конкретном человеке, и обвинения скорее отвлекают.
- Очевидно негативно. Проблема не требует пояснений, какие негативные последствия вызывает.
«В прошлом месяце ленивый отдел продаж не стремился советоваться с разработкой».
Если бы в прошлом месяце ленивый отдел продаж НЕ стремился советоваться с разработкой, с какими важными проблемами мы бы не сталкивались?
«Я добросовестно перебрал все буквы алфавита, и единственная болезнь, которой я у себя не обнаружил, была родильная горячка».
Не найти ответственных.
Хаос в бизнес-процессах.
Проблема с данными.
Мы заметно срываем сроки по 70% задач.
Мы не можем использовать заметную часть данных.
До 80% разработки не попадает на прод.
Здесь и дальше не во всех формулировках есть цифры, потому что я хотела показать честный результат диалога. Жирным выделены места, где мы хотим, чтобы появились метрики. Не все итоговые формулировки подходят под критерий «идеальная формулировка НЖЯ», но иногда лучше остановиться на почти хорошей, но не потерять важный смысл.
Слабая коммуникация между командами из разных областей.
Различная интерпретация SLA и критичности процессов.
Сложность с определением ответственных за систему.
Наш техдолг постоянно растёт.
Мы регулярно нарушаем SLE.
Мы регулярно нарушаем собственные критически важные процессы.
Уверенность в своей правоте без проверки кода.
Неаккуратность. Назвать человека чужим именем или написать ответ так, что никто его не поймёт.
Прокрастинация и неумение работать на удалёнке. Люди делают что угодно, только не работают.
Часто возникают ошибки в основном процессе клиентов.
Много повторной работы по сбору информации о проблеме клиента.
Заметно выросло количество аварийных обращений в поддержку.
Сроки выполнения больших тикетов часто заметно срываются.
Сложно распространять знания. Люди не читают, не знают, где искать и как использовать информацию.
Сложно привлекать людей к фиксации знаний.
Пока знания фиксируются, информация устаревает, что удлиняет доставку ценности.
Загрузка сотрудников-экспертов заметно превышает 100%.
У нас много повторной работы (прорабатываем одни и те же решения).
Мы часто повторно совершаем одни и те же ошибки.
Разграничение ответственности между проджектом и продактом.
Оценка ресурсов на задачи в разработку.
Управление ожиданиями клиентов.
Часто заметно превышаем запланированный бюджет проекта.
После завершения проекта возникает большое количество переделок.
Исходные формулировки: «Виноваты кто угодно, только не я/мы». «Это они не признают свою ответственность и не хотят искать проблемы в себе».
Итоговая формулировка: «Виноваты были они, а теперь дело в нас».
Исходные формулировки: «Это не проблемы, это мои субъективные боли. Даже из моей команды могут быть люди, у которых нет этих болей». «У меня болит, я устал, меня это раздражает, это противоречит моему чувству прекрасного».
Итоговые формулировки: «Это, очевидно, проблемы, и не только мои. Возможно, команда добавит ещё конкретики». «Возможно, команда выявит дополнительные проблемы, с которыми я тоже соглашусь».
Исходные формулировки: «Формулировки звучат нерешаемо».
Итоговая формулировка: «Понятно, что делать. Либо понятно, у кого спросить».
Исходная формулировка: «Давно обсуждаем, но заметного результата нет, как и сил/желания обсуждать дальше».
Итоговая формулировка: «Новые формулировки — это ещё не решение проблем, но в качестве промежуточного результата захотелось снова поговорить с коллегами».
Если бы [исходная формулировка проблемы] не было, с какой важной проблемой мы бы не столкнулись?
Если бы [...] не было, с какой важной проблемой мы бы не столкнулись?