Оля — тимлид группы аналитики в Naumen Service Management Platform. Часто аналитики приходят к ней с разными вопросами. Например, как правильно работать с требованиями и общаться с разработчиками, почему не получается эффективно распределить время и приоритизировать задачи. Чтобы помочь команде решить сложности, Оля разработала стратегию самопомощи для аналитиков.

Оля Габдрашитова

Руководитель группы развития в Naumen Service Management Platform

В статье она расскажет об ошибках, их причинах и «красных флагах», которые помогают понять, что что‑то идет не так. Также Оля поделится выработанными рецептами предотвращения ошибок и объяснит, как и почему важно признавать промахи.

1. Ошибка масштаба

Ошибка масштаба — это ситуация, в которой работа и сроки реализации проекта или продукта изменяются нелинейно и непредсказуемо из‑за масштаба их требований.

Почему возникает?

Неправильно определили приоритеты или не определили совсем. Например, начали заниматься оптимизацией приложения, вместо того, чтобы сосредоточиться на разработке новых фич.

Не понимаем, где заканчивается наша зона ответственности, поэтому выполняем задачи, которые относятся к разработчикам, дизайнерам или тестировщикам. Нарушается рабочий процесс и ухудшается эффективность всей команды.

Перегружаем себя требованиями и стремимся приблизиться к идеалу в решении задачи. Часто учесть все и сразу невозможно: тяжело приоритизировать задачи, и мы просто физически не можем охватить все аспекты из‑за ограничений в ресурсах и времени.

Как понять, что что-то делаем не так?

? Чувствуем панику от задачи, чрезмерное беспокойство и стресс из‑за того, что задача кажется непосильной. Убегая от переживаний, откладываем задачу и переключаемся на что‑то более простое и менее приоритетное. Проект затягивается.

? Долго решаем проблему самостоятельно. Ощущаем разочарование, теряем энергию и совсем не понимаем, что вообще делаем.

? Ощущаем перегруз большим количеством требований, объем информации просто не вмещается.

Рецепты самопомощи: как устранить ошибку масштаба?

? Декомпозировать — разбить сложный процесс, требования или задачи на управляемые шаги. Например, перед нами стоит задача на разработку решения. Заниматься будем следующим: проводить интервью, анализировать конкурентов, консультировать разработчиков и проектировать решения. Каждый из этих этапов можно разбить на небольшие шаги. Так увидим, что весь процесс может быть более управляемым и понятным.

? Приоритизировать — ответить на вопрос, что сейчас важнее для бизнеса? Например, работаем с требованиями к продукту. Здесь можно обратить внимание на количество стейкхолдеров, проследить откуда больше всего проблем и к какой фиче много вопросов. Важно посмотреть на требования под разным углом и определить их приоритет.

? Уточнить постановки задачи и своей зоны ответственности. Можно посмотреть регламенты, что делает аналитик, что разработчик, а что тестировщик. Спросить у наставника и руководителя. Если это наша зона ответственности, декомпозируем, приоритизируем и берем в работу. Если нет — отдаем тем, кто за это ответственный.

? Задать себе вопрос: «‎Чтобы что…?»‎. Всегда стоит задаваться универсальными вопросами: какую я достигну цель, выполнив это требование, или какую проблему решение этой задачи закроет. Это помогает сфокусироваться на приоритетных задачах и определить цель.

2. Ошибка заточения

Мы в своей работе всегда стремимся найти решение: прийти к определенному выводу, сделать прогнозы, составить требования к работе системы. Но иногда настолько сильно погружаемся во все эти процессы, что начинаем буквально жить поиском решения задачи. А когда находим — «‎влюбляемся»‎ в это решение. Так начинаем верить в свою правоту и отторгать альтернативные подходы. Это и есть ошибка заточения.

Почему возникает?

Специализируемся в одной области и уделяем внимание элементам, которые согласуются с нашими ожиданиями, не принимаем новую информацию несовместимую с нашей специализацией. Например, бизнес‑аналитик специализируется на финансовых технологиях. Он привык работать с транзакциями, банковскими системами, стандартами безопасности для финансовых операций, умеет адаптировать любые требования и потребности в этой области. Но если такого аналитика погрузить в сферу здравоохранения, ему, вероятно, будет сложно перестроиться — требования и реализации решений разные. То же самое происходит при переключении с одного проекта на другой. Мы можем мысленно оставаться в предыдущей специализации и быть уверены в правильности выбранного подхода.

Руководствуемся подтверждающим предвзятым мышлением и при реализации требований или проведении интервью начинаем искать информацию и интерпретировать ее таким образом, чтобы подтвердить наше мнение. Докопаться до корня проблемы станет гораздо сложнее, а еще будем решать выдуманную проблему, которая не настолько важна для бизнеса.

Стремимся к идеальному результату, без учета реальности или ограничений. Мы живем в мире, где требования постоянно меняются, а технологии развиваются. В попытках завернуть наше решение в идеальную упаковку, не учитывая сроки и стоимость разработки, рискуем совсем не реализовать решение.

