x

Добро пожаловать в IT Leader Assistant.
Please Войти!

Создать аккаунт

Что делать, если бизнес отказывается описывать задачи на разработку

Максим Шаламов
10-22-2021 12:01
Что делать, если бизнес отказывается описывать задачи на разработку
В своей работе я много раз проходил через проблему того, что бизнес отказывается описывать задачи на разработку бизнес-функционала. Это может очень негативно сказываться на эффективности работы команды и качестве продукта. Поэтому я хочу разобрать подробнее, что можно сделать и возможно ли вообщем наладить ситуацию.

Почему важно работать с проблемой описания задач?

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

Решите для себя, готовы ли вы к изменениям

В большинстве компаний ситуация с плохим описанием задач не меняется годами. Люди терпят постоянные изменения в постановке задач, претензии к качеству результата в деталях, о которых не было упомянуто в описании, и бесконечные переделки функционала без изменения сроков. К сожалению эта проблема никогда не решится без вмешательства. Но главное, с чего нужно начать решение этой проблемы, это спросить себя, готовы ли вы на борьбу за хорошее описание задач? Готовы ли вы проявить твердость, пойти на конфликты ради отстаивания процесса и, в самом крайнем случае, сменить в итоге работу, потому что договориться не получилось (люди часто обижаются и начинают защищаться, если указывать им на проблемы)? Если вы не готовы пройти через это ради комфортной и эффективной работы, то принимайте правила игры и продолжайте работать как раньше.

Что, если вы решились все поменять?

Если вы решили, что работать эффективно для вас важнее риска, то главное это начать диалог и фиксацию проблем. А дальше действуйте по такому алгоритму:
  • договоритесь с теми, кто готов поддержать изменения и вместе обсудите алгоритм действий. Чем больше человек будет голосовать за изменения, тем весомее будут восприниматься ваши аргументы;
  • разработайте правильный формат описания задач и обсудите его со своими коллегами, чтобы ничего не упустить;
  • соберите ретроспективу по неописанным задачам и тому сколько раз вносились изменения (если используете git правильно, то проблем по репозиторию найти изменения не будет). Если данных пока нет, то сначала соберите нужную информацию;
  • соберите встречу, на которой вы подсветите бизнесу проблемы с описанием задач;
  • покажите ретроспективу по неописанным задачам и тому сколько раз вносились изменения, сколько раз откладывались сроки и проводились дополнительные обсуждения;
  • предложите провести эксперимент: бизнес описывает в предложенном вами формате задачи в течении месяца и вы замеряете, на сколько улучшилось время выполнения и уменьшилось число правок (эксперимент должен быть честным, если задачи не были описаны, то нечего измерять);
  • обычно результаты эксперимента настолько хороши, что бизнес соглашается играть по вашим правилам. Какое-то время…
  • как только ваша бизнес-команда снова начинает халтурить (возвращение к старым привычкам практически неизбежно), вам важно возвращать задачи на доработку и не брать в работу не описанные задачи;
  • если контакта с бизнесом добиться не получилось, но вы хотите попробовать устаканить свою работу, привлеките к решению свое руководство. Используйте в разговоре с руководством уже подготовленные данные по эффективности работы с плохим описанием задачи.

Если наладить проблему с описанием задач не получилось

Если все описанное выше вам не помогло, то вы можете использовать следующий подход:
  • фиксируете проблемные задачи (например в почте или комментариях в JIRA) в формате: “получил задачу, есть много вопросов (прикрепить список вопросов), за сроки не ручаюсь, ориентировочно сделано будет в дату”;
  • дальше ведете лог изменений в формате: “получил новые вводные, вопросы такие, новый срок такой-то”;
  • после этого спокойно работает по своим срокам. Если вы адекватно все оценили и понимаете в чем проблемы, то ни ваше руководство, ни HR не смогут найти к вам законных претензий.
Если к вашему подходу присоединится вся команда, то вы в любом случае получите адекватные сроки для работы. И, скорее всего, после какого-то времени, сам бизнес пойдет на то, чтобы хорошо описывать задачи. Однако, я бы все таки сильно не рассчитывал на помощь коллег в такой ситуации. Из десяти человек в команде, как минимум шестеро не будут готовы к применению такого подхода. Конечно ситуацию можно сильно улучшить, если инициатором такого процесса будет ваш руководитель.
Помните, что правильно поставленный процесс работы это залог хорошего результата, комфортной работы и ваша защита от выгорания. Удачи и не отступайте перед трудностями, тогда у вас точно все получится! А если нужна будет помощь, приходите за консультацией.
Если у вас есть какие-то вопросы или пожелания вы можете воспользоваться формой для связи с нами:
Теги:
УправлениеAgile

Комментарии

Чтобы оставить комментарий, пожалуйста, авторизуйтесь

Подписывайтесь на обновления

Последние статьи из нашего блога