Участники:
Асхат Уразбаев, Денис Миллер, Никита Филиппов

Темы
* Мысли о предыдущем подкасте. Waterfall как Agile с 1 Итерацией
* С чего начинается проект-
* Общее видение проекта. Продукт вижн.
* Роль Product Owner.
* Анонс следующего подкаста

Участники:
Алексей Кривицкий, Асхат Уразбаев, Денис Миллер, Кирилл Медведев

Темы
* Scrum-команда
* Понятие ролей, соотношение с должностями
* Кроссфункциональность и узкая специализация
* Синергия команды: 1 + 1 = 11
* Тестировщик и разработчик в Team
* Менеджер проекта
* Product Owner
* Мотивация, индивидуальные поощрения
* Scrum Master – вымирающий динозавр

Алексей Кривицкий — лидер украинского Agile сообщества, тренер Scrum.

Блог Подкаста (rss for itunes)

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера


Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Продакт оунер. Владелец продукта. Продуктолог. PO.



Должность, которую часто считают синонимом «Менеджера проекта», благо ряд задач и обязанностей довольно схожи.

О том, кто такой продакт в понимании Альфа-Банка, что это за человек, что он умеет делать и как относится к своей команде, нам рассказал VDavydov Владимир Давыдов, руководитель по развитию цифровых каналов и продуктов Блока “Массовый бизнес”

DevOps обычно рассматривается в двух ипостасях:

1. Инструментарий — техника, tooling, технические процессы, CI/CD и прочие штуки — авто-всё, всё как код и т.д.
2. Культура — это как отдельным разработчикам прийти всем вместе к «мир, дружба, жвачка».

На стыке этого у людей происходит некоторый слом, и они не понимают – ОК, есть DevOps, есть автоматизация, у нас всё это есть. Но, ребята, у нас команда из 10 человек — мы не можем, например, пилить процессинг на банк, или сервис для нашего биллинг-оператора, или что-то еще такое. 10 человек — та самая Scrum-команда, которой предлагается всё это сделать, — не могут этого технически.

У таких команд, помимо «мы так не умеем, потому что так раньше не делали», есть и другие вызовы. Михаил Бижан рассказал на конференции DevOps Conf 2019 о тех, с которыми встретилась его команда в Райффайзенбанке, и как они это решали. Михаил отвечает за автоматизацию в банке, вместе с командой внедряя инженерные практики и поддерживая инструменты автоматизации.

Раньше Михаил уже внедрял культуру DevOps в Сбербанке. Но до этого, работая на стороне интегратора (в основном на «госов») наловил кучу анти-паттернов. Потому что чем характерны госзаказчики? Годовалыми проектами, невообразимыми бюджетами и полным отсутствием намека на Agile и DevOps. Там все строго. Сначала ты пишешь ТЗ, чтобы стопка бумаги была метр от пола. Если меньше, это не ТЗ (и даже не проект) — это несерьёзно. Потом ты разрабатываешь, а если что-то не получается — виноват ты и денег не получаешь (хотя госзаказчик, скорее всего, все равно счастлив, потому что бюджет освоен и что-то формальное достигнуто).

Так что у Михаила большой опыт в том, как делать не надо. А как делать можно — понимает из чтения книг и общения с сообществом и коллегами. Как системный аналитик, Михаил не старается решить всё методами разработки, а анализирует проблему, чтобы понять её root cause и сделать так, чтобы она больше никогда не повторялась. На этом сочетании и построен доклад.

Надежда Мецкер, Senior QA, DataArt

Я расскажу, как повысить эффективность команды в сложном проекте за счет гибкого подхода к разработке, с которым наша команда благополучно живет уже третий год. Собственно, реальный проект из области здравоохранения и будет служить мне примером. Я думаю, о теории Scrum и Agile рассуждать относительно легко, какие-то из использованных нами решений даже могут показаться очевидными. Но я уверена, что личный опыт и опробованные в ответственном проекте методы могут пригодиться многим.

Первое, о чем я расскажу, это Feature Demo — процесс, в ходе которого мы демонстрируем новый функционал приложения внутри своей же команды. Мы рассматриваем, как именно он был сделан, что получилось особенно удачно, а где можно было сделать лучше. Уже после общего рассмотрения и окончательного одобрения функционал может уходить в продакшн.

И снова здравствуйте!

Мы продолжаем расширение тем, которые преподаются у нас. Вот теперь разработали и вывели курс «Product Owner». Автор курса Екатерина Марчук предлагает вам ознакомится со своей авторской статьёй и приглашает на открытый урок.

Как нам интерпретировать фидбек?

О customer development или развитии пользователей в последнее время говорят все кому не лень. И каждый, кто знаком с понятием, осознает, насколько это важно, а если говорить прямо — жизненно необходимо для успешного запуска продукта.

Customer develoment помогает понять ценность продукта, выявить скрытые мотивы потребителей, их реальные проблемы и потребности. И самое главное, custdev позволяет нам проверять гипотезы. Без проверки гипотез сложно вести проект в правильном направлении, потому что, как показывает практика, голые цифры, увы, не репрезентативны.

Но, как водится, на чисто теоретическом понимании всё и заканчивается. У нас же ни на что не хватает времени, в том числе — и на такие важные задачи.

Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.

Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:

• До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
• Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
• После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
• Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».

Все как в жизни.

Предыстория

В классических методологиях роли владельца продукта не было. Впервые роль владельца продукта появилась в Scrum фреймворке. До этого ближайшей по смыслу ролью была роль менеджера проекта в методологии PMI PMBoK. Роль менеджера проекта содержала в себе ряд противоречий и конфликтов интересов:

1. Менеджер проекта отвечал и за команду, и за отношения с заказчиком. К сожалению, интересы заказчика противоречат интересам команды.
2. Менеджер проекта отвечал только за стадию создания продукта. Менеджеру проекта все равно что будет потом, главное закончить в срок проект с нужными свойствами, качеством и уложиться в бюджет.
3. Менеджер проекта не обязан знать как продавать и продвигать продукт. Отсюда — столько провалившихся на рынке, но формально успешных (выполненных в срок и уложившихся бюджет) проектов.

Решая эти проблему, создатели Scrum:

1. Разделили роль менеджера проекта на две: Scrum мастер, которые заботится о команде, этакая строгая, но любящая нянька, и владелец продукта.
2. Сделали так, что ответственность владельца продукта не заканчивается на завершении разработки, а продолжается в период коммерческой эксплуатации.
3. Решили, что в компетенции владельца продукта входят: маркетинг, продажи, знания бизнеса и предметной области.

Проходя собеседование на позицию Product Owner я понял, что у меня серьезный пробел по бизнес метрикам в Agile проекте, т.к. работаю в госструктуре. В русском сегменте информация достаточно скудная. В английском сегменте очень понравилась статья Ashwinee Kalkura. Поэтому решил сделать немного вольный перевод. Оригинал статьи здесь.

Что значат метрики для Agile команд?

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

Организации склонны копировать «то, что сработало для других», даже не заботясь об ограничениях и условиях, в которых конкретная метрика работала на «других».

Тогда, что измерять? На мой взгляд, организации, которые поняли, что и сколько измерять в продукте, выжили и процветают до сих пор. Они в конечном итоге стали Agile-организациями. Когда у них несколько продуктов, у них разные подходы для каждого из них. Некоторым продуктам потребуется много статистики и данных, в то время как некоторым понадобиться лишь пара метрик!

И как тогда понять, что именно нужно измерить? Для меня ближайший путеводитель — это 7-й принцип в Agile Manifesto — «работающее программное обеспечение — лучший измеритель прогресса». Если Вы можете определить, что является для Вас рабочим программным обеспечением, становится легче измерить прогресс.

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

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

Эффективность и прозрачность это никогда не одно и то же. Можно прозрачно делать неэффективные вещи, а эффективно делать вещи непрозрачные.

Построение структуры работы это сложный, индивидуальный процесс, с налётом дерзости. Потому что нужна не только смелость и рефлексия («мы работаем неэффективно, почему?»), но и умение делать изящные нагромождения.

В статье будет приведено несколько терминов, а также примеры индустрий, где неграмотный менеджмент может привести к катастрофе.

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

Приглашаем на Рождественский Scrum Meetup, который состоится 20 декабря на площадке Райффайзенбанка в Нагатино.

Ежемесячный дайджест новостей российского продуктового сообщества.

В этом выпуске отчеты про жизнь продуктологов и маркетологов за рубежом The State of Product Leadership 2019 и The 2019 State of Marketing. Множество материалов по Growth Teams. Старт набора в весеннюю программу стартапов от Russol и в бесплатную школу product owner-ов от Додо Пицца.

Все материалы Product Mindset, отчет PM Trands & Benchmarks, квартальный отчет по мобильному рынку, конкурс стартапов от Visa на 11 млн рублей.

Young product managers aim to rapidly learn the fundamentals of their role and master the craft. However, there are no magic power, specific book or a class that can give you 100% of professional mastery.

You want it all, you want it now. But it will surely take some time to make you a product management guru. This post contains a set of relevant resources about product management for those who prefer to read, listen and watch.

The Agile methodology consists of various mandatory concepts and artifacts. A product backlog is one of them. This is actually a set of requirements received from the business and formulated in the form of development tasks.

Backlog grooming is not a magic wand; it's a comprehensive activity aimed to ensure that all the tasks are always in clear order. How can the grooming process be improved? And what are the special things about it?

Управление продуктом — состоявшаяся дисциплина. На продакт-менеджеров большой спрос, а практических знаний хватает не у всех, поэтому 9 декабря мы проведем профессиональную продуктовую конференцию Product Fest. К её организации и программе мы применяем правило: «Сделать такую конференцию, на которую сами хотели бы сходить».



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

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Что делать, если вы не знаете, что такое Скрам?

В первую очередь стоит хотя бы прочесть Руководство по Скраму (PDF) и начать ему следовать. Если вы не следуете этому руководству, значит вы делаете что угодно, только не Скрам. По сути Владелец продукта занимается максимизацией ценности продукта для конечного пользователя. Он может делегировать свои обязанности кому-то из команды, но отвечать за результат должен только он один. Также он должен быть единственным источником знаний о продукте для команды. Если у разработчика есть вопрос, он идет только к Владельцу продукта. Тот выясняет все детали, разруливает зависимости (если они есть) и согласует дальнейшие дествия с разработчиком.