Как понять, что что-то делаем не так?

? Ощущаем сверхуверенность в своей правоте, нам сложно принять другую точку зрения. Не хотим искать очевидные ошибки в своей работе: исходим из позиции «‎это же логично, иначе быть не может»‎. Но на самом деле, наше решение может быть логичным только для нас или для определенной сферы.

? Сопротивляемся обратной связи. Например, презентуем решение разработчику, который пока не погружен в тему. Он задает простой и очевидный для нас вопрос, а мы ощущаем раздражение или гнев. Это может быть признаком, что где‑то мы переоценили свое решение из‑за привязанности к нему.

? Игнорируем альтернативные решения. Не хотим воспринимать подходы, которые нам могут рекомендовать коллеги.

Рецепты самопомощи: как устранить ошибку заточения?

? Проверить гипотезы — вместо того, чтобы предполагать, что наше решение верно, логично и идеально, лучше сформулировать его как гипотезу, которую нужно проверить. Это позволит сохранить объективность и открытость для новой информации.

? Рассмотреть альтернативные решения. Даже если кажется, что правильное решение найдено, нужно рассмотреть другие подходы. Задать себе вопрос «А как еще можно достичь этих целей?». Я, например, сталкивалась с ситуацией, когда разрабатывать ничего не потребовалось, достаточно было просто поменять что‑то в процессах и таким образом решить проблему. Так мы нашли альтернативное решение, помогли достичь ценности заказчикам и сэкономили себе время.

? Расширить фокус. Стоит смотреть на свое решение с позиции наблюдателя — в этой ситуации мы не аналитик, а, например, заказчик. Получится подсветить детали, которые могут быть ключевыми. Сюда же я включаю постоянное обучение: митапы, лекции и общение с другими экспертами. Такие мероприятия расширяют наш кругозор и представление о возможных путях решений.

? Получать и принимать обратную связь. Не нужно бояться критики — коллеги могут заметить то, что мы пропустили. А еще всегда стоит задумываться над тем, откуда появилась такая привязанность и любовь к своему решению. Важно держать в голове, что наше решение — это не мы. Оно может быть правильным и неправильным, идеальным и не очень. Необходимо сохранять гибкость и активно собирать обратную связь.

3. Ошибка отсутствия зафиксированных договоренностей

К неверным заключениям и решениям мы можем прийти из‑за отсутствия договоренностей или недостаточного понимания всей картины.

Почему возникает?

Предполагаем, что все участники встречи отлично нас поняли. Думаем, что заказчики и разработчики погрузились в дискуссию, процесс и наше решение. Поэтому считаем ненужным отправлять обобщенные заметки или обозначать вопросы, которые обсуждались на встрече. Но это неправильный подход. У каждой роли есть свои задачи. Мы, аналитики, например, находимся в полном контексте своей задачи и все о ней знаем. Но другие роли могут знать об этом гораздо меньше.

Не зафиксировали ответственных. Бывают ситуации, когда участник или организатор встречи не понимает ценности фиксировать ответственных после созвона. Например, над проектом работают несколько аналитиков. Мы договорились, что один собирает кейс, другой уточняет вопрос у разработчика. Проговорили, но никак не зафиксировали.

Сильно загружены другими задачами, поэтому пропускаем этап написания совещательных заметок.

Как понять, что что-то делаем не так?

? Когда у нас спрашивают «Почему было принято решение сделать именно так?»‎, у нас нет ни доказательств, ни аргументации.

? Приходим на очередную встречу по проекту и начинается перекладывание ответственности. Проблема — договоренности не выполнили, проект простаивает.

? Пытаемся отложить подведение итогов на потом. Созвон прошел, и мы думаем, что завтра вспомним все договоренности и сможем их прописать.

Рецепты самопомощи: как устранить ошибку отсутствия зафиксированных договоренностей?

? Фиксировать договоренности — да, очевидно, но тем не менее часто об этом забываем. Фиксировать основные моменты и вопросы в заметки можно прямо на встрече. Для записей я по старинке использую карандаш и бумагу. После встречи оцифровываю, фиксирую и отправляю всем участникам встречи.

? Отдыхать и делать перерывы между встречами. Перерывы нужны для того, чтобы успевать фиксировать результаты созвона сразу же после встречи. Поэтому полезно закладывать 10–15 минут и за это время подготавливать информацию и рассылать ее участникам.

? Записывать встречи — это поможет освежить какие‑то моменты. Однако нужно время, чтобы пересмотреть запись, так что этот момент тоже необходимо учитывать.

? Применять «Правило двух минут» — если какая‑то задача занимает меньше двух минут, делаем ее прямо сейчас, прямо на встрече. Например, договариваемся вынести за рамки встречи какой‑то вопрос с заказчиком, лучше прямо на встрече открыть календарь и назначить встречу.

4. Ошибка неопределенности требований

