Agile — только для IT? Точно нет. Команда Kaiten поговорила с экспертами из разных сфер и выяснила, как принципы Agile работают за пределами разработки: какой эффект они приносят и какие сложности вызывают.
Рассказываем истории других команд, которые помогут пересмотреть подходы в своем отделе и сделать процессы эффективнее.
Приложения для планирования и управления проектами призваны помочь нам успешно разрабатывать и поддерживать проекты в рамках нашего бизнеса. Сегодня, в эпоху цифровых технологий, когда все больше отраслей уходит в онлайн и все больше людей работают дистанционно, на рынке программного обеспечения для управления проектами царит настоящие изобилие. Но как понять, какие продукты действительно хороши, а от каких лучше держаться подальше?
«Подчинение авторитету» — книга не о менеджменте, но она как нельзя лучше расскажет про базовые психологические процессы, происходящие в людях, которыми управляют. На стыке психологии и философии в ней рассказывается про эксперимент, где выявляли предел, до которого может дойти человек, подчиняясь другому человеку.
Создателей эксперимента вдохновили преступники нацистской Германии, и они задались вопросом: «Почему обычные люди выполняли чудовищные приказы?». Чтобы на него ответить, они провели серию экспериментов, в которых обычные люди попадали в ситуацию подчинения.
Изменения в управлении часто ассоциируются с громкими заявлениями, трансформациями, реструктуризациями и, конечно, внутренним сопротивлением. У нас всё случилось иначе.
За последние несколько лет мы практически полностью перешли от принципов менеджмента 2.0 к менеджменту 3.0. Но интереснее всего то, что сотрудники этого почти не заметили — просто потому, что всё происходило естественно. Делюсь своими наблюдениями, как и почему это получилось.
Всем привет!
Сразу оговорюсь, что это моя первая статья на Habr. Надеюсь, что она окажется полезной для команд, сталкивающихся с проблемой вовлеченности и ответственности новых участников. Желание написать ее появилось внезапно. Мне захотелось поделиться успешным опытом преодоления проблемы, с которой мы в нашей команде внезапно столкнулись. Но обо всем по порядку.
Время выполнения потоковых задач в разработке часто колеблется: один день задача занимает 2 часа, в другой — 6. Из-за этого сложно предсказать, уложится ли команда в срок. Control chart помогает отслеживать разброс времени, находить аномалии и корректировать процесс до того, как отклонения станут проблемой.
В статье разберем, как это работает, и покажем, как можно читать график, чтобы определить SLA при работе с заказчиком.
Знаете, в чем сила канбан-досок? С их помощью можно организовать любой проект — и разработки, и крипто-стартапа, и контент-студии. Чего угодно. Рассказываю, как сэкономить время, силы и деньги и выбрать лучший сервис с канбан-досками.
Для кого эта статья: менеджеры, тимлиды, директора, отвечающие за организацию процессов, трансформацию команд и внедрение устойчивых практик управления IT. Если вы ищете понятный способ освежить знания по ITIL 4 и посмотреть, как принципы работают вживую — этот разбор для вас.
Разработчики делают задания ради галочки, в их глазах больше не горит огонь, а число инновационных идей от девелоперов уменьшилось? Нет, сотрудники не обленились. Им просто не хватает мотивации для эффективной работы. Разбираемся вместе с командой системы управления проектами Kaiten и консультантом по современному менеджменту Neogenda Марией Савельевой, как вернуть мотивацию IT-команде.
Таск-трекер без бизнес-процессов ― деньги на ветер! Самая частая ошибка ― пытаться заводить задачи, не продумав сам процесс. В этом тексте показываем 6 универсальных процессов, которые можно внедрить буквально за 10 минут: от онбординга до работы с подрядчиками.
Всем привет! С вами Леша Жиряков, и сегодня я затрону тему планирования и Agile. Недавно кластер/трайб/холдинг, в котором я работаю, проходил трансформацию методов работы, все началось с идеи: а давайте сделаем продукт более открытым. С одной стороны, бизнес требует предсказуемости и возможности строить долгосрочные стратегии, с другой — рыночная турбулентность и подводные камни в IT диктуют необходимость быстрой адаптации к меняющимся условиям.
Это противоречие особенно остро проявляется при столкновении традиционного многолетнего планирования с гибкими Agile-методологиями, призывающими «реагировать на изменения важнее, чем следовать плану». Открытость, гибкость, скорость, эффективность, надежность — вот критерии успешного продукта. Но, развивая надежность, сложно оставаться гибким, повышая эффективность, рискуешь потерять в скорости, а стремление к открытости может снижать безопасность.
Классическое долгосрочное планирование на год и более даёт стратегическую перспективу, но часто оторвано от реальности быстро меняющегося рынка и технологий. Двухнедельные спринты позволяют гибко адаптироваться к изменениям, но затрудняют видение большой картины и координацию масштабных инициатив. Где же золотая середина?
Квартальное планирование становится компромиссным решением, позволяющим синхронизировать циклы бизнеса с работой IT-команд. Квартал как временной интервал достаточно короток для маневренности, но при этом дает необходимую устойчивость для реализации значимых инициатив. В умелых руках оно способствует Agile-трансформации, усиливает прозрачность и повышает эффективность команд. При неправильном внедрении может превратиться в бюрократический ритуал, возвращающий организацию к каскадным методологиям под видом прогрессивного подхода.
Все мы знаем, что наш мир быстро меняется, и, к сожалению или к счастью, скорости никак не уменьшаются, а только нарастают. Особенно это чувствуют компании, ведь с изменением мира меняются и механизмы работы. Как приспособиться к новым реалиям, как повысить эффективность, как изменить подход к выполнению задач, если это кажется необходимым? Конечно, нужно обучение. К этому выводу однажды приходят как самые крупные, так и совсем небольшие компании. Но как найти и построить это обучение?
В процессе создания программного обеспечения участвует множество ролей, каждая из которых имеет свою систему ценностей, приоритетов и целей. Эти различия часто приводят к противоречиям в требованиях. Для структурированного анализа таких конфликтов используется модель «Гексапараллакс», которая рассматривает шесть ключевых точек зрения:
Много JavaScript‑фреймворков назад, в 2009 году, Джеффри Дин, будучи инженером в Google, представил знаменитые «числа, которые должен знать каждый программист».
Много лет в разных компаниях я была перегружена. Делала слишком много ― и всегда было мало. Решение оказалось проще, чем казалось. Поделюсь, как без навороченных инструментов и с помощью всего одной канбан-доски бустануть эффективность.
Последние годы в управлении проектами активно распространилась идеология Agile. Многие работодатели указывают знание Agile как обязательное требование к кандидату. Появились целые школы, которые обучают Agile, выдают сертификаты и т.п. Я считаю, что эти люди( и работодатели, я уж не говорю про HR) просто не имеют опыта управления, а Agile - модное слово, наверно что-то продвинутое, современное. В общем я знаю, как образовалась Agile, с точки зрения программиста она достаточно привлекательна. Но распространять идеологию Agile на все проекты в ИТ - мягко выражаясь некорректно. Предлагаю вашему вниманию другую идеологию управления проектами и продажами.
За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — около 50 команд в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному.
Причем конверсия в правильное использование Story Points 3 месяца после тренингов составляет дай бог 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей.
Чем дольше я работаю в разных системах управления проектами — тем лучше понимаю, насколько разные у команды и руководителей приоритеты.
— Сотрудникам важно легко разобраться в интерфейсе, держать под рукой свои задачи и красивый фон для доски с задачами выбрать 😌
— Руководителям важно знать, кто чем занят, контролировать работу команды и видеть полную картину по проектам 😎
Этот обзор я решила посвятить руководителям, так как сама пару лет назад начала управлять отделом. И теперь мои требования к системе управления проектами сильно возросли. В нем будут обзор возможностей для руководителей в разных сервисах, примеры использования и комментарии из личного опыта. Сотрудником тоже будет полезно о них узнать.
Переименование Scrum Master в Agile Delivery Manager — не просто смена названия на бейдже. Это отражение глубинных изменений в понимании роли, сфокусированной не на фреймворке, а на реальной ценности, которую команда приносит бизнесу. В эпоху потокового мышления и зрелых инженерных практик, где CI/CD — уже норма, лидерство в поставке перестаёт быть вспомогательной функцией. Эта статья — о том, как меняется суть роли, почему Scrum становится слишком узким, и почему переход к модели ADM может стать следующим логичным шагом для тех, кто давно перерос рамки agile 101.
Никто не любит очереди и ожидания. Мы не любим стоять в очередях и ещё больше не любим лезущих вне очереди. Сверхэффективный ад порой представляют как бесконечную, зацикленную саму на себе очередь... В конце концов, что есть символ неизбывной печали и тоски, как не Хатико.
Знаете, кто ещё больше не любит ожидания? Бизнес. Бизнес очень не любит, когда ожидания копят важные проекты и инициативы. Согласно исследованиям средняя эффективность потока в Delivery составляет 35%, а всё остальное время - задачи ждут. (Данные на основе опросов специалистов — ссылка. Метаанализ тысяч workflow от Nave - ссылка ) Справедливо, что ключевая точка роста для ускорения поставки — уменьшение ожиданий.
Именно об этих "фантастических" ожиданиях и пойдёт речь в статье. Я расскажу о системной работе с блокировками и зависимостями, которые повинны в значительном количестве задержек. Мы погрузимся в необходимую теорию, рассмотрим наш успешный практический кейс в hh.ru и, что особенно ценно, я поделюсь конкретными пошаговыми инструкциями по настройке Jira & n8n, а также способами работать с визуализацией блокеров в удобных плагинах, чтобы вы могли применить этот подход у себя.
Этот материал будет полезен IT-менеджерам, тимлидам, руководителям проектов, delivery менеджерам и руководителям функций — всем, кто стремится более осознанно и эффективно распоряжаться временем и ресурсами.
