В декабре в ScrumTrek поступил заказ от стартапа AviaSales.Ru. Компания занимается подбором и продажей дешевых авиабилетов. А базируются они в Таиланде на острове Пхукет, в удобной вилле, переоборудованной под офис, на берегу моря. Куда я и приехал.
AviaSales столкнулись с достаточно типичной проблемой для развитых стартапов — набираются всё новые и новые сотрудники, но скорость разработки при этом растёт незначительно.
Весь первый день просидели вместе с руководством и тим-лидерами в переговорке. Проанализировав следствия и причины, сошлись на том, что не смотря на то, что видимые причины одни, на самом деле первопричинами проблем c падением скорости является отсутствие структурированности коммуникаций.
С одной стороны все сидят в одном помещении и постоянно неформально общаются, что, действительно, очень благотворно для разработки. А с другой стороны нет эффективных коммуникаций — видение продукта теряется на пути от владельца к разработчикам, владельцам непонятны сроки, а разработчикам приоритеты работ, и отсутствуют ретроспективы для совершенствования процесса.
В то же время в компании есть очевидные и несомненные преимущества: налаженная система continuous integration, активно используемое юнит-тестирование, и великолепно технически подкованная команада, уже работающая с итерациями всего в неделю длиной.
Решили, что в их случае правильно будет внедрение Kanban с его плавным потоком выпуска продукта, как нельзя лучше использующим наработанные технологические преимущества. Но путь к нему решили проложить через Scrumban, так как для начала требовалась дисциплина проведения совещаний и чёткий ритм работы. Для стартапов такая схема работает хорошо: переход от неформального неструктурированного "сложившегося" процесса лучше осуществляется, через сначала небольшое "перекручивание гаек" — внедрение процесса более структурированного, такого как Scrum или Scrumban, с последующим их ослаблением через 4-6 месяцев к менее структурированному, но требующему больше внутренней дисциплины Kanban.
Для решения проблемы потери видения продукта за множеством мелких задач пришлась техника Story Mapping. Так как большие фичи имеющие бизнес-ценность плохо ложились на короткие итерации в неделю и нужна была система, позволяющая с одной стороны разбить фичу на понятные задачи в пределах итерации, а с другой — не потерять за деревьями леса — и держать в поле зрения окончательную цель, ради которой делаются эти задачи.
Но самое главное, что нужно было сделать, это реструктурировать четыре команды, работающие над четыремя модулями двух продуктов, в две команды, работающие каждая над одним продуктом, но зато в целом. Ранее ни одна из 4-х команд не могла сама полностью сделать новую фичу продукта, за исключением фич, затрагивающих только один модуль, и команды, делая один продукт, очень слабо взаимодействовали при планировании данного продукта — фактически только на уровне тимлидов. Типичная красивая система каждой команде свой модуль, так привлекающая сторонников теории: "дай всем программистам по задаче, а потом собери результат", на деле имела все присущие ей недостатки. Поэтому от неё успешно перешли к системе "команда делает продукт в целом".
В следующие два дня я провёл тренинг по обучению команды техникам Kanban и Storym Mapping, мы разделили команды, выбрали Scrum Master'ов и Product Owner'ов.
Должен сказать, что команда очень приятная. Целеориентированный директор, Константин, чётко расставляющий приоритеты, и в то же время понимающий особенности разработки ПО. Отличные технические лидеры, многие из которых сами и внедряли такие чудесные методики как CI и unit-tests. Так что работа спорилась.
Был на тренинге и свой гвоздь программы. В одном из упражнений в процессе тренинга мы в ScrumTrek обычно используем шарики или кубики. А вот удобных кубиков или шариков в магазинах Таиланда не оказалось, зато были чудесные пластмассовые уточки по демократичной цене. Которых я и купил. Уточки произвели фурор :) И теперь купаются вместе с программистами в бассейне на вилле :)
Успешной работы, AviaSales!