С подобной проблемой мы сталкиваемся, когда система, проект или продукты начинают неправильно функционировать из‑за нечетко определенных или пропущенных требований.

Почему возникает?

Нет понимания цели задач проекта и детализации изначальной проблемы. Представления и ожидания от результата у всех участников процесса разные.

Долго работаем над одной и той же задачей без синхрона с заказчиком. Отсутствие эффективного общения между командами аналитиков, разработчиков и заказчика приводит к нечеткости требований.

Требования меняются без определенного порядка и проверки: один приходит с одним запросом, другой с третьим. Проблема в том, что все эти требования могут противоречить друг другу. Наша задача — организовать процесс приема этих требований и валидации с тем, что уже есть. Сначала проверить и не брать требования сразу же в работу.

Как понять, что что-то делаем не так?

? Долго восстанавливаем контекст. Например, у нас идет встреча около часа, и 40 минут из этой встречи мы просто вспоминаем, а что вообще было. Появляется ощущение, что мы говорим с разработчиками и тестировщиками на разных языках об одном и том же требовании.

? Зацикливаемся — обращаемся к одним и тем же проблемам, но не получаем четкий прогресс или решение. Постоянно возвращаемся к изначальной точке и не генерируем новые идеи.

? Как только замечаем, что большое количество требований приходит хаотично и противоречит друг другу, не проверяем их и не налаживаем процесс управления этими требованиями.

Рецепты самопомощи: как устранить ошибку неопределенности требований?

? Регулярно встречаться со стейкхолдерами — взаимодействовать и периодически проверять требования, чтобы на ранних стадиях выявить размытые требования.

? Прототипировать — использовать техники раннего обнаружения проблем: обзор требований, моделирование и прототипирование. Это поможет нам выявить неопределенность и засинхронить контекст.

? Сверять понимание целей — для того, чтобы все работали в одном поле и понимали, зачем делается та или иная фича, очень важно сверить, понять и распространить цели на всех участников проекта.

? Проверять каждое требование на полноту и согласованность и выявлять противоречия на ранних этапах, как только получили эти требования. В нашей команде, например, есть ревью итогового решения. Другой аналитик вычитывает уже собранные кейсы, требования и решения. Такое же ревью проводит тестировщик. Это позволяет нам на ранних этапах понять, есть у нас несогласованность в требованиях или нет.

5. Ошибка переполнения

Речь о перегрузе, когда у нас так много всего, что мы просто не понимаем, что с этим всем делать.

Почему возникает?

Неэффективно планируем рабочее время. Например, на одно время запланировали две встречи.

Пытаемся делать несколько задач одновременно и занимаемся несколькими проектами в один момент.

Не подходит ритм команды. Мы все разные: кто‑то привык работать в динамичной команде и ему подходит ускоренный формат, кому‑то, наоборот, хочется помедленнее и основательнее подходить к задачам.

Как понять, что что-то делаем не так?

? Берем в работу 15 пунктов, которые нужно выполнить за один день. Параллельно еще задействованы в работе с другими участниками.

? Работаем над задачей только после определенного времени, чтобы никто не отвлекал. Выбираем для этого нерабочее время и по вечерам прорабатываем требования.

? Чувствуем раздражение, любые вопросы от команды и участников проекта начинают триггерить.

Рецепты самопомощи: как устранить ошибку переполнения?

? Опустошить инбокс и выплеснуть все, что есть в голове на бумагу, как только появилось ощущение, что слишком много задач и требований. Это займет буквально 15–20 минут, но поможет выйти из состояния шока и понять количество работ, которое необходимо сделать.

? Не пренебрегать этапом планирования личной эффективности и личной работы. Выделять определенный день под конкретные задачи или ставить в календарь регулярные встречи на проверку документации, чтобы все держать в фокусе.

? Сигнализировать руководителю и уточнять приоритеты. Не нужно пытаться решить все дела сразу и одновременно. В моей практике была ситуация, когда я занималась несколькими задачами и в какой‑то момент пришла к своему руководителю. Оказалось, что результат по одной из задач от меня ожидался только через месяц. Так я уточнила приоритеты и сроки, и мне стало спокойнее. А еще не стоит забывать о балансе работы и личной жизни. Планируйте не только работу, но и отдых. Добавляйте короткие перерывы и делайте разминку, это поможет поддерживать ум в легкости и спокойствии.

Нет ничего страшного в том, чтобы совершать ошибки. Важнее то, как мы их исправляем. Нужно уметь смотреть в глаза своим промахам, знать «‎красные флаги» и вовремя использовать собственные рецепты устранения ошибок.

Лучший универсальный рецепт для того, чтобы найти именно свои рецепты, «‎красные флаги» и решения, — рефлексия. Этот инструмент помогает проанализировать свое поведение, прошлый опыт, свои задачи. Полезно изучать свои подходы к решениям, ошибки и систематизировать знания в собственные рецепты и «‎красные флаги», на которые можно обращать внимание и предотвращать ошибки.