Ниже описаны 10 практичных и проверенных способов, как поставить задачу таким образом, чтобы жизнь разработчиков не казалось манной небесной, поставки срывались, бюджеты превышались, а качество трещало по швам.
1. Не описывайте задачу
Title = description.
2. Добавляйте требования по ходу выполнения задачи
Задача уже в разработке? Скоуп утвержден? План построен и прояснен с клиентом? Настал твой звездный час. Поменяй требования задачи.
3. Не давайте дизайн
Задача затрагивает фронтенд? Новый функционал связан с изменением интерфейса? Супер! Не прикрепляй мокапы и финальный дизайн к задаче. Пусть ребята потренируют фантазию
4. Держите нефункциональные требования в тайне
Твоим приложением должны пользоваться в Internet Explorer 5 на Win 3.11? Письма должны красиво выглядеть в Outlook 97? Тебе повезло! Попридержи эту информацию как минимум до демо.
5. Не раскрывайте бизнес-ценность
Ты именно тот парень, который ближе всего к бизнес процессам, и понимаешь, какую цель клиента решает данная фича. Ты красавчик! Храни эту информацию, как зеницу ока. Ведь если разработчики проникнутся пониманием целей и ценностей продукта, они смогут сами генерировать классные идеи, творчески решать задачи, предлагать улучшения существующего функционала и попадать в ожидание пользователя. Оно тебе надо?
6. Не думайте о том, как оценить результат внедрения
Ты придумал сложный функционал, который затрагивает ядро платформы? Ты прочел, что зеленая кнопка продает лучше, чем красная? Не думай про аналитику. Все можно оценить на глаз, а цифры придуманы для манипуляций.
7. Не описывайте примеры использования
Несколько условий исключают друг друга, и должны быть обработаны особым образом. Это просто клад! А клад должен быть спрятан.
8. Не давайте доступы и документацию к сторонним API
У тебя продукт, который использует сторонние API, требующие данные учетной записи, доступы к точке доступа предоставляются по IP, для разработки нужна специфическая документация? Это чистое везение. Держи все явки и пароли при себе. Пусть команда сама расчищает свой тернистый путь.
9. Не фиксируйте устные договоренности в Jira
Вы устно обсудили с PM или QA ряд неучтенных требований. Часть функционала решили сделать позже, часть по-другому. Мозг человека способен хранить до 10 ТБ информации. Зачем тратить серверное пространство Jira хостинга и фиксировать договоренности в комментариях? Оставь так. Дальше ты забудешь все, о чем вы говорили, или часть разговора. На демо у тебя будет волшебный козырь: мы говорили, что это должно работать по-другому. И крыть козырь будет нечем.
10. Обновляйте требования в комментариях, а не в description
Тебе не удалось провернуть пункт номер 9. И зануда PM или QA таки добились от тебя ответа в комментариях, которые прямо противоречат требованиям задачи. Комментариев накопилось несколько десятков. Имеем в требованиях А, в начале комментариев Б, а в итоге С. Отлично! Не вздумай актуализировать требования. Оставь так.
(c) Kostiantyn Perevoznyk, Project Manager в Ciklum