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

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

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

Методология Agile сейчас обширно применяется во многих ИТ-компаниях. От нее ждут решения многочисленных проблем и улучшения процесса поставки продукта. Однако, в каких случаях Agile может не сработать? Разберем в нашей статье "Проблемы с Agile или когда нужен здравый смысл".

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

https://oros-it.ru/blog/common-issues-with-agile?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Часто в компаниях нет однозначного понимаю в разнице между позициями PO и PM. Обязанности этих ролей могут перекликаться, понимание зоны ответственности путаться. Иногда могут даже отказываться от позиции PM как таковой. В нашей статья "Разница между PO и PM" мы разбираем подробный список различий между этими позициями и обсуждаем почему так важно, чтобы в команде присутствовал и PO и PM.

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

https://oros-it.ru/blog/the-difference-between-PO-and-PM?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Методология Agile продолжает очень активно внедряется в огромном количестве компаний. При это не в каждой команде эта методология начинает сразу же работать без проблем и процесс Agile-трансформации может быть достаточно сложным и трудоемким. Так на сколько же оправданно для бизнеса тратить время всей своей команды и деньги на тренинги, чтобы перейти на новые процессы? Что дает Agile для бизнеса?

В нашей статье "Топ 5 причин, которые делают Agile-трансформацию выгодной для бизнеса" мы выделили пять, по нашему мнению, самых важных показателей, в которых Agile действительно помогает сделать большой шаг вперед для компании:

- Time to market
- Окупаемость инвестиций
- Разработка правильного продукта
- Удовлетворенность клиента
- Предсказуемость

Читайте статью полностью, чтобы узнать как Agile влияет на эти пять важных для бизнеса показателей.

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

https://oros-it.ru/blog/five-reason-why-agile-transformation-is-good?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

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

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

https://oros-it.ru/blog/five-steps-for-effective-stendup?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://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