×Закрыть

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

Ниже описаны 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 таки добились от тебя ответа в комментариях, которые прямо противоречат требованиям задачи. Комментариев накопилось несколько десятков. Имеем в требованиях А, в начале комментариев Б, а в итоге С. Отлично! Не вздумай актуализировать требования. Оставь так.

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


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

👍НравитсяПонравилось0
В избранноеВ избранном1
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: SoundCloud | Google Podcast | YouTube

39 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Был заказчик, который задачу не описывал, а когда я говорил, что буду разбираться в том, что нужно сделать сам при помощи исследования — он сказал, что не заплатит за это время. В конце концов была получена настолько труднопонимаемая задача, что без рисерча не обошлось, за 3.5 часа, которые я проработал он мне платить отказался и на этом типуля попал на исполнителя (ну и на бабки и время, конечно же).

Якось я спитав замовника чому він не хоче витрати годину часу й не пояснить що конкретно він хоче побачити в результаті.
— Моя година коштує дорожче, ніж 10 годин програміста, — відповів він.

потому он потеряет в итоге и деньги, и время.
UPD и так и не получит желаемое

Ну дурак тот замовник.

А да у меня был директор конторы, что зарабатывал за час $35К баксов, но он всё равно объяснял программистам, что точно ему нужно.

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

Если не секрет, то какие из пунктов действительно стоит делать во благо проекта, и почему?
(Не спора ради, а чтобы рассмотреть разные кейсы).

С половиной я погорячился )))

многие со мной не согласятся но вот мой список, того что бы я выкинул:

1. Не описывайте задачу
3. Не давайте дизайн
7. Не описывайте примеры использования
10. Обновляйте требования в комментариях, а не в description

единсвенное 7 можно делать для багов только.
3 — опционально, не всегда надо/ненадо

почему так — клиент, зачастую, не имеет понятия что ему надо.

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

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

другое дело когда команда на 100% вовлечена в сам продукт, это требует доверия как со стороны клиента, так и со стороны менеджера к своей команде. обычно с клиентами его получить куда проще, с ПМами — тяжелее, почему так — у меня только теории.

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

как то-так

Антон, спасибо за развернутый ответ. Я вас поддержу, и соглашусь что требовать от клиента пункты 1,3,7 и 10 это не всегда оправдано, а часто не имеет смысла. Я разделяю роли постановщика задачи и клиента. Это не всегда один и тот же персонаж.
Статья адресована именно постановщику задачи. Он может быть как на стороне клиента, так и внутри команды. Звать его могут Product owner|Product manager|Business analyst|Technical writer итд. Вот этому парню советы и адресованы.

ну, судя по всему вы мою мысль уловили.

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

Зависит от цели команды. Если цель это качественный продукт в срок, то полагаю что такой способ делу не поможет. Риск «интеграция со сторонним API» переместится на этап приемочного тестирования, но меньше не станет. Скорее вы даже потратите лишнее время на Mock-API.

Есть версия на английском?

Нет. Писал на русском изначально. Нужна?

Да, хочу своим двум коллегам отправить :-)

O) agile manifesto перевели на русский наконец-то )

Еще очень важно при соблюдении всех 10-ти заповедей не отвечать на уточняющие вопросы dev/QA. Пусть учат телепатия.js

Знакомые жалобы прогреммеров. Когда PM — просто авторитетный пацан, когда об альфа-версии никто и не слышал, когда SCRUM — это для нас слишком сложно...

Ступай Ваня, просто ступай)))

Практически все проекты, что я видел 10 из 10. Но всем срать, разработчики пофиксят.

В пункт 1 можно добавить «задачи-скриншоты».

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

Снятая на айфон. Фото повернуто на 90 градусов.

А шо бывает как-то по-другому?

бывает. когда уже проект потопят окончательно

Заказчики мешают работать?

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

Надо было сразу в стихах, для самых маленьких. По заветам великого Остера.

Маленький мальчик проект управлял
Как это делать — на ДОУ узнал
Вопорсов немало, камент на камент,
Как результат — недоволен клиент

Why not?

Маленький мальчик продукт управлял,
Тикет создал он но не описал,
Нету дизайна, что делать ХЗ,
В топку и мальчика и такое ТЗ!

Помогите, плиз, в поиске английского эквивалента для фразы «Нет ТЗ — результат ХЗ».

Не пришло на ум ничего оригинальнее чем «Poor spec — the result will be wreck». Но я тот еще лингвист.

No mockup, brings fuckup

No TS (technical specification) — get BS (bullshit)

супер, только это не Остер, а черноюморные народные стишки по типу «маленький мальчик нашел пулемет, больше в деревне никто не живет»)). У Остера длиннее строка)) Попробуйте так:
Есть надежный способ папу
Навсегда свести с ума.
Расскажите папе честно.
Что вы делали вчера.
Если он при этом сможет
Удержаться на ногах,
Объясните чем заняться
Завтра думаете вы.
И когда с безумным видом
Папа песни запоет,
Вызывайте неотложку,
Телефон ее — ноль три.

Вызывайте неотложку,
Телефон ее — ноль три.

Эти сведения устарели. Верно «Телефон ее — сто три» как для Украины, так и для России.

Подписаться на комментарии