Интервью: Как управлять IT-проектами? Основатель Byndyusoft об Agile

В офис Byndyusoft в Челябинске снова пришли ребята с канала Бизнес в стиле диджитал. В прошлый раз мы общались на тему устройства компании, собеседования сотрудников и IT-архитектуры.

Темы из интервью:

1. Что такое Agile
2. Почему сложно внедрять Agile
3. Как менять культу компании
4. Водопадная модель управления и проблемы с её использованием в IT
5. Инструменты для создания качественной коммуникации
6. О тренинге для руководителей банка
7. Практика Impact Mapping

Ссылки, которые упоминаются в видео:

• На 8-й минуте я цитирую выступление Грефа на Гайдаровском форуме
• Инструменты для изменения культуры Culture is a rubber band around your organization
• Манифест гибкой разработки ПО
• Impact Mapping на практике
• Stand-up meeting: лучшие и худшие практики
• Шпаргалка для предпринимателя по IT-миру
• Кнопочное мышление против целостного IT-продукта

— С нами Саша Бындю, вы его видели в выпусках нашего блога. Предыдущее интервью было интересно нашим подписчикам и поэтому мы решили с ним еще раз встретиться.

— Согласен.

— И сегодня мы хотели бы с тобой поговорить на тему Agile и Lean, потому что, помимо того, что ты IT-архитектор, ты еще и эксперт в этом. Можешь для начала расшифровать, что такое Agile и и что такое Lean, в твоем понимании?

— Agile — это набор из 4 ценностей и 12 принципов. И это все, что в нем есть. Его не надо никак интерпретировать, никак по-своему понимать. Нужно просто зайти на сайт agilemanifesto.org и прочитать 4 ценности, 12 принципов.

Agile — это не набор практик: сделаешь шаг влево, и потом шаг вправо, и потом подпрыгни, там такого нет. Это, в целом, то как жизнь устроена. Это можно назвать культурой. То есть когда кто-то говорит «мы внедряем у себя Agile», по сути надо это понимать как «мы меняем культуру компании на более гибкую». Вот здесь как раз и кроется камень преткновения с внедрениями, потому что люди готовы выполнять механические действия, но никто не готов менять культуру. Просто люди так устроены, что они не готовы меняться и поэтому начинаются всякие интерпретации, начинается, что мы в целом делаем Agile, но не совсем делаем Agile, но почти… почти все, что там написано мы делаем.

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

— Это точно.

— И из твоего опыта, на какие примерно сроки рассчитывать? Обычно, когда культура меняется, возникает саботаж внутри компании, потому что кто-то не подходит в эту культуру, кто-то не понимает ее ценности. Может у тебя опыт был, когда ты видел компания пришла и сказала, что нас сейчас нет этой культуры, но мы хотим, и потом ты увидел там бабочки залетали и радуга после дождя появилась?

— Тут самое главное не про сроки понять. Главное понять, что значит «поменять культуру в компании». Компанию можно представить себе как пирамидку, наверху стоит управление, то есть куда компания движется, потом, например, операционное управление, средний менеджмент, ценности компании, люди и т.д. Такая пирамидка и процессы компании где-то в серединке есть (см. статью Culture is a rubber band around your organization).

Как обычно все поступают: «Давайте меняться? Давайте. С чего начнем? С самого простого — с процессов.» И начинают двигать процессы. В этой пирамидке процессы где-то в середине и мы их немного подвигаем: были процессы такие, стали процессы другие, всё получилось, всё сработало.

Но проблема в том, что вокруг этой пирамидки есть очень тугая резинка и эта резинка называется культура. И она эту пирамидку очень плотно держит. Если сдвинуть в этой пирамидке один кубик в сторону, в лучшую сторону, в худшую сторону, без разницы, то культура аккуратненько обратно кубик задвинет. Потом, со временем, не сразу — через 2 месяца, через полгода. Она умеет ждать, она умеет постепенно задвигать.

Если прийти и прочитать тренинги про культуру, всех замотивировать, закоучить, то культура дождется определенного момента и обратно это все изменения задвинет и всё вернется в предыдущее состояние. Так всегда происходит.

Поэтому есть разные стратегии сдвига культуры. Например, можно подвигать всю пирамидку целиком, но по чуть-чуть. Можно найти самую большую часть пирамидки и начать двигать ее. Например, в компаниях, которые стали “не банком, а IT-компанией с банковской лицензией” как сказал Сбербанк, у них очень большой IT-отдел и можно при таком большом IT-отделе и такой фокусировке на IT начать со смены культуры именно в IT, а все остальные за ним подтянутся. Но в разном бизнесе по-разному, смотрите на самый большой кусок и начинаете его менять. Так как он ключевой в бизнесе, за ним все начинают меняться.

Бывает так, что какой-нибудь один отдел поменял свою культуру, остальные не поменяли. Суть в том, что если всё вокруг работает по водопадной модели, а где-то в серединке вы вставили свой Scrum или Kanban, то в целом вообще ничего не поменяется и, в итоге, вас все равно вынудят скатиться обратно на водопадную модель.

— Давай пояснять подписчикам, что такое водопадная модель.

— Это каскадная модель управления или водопад. Она похожа на водопад, потому что она ступенчатая, сверху вниз идет. Сначала у нас идет аналитика, проектирование, разработка, тестирование, внедрение. Очень простая, ложиться в голову хорошо. На заводе по производству машин она отлично работает, при строительстве домов она отлично работает, но в IT она плохо работает.

— Почему?

— Цикл нужно пройти дважды минимум, потому что ПО оно же нематериальное. Когда вы строите дом, никто не догадается предложить в конце строительства дома раздвинуть 5 и 6 этаж и поставим туда аквариум с рыбками. Так никто не делает в строительстве домов, но в разработке ПО так постоянно происходит. Почему? Потому что ПО оно не материально, оно абстрактно, его очень легко менять, а раз его легко менять, его все хотят менять. И сейчас встал вопрос о том, кто меняет его быстрее других. Сбербанк делает 40 тысяч изменений платформы в год, думали, что это много. Потом съездили в Amazon и оказалось, что те делают 10 тысяч изменений в день. Вот так. Так как ПО очень абстрактное, то кто быстрее научиться его менять и подстраиваться под рынок, тот и победил.

— А Agile это дает, да? То есть он дает…

— Agile дает определенную культуру, в которой вырастают такие люди, которые готовы делать много изменений и часто.

— А ты можешь, понятно что там 4 ценности и 12 принципов, все не перечислить, ну хотя бы 4 ценности можешь сказать, чтобы людей заинтриговать, чтобы они перешли на тот сайт, про который ты рассказал.

— Тут чем интриговать, первая ценность — люди и их взаимодействия важнее, чем инструменты и процессы. Она кажется очень простой, но есть множество нюансов. Вы сосредоточились на людях, дали им все возможности, следите за качеством коммуникации между всеми членами команды, заказчиками, стейк-холдерами, инвесторами, клиентами, пользователями. И немного всё это упорядочиваете с помощью инструментов и процессов.

— Какие инструменты, в своей компании, ты применяешь для создания правильной коммуникации, хорошей, между всеми теми сторонами, которые ты перечислил?

- Инструменты очень простые, я бы сказал элементарные. Первое — это постоянные стендапы. Что такое stand-up — встали всей командой и проговорили, 1) что сделали вчера, именно сделали, не делали как процесс, а сделали.

— Результат?

— Да, завершено. 2) Что хотим сделать сегодня, как результат. 3) Какие проблемы у нас есть, давайте подумаем как их решить. То есть все постоянно со всеми общаются, проблемы всплывают, их решают.

— Я вижу как в IT-компаниях это строится и реально ребята это стоя делают. Почему stand-up?

— Потому что стоя ты не простоишь дольше 15 минут.

— То есть по сути эта коммуникация не больше 15 минут занимает.

— В идеале, да.

— Количество людей в команде влияет на нее?

— Если все сделано грамотно, то не особо. Хороший пример, который мне нравится, я видел в Альфа-лаборатории (IT-часть Альфа-банка). У них где-то на 30-40 человек stand-up проходил за полчаса, причем часть команды удаленно. Но он был определенным образом организован.

— Мы применяем такой опыт: человек сначала отправляет в чат сообщение, что он сделал, что планирует и что ему может помешать, какие проблемы. А потом по сути зачитывает всё. Это ускоритель процесса. У тебя есть какой-то инструмент в этом или нет? Или все таки люди просто говорят.

— У меня есть статья Stand-up meeting: лучшие и худшие практики, и все сотрудники ее прочитали. Один из главных факторов успеха — к стендапу нужно готовиться.

Еще один хороший инструмент ведения проектов — это визуализация. Визуализировать нужно всё. Всё, что есть в голове нужно превращать в схемы, таблицы, в какие-то mind map’ы.

— Визуализация, ты считаешь, должна быть какая-то схема, которая понятна?

— Любая визуализация, которая может объяснить текущую ситуацию, должна быть нарисована. Вот [на столе] у нас есть даже книга National Geographic Infographics для вдохновения. Каждый сотрудник должен заниматься инфографикой на работе. Все что есть в текущий момент в голове, все связи, проекты, все мысли, которые у тебя есть, все взаимосвязи между частями проекта, исполнителями и т.д., то есть весь проект у тебя в голове, он должен быть визуализирован в схемах, в mind map’ах, в рисунках, в таблицах, как угодно.

Качество визуализации проверяется просто — смотришь и тебе понятно. Если ты смотришь и тебе не понятно — в мусорку, рисуешь заново.

Еще один инструмент — доска, на которой расположены задачи. Зачем эта доска нужна? Смотришь на доску и понимаешь, что сейчас на проекте происходит, где затык, где бутылочное горлышко, что на входе ждет, как много задач, как много сделано и т.д. Ты на доску посмотрел и все понятно, что происходит на проекте. Ты на доску посмотрел и тебе нужны комментарии о том, что происходит на проекте, значит плохая доска.

— Каким ПО пользуетесь в этом, по доскам?

— Очень разным. У нас заказчик приходит обычно с каким-то своим ПО, но из основных — Trello, YouTrek, Jira и TFS.

— Ты сказал, что недавно проводил мероприятие для руководителей банка.

— Да.

— Обучающее? Можешь сказать о чем ты говорил?

- Сначала, мы им дали ссылку на мою статью, которая называется Шпаргалка для предпринимателя по IT-миру. Мы дали им эту статью, сказали прочитайте, чтоб вы поняли как сейчас устроено IT. Они все материалы изучили, пришли и мы с ними стали обсуждать как строиться разработка в целом, как строиться взаимодействие не-IT и IT

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

Рассказывал про User Story: что такое истории использования, как они из чего они состоят и почему они сделаны именно так как сделаны. Есть статья на эту тему про кнопочное мышление, там расписано про то, что такое User Story.

Еще была техническая «как сохранить целостность IT-продукта, чтобы он не разрастался в монстра». Простой пример — это 1С, открываете и у вас от кнопок глаза разбегаются в разные стороны. Продукт не должен быть таким.

— У на есть знакомый, который 1С внедряет, это не легкий труд , я вам скажу.

— Продукт должен быть другим. Если вы делаете продукт для себя или для кого-то, естественно, не хочется чтобы он выглядел как 1С, но когда вы делаете продукт на более широкий рынок, тем более не для России, то нужно думать о UX, думать о том, как пользователь будет взаимодействовать с системой, как ему помочь, как его за руку провести через всю систему от момента получения услуги до момента оплаты.

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

— Сильно зависит от проекта. Очень сильно. Иногда это занимает пару недель, иногда это занимает несколько часов. Несколько часов занимает, если задача слишком простая, или если на первых шагах Impact Mapping заказчик понимает, что проект не имеет смысла дальше продолжать.

— А что такое Impact Mapping, можешь еще раз расшифровать?

— Impact — это влияние, Impact Mapping — это карта влияний. По сути это mind map, в корне стоит цель, которую мы хотим достичь. Дальше идут люди, или рынки, или компании, или еще какие-то сегменты, жизнь которых мы должны каким-то образом поменять, чтобы изменение жизни привело нас к цели.

— Можешь на примере каком-то привести?

— Основная ценность карты в гипотезах о том, как и за счет чего жизнь будет меняться. Допустим про молоко, давай пофантазируем. Мы хотим увеличить продажи молока, жизнь кого надо поменять и как? Для ответа этого нужно провести сегментацию рынка и, я не знаю каким образом, но мы с тобой поняли, что дети до 3х лет мало пьют молоко нашей продукции, а должны больше. Дети до 3х лет молоко сами не покупают, поэтому нужно поменять каким-то образом мировоззрение их родителей. Нужно объяснить родителям, у которых дети до 3х лет, то что молоко именно до 3х лет полезно, потому что... Ну и дальше есть какие -то критерии. Или наоборот, опасно его не пить потому что... Напугать, ну или еще какие-то приемы. И таким образом мы составляем карту гипотез, она циничная получается, но это бизнес, а что делать. Мы берем такой сегмент родителей, у которых дети до 3х лет, смотрим на гипотезы, которыми мы хотим повлиять, приоритезируем их, понимаем за какую гипотезу мы возьмемся первую, и потом разбиваем на User Story, которые нужно реализовать,чтобы эту гипотезу проверить.

Когда ты приходишь и просишь сделать тебе фичу, то мы говорим хорошо сделаем, давайте посмотрим в какую часть Impact Map она приклеивается. Если ни в какую, то может быть какие варианты — допустим этой ветки нет, такое может быть. Если ветки нет и приклеивать некуда, то значит это pet feature (фича домашний питомец), и мы понимаем, что она бизнес никак не изменит.

— Как падающий снег.

— Как падающий снег на сайте, но вот просто кто-то хочет за нее заплатить, чтобы ее сделали. Кто-то пришел посмотрел, что он падающий и говорит прям как я хотел.

— Из твоего опыта, из опыта твоих клиентов, много людей хотят как ты сказал pet feature?

— Все хотят петфичи, но когда мы рисуем эту схему и начинаем говорить о бизнес-метриках, все не хотят петфичи, потому что бизнес обычно умеет считать деньги. Покрайней мере мы работаем с тем бизнесом, который настоящий, который умеет считать деньги.

— Можешь в двух словах сказать, что увидит человек в книге [про Impact Mapping], которую мы разыграем?

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