Привет, Хабр! Хочу рассказать вам сегодня об одном инструменте. Он помог мне когда-то понять как устроены сложные организационные системы, как с ними работать, и самое главное, как их менять. Можно сказать, этот инструмент - линза, через призму которой мы можем по-другому посмотреть на окружающий нас мир.
Инструмент называется Айсберг системного мышления, и сегодня поговорим о нем.
Scrum, Kanban и другие «эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При этом легко сломать то, что работает, ничего не исправить и испортить жизнь всем участникам проекта.
Рассмотрим острые методологические проблемы, на которые почему-то редко обращают внимание. Порассуждаем, как не споткнуться о такие камни преткновения или хотя бы удержать равновесие после этого.
Спойлер: многие затронутые вопросы спорные, и готовых решений у нас нет (как, наверное, у большинства PM). Так что заранее приглашаем всех желающих к диалогу и обмену опытом в комментариях.
Привет!
Меня зовут Михаил, и больше 7 лет я занимаюсь улучшением рабочих процессов для малых и средних IT-команд. И конечно, для того чтобы понять что происходит в этих самых командах и процессах нужны правильно подобранные метрики, а еще лучше единая приборная панель, взглянув на которую и члены команд, и менеджмент могут сразу понять ситуацию, могут сразу найти зарождающиеся проблемы.
Про метрики отвечающие за скорость и качество доставки ценности всем давно уже всё известно, и как правило все стараются их отслеживать. Но сегодня я хотел бы сфокусировать внимание на метриках благополучия команд (Well-Being metrics).
Меня зовут Курдюмов Дмитрий, я сертифицированный Agile коуч и Лидер по трансформации бизнеса, последние 7 лет помогаю компаниям трансформировать их процессы и структуру для достижения большей адаптивности и скорости. В этой статье хочу поделиться тем, как Agile поменял принципы регулярного менеджмента в компаниях.
Всем привет! На связи Сергей Гончарук, менеджер проектов компании «Флант». 30 ноября и 1 декабря 2023 года прошла конференция TeamLead++ Conf 2023. Ниже — текстовый вариант моего доклада с конференции про опыт «Фланта» в построении процессов управления задачами для Dev-части нашей DevOps-работы.
В докладе я рассказал, как можно применить ценностную модель, чтобы построить идеальный фреймворк для команды, и как приносить изменения в компанию через создание профессионального сообщества, в нашем случае — гильдии.
В сети множество материалов по гибким методологиям управления проектами. Моя цель – дать конкретику в подходе, скомбинировав лучшие практики современного проектного менеджмента на основе существующих Agile практик. Секрет состоит в том, что используемые подходы – отлично дополняют друг друга.
Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании. Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?
Думается, что они выступают в качестве удачных базовых рабочих процессов, которые можно и нужно модифицировать. Однако перед тем, как что-то менять, постараемся в общих чертах разобраться, что не так с популярными методологиями разработки, в чем их особенности и как выбрать подходящую.
Спойлер: многие затронутые вопросы спорные, и готовых решений у нашей команды нет (как, наверное, у большинства PM). Так что заранее приглашаю всех желающих к диалогу и обмену опытом в комментариях.
Последние двадцать лет привели к серьезной трансформации технологического ландшафта и работы архитекторов, которые за ним должны следить. Архитекторы работают с технологиями и людьми. Компьютерные технологии за последние десятилетия значительно изменились и продолжают это делать. Люди меняются не так быстро. Однако, для работы с людьми выделяются новые роли: продакт-менеджеры, прожект-менеджеры, тимлиды. Роль и влияние архитекторов не так велико, как раньше, они становятся прерогативой больших компаний.
В статье попробуем разобраться действительно ли роль архитектора незаменима, для чего она нужна, как возникла и работает в реальном мире?
Более 10 лет я наблюдаю за процессом разработки программного обеспечения, как изнутри, так и со стороны. За это время я занимал различные должности, от джуниора до техлида, тимлида и менеджера продукта. Сейчас совмещаю всё понемногу.
Недавно менеджмент обратился ко мне с вопросом о том, как ускорить поставку ценности командой разработки.
По сути, озвученная менеджментом проблема заключалась в следующем: у нас аналитики не успевают писать спеки, а тестировщики не успевают тестировать фичи. Давай заставим программистов писать спеки и тестировать фичи. К моему превеликому сожалению, этот подход я встречал практически на каждом месте своей работы, и не только там.
Привет! Меня зовут Александр Апазиди, я руковожу в СИБУРе цифровизацией процессов головного офиса.
Сегодня я расскажу, как мы приводили IT-проекты в огромном нефтегазохимическом холдинге к одной модели, пытались примирить Agile и Waterfall, да и в целом, ускорить выполнение проектов.
С 2020 по 2022 количество наших IT-проектов увеличилось с 70 до 220, так что тема ухабистая. Приятного чтения!
5 методик, которые необходимо использовать продуктовому дизайнеру в 24-м
Практическое руководство по использованию фреймворков, которые помогут вам создавать лучшие продукты с разбивкой по этапам
Статья не претендует на научность, а просто рассказывает, как бывает в жизни, когда уже прошел все курсы, проверил разные гипотезы, но все еще получаешь новый опыт. На моем примере вы увидите как не нужно «впиваться» в конкретную фичу и биться с ней до конца, отпускать — это нормально, ошибки — это нормально.
Привет, Хаброжители!
Что такое Agile? Как гибкие подходы могут помочь в работе, бизнесе или даже в обычной жизни? В этой статье вы узнаете, что Agile-принципам можно следовать даже при приготовлении новогоднего оливье. Будет полезно всем, кто хотя бы раз сталкивался с таким непростым делом, как подготовка новогоднего стола!
Всем привет! На связи снова Петрова Марина — QA Lead в Сloud.ru. Сегодня поделюсь опытом оценки и оптимизации процессов тестирования с помощью модели зрелости TMMi. Наша команда использует TMMi с третьего квартала 2022 года: за это время мы не раз оценили процессы и адаптировали модель для команд, которые работают в Agile-парадигме, но обо всем по порядку.
Привет! Это Дмитрий Гайдук, менеджер в АТОМе по корпоративным и онлайн-сервисам.
Каждое инженерное и программное решение в АТОМе – это отдельный продукт. Но если вырывать эти продукты из контекста, они останутся отдельными разрозненными решениями. Для нас крайне важно изменить само восприятие автомобиля и создать опыт, который задействует все сплетение новых технологий. Проекция дополненной реальности на лобовое стекло, голосовой ассистент, продвинутая система помощи водителю и множество других решений должны соединяться с эргономическими особенностями электромобиля, и только тогда они станут цельной экосистемой.
Как это работает?
Разберем на примере АТОМ-такси. Главная особенность этой модели – отсутствие переднего пассажирского кресла. Очевидное преимущество такого решения: у клиента больше места для ног. Менее очевидное: ничто не перекрывает обзор. Вид на город становится практически панорамным.
Ретроспектива. Новогоднее ретро. Как погрузить команду в Christmas mood?
Всем привет, это вторая часть статей о готовых шаблонах проведения ретроспектив. Эта статья посвящена новогодней рестроспективе. Новый год, декабрь месяц, подарки, глинтвейн, сугробы, «Гарри Поттер», «Один дома», селёдка под шубой…
Всё не перечислить, да и не нужно, ведь наша ретроспектива определит ваши планы на декабрь, январь и февраль. Да-да, это чистая правда.
Меня зовут Александр Шаповалов, я руководитель отдела разработки систем расчёта и доставки Mediascope. Количество людей и задач в нашем отделе росло постепенно. Когда в моей команде был только один сотрудник, было легко держать весь рабочий контекст на листке бумаги и в голове: аналитика, архитектура, стек, взаимодействие с заказчиком. Но когда нас стало больше 10, я заметил, что часть аспектов стала ускользать из фокуса. Любые ручные проверки для такого объёма задач не приемлемы, поэтому мы внедрили калибровку процессов с помощью метрик разработки.
