User Story Mapping или КАРТЫ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ - это способ визуального планирования и приоритизации задач. Способ хорош тем, что заставляет нас думать о своих software решениях с позиции ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ(User Story).
Прежде чем мы перейдём к знакомству с методом, важно разобраться с тем, а что такое вообще ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ.
Поделюсь личным опытом работы в ИТ-компании, использующей проектное управление. Постараюсь выделить важные вещи в эффективной работе, которые, на первый взгляд,как будто не видны и с которыми пришлось столкнуться. Углубляться в project managment не имею цели. Для этого существуют стандарты PMI The Standard for Portfolio Management, ГОСТ Р 54870-2011 «Требования к управлению портфелем проектов». Хотелось бы отметить, что работаю в госсекторе, но возможно опыт будет полезен всем.
Немного о себе. Петряшова Оксана Николаевна - 5 лет руководитель отдела развития, с большим багажом опыта. Всё нижесказанное является личным опытом и субъективным мнением.
Хочется начать с тезиса: все методологии хороши, главное – правильно их применять. Однако несмотря на все усилия, я все еще встречаю скепсис у технических специалистов и иногда бизнеса, что Agile методологии не применимы к большим и сложным проектам. Фразы из серии «давайте сначала все продумаем», «у вас не будет второго шанса произвести первое впечатление», «мы не принесем ценности пока не сделаем все фичи», «UI/UX должен быть самый лучший на старте» все еще звучат, и данная статья в легкой форме покажет, что они не всегда актуальны 😊
Меня зовут Сергей Солдатов, я занимаюсь развитием продуктов в ЕДИНОМ ЦУПИС, поэтому статья будет построена в плоскости управления продуктом, но, надеюсь, будет интересна и техническим специалистам, командным лидам, проектным менеджерам и возможно тем, кто планирует строительство дома 😊
Еще один важный момент: моя дорожная карта не подразумевает привязки ко времени, так как в моем рассказе важнее ключевые этапы развития продукта (дом), определение MVP и масштабирование, а дедлайны оставим к темам KPI и построения временных планов.
В предыдущей статье, где я затронул тему отмены задач, возникли оживленные дискуссии. Некоторые утверждали, что достаточно найти тим лида с "стальными яйцами", и проблемы с непонятными задачами исчезнут. Но действительно ли это так просто? И правда ли, что решение этих проблем не входит в нашу компетенцию? Как руководитель разработки, я часто вижу, как команды берут на себя задачи, которые кажутся им неправильными, тратят часы на их разъяснение и еще больше времени на доработку перед сдачей.
Может показаться, что работа по формулировке задач лежит за пределами нашей ответственности, но если мы продолжим брать непонятные задачи, для продуктовых менеджеров это будет сигналом, что все идет хорошо. Но мы знаем, что это не так. Не стоит ждать, что ситуация изменится сама по себе или кто-то внезапно решит все проблемы за нас. Пора задуматься о том, как мы можем влиять на этот процесс и сделать нашу работу более эффективной. Ведь в любом случае время на эти задачи уходит, так давайте по крайней мере потратим его с пользой.
Я ожидаю, что некоторые из вас скажут: "Всё это очевидно, просто возьми и сделай". Но давайте не будем забывать, что целые книги написаны о том, как правильно описывать требования и структурировать работу, существуют стандарты, но проблема всё ещё актуальна. Понимание того, что перед нами не простая задача, приходит с опытом в разработке, и именно поэтому я отношу её к категории средней сложности. Я старался изложить её как можно проще, но уверен, что ваши конструктивные комментарии помогут сделать изложение идеальным. Спасибо вам заранее за это.
Когда продукт входит в фазу эксплуатации, продакт-менеджер занимается его поддержкой и развитием. Для этого есть много каналов пополнения бэклога идеями: анализ запросов в поддержку, интервью с пользователями, анализ данных продуктовой аналитики, анализ конкурентов и пр. Но есть еще один, который недооценен – это сотрудники всей компании.
Меня зовут Артём Трубин, я директор продуктового портфеля в облачном провайдере ActiveCloud. Расскажу, как мы наладили пополнение продуктового бэклога идеями от коллег из разных департаментов компании, дали им почувствовать свою важность и сэкономили силы продакт-менеджеров с помощью Kaiten.
Многие основатели и ТОП-менеджеры компаний, а также те, кто отвечают за рост продуктов в компаниях, рано или поздно задумываются о том, как вырастить бизнес, увеличить продажи, получить больше лояльных пользователей, обогнать конкурентов, как сделать бизнес и продукты внутри такими чтобы их больше покупали?
- И всегда встают резонные вопросы:
- Как делать больше за меньшее количество ресурсов?
- Как успевать и обгонять конкурентов?
- Как достигать тех целей которые ставим?
- Как кратно масштабировать бизнес и продукты?
Как правило в компаниях запускается множество проектов, которые направлены на рост бизнеса, однако более 75% не приносят тех эффектов, которые мы от них ожидали. Более того, сроки и бюджеты проектов могут растягиваться в разы. И это происходит повсеместно, и в среднем и в крупном бизнесе.
Технический долг – это термин, который вызывает тревогу в рядах IT-специалистов по всему миру. Он способен уничтожить любой успешный проект. В мире, где время – это деньги, а сроки разработки постоянно сокращаются, очень высок соблазн пойти на компромисс с качеством в погоне за поощрением руководства за скорость релизов. Но какова реальная цена этих компромиссов? Как бороться с этим невидимым врагом, который медленно но верно, подрывает все усилия по достижению прогресса?
Конфликтология – это дисциплина, изучающая конфликты, их структуру, динамику, методы разрешения и предотвращения. В IT-сфере, как и в любой другой области, где работает множество людей с разными интересами и точками зрения, конфликты неизбежны.
На моем текущем месте работы руководство очень трепетно относится к внесению трудозатрат. Необходимость ведения трудозатрат при продуктовой разработке - вопрос дискуссионный, но кто бы что не говорил, статистические данные могут быть полезны при планировании.
Как правило, если мыслить категориями гибких методологий задачи имеют иерархическую структуру, самые крупные - эпики, своеобразные вехи продукта, которые задают направление развития. Далее идут истории / фичи - законченные фрагменты функционала представляющие ценность. Внизу иерархии располагаются уже задачи предназначенные для конкретных исполнителей (аналитиков, дизайнеров, разработчиков). С моей точки зрения наибольшую ценность представляют исторические данные от том, на сколько точно команда попадает в оценку той или иной фичи. Однако точно оценить фичу целиком очень сложно, поэтому мы оцениваем только задачи нижнего уровня.
Большинство современных систем ведения задач позволяют не только фиксировать оценки и трудозатраты по конкретным задачам, но и агрегировать оценки подзадач в задачах верхнего уровня.
И вот в какой-то момент мы обратили внимание, что несмотря на то, что мы вроде бы достаточно точно оцениваем задачи нижнего уровня агрегированные трудозатраты по фиче все равно сильно уезжают за первоначальную оценку. Причина оказалась в том, некоторые участники команды вносили трудозатраты не в задачи нижнего уровня, а непосредственно в эпики и истории, размывая тем самым показатели.
Для ведения задач в компании используется продукт JetBrains YouTrack, поэтому для решения проблемы трудозатрат списываемых в верхнеуровневые задачи было решено воспользоваться механизмом пользовательских рабочих процессов (в YouTrack можно писать свои собственные рабочие процессы на JavaScript).
Я размышлял о недавнем разговоре с руководителем одной из моих команд о важности поддерживать наши бэклоги в чистоте. Мы обсудили как поступать с задачами, которые постоянно откладываются.
Я записал свои мысли и делюсь ими с вами. Это довольно распространенная проблема. Задачи висят без движения, их всё время откладывают. В статье поговорим о последствиях такого беспорядка, и как правильно с этим справляться.
Я изложу мой подход поддержания гигиены бэклога. Поверьте мне, ваша команда будет вам за это благодарна.
Изначально публикация должна была называться "Гре****е управление временем", что должно символизировать боль и проблемы связанные с этой активностью. Неумение решать тучу задач это очень неприятный ком в горле, мешающий находится на волне развития. Собрал методики, статьи и материалы, которые помогают мне в моем маленьком старте исследования.
В мире жесткой конкуренции и борьбы за опыт клиентов, многие компании сталкиваются с тем, что их операционная модель и процессы не успевают за скоростью изменений.
Поэтому многие компании стали рассматривать трансформацию своей модели управления на Agile, создавая автономные и универсальные команды сфокусированные вокруг продуктов, которые могут смотреть на метрики продукта, работать короткими итерациями и проводить много экспериментов с целью быстро улучшать ценность продукта и увеличить скорость обратной связи с рынка.
Однако вокруг массового перехода компаний на Agile сложилось поверхностное понимание и неправильная интерпретация Agile подходов и философии.
Более того, у многих компаний Agile превратился в карго-культ, который не просто не приносит ценности, а мешает.
В данной статье мы рассмотрим то, какой фундамент должен закладываться в компании, чтобы ей извлечь реальную выгоду от Agile.
В моей жизни произошло несколько событий, которые смотивировали меня создать самоорганизованную команду, которая могла бы самостоятельно следовать Скраму, соблюдать все события, эффективно работать и выполнять все задачи инкремента, не привлекая Product Owner для решения текущих проблем. Вот в таком случае мы можем говорить о Скрам-мастере как о сервисе. То есть Скрам-мастер как сервис — это когда ты приходишь в команду по какому-то запросу, помогаешь и уходишь. А команда остается одна, совсем одна, и ей должно быть абсолютно нормально. Всё так работает в идеальном мире, по крайней мере, должно так работать.
Привет, меня зовут Анастасия, я руководитель проектов в команде разработки Ареал.
Моя ежедневная среда для управления проектами — задачник, оперативник, баг-репорт, gitlab с описаниями задач программистов, kaiten с описанием задач дизайнеров и проектировщиков. Мои коллеги сталкиваются с таким же “зоопарком” площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — gitlab. Большинство команды знакомо с gitlab — программисты работают с кодом, проджекты ставят задачи.
Когда коллега уходит в отпуск или увольняется — работа часто буксует или останавливается даже в большой команде. Происходит это, так как внезапно выясняется, что ушедший был «узким местом» или «критичным звеном».
Мне удалось снизить влияние этих «узких мест» и «критичных звеньев» за счёт налаживания горизонтальных связей, построения ролевой модели большой команды и ещё нескольких приёмов.
Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.
Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.
Сейчас расскажу, как мне удалось этого добиться.
Привет, Хабр! Хочу рассказать вам сегодня об одном инструменте. Он помог мне когда-то понять как устроены сложные организационные системы, как с ними работать, и самое главное, как их менять. Можно сказать, этот инструмент - линза, через призму которой мы можем по-другому посмотреть на окружающий нас мир.
Инструмент называется Айсберг системного мышления, и сегодня поговорим о нем.
Scrum, Kanban и другие «эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При этом легко сломать то, что работает, ничего не исправить и испортить жизнь всем участникам проекта.
Рассмотрим острые методологические проблемы, на которые почему-то редко обращают внимание. Порассуждаем, как не споткнуться о такие камни преткновения или хотя бы удержать равновесие после этого.
Спойлер: многие затронутые вопросы спорные, и готовых решений у нас нет (как, наверное, у большинства PM). Так что заранее приглашаем всех желающих к диалогу и обмену опытом в комментариях.
Привет!
Меня зовут Михаил, и больше 7 лет я занимаюсь улучшением рабочих процессов для малых и средних IT-команд. И конечно, для того чтобы понять что происходит в этих самых командах и процессах нужны правильно подобранные метрики, а еще лучше единая приборная панель, взглянув на которую и члены команд, и менеджмент могут сразу понять ситуацию, могут сразу найти зарождающиеся проблемы.
Про метрики отвечающие за скорость и качество доставки ценности всем давно уже всё известно, и как правило все стараются их отслеживать. Но сегодня я хотел бы сфокусировать внимание на метриках благополучия команд (Well-Being metrics).
Меня зовут Курдюмов Дмитрий, я сертифицированный Agile коуч и Лидер по трансформации бизнеса, последние 7 лет помогаю компаниям трансформировать их процессы и структуру для достижения большей адаптивности и скорости. В этой статье хочу поделиться тем, как Agile поменял принципы регулярного менеджмента в компаниях.
Всем привет! На связи Сергей Гончарук, менеджер проектов компании «Флант». 30 ноября и 1 декабря 2023 года прошла конференция TeamLead++ Conf 2023. Ниже — текстовый вариант моего доклада с конференции про опыт «Фланта» в построении процессов управления задачами для Dev-части нашей DevOps-работы.
В докладе я рассказал, как можно применить ценностную модель, чтобы построить идеальный фреймворк для команды, и как приносить изменения в компанию через создание профессионального сообщества, в нашем случае — гильдии.
