Сегодня поговорим о том, как владельцу продукта (ПО) наладить контакт со своей командой разработки. Поговорим про то, как стоит действовать и чего стоит избегать, чтобы получить доверие команды. Делитесь со своими ПО, чтобы проверить, знают ли они эти правила?

#agile_который_работает
#владельцу_продукта
#настройка_процессов

https://oros-it.ru/blog/how-can-po-deal-with-it-team?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Однажды владелец продукта Вася сказал, чтобы тимлид Коля перестал добавлять свои технические задачи в спринт без его ведома. А потом они долго спорили на глазах у всей команды. Знакомая ситуация? В нашем новом подкасте мы говорим о том, как нужно правильно выстраивать общение между тимлидом и ПО, чтобы не попадать в похожие ситуации.

#владельцу_продукта

https://youtu.be/8f8vMChEdT8

Практически каждый человек, работающий в ИТ, сталкивался с ситуацией проваленных сроков. И чаще всего вина ложится на разработчика, который не успел доделать функционал и выкатить задачу вовремя. На самом же деле все намного сложнее. Задача проходит много этапов, в которые входит проработка и описание ПО, отрисовка дизайна, разработка, согласование с отделом безопасности, тестирование, принятие задачи заказчиком и так далее, в зависимости от вашего процесса. Если происходит задержка на одном из этих этапов, то сроки всегда съезжают. И это никогда не задача разработчика компенсировать задержку в согласовании дизайна с ПО или подвисшем на безопаснике апруве. Если вы хотите, чтобы в вашей команде всегда было понятно, в какой момент задача подвисла и сроки начали страдать, одним из выходов является ведение статусов и ответственных в трекере задач. Ушла задача на проверку бизнесом? Переводим задачу на ответственного или заводим отдельную блокирующую задачу. В итоге, когда возникнет вопрос “кто виноват, что сроки провалены?” вы всегда сможете четко определить это по трекеру. Таким образом вы не просто найдете виноватого, а увидите, где именно в процессе у вас есть проблемы и сможете над ними работать. Один виноватый есть не всегда, иногда это просто неэффективно построенный процесс. Подробнее читайте в статье нашего блога.

#настройка_процессов #владельцу_продукта

https://oros-it.ru/blog/who-is-responsible-for-release?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Почему важно правильно описывать задачи на разработку?

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

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

#agile_который_работает #владельцу_продукта

https://oros-it.ru/blog/how-create-tickets-for-development?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Действенный способ измерения эффективности на удаленной работе
Многие при переходе на удаленную работу столкнулись с проблемой измерения эффективности команды. Хотите узнать способ, который реально работает? Мы все разобрали в своей статье. Спойлер: измерение времени не поможет 😕

#тимлиду #владельцу_продукта

https://oros-it.ru/blog/efficiency-metrics?utm_source=tg&utm_medium=article&utm_campaign=time

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

#владельцу_продукта

https://oros-it.ru/blog/how-to-use-metriks-for-it-team-work?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Навигация по каналу

У нас набралось уже довольно много материалов. Чтобы вы не терялись мы сделали удобную навигацию по тегам. Она будет всегда в закрепленных сообщениях и мы будем ее дополнять по мере появления новых рубрик.

#разборкейса - разборы кейсов, вы можете прислать свой кейс на почту info@itleadassist.io

#чеклист - бесплатные чеклисты

#agile_который_работает - материалы по Agile в том виде, который реально работает

#настройка_процессов - материалы по процесса в команде

#построение_команды - все о построении команды, от структуры до обязанностей каждой должности

#владельцу_продукта - все что будет полезно для представителей бизнеса

#тимлиду - все что будет полезно тимлиду и любому руководителю

#советы - рубрика советов и статьи с советами

#ответы_на_вопросы - ответы на ваши вопросы

Проект летит ко всем чертям, а бизнес не понимает почему вы хотите все переписать? Хотите узнать, как спасти проект? Есть решение! Но придется немного подготовится. Обо всем по порядку, но начните с метрик.

#тимлиду #владельцу_продукта

https://oros-it.ru/blog/refactoring-for-it-and-business?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Мой прошлый тимлид любил говорить: "давайте вы самоорганизуетесь". Волшебная фраза, по которой весь отдел сразу начинал эффективно работать. Если все таки у вас в команде такое волшебство не случилось, то у нас есть самая подробная инструкция как заставить самоорганизацию работать. В ней подробно описаны шаги для бизнеса, но технологию работы нужно знать каждому участнику команды. Это перевернет ваше понимание о правильной работе отдела. Ну а для вашего ПО это просто мастхев, без которого невозможно работать.

Спорим, что, прочитав эту статью, вы точно захотите так работать, немедленно отправите ее своему ПО и начнете делать все самостоятельно? 😉

#владельцу_продукта

https://oros-it.ru/blog/self-organized-teams-with-help-of-PO?utm_source=tg&utm_medium=article&utm_campaign=tg_post