Меня зовут Валерий Студенников, я программист, и вершиной моей IT-карьеры стала компания REG.RU, где я был сооснователем, техническим директором и руководителем разработки.

За 10 лет REG.RU стала №1 в России по количеству зарегистрированных доменных имен, а затем вошла в тройку лидеров по web-хостингу и VPS. В 2021 году мы с партнером продали компанию, я ушел «на пенсию» и с тех пор занимаюсь преподаванием в Самарском университете, обучая студентов различным IT-предметам.

Именно в REG.RU я стал активно применять гибкие методологии и впервые столкнулся с Kaiten, и так получилось, что и то и другое забрал с собой и сейчас использую в преподавательской деятельности. Собственно, об этом и хочу рассказать.

Рост компании и «аджайлизация» REG.RU: от баг-трекера к Канбану

С начала основания REG.RU нам нужен был какой-то инструмент для организации задач. Бюджеты были поначалу небольшие, поэтому тратить их на платные инструменты типа Jira не хотелось. Тогда я решил пойти оригинальным путем — использовать бесплатный баг-трекер Mantis (mantisbt.org), написанный на PHP. 

Хотя этот инструмент изначально и не был предназначен для управления задачами, нам удалось его как-то настроить и приспособить для этой цели. Главными его преимуществами были:

• легковесность,

• быстрая скорость работы,

• интуитивно понятный интерфейс.

Более того, мой партнер и генеральный директор REG.RU был в тот момент настолько очарован Mantis, что решил использовать его и в другом своем бизнесе — веб-студии «ЦЭТИС». Они даже выделили отдельного разработчика, чтобы он переработал Mantis под их цели и задачи, и в итоге выстроили весь свой workflow вокруг этого инструмента.

Мы серьёзно допиливали Mantis под свои нужды: добавили поддержку родительских / дочерних задач, «формулы» для приоритизации задач на основе каких-то «объективных» критериев, а не чьего-то субъективного мнения. Даже начали делать в виде стороннего web-приложения визуальную доску, в которой бы задачи из Mantis визуализировались в виде карточек.

Однако шло время, REG.RU рос, а вместе с ним и объем задач, количество программистов и отделов в компании. В какой-то момент разработка начала буксовать, не поспевая за новыми хотелками внутренних заказчиков и быстро меняющимся бизнесом.

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

• вездесущие дедлайны. А приоритет в выставлении дедлайнов, естественно, имели те отделы и руководители, у которых был больше «административный ресурс»;

• «Список Шиндлера» — так мы назвали приоритетный пул задач, который периодически утверждался высшим руководством. Понятно, что все внутренние заказчики хотели в него попасть, но не все могли. А вне этого «белого списка» начала выполнения задач можно было ждать очень долго.

Шёл 2017 год и нужно было что-то менять в нашей работе. После того как несколько руководителей съездили на Agile Days (до этого там бывал только я один), всем стало понятно, что нужно «аджайлизироваться». Также мы решили наладить полноценную работу с продуктом. Так у нас появился продуктовый отдел и несколько product-менеджеров по разным субпродуктам: домены, хостинг, внутренние инструменты для поддержки и прочие.

Решено было внедрять Agile-процессы разработки. Тогда начиналась (а для кого-то уже продолжалась) мода на Scrum, и начали активно работать компании вроде ScrumTrek, которые помогали внедрять компаниям эту методологию разработки.

Мы также с помощью внешних консультантов запустили несколько Scrum-команд: «Новый Личный Кабинет», «Новое рабочее место для сотрудников техподдержки», а потом, через какое-то время и другие команды: «Облачные VPS» и «Cloud GPU».

Однако Scrum всё-таки больше подходит именно для новых продуктов, когда «всё новое и ничего не понятно». Основное же количество команд разработки делали уже зрелый функционал, а для этого Scrum подходил плохо.

Для основной массы команд, (а впоследствии также вообще для всех отделов компании, включая HR, PR и маркетинг, админов и др.), мы решили использовать процесс Kanban (хотя, строго говоря, Kanban — это не процесс, а «метод улучшения процесса»).

Kanban универсален, подходит практически для любых команд и видов деятельности (не только для разработки ПО) и позволяет оптимизировать почти любой процесс. При этом, что важно, Kanban можно внедрять пошагово и эволюционно, в отличие от Scrum, внедрение которого — это всегда «революция».

Здесь-то нам и понадобился инструмент для онлайн-досок под Kanban. На тот момент несколько наших команд уже работали по Scrum, и в компании начал разрастаться целый «зоопарк» таск-менеджеров, включая переделанный Mantis, Jira и другие инструменты.

Мы пересмотрели целый ряд популярных популярных вариантов, но они не вполне удовлетворяли нашим требованиям, — плохо поддерживали Kanban. Jira на тот момент был очень перегруженным с точки зрения UI, достаточно дорогим и весьма далеким от Kanban. Или, например, SwiftKanban — это, формально, инструмент для Kanban, но, цитирую одного из сотрудников: «максимально убогий, выглядел хуже чем Mantis» (на тот момент, возможно сейчас все стало лучше).

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

В результате Kaiten обошёлся нам на порядок дешевле, чем продукты-конкуренты, при том, что его функциональность для Kanban была на голову выше (в частности, большое количество полезных графиков и статистики).

И вот начался масштабный переезд на Kaiten.

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

Разумеется, вначале было несладко, инструмент сильно тормозил под нашей нагрузкой, учитывая, что практически ВСЕ отделы (кроме разве что бухгалтерии) перешли на эту онлайн-платформу.

Однако за несколько месяцев очень плотного взаимодействия с разработчиками Kaiten, все «детские болезни» были излечены, да и мы наконец научились эффективно использовать этот инструмент.

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

В конце концов всё получилось и REG.RU плотно «подсела» на гибкие методологии в целом и на Kanban и Kaiten в частности. Работа всех отделов, включая разработку, была значительно упорядочена, у всех продуктов, как внутренних так и внешних, появились продакт-менеджеры, понятные приоритизированные списки задач и прозрачные критерии взятия инициатив в работу.

Хэппи энд. А дальше — вторая серия.

Активная пенсия и Самарский университет

Осенью 2021 года мы с моим партнером Алексеем Королюком продали компанию новым владельцам. Алексей Королюк занялся несколькими новыми проектами и написал пару книг.

Я же решил временно отдохнуть от разработки и реализовать «социальную миссию» в области образования в родном Самарском университете, откуда сам выпустился в 2001 году. В то время уровень обучения программированию в нем был невысок и я дал себе слово, что когда-нибудь вернусь сюда в качестве преподавателя, чтобы улучшить эту ситуацию. 

Я создал несколько авторских курсов для университета еще до 2021 года. А после продажи компании я решил погрузиться в преподавание более основательно. В 2022 году мне предложили создать курс по управлению разработкой ПО. Я согласился. Мотивацией было, в том числе, самому лучше разобраться в этом предмете, подытожив свой опыт руководства разработкой в REG.RU. Чтобы дополнительно прокачаться, я прошел пару профильных курсов: по Kanban от Neogenda и по управлению командой от «Стратоплана».

Я сам себя считаю практиком, а не теоретиком. Лучше всего учиться любому делу в реальных условиях — относительно небольшой объем теории и максимум опыта с настоящими проектами. Именно так я решил построить свой курс «Управление разработкой ПО». 

В рамках курса студенты должны разбиться на команды, выбрать себе любой IT-проект на базе любых технологий, которые им интересны, и в течение семестра работать командой над этим продуктом, используя различные методологии и практики разработки: Scrum и Kanban. Также в курсе есть большой блок теории и практики по «Управлению продуктом», включая несколько командных заданий, связанных с продуктовой разработкой: исследования, CJM, продуктовые метрики, unit-экономика, Lean Canvas и т. п.

Судя по анонимным опросам после прохождения каждого потока, курс хорошо заходит студентам, некоторые пишут, что «это был самый полезный предмет за всё время». На базе этого курса мы также создали цифровую кафедру «Управление IT-проектами», чтобы курс могли пройти вообще все желающие студенты, не только IT-направлений. В результате за 3 года его закончили уже несколько сот человек.

Что особенно радует, по итогам этого курса студенты получают достаточно весомую строчку в свое будущее резюме. Их обучение на реальных проектах можно почти приравнять к работе в компании в течение полугода, и это дает достаточно много «очков опыта».

Причем тут Kaiten?

А Kaiten-то как раз играет одну из первых скрипок в обучении в рамках этого курса. Поскольку он прекрасно подходит как для Scrum, так и для Kanban и в процессе работы почти все студенты пользуются именно этой доской:

• Сначала студенты работают по процессу Scrum, и в Kaiten есть весь необходимый для этого набор функций, включая Velocity Chart и Burndown Chart.

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

Хотя я никак не ограничиваю студентов в инструментах и они могут использовать любые другие онлайн-доски, каждый семестр происходит одно и то же: после переключения процессов со Scrum на Kanban какая-то из команд, которая НЕ использует Kaiten, пишет: «Ой, а мы не можем провести ревью сервиса, выполнить такие-то задания, в нашем инструменте отсутствуют нужные графики и аналитика». 

Остается каждый раз разводить руками и писать: «Я же говорил, что для Kanban лучше подходит Kaiten, вы бы для начала проверили, что в вашем инструменте есть необходимый функционал»... )))

Призыв к действию

Говорят, в любой хорошей статье, кроме чисто аналитических, должен быть «Call to action». Так вот: «Используйте Kaiten!» ;)

Во-первых, он прекрасно подходит как для Scrum, так и для Kanban.

Во-вторых, с точки зрения полноты инструментария в рамках Kanban ему практически нет равных. Почти все известные нам онлайн-доски создавались либо как «Приоритизированный список задач», либо как доска для Scrum, куда позже добавились функции для Kanban. Kaiten же изначально создавался как мощный инструмент для работы по Kanban. Особенно это касается наличия различных графиков и аналитики досок, что очень важно для оптимизации вашего Kanban-процесса.

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

И, что не менее важно, руководство Kaiten достаточно гибкое (как и гибкие методологии), открыто для диалога и готово идти навстречу своим клиентам, реализуя их пожелания.

Так что используйте Kaiten как в коммерческих проектах, так и в учебных целях.