Посмотри управление требованиями, ПО важно обладать этим навыком

How to manage requirements загугли, на английском информации больше, вопрос не правильно поставленной задачи чаще всего кроется в требованиях и приоритезации,

Чувак совета просит, а не нравоучения бро

Спасибо, сейчас погуглю

У нас много продуктов, в том, где я работаю с начала из 30 разработчиков ушёл один из-за трансформации, и команда отметила этот уход как один из лучших результатов трансформации ever. Также один раз человек не прошёл испытательный срок по мнению команды. В соседних продуктах примерно такая же ситуация.

Самое простое, что ты можешь сделать - это описывать задачи как: 1. Что надо сделать, 2. Для кого надо сделать. 3. Почему это надо сделать (опиши мотивацию заказчика к этой задаче). 4. Как ты поймешь, что задача сделана правильно (сценарий того, как ты ее проверять будешь). Что важно не писать - Как сделать задачу - с этим команда разберется сама. думаю для первого шага будет норм. Можно в JIRA прямо как шаблончик это использовать

>задачь
>новичек

Это наверное прозвучит не очень, я дико извиняюсь, но пока кто-то пишет вот примерно на таком уровне грамотности, о каком управлении требованиями может идти речь? Команда же просто будет отфутболивать неграмотного ПО, потому что тут под сомнение может попасть вообще умение человека выражать свои мысли, а уж выполнять задачи от такого продакта...Так и будут отправлять читать мануалы, пока не выдавят.

Супер, спасибо

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

Точка в конце - где?

кхм. а зачем вокруг да около бродить? сомнения - благо.

Меня не перестаёт удивлять уровень профессионализма и подача обратной связи. Я уж не говорю про уважение...

Конечно. Поэтому мы сразу ушли в ЛС все контекст обсуждать

скиньте сюда результаты, интересно

Алёна, добрый день! Ни всегда это связанные напрямую вещи. Знаю лично пару примеров отличных PO, у которых есть проблемы с опечаткой, но при этом они не вызывают ни капли недоверия со стороны своей команды и руководства. Просто мысли генерируют быстрее, чем печатают)))

Спасибо, а что-нибудь а-ля KSD (проходил, как и psm), KSI, KMM по канбану, SPC, PO/PM по SAFe у кого-то дистанционно был опыт? Может что-то еще подобное, но не теряющее смысл при удаленке?

Привет! Мы используем формат User Story на этапе описания (Что и зачем я хочу как пользователь?). А потом к ней же всей командой  формируем Приемочные критерии (Как я пойму, что проблема решена?). Очень грубо.

грамотность никак не коррелирует с годностью в PO. даже формальные знания не так важны, как понимание процесса, fast learning, признание ошибок и готовность к изменениям

Мы созвонились. Разговор был про необходимость PBR , User Story и критерии ее приемки.

@gospodchikovs + @pimenaus выше все четко написали