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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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