Изначально публикация должна была называться "Гре****е управление временем", что должно символизировать боль и проблемы связанные с этой активностью. Неумение решать тучу задач это очень неприятный ком в горле, мешающий находится на волне развития. Собрал методики, статьи и материалы, которые помогают мне в моем маленьком старте исследования.
В мире жесткой конкуренции и борьбы за опыт клиентов, многие компании сталкиваются с тем, что их операционная модель и процессы не успевают за скоростью изменений.
Поэтому многие компании стали рассматривать трансформацию своей модели управления на 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-работы.
В докладе я рассказал, как можно применить ценностную модель, чтобы построить идеальный фреймворк для команды, и как приносить изменения в компанию через создание профессионального сообщества, в нашем случае — гильдии.
В сети множество материалов по гибким методологиям управления проектами. Моя цель – дать конкретику в подходе, скомбинировав лучшие практики современного проектного менеджмента на основе существующих Agile практик. Секрет состоит в том, что используемые подходы – отлично дополняют друг друга.
Благородя своей гибкости, Jira в большинстве крупных компаний, используется в качестве единой системы принятия решений и отслеживания изменений.
Вопреки расхожему мнению, далеко не все компании занимаются разработкой софта.
Во многих крупных организациях Dev и Ops – это всего лишь одно структурное подразделение, так называемый Cost Center (то есть напрямую компании доходы не приносит). При этом одной из главных задач в Agile является обеспечение прозрачности процессов для всех заинтересованных сторон (stakeholders).
Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании. Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?
Думается, что они выступают в качестве удачных базовых рабочих процессов, которые можно и нужно модифицировать. Однако перед тем, как что-то менять, постараемся в общих чертах разобраться, что не так с популярными методологиями разработки, в чем их особенности и как выбрать подходящую.
Спойлер: многие затронутые вопросы спорные, и готовых решений у нашей команды нет (как, наверное, у большинства PM). Так что заранее приглашаю всех желающих к диалогу и обмену опытом в комментариях.
Последние двадцать лет привели к серьезной трансформации технологического ландшафта и работы архитекторов, которые за ним должны следить. Архитекторы работают с технологиями и людьми. Компьютерные технологии за последние десятилетия значительно изменились и продолжают это делать. Люди меняются не так быстро. Однако, для работы с людьми выделяются новые роли: продакт-менеджеры, прожект-менеджеры, тимлиды. Роль и влияние архитекторов не так велико, как раньше, они становятся прерогативой больших компаний.
В статье попробуем разобраться действительно ли роль архитектора незаменима, для чего она нужна, как возникла и работает в реальном мире?
Более 10 лет я наблюдаю за процессом разработки программного обеспечения, как изнутри, так и со стороны. За это время я занимал различные должности, от джуниора до техлида, тимлида и менеджера продукта. Сейчас совмещаю всё понемногу.
Недавно менеджмент обратился ко мне с вопросом о том, как ускорить поставку ценности командой разработки.
По сути, озвученная менеджментом проблема заключалась в следующем: у нас аналитики не успевают писать спеки, а тестировщики не успевают тестировать фичи. Давай заставим программистов писать спеки и тестировать фичи. К моему превеликому сожалению, этот подход я встречал практически на каждом месте своей работы, и не только там.
Привет! Меня зовут Александр Апазиди, я руковожу в СИБУРе цифровизацией процессов головного офиса.
Сегодня я расскажу, как мы приводили IT-проекты в огромном нефтегазохимическом холдинге к одной модели, пытались примирить Agile и Waterfall, да и в целом, ускорить выполнение проектов.
С 2020 по 2022 количество наших IT-проектов увеличилось с 70 до 220, так что тема ухабистая. Приятного чтения!
5 методик, которые необходимо использовать продуктовому дизайнеру в 24-м
Практическое руководство по использованию фреймворков, которые помогут вам создавать лучшие продукты с разбивкой по этапам
Статья не претендует на научность, а просто рассказывает, как бывает в жизни, когда уже прошел все курсы, проверил разные гипотезы, но все еще получаешь новый опыт. На моем примере вы увидите как не нужно «впиваться» в конкретную фичу и биться с ней до конца, отпускать — это нормально, ошибки — это нормально.
