Вредные советы по постановке задач и описанию требований

 

Ниже описаны 10 практичных и проверенных способов, как поставить задачу таким образом, чтобы жизнь разработчиков не казалось манной небесной, поставки срывались, бюджеты превышались, а качество трещало по швам.

  1. Не описывайте задачу

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

Как результат: команда поймет требования по своему, оценка будет неправильной, ожидания клиента не оправдаются.

  1. Добавляйте требования по ходу выполнения задачи

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

Как результат: сроки будут сорваны, команда демотивирована. Часть кода полетит в корзину, и бюджет будет превышен. Красота!

  1. Не давайте дизайн

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

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

  1. Держите нефункциональные требования в тайне

Твоим приложением должны пользоваться в Internet Explorer 5 на Win 3.11? Письма должны красиво выглядеть в Outlook 97? Тебе повезло! Попридержи эту информацию как минимум до демо клиенту. Дальше заведи критикал баг и требуй поддержки экзотического браузера или почтового клиента в рамках начальной оценки. Ведь твой продукт разрабатывают профессионалы, в конце-то концов.

Как результат: в спешке, работая с овертаймами и ненавистью к Internet Explorer, команда таки добьется подобия работы приложения в IE и Outlook. Но сроки и бюджет будут сорваны, а технический долг проекта возрастет.

  1. Не раскрывайте бизнес-ценность

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

Как результат: команда будет слабо вовлечена в продукт, ты не получишь выбора в способах решения задачи, продукт не будет соответствовать ожиданиям пользователя.

  1. Не думайте о том, как оценить результат внедрения

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

Как результат: продукт будет развиваться вслепую, классные идеи будут пылиться на полке, а команда пыхтеть над фичами, которые не нужны проекту.

  1. Не описывайте примеры использования

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

Как результат: бюджет превышен, сроки сорваны, ну все как ты любишь.

  1. Не давайте доступы и документацию к сторонним API

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

Как результат: время потеряно. Бюджет превышен. Качество... Ну ты понял.

  1. Не фиксируйте устные договоренности в Jira

Вы устно обсудили с PM или QA ряд неучтенных требований. Часть функционала решили сделать позже, часть по-другому. Мозг человека способен хранить до 10 ТБ информации. Зачем тратить серверное пространство Jira хостинга и фиксировать договоренности в комментариях? Оставь так. Дальше ты забудешь все, о чем вы говорили, или часть разговора. На демо у тебя будет волшебный козырь: мы говорили, что это должно работать по-другому. И крыть козырь будет нечем.

Как результат: твои ожидания и ожидания клиента будут нарушены, переделывать нужно будет в спешке, а это дополнительные затраты и риски сделать продукт некачественно.

  1. Обновляйте требования в комментариях, а не в description

Тебе не удалось провернуть пункт номер 9. И зануда PM или QA таки добились от тебя ответа в комментариях, которые прямо противоречат требованиям задачи. Комментариев накопилось несколько десятков. Имеем в требованиях А, в начале комментариев Б, а в итоге С. Отлично! Не вздумай актуализировать требования. Оставь так.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.