Знание, как реагировать, когда что-то идет не так, важнее, чем предотвращать поломки. Основные принципы проектного менеджмента.
Шаг 1. Не паникуйте и определите свою проблему.
Мой самый первый “сбой” произошел, когда я была новичком в управлении проектами. На тот момент я вела проект по разработке самописной CRM-системы. Она была наполнена разными фишками, а также была функция нового для меня метода сохранения информации. Суть этой функции заключается в том, что после нажатия вне поля изменения должны автоматически сохраняться. Хотя эта функция казалась обычной, в какой-то момент она перестала работать правильно, вызывая сбои и дублирование информации. Наш клиент точно бы не обрадовался, если бы мы такое выкатили) А выявилась данная проблема почти перед релизом.
Изначально мы не считали это серьезной проблемой, но когда фикс одного бага начал вызывать другой баг и так до бесконечности, я испугалась. В этот момент мы немедленно собрали людей, чтобы обсудить проблему.
Наша интуиция просто кричала “Быстро откатывайте все назад!”. Это вполне естественно: мы сами создали проблему, неудивительно, что мы сразу же хотели ее исправить. Однако быстрые решения часто приводят к новым ошибкам. Как уместен был бы тогда вопрос: "Почему это не работает?". Но в моей голове на тот момент звучало: "Что это меняет? Пусть ребята делают свою работу им лучше знать”.
Шаг 2. Диагностика и понимание источника(ов) вашей проблемы.
Из-за беспокойства и паники, которая охватила команду, мало кто спрашивал нас, почему что-то идет не так. Мы проверяли все что можно и даже смотрели, нет ли чего-нибудь странного на системном уровне. Необычно было то, что у нас не было кеширования, но после сброса кеша все начинало работать, а потом опять постепенно отваливалось. После того, как мы выяснили корень проблемы, мы все еще раз перепроверили, убедились и начали откат. В дальнейшем мы приступили к рефакторингу и это был верный шаг.
Прежде чем откатывать все назад, важно уметь обнаружить возможности для изучения корня проблемы, иначе можно упустить ценный источник информации.
Шаг 3. Исправление: приступим к работе над проблемой.
Когда мы сталкиваемся с проблемой, может показаться, что решение ее - это следующий шаг. Однако часто необходимо быть более внимательным. Важно определить приоритеты, выделить ключевые шаги для минимизации рисков и убедиться, что ожидания других заинтересованных сторон соблюдены. Необходимо также обеспечить доступ к ресурсам, необходимым для решения проблемы. Это может включать время, доступ к информации или помощь коллег. Во время исправления ошибок, я пришла к выводу, что основная проблема заключалась не столько в информации или помощи других разработчиков, сколько в отсутствии фокуса. Частые созвоны и стремление получить всю информацию о ходе работы только мешали, отнимая время и концентрацию. После обсуждения этой проблемы с техническим руководителем, удалось сократить ежедневные собрания разработчиков до минимально необходимого уровня, что привело к значительному увеличению скорости работы и улучшению их концентрации.
Шаг 4. Проверка и обучение
Часто замечаю, если набраться немного терпения и дать разработчикам больше свободы на начальных этапах решения проблем, это приводит к уверенности и спокойствию при последующих выпусках и исправлениях.
Однако, после того как все исправлено и работает хорошо, наша работа все равно не закончена. Теперь необходимо убедиться, что полученные уроки из этой проблемы помогут развитию всей организации. Часто люди видят положительную ретроспективу как сигнал, что проблема больше не повторится, но это не совсем разумно. Лучшим уроком является умение более эффективно справляться с проблемами, а не просто избегать их.