Привет, Хабр! Меня зовут Иван, я руководитель отдела тестирования фронт-офисных и интеграционных систем в РГС.
В этой статье я хочу посмотреть на ключевые ценности Agile не сквозь розовые очки, а через призму управленческой практики. Разобрать, как они на самом деле работают, где помогают, где ломаются и что с этим делать тем, кто отвечает за результат.
Всем привет! Меня зовут Артем — за последние 10 лет поработал в больших компаниях, стартапах, консалтинге на позиции продакта и проджекта. Сегодня расскажу про мой подход работы с бизнесом и технической командой и про то, как превратить хаотичный поток задач в предсказуемый фреймворк.
В моей профессии Roadmap — ключевой артефакт. И при правильном формировании он способен выводить продукты из хаоса в предсказуемость. Дорожная карта не про сроки, а про баланс интересов — прикладная часть этого тезиса как раз и будет раскрыта в статье ниже.
Поработав в разных доменных областях я видел десятки команд, которые работали в постоянном пожаре. И везде проблема была одна и та же: никто не понимал, что мы делаем завтра и почему именно это.
Тогда я пришел к фреймворку «Квотирование» — методу, который делает дорожную карту предсказуемой в любой среде: в стартапе, enterprise, консалтинге.
Лучше всего, перед формированием дорожной карты использовать RICE для расстановки приоритетов, а только потом положить задачи на дорожную карту.
Вопрос выбора системы управления продуктовой командой перестал быть теоретическим упражнением. Jira больше не обновляется, техподдержка молчит, а требования к импортозамещению никуда не делись.
Тысячи команд одновременно столкнулись с необходимостью искать альтернативу, причём желательно не методом научного тыка.
История с Jira — это не просто уход очередного западного вендора с российского рынка. Это идеальный шторм из трёх факторов, которые делают дальнейшее использование системы проблематичным даже для тех, кто готов работать на старых версиях.
Для понимания меня, наверно нужно знать мой путь разработчика.
Закончен университет Имени Ярослава Мудрого в Великом Новгороде по специальности радиотехника.
Практика в КБ Планета, диплом считыватель R-FID меток. защита на 4, кажется никто не понял с моих слов сути устройства и каков был мой вклад.
первая работа:
2010 год сентябрь трудоустройство в НПК СПП в отдел систем видеорегистрации
мы делали видеорегистраторы полетной информации для Сухих и других крутых КБ
дальше меня после 9ти лет стажа и отсутствия перспектив из-за карьерных косяков закинуло в Diakont в 2020 году мы переехали с женой под рождение сына в Алмазово но это отдельная история...
Началась разработка средств доставки и диагностики бесконтактным методом ЭМА и другими...
Роботы были разные, все внутритрубной диагностики. Самый пик и интерес был робот для Малазийцев в проекте стоимостью в 300+ мультов русских. И даже некоторые из команды побывали в Куала-Лумпур, но не я...
Когда я решил выстроить систему планирования в Obsidian, я начал документировать: что я делаю в течение рабочего дня, с какой информацией работаю, где её ищу, как принимаю решения.
Когда у команды большой бэклог задач, как решать, в каком порядке их делать? Привет, я Владимир Князев, Agile-коуч трайба HR Tech в ОТП. Сегодня я кратко расскажу, как трайб HR Tech использует приоритизацию ICE.
У нас в трайбе всё как у всех: заказчиков много, запросы сложные и разные, а задач больше, чем мы можем физически сделать. Чтобы упростить работу команды над ними, мы решили внедрить приоритизацию по методу ICE.
Последние 2 года я выстраивал и непрерывно улучшал собственную систему планирования в Obsidian. За это время я обнаружил кое-что важное, что решил разделить с сообществом.
И вот что я заметил: почти все, кто пытается выстроить систему управления, начинают с одного и того же вопроса — «Какой инструмент мне взять?» Notion? Jira? Obsidian? Linear? Асана?
Тут я всегда отвечаю одно: выбор инструмента — это последний вопрос, а не первый.
Управление целями нужно не ради красивых слов, а чтобы соединить долгосрочные планы с ежедневной работой. Когда понятно, ради чего ставятся задачи и как их выполнение влияет на общий результат, команда чувствует, что двигается в одном направлении. Руководители при этом видят реальную картину, а не набор несвязанных отчетов.
В статье мы разложим по полочкам четыре ключевые методологии целеполагания — MBO, KPI, OKR и BCS — покажем, как они помогают связать стратегию с повседневной работой, и дадим полезные инструменты управления целями, чтобы бизнес шел по курсу, а не дрейфовал.
Выбираем архитектуру по кайдзен: на что обратить внимание
Я часто замечаю одни и те же ошибки в различных решениях — как по работе, так и в жизни. Зачастую многие думают, что сейчас сделают прототип, а потом допилят, но не учитывают, как будет развиваться решение и что лучше взять за основу. Поэтому эта статья будет полезна не только архитекторам при выборе основы, но и разработчикам для понимания более важных и ценных задач. А также проектным менеджерам — чтобы создать верную стратегию развития.
Предлагаю разобрать на примере подход выбора архитектуры для продукта!
В последнее время тема лидерства в IT компаниях потерялась в потоке энтузиазма, вызванного безграничными перспективами отрасли. Лидерство, конечно, фигурирует в современных методологиях типа Agile и DevOps, но при этом не наделяется достаточной силой, чтобы выполнить свою трансформационную роль. Лидерство выглядит как Золушка с неочевидным для всех королевским потенциалом. Эта статья возвращает лидерство на пьедестал, обосновывая его уместность именно для IT. Речь здесь идет о таком лидерстве, которое одержимо незаурядным результатом в равной степени, как и опорой на смыслы и человеческое достоинство и не имеет ничего общего с расхожим «лидерством», которое практически равнозначно понятию «руководитель». За таким подлинным пониманием лидерства, стоят хорошо известные с 70-х годов принципы трансформационного лидерства Джеймса Бернса и Бернарда Басса. В период индустриальной эпохи эти принципы использовались факультативно, хотя и с большим успехом. Лидерство в компаниях стало притчей во яцызах , но не возобладало в традиционном менеджерском управлении. Эра информационных технологий делает трансформационное лидерство в IT компаниях безальтернативным. Эта статья не про теоретические изыскания на будущее, а про достижение незаурядных результатов в настоящем.
Любите настолки? И я люблю. Не только играть в них, но и разрабатывать. Правда, процесс это настолько длительный и непростой, что в основном мои амбициозные идеи умирали на бумаге. Пока на помощь не пришел генеративный ИИ.
Меня зовут Андрей Шумаков, я scrum-мастер, а также куратор по розничному бизнесу в центре развития гибких практик разработки и внедрения продуктового подхода в ПСБ. Мой интерес к настолкам в том числе рабочий: я создаю бизнес-игры. В этой статье расскажу, как создал бизнес-игру с помощью искусственного интеллекта. Scrum-мастера, берите на заметку! Под катом объясню в деталях, как составить хороший промпт и какие именно задачи поручить ИИшке, чтобы она не галлюцинировала излишне, не путалась в контексте и выдавала результат, который потом можно итерировать своими руками. Поехали!
Почему каскадная модель не так «жёстка», как кажется, а Agile — не методология.
На написание статьи сподвигла статья и обсуждения в чате одного сообщества по бережливому производству.
Хочу сразу обратить внимание, что здесь будем обсуждать ложную дихотомию в управлении проектами.
Споры о превосходстве Agile над Waterfall или наоборот давно стали клише в IT-среде. Однако корень этой дискуссии — фундаментальное непонимание сути обеих концепций. Agile часто ошибочно называют методологией, тогда как на деле это набор ценностей, а выбор реальных инструментов управления происходит между каскадной моделью (Waterfall) и итерационными подходами — Scrum, Kanban, XP. Почему этот нюанс так важен? Потому что смешение философии и инструментов ведёт к мифам, которые мешают эффективно управлять проектами.
Термин «Agile» сегодня используется повсеместно, но зачастую его глубокий смысл теряется за множеством интерпретаций. Стремясь стать более гибкими, многие компании сталкиваются с одной и той же проблемой: они не меняют суть своих процессов, а лишь добавляют к ним отдельные элементы «современных» методик, таких как SCRUM. Подобные поверхностные изменения напоминают косметический ремонт старого здания: внешне все выглядит обновленным, но со временем старые проблемы проявляются вновь.
Поработав в компаниях с традиционным подходом, а затем в среде, где SCRUM применялся осознанно и полноценно, я на собственном опыте увидела принципиальную разницу.
Именно через сравнение двух подходов становятся видны конкретные преимущества SCRUM. Это позволяет понять, какие системные недостатки традиционного управления он устраняет и за счет каких принципов обеспечивает стабильную и предсказуемую реализацию проектов – без перегрузки команды. Давайте попробуем разобраться.
Каждое ретро превращается в длинный список проблем: команда обсуждает всё подряд, составляет планы — но через месяц список остаётся тем же. Проблемы не решаются, а участники устают от бесконечных разговоров без результата. Squad Health Check работает иначе: он помогает выявить одну самую «больную» точку и сфокусировать команду на её решении.
Чтобы наглядно показать, как это работает, расскажу историю в духе сказки про Винни‑Пуха. В ней отражены типичные ошибки, с которыми сталкиваются команды, и дана пошаговая инструкция по применению метода. Мы адаптировали методику Spotify Health Check и протестировали её на более чем 50 командах — все ситуации и ошибки в сказке основаны на реальном опыте.
Когда команда растет вместе с проектной нагрузкой, задачи перестают умещаться в блокнотах или Excel. В каждой ИТ-команде, маркетинговом отделе или проектном офисе задаются главным вопросом: где и как фиксировать задачи, чтобы ничего не потерять? Казалось бы, ответ понятен — есть десятки таск-трекеров, которые помогут упорядочить этот процесс. Только как выбрать подходящий сервис?
Внедрили Agile, проводите дейли и ретроспективы, делите работу на спринты — но результата нет. Пожары задач, техдолг растет, команды не успевают. В чем проблема?
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Я считаю, что если Agile не работает в вашей компании — то методология тут ни при чем.
Разберемся, в чем настоящая проблема и как ее решить.
Если в вашей команде больше семи человек, то вы наверняка сталкивались с тем, что во время ретро часть участников «отваливается»: кто-то молчит, а кто-то участвует формально. Однако чтобы встреча прошла успешно и стала источником задач для улучшений, это должен быть разговор всей команды, а не простая расклейка стикеров. А что если добавить в этот процесс геймификацию?
Меня зовут Лея, я менеджер проектов в Lamoda. Я решила сделать ретро полезным и интересным для команды, вдохновившись примером одного из хабровчан и популярными играми. Опишу процесс на примерах с Pac-Man и Тетрисом, полученный результат и оставлю для вас рекомендации для применения в своей команде.
Вредные советы о лидерстве, которые превращают сильную команду в хаос — и о том, что на самом деле помогает лидам развивать людей, доверие и устойчивые процессы.
С иронией о типичных ловушках: от микроменеджмента и героизма до игнорирования обратной связи.
Все вокруг твердят о рисках, «риски надо учитывать», «риски нужно минимизировать», но мало кто системно объясняет, какие вообще риски бывают и как их классифицировать именно применительно к Delivery Management.
Привет, Хабр! Это Женя Руденко, Agile Cluster Lead в МТС Web Services. Когда в компании запускают Agile-трансформацию, чаще всего сталкиваются не с нехваткой инструментов или методик, а с сопротивлением людей — от тимлидов до C-level. Именно это и стало для меня первым вызовом при работе с командой KION: вместо работы «по учебнику» пришлось искать свой путь, балансируя между стратегией и ежедневными задачами, между конфликтами и доверием.
Сегодня я расскажу, как шаг за шагом выстраивал взаимодействие с командами, что помогало удерживать доверие, почему честный диалог работает лучше презентаций и какие принципы оказались ключевыми для того, чтобы Agile действительно прижился. Да, во многом это достаточно очевидные вещи, но надеюсь, что мой опыт будет полезен тем, кто приходит в новую компанию менять сложившиеся там процессы.
