Как мы пришли к неожиданным выводам в ходе Agile-трансформации
Можно ли самостоятельно внедрить Agile в компании, и что из этого получится? Сегодня историей освоения культуры Agile делится Олег Кияшко, технический директор компании DSSL.
Эпизод 1. Скрытая угроза роста
DSSL — отечественный разработчик систем цифрового видеонаблюдения. Скорее всего, вы не раз видели наши камеры в городах — они установлены и на Дворцовом мосту в Санкт-Петербурге, и в крупных гостиницах вроде гостиничного комплекса «Измайлово», и во многих крупных сетевых супермаркетах.
Нашей компании 15 лет, и у нас работает приблизительно 300 человек. Одно из ключевых направлений — это разработка ПО для видеонаблюдения. Сейчас у нас распределенная команда разработки, бóльшая часть которой находится в Москве, а меньшая — в Краснодаре.
Примерно пару лет назад мы столкнулись с проблемой роста. Уровень решаемых задач становился сложнее, задачи требовали взаимодействия бóльшего количества людей, а некоторые ключевые процессы замыкались всего на нескольких ответственных. В условиях распределенной команды эта ситуация «бутылочного горлышка» проявилась особенно: например, когда технический директор (являющийся таким горлышком) не может «дотянуться» до всех проблемных зон, скажем, в архитектуре. Но основной проблемой оказалась коммуникация, которая перестала работать, когда в команде стало 50+ человек, а стиль разработки оставался, как будто нас всё ещё 15. В общем, людей стало больше, а ожидаемого масштабирования и роста производительности не произошло: эффективность упала, и мы начали буксовать. Стало тяжело, но больше всего огорчало то, что дальнейший рост казался невозможным.
Эпизод 2. Scrum как новая надежда
Свет забрезжил после прочтения книги Джеффа Сазерленда о Scrum. В ней описываются очень похожие проблемы, с которыми сталкиваются компании — мы в них узнали себя, — а потом очень разумно расписывается, как можно с этими проблемами бороться. Так выглядело первое знакомство с Agile. Дальше мы стали осторожно пробовать кое-что из описанного. Таким образом, Agile у нас был сначала “самопальный”: мы не стали внедрять канонический Scrum, боясь резко перейти на новые рельсы, так как опасались навредить сами себе. Мы исходили из того, что есть некие проблемы и их можно решить с помощью отдельных практик Agile. Пробовали решать — кое-что даже работало. Например, ввели ежедневный созвон в 12:30, часть проблем ушла.
Этот самостоятельный этап продлился год, в течение которого наблюдалась положительная динамика. Однако было очевидно, что этого мало. В феврале 2017 года, преодолев себя, мы все-таки решились обратиться за помощью к консультантам, и они сняли многие барьеры и страхи в нашей голове. Например, что тратить на планирование два дня — нормально, на демонстрацию день — нормально. Это развязало руки и ускорило процесс.
Признаюсь, изначально я был полон скепсиса относительно тренеров. Со временем пришло понимание, что здесь всё примерно как в спорте: можно посмотреть 200 видеоуроков, прочитать книжку и начать тренироваться самому, но с тренером-профессионалом результат будет несравненно лучше.
Изучая рынок услуг, мы выбирали из четырех компаний. ScrumTrek среди них был не самым дешевым вариантом, но показался наиболее адекватным и самым подходящим: в данном вопросе хотелось иметь дело с компанией, схожей с нашей по масштабу и стадии развития, чтобы она так же менялась, развивалась. Варианты «гениев-одиночек» мы не рассматривали. Вариант с большой компанией тоже не особо подходил, потому что это прежде всего риск неповоротливости. Вот так выбор и пал на ScrumTrek.
Эпизод 3. Пробуждение силы
Сначала мы сделали несколько тренингов у нас в офисе. Сразу стало понятно, что мы нащупали что-то полезное, после чего провели масштабную операцию: пригласили наших ребят из Краснодара в Москву, сняли им жилье на месяц, поместили в наш офис и стали все вместе работать. Начался период интенсивного перехода от «самопального» Scrum, к тому, который рекомендуют лучшие «скрамоводы». Сперва было тяжело. Сопротивления не было, но было недоумение: казалось, это какие-то бессмысленные ритуалы, которые не ясно зачем соблюдать. А зачем эта ретроспектива в каждой команде? А что мы должны здесь делать? А почему так? Потом, когда стали видны результаты, возникло облегчение.
Основным результатом работы по Agile с февраля по декабрь 2017 стало то, что мы осознали новую проблему, которая до этого была не в фокусе. Мы думали, что для роста нам нужно увеличивать объемы разработки и налаживать процессы по поставке ценности. По факту же оказалось, что у нас все работало не самым худшим образом, и Agile-трансформация вписалась весьма органично — самым главным изменением стали регулярные демонстрации и планомерные итерации. До этого у нас были робкие попытки делать и планирование, и ретроспективы, а консультанты убедили, что на это нужно смело тратить больше времени. Теперь разработчики чувствуют ответственность в конце каждой итерации.
Новой главной проблемой оказался процесс поставки новых задач в разработку, которому раньше не уделялось достаточно внимания. Его было сложно «перезапустить». На самом деле, он до сих пор не завершен. И это главная наша цель на ближайшее время — наладить процесс доставки новых задач, сформированных требованиями рынка, формулировать идеи для продукта на основе реальных запросов. И, конечно, научиться отслеживать удовлетворенность потребителя после внедрения этих идей в продукт.
Я работаю на рынке видеонаблюдения больше 15 лет. За все это время я твердо усвоил, откуда нужно брать качественные идеи: чувствуй рынок и слушай своего клиента. Рынок всегда прав, клиент всегда прав. Наша задача — усилить продукт за счет этих идей, сохранив при этом его целостность. Пока что у нас нет налаженной машины по сбору данных с рынка. Поэтому наш приоритет в новом году — внимание к рынку как к источнику новых идей и настройка эффективного канала обратной связи с потребителем, чтобы получать четкое видение продукта, который решает вопросы клиента. Это новые правила игры, о которых мы договорились совсем недавно и которые положили в основу дальнейшего развития, изменив критерии отбора задач в команду Discovery (нашу исследовательскую продуктовую команду), поставляющую новые задачи разработке.
Эпилог
Сейчас мы понимаем, что это нормальный путь — последовательно настраивать сначала процессы разработки и поставки ценности, а потом Discovery, а не наоборот, иначе идеи не будут реализованы. Хорошо, что мы осознали это, хоть и спустя столько времени. Когда мы усовершенствовали разработку, можно фигурально сказать, что был решён вопрос с «кровообращением нижних конечностей»: теперь бегаем мы хорошо, но не всегда правильно и в нужном направлении. Осталось решить вопрос с «кровообращением мозга» — и это откроет нам путь в светлое будущее.