Новый заказчик, собственник медиа-компании, начал с того, что захотел индивидуальные занятия по Agile для себя 2 раза в неделю – обучение один на один.

Нестандартное начало, потому что обычно я помогаю внедрить Agile-процессы в компании, тренируя команду, прокачивая менеджеров, попутно обучая руководство. Индивидуальных тренингов один на один не проводил.

Выяснил подробности:

► Компания заказчика занимается массовым производством роликов для YouTube. У компании несколько каналов и миллионы просмотров каждого ролика.

► Команды состоит из ооочень креативных людей – режиссёры, актёры, мастера

► Заказчик строит “бирюзовую” организацию. Кто не знаком с термином &n ... Читать дальше »

Последнее время всё больше ухожу от постановки процессов в компаниях к постановке целей с руководством.

Помните, у Стивена Кови было «можно очень быстро и эффективно карабкаться по лестнице, приставленной не к той стенке»? В компаниях то же самое.

Мало толку налаживать Agile, когда владелец продукта/компании, руководитель проекта и маркетологи не могут правильно позиционировать продукт.

Изнутри часто кажется, что всё ok. Вот же «продукт для людей такой-то профессии в возрасте 20-40 лет, которым нужно ....».

Но какие свойства продукта нужны этим людям, а какие — нет? «Мы опросили пользователей / по заявкам на сайте мы поняли...» Всё это — от лукавого. Где суть продукта, что на острие этого продукта? Что самое главное?

Позволю себе привести пример из личной практики.

Я считаю, что главное мое достижение во время работы в компании JetBrains — позиционирование продукта WebStorm.

До&n ... Читать дальше »

Один из самых популярных вопросов у интересующихся: «Когда этот ваш Agile применять можно, а когда нет?»

Можно ли применять Agile в управлении бухгалтерским отделом? В юридической компании? Работает ли Agile в банках или в строительстве?

Agile это множество различных методик, объединённых одними и теми же принципами, описанными в манифесте.

Если посмотреть на эти принципы, становится ясно, что изначально Agile появился в разработке программного обеспечения. Это так. Но с тех пор Agile далеко вышел за пределы IT. Тем не менее, исходя из этих принципов, можно и определить границу применимости Agile. Рассмотрим некоторые их них.

Принцип: изменение требований — это нормально и приветствуется

• Важно ли это в разработке программного обеспечения?

Да, на каждом шагу! Продукты постоянно эволюционируют, взгляд заказчика на них тоже. Значит, судя пока только по этому одному принципу, методика, берущая за основу нормальность изменений, в программировани ... Читать дальше »

Вот и закончилось внедрение Agile в строительной компании Gravion Group. Если быть более точным — в компании занимающейся инвестиционными проектами в сфере недвижимости. Работал в команде архитекторов, инженеров, конструкторов. Хотя в итоге ими дело не ограничилось. Об этом дальше.

Это был мой первый опыт применения Agile в сфере строительства. Но как набор принципов и методик Agile себя полностью оправдал. Как оказалось, ключевые проблемы в проектировании зданий — такие же как в проектировании программного обеспечения. Не поговорили вовремя с заказчиком. Неправильно расставили приоритеты. Изменения Технического Задания на каждом шагу.

Последнее было особенно неожиданно. В сфере IT люди свято уверены, что уж в строительстве-то ТЗ незыблемо. Как бы не так. На стадии проектирования постоянно изменения. Проектируешь дом на 40 квартир, а заказчик потом просит сделать их меньше, но 50, и ещё добавить детскую площадкуб и чтобы фасад был нестандартный, но чтоб всё дёшево.

Оказалось, и в строительстве надо быть гиб ... Читать дальше »

Этим летом выпала необычная работа. За внедрением Agile обратилась строительная компания. Речь шла о внедрении Agile в проектировочном отделе: архитекторы, инженеры, конструкторы.

Несмотря на специфику области, принципы управления проектом в любой команде, создающей интеллектуальный продукт - будь это программный код, или строительная документация - одинаковы. Насколько они одинаковы очень хорошо показал тренинг - в интеллектуальных проектах одни и те же проблемы:

• "не хватает ресурсов"
• "заказчик не знает чего хочет"
• ТЗ постоянно меняется (да-да! В строительстве, оказывается, тоже так! Не только в IT)
• сроки всё время сдвигаются

Все те проблемы, которые в IT успешно решает Agile. Поэтому за проект я взялся и вот уже два месяца мы работаем вместе.

Скоро можно будет похвастаться результатами, а пока хочу показать самую образцовую Kanban-доску, которую я видел в жизни:

 Сразу видно рисовали не программисты, а архитекторы зданий =) У которых было 5+ по черчению =)

А из кубиков для тренинга, конечно же, построили дом:

... Читать дальше »

Когда ко мне обращаются с вопросом внедрения Scrum или Kanban для удалённой разработки, географически распределённой команды или для любой другой ситуации, когда разработчики не сидят в одном офисе, я обычно отвечаю так:

Scrum и Kanban, конечно, увеличит эффективность работы, но гораздо больше увеличило бы эффективность работы просто посадить всех в одном офисе.

Да, знаю, это как раз не просто, но, по моему опыту, вложение в один офис окупится гораздо быстрее и поднимет скорость и качество работы сильнее, чем при тех же условиях внедрение Scrum или Kanban. А вот если вы сначала посадите всех в один офис, а потом внедрите Kanban или Scrum - вот тогда вас действительно ждёт отличнейший подъём производительности.

Конечно, современный мир таков, что всем хочется работать удалённо, из дома. Или же аутсорсить проекты в Индию или Китай. Но если вам действительно нужно быстро и хорошо сделать проект, особенно стартап - сядтьте в одну комнату!

Заказ от SemRush поступил очень неожиданно :) Я уж думал, что летом буду отдыхать, а, оказывается, меня порекомендовал в SemRush директор AviaSales Костя Калинов, у которых я как раз накануне закончил внедрение. Рекомендация это всегда приятно, значит работу оценили.

Приехав в офис SemRush, обнаружил там 4 очень разных команды. Давно не видел такого разнообразия :) Обычно все команды в одной компании исповедуют более менее одну идеологию. А тут прям совсем разные люди, впрочем, мирно уживающиеся друг с другом.

Было интересно: то, что работало с одной командой, не работало с другой, и наоборот. Но вначале мы собрались вместе и составили список проблем, которые видели сами команды и руководство компании:

• нет обратной связи от руководства об успешности действий
• нет обратной связи от пользователей в команду (только маркетологам)
• сроки не выполняются
• нет последствий нарушения качества или сроков
• в некоторых ситуациях не понятно, кто должен принимать решение
• менеджеры перегружены
• затруднено согласование действий между командами
• опасность развала про ... Читать дальше »

Последние несколько лет я много времени провожу в Таиланде, иногда выезжая на заказы по внедрению Agile в России. И вот поучаствовал в мини-конференции русских It-шников тут.
Весёлый живой формат — 15-и минутные доклады о самых разных вещах.

Я рассказал об опыте удалённого управления по Agile в не-IT компании. А именно про опыт удалённого управления Квесторией.

Нарезка видео по итогам конференции.

Слайды презентации.

Год прошёл с момента окончания проекта по внедрению Scrum в AviaSales и можно подводить итоги. Проект для меня, как тренера и консультанта по Agile, был очень интересен: работать с прогрессивной, готовой к изменениям командой - одно удовольствие. Мы почти не останавливались на технических деталях, а шли сразу к цели - увеличению эффективности работы и достижению ответственности за результат.

Комплекс мероприятий включал в себя как работу с программистами по объяснению Scrum и созданию благоприятной обстановки для внедрения, так и работу с ProductOwner'ами по формированию чёткого видения и донесения его до команды. Радует, что программисты сразу поняли идею и мы с самого начала говорили о последующем переходе от Scrum к Kanban - как к более подходящему для команды процессу. И судя по отзыву у ребят получилось перейти на Kanban! Это круто! Поздравляю! С вами было очень и очень здорово работать! :)

Отзыв от CTO AviaSales, Бориса Каплуновского: