Задачи от клиента напрямую: хаос с человеческим лицом

Недавно в комментариях прилетел такой вопрос:

Интересно узнать твоё мнение: а если постановки задач нет вообще, на проекте ~20 человек — это может работать или это заранее плохой процесс, обречённый на провал и страдания программистов? (в моём случае был как раз последний вариант.) То есть когда задачи идут напрямую от клиента к разработчикам, а менеджер на первичном этапе только определяет, что брать в работу и кому какую задачу отдать.

Тема постановки задач команде настолько важна, что мне захотелось дать на неё развёрнутый ответ.

⭐️ Отсутствие нормальной постановки задач == хаос

Может показаться, что постановка задач клиентом на разработку «сквозь» руководителя — крутая практика. Такая система выглядит гибкой и удобной. Убираются лишние прослойки коммуникации, лишние ритуалы, не так ли?

Не так. Все эти планирования, груминги, DoR/DoD были придуманы не просто так. Если вы когда-либо работали в аутсорсе или на фрилансе, то прекрасно знаете, насколько непредсказуемыми и непонятными могут быть клиенты.

Если дать клиенту ставить задачи напрямую в разработку, то это приведёт к трём проблемам: ➡️ Нет общего контекста. Каждый член команды предоставлен сам себе. ➡️ Нет приоритизации. Все задачи должны быть сделаны «вчера». ➡️ Размыта ответственность. Неправ всегда разработчик.

В итоге люди работают в условиях постоянной фрустрации: задачи делаются не в срок и не так, как хотел клиент. Это приводит к выгоранию и текучке. Или же они начинают делать работу «на минималках», лишь бы от них отстали.

Нормальный процесс работы начинается с нормальной постановки задачи. Иначе будет как у Кэрролла:

— Скажите, пожалуйста, куда мне отсюда идти? — А куда ты хочешь попасть? — ответил Кот. — Мне всё равно... — сказала Алиса. — Тогда всё равно, куда идти, — заметил Кот. — ...только бы попасть куда-нибудь, — пояснила Алиса. — Куда-нибудь ты обязательно попадёшь, — сказал Кот. — Нужно только достаточно долго идти.

⭐️ Когда это нормально?

Всегда ли окупается нормальная постановка задач? На мой взгляд — да. Даже в своих проектах я не бросаюсь в омут с головой, а уделяю время планированию, приоритизации и постановке задач. Просто потому, что мне самому потом будет проще и комфортнее работать.

Однако в некоторых условиях без бюрократии можно и обойтись. Например, если вы работаете над маленьким стартапом, и у вас всё очень быстро меняется. Или если вы делаете небольшой проект для себя. Но в таких ситуациях нужно следить, не возникают ли конфликты и разногласия из-за неверного трактования задач. Если такое происходит — пора менять процесс.

⭐️ Что делать, если у меня на проекте так?

Конечно, дико неприятно оказаться на проекте, где все задачи нужны ещё вчера или требования описаны в формате «пойди туда — не знаю куда, принеси то — не знаю что». Но никто от этого не застрахован.

В таком случае я голосую за то, чтобы постараться создать максимально комфортные условия для себя (а по возможности и для других). Если пришла задача с непонятным описанием — сделайте его понятным. Если задача вообще не поставлена и не формализована — формализуйте её самостоятельно. И так далее.

Можно бесконечно возмущаться: «Это не моя работа и не моя обязанность!» — и вы будете правы. Но я предлагаю посмотреть на это с другой стороны: вы делаете свою работу комфортнее. Да, возможно, это должен был сделать кто-то другой. Но он не сделал. Поэтому берём свою жизнь в свои руки и идём заботиться о себе.

// Ставь 💛**, если иногда чувствуешь себя как Алиса в стране чудес