Чеклист постановки задачи в разработку ============ Это чек-лист, которому должны соответствовать задачи от продактов и проджектов в разработку. Следуя ему, мы будем вместе тратить меньше сил на вопросы и уточнения, сможем лучше и быстрее делать задачи.  Если ты продакт — прочитай и используй. Если ты разработчик — внимательно изучи и показывай продакту, когда видишь несоответствующую чек-листу задачу. Дополнительно можно прочитать статью о <a href="https://habr.com/ru/post/302382/" class="external-link">Кнопочном мышлении</a>, о том как правильно взаимодействовать разработке с бизнесом. :white_check_mark: Описана решаемая бизнес-проблема --- Если в постановке задачи есть продуктовое решение, оно должно быть детализировано до решаемой бизнес-проблемы. Критерий хорошей постановки задачи — возможность предложить несколько альтернативных решений. **Хорошо:** Мы хотим оплачивать время операторов, когда они делают активные действия в системе и предлагаем ввести статус "В работе". Мы считаем введение такого статуса повысит производительность операторов на 10%. *Почему хорошо: есть детальное описание проблемы и возможность предложить альтернативное решение. Например, не делать статусы и обойтись существующей информацией.* **Плохо:** Нам нужен статус "В работе", чтобы контролировать время оператора. *Почему плохо: мало информации для принятия альтернативного решения.* :white_check_mark: Есть информация о минимальном результате с точки зрения бизнеса --- Поможет разработке декомпозировать задачу и как можно быстрее выкатить первую часть в прод. :white_check_mark: Вы задали себе вопросы "а почему?", посмотрев на описание задачи --- Например, вы предлагаете "добавить в виджет возможность принимать платежи по картам в USD через ECP". Какие вопросы возникнут у разработчика? Напишите их сразу вместе с ответами! Хорошие вопросы: - Зачем USD? - Почему в виджет? - Почему именно через ECP? :white_check_mark: В задаче есть данные, сколько задача принесёт денег, и как это было посчитано *(желательно)* --- Если задача — эксперимент, и у нас нет такой информации, то это должно быть отражено в задаче. :white_check_mark: В задаче нет технических деталей от продакта, ***нет простых и дешевых решений***, особенно (!) в межкомандных задачах --- Многие из продактов способны принимать технические решения. Это здорово, но, вероятно вы не знаете всех деталей технической реализации. Вы всегда сможете узнать, как и что в итоге реализовано, что-то посоветовать, но задачи с техническими решениями и техническими деталями от продактов вредят! **Ещё материалы, идеи и секреты разработки Skyeng в telegram-канале**: <a href="https://tlg.name/teamleadleonid">@teamleadleonid</a>