21 жовтня – JS Conference 2017 у Києві. Як уникнути критичних помилок при створенні нового проекту?
×Закрыть

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

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

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


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

LinkedIn

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

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

Якось я спитав замовника чому він не хоче витрати годину часу й не пояснить що конкретно він хоче побачити в результаті.
— Моя година коштує дорожче, ніж 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 можно добавить «задачи-скриншоты».

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

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

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

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

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

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

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

Why not?

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

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

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

No mockup, brings fuckup

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

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

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

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

Жду очередного шедевра от Natalia Riabokon

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