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

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

https://oros-it.ru/blog/do-not-fix-bugs-manually?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

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

- сроки;
- ресурсы;
- потребность в остановке выпуска нового функционала;
- на какие метрики влияет рефакторинг;
- планируемые шаги.

В нашей статье "Что делать если IT команда опять хочет переписать проект? Как работать с рефакторингом" мы не только рассматриваем подробнее эти пункты, но и рассказываем на что еще важно обращать внимание обеим сторонам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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