Часто бывает, казалось бы: сплоченный коллектив профессионалов, сильный и качественный продукт на подходе, толстая инвестиционная подушка финансовой безопасности, а что-то не так. Причем, с каждой неделей этих «что-то» становится все больше и больше. Сотрудники нервничают, огромное количество работы проходит в режиме овертайм, постоянные сбои во внутренних коммуникациях, поиск ответственных и виноватых – у победы много отцов, поражение – всегда сирота. Такой деструктивный сценарий развития студии – медленный, но верный путь к завершению её деятельности. Но мы же не просто так собрались несколько месяцев назад?
Большое количество стартапов «сходят с дистанции» именно из-за того, что в какой-то момент не могут правильно спланировать и проконтролировать своё масштабирование. Любая организация, как живой организм. Отсутствие развития прямо свидетельствует про медленное, но верное умирание. Парадокс заключается в том, что бурный и неконтролируемый рост может привести к обратному от желаемого результату. Через некоторое время компания становится колоссом на глиняных ногах. Ощущение, что все может рухнуть от малейшего дуновения ветерка, изменения конъюнктуры рынка или еще каких-либо глобальных процессов оптимизма совершенно не добавляет. Нервозность, стресс, склоки, падение продуктивности как следствие.
В этой статье мы попробуем описать наш опыт преодоления подобного рода ситуации. Это было чертовски не просто, но мы с этим справились.
История
Компания Room 8 появилась весной 2012 года. Классика жанра. Огромное желание создавать игры для мобильных устройств сплотило нескольких единомышленников, у каждого из которых совершенно не было опыта, связанного с индустрией, в которой вновь созданная компания собиралась осуществлять свою деятельность.
Бизнес-модель предполагала построение полноценной студии разработки игр. В планах было выпускать 5-6 высококачественных игр в год. Бурный рост индустрии мобильных игр вселял надежду на то, что основные риски сбалансированы, а потенциал для дальнейшего роста и развития высок. В совокупности, оба этих фактора привлекли внимание венчурной компании VostokVentures и студия Room 8 договорилась про инвестиционную поддержку.
После получения инвестиций студия начинает бурно расти. Существенно усиливаются департаменты разработки, тестирования, дизайна, геймдизайна и маркетинга. Всего за два месяца штат вырастает с 7 до 30 человек. Еще через три месяца студия насчитывает уже 60 сотрудников. По прошествии пяти месяцев с момента основания компания представляла собой пестрый букет разношёрстной команды с огромным количеством вновь выявленных проблем.
Пожары
Как мы упоминали выше, бурный рост привел к ряду глобальных проблем, каждую из которых тщетно пытался решить в одиночку тот или иной сотрудник. Помимо (решаемых) проблем с разработкой, «горели» еще и вопросы управления. Исторически сложилось, что функция управления проектом была возложена на GameDesigner’а, которому приходилось ее совмещать с основной своей деятельностью – развитием продукта с точки зрения геймдизайна. Координирующим действиям группы учредителей мешала неслаженность, отсутствие опыта и неумение управлять ожиданиями друг друга. Усугублялось все это перегруженностью овертаймами и коммуникационными проблемами. В то время организационная структура выглядела примерно вот так:
Типичная картинка для одного проекта
Попробуем разобраться в недостатках такой структуры:
- Полномочия и ответственность. С одной стороны, на геймдизайнере лежит личная ответственность за создаваемую игру. С другой стороны, полномочия управлять членами проектной команды есть и у директоров. На практике оказывается, что свобода в принятии решений у геймдиза ограниченна. Такое положение вещей приводит к размытию ответственности – в любые «горячие» обсуждения рано или поздно вовлекался один из директоров.
- Доступность и коммуникации. Схема сложна также тем, что в управление проектом вовлечено большое количество людей, многие из которых участвуют сразу в нескольких проектах.
- Конфликт интересов. Геймдизайнер совмещал продуктовую ответственность (нужно же создать самый лучший продукт!) и проектную (постоянный поиск оптимальных путей создания продукта). Таким образом, геймдизайнер находился в перманентном состоянии внутреннего противоречия. С одной стороны, качество и чувство прекрасного, а с другой – сроки, дедлайны и рентабельность.
- Ошибки в расстановке приоритетов. Быстро выросшая структура сложна в управлении. Зачастую разнонаправленное давление на геймдизайнера исподволь приводило его к противоречивым решениям. То, как себе представлял продукт геймдизайнер, часто отличалось от картины мира других участников проекта. Отсюда сбои в коммуникациях, конфликты и огромное количество отрицательного фидбека.
Надо отметить, что одно характерное свойство (пусть и быстро выросшего) стартапа все же сыграло на нашей стороне. Мы имеем ввиду гибкость. Да, ремонт и обновление структуры компании занял почти полгода. Да, приходилось преодолевать проблемы его участников. Договариваться, идти на компромиссы и снова договариваться. Но в данный момент мы намного больше похожи на отлаженный и целостный механизм, работающий по agile принципам, чем пару сотен дней назад. Хочется верить, что все пертурбации последних шести месяцев позволят нам выпускать еще более качественные продукты. Но обо всем по порядку.
Как мы потушили пожар
Будучи участником процесса, крайне сложно влиять на его принципы и его логику. Риск самостоятельного изменения системы управления очень велик. Если с самого начала руководством компании были допущены ошибки в организации системы управления, то где гарантия того, что проделав большую и серьёзную работу над ошибками, мы не получим аналогичный результат?
Для снижения этого риска, мы пошли на несколько нетипичный для множества отечественных стартапов шаг. А именно, был приглашен человек из вне. Знание принципов построения системы управления в совокупности с позицией этого специалиста «над» процессами, вселяло определенные надежды. Мы были полностью открыты для любых идей и предложений, и эти идеи были озвучены. Фактически, мы инвестировали в укрепление собственной организации, а после утилизации стартапного энтузиазма у студии открылось второе дыхание.
Кто этот человек со стороны?
Бытует заблуждение, что венчурные компании ничего не дают стартапу, кроме денег. Это совсем не так, хотя бы потому, что деньги не «дают», а «инвестируют». Наши «бизнес-ангелы», разумеется, были совершенно не заинтересованы в том, чтобы мы через какое-то время загнулись. Экспертные советы, контактные данные возможных бизнес-консультантов, моральная поддержка – все это мы сполна получили от нашего венчурного инвестора.
Что же мы сделали?
Начали мы сверху — с Совета Директоров. Были определены приоритеты в важности того или иного проекта, пересмотрены объемы ресурсов, которые мы готовы направлять. На картинке это выглядит примерно так:
Приоритеты проектов определялись в зависимости от перспективности. Естественно, все не может быть самым важным. Бритвой Оккама выступает простой вопрос: “если у нас есть возможность сделать только одну игру, то какую мы выберем для разработки?” Выбор, надо отметить, так себе. Кто из моих детей будет сегодня ужинать? Жестко, не комфортно, но необходимо.
Распределение ресурсов. После сложной расстановки акцентов среди действующих проектов, произошло распределение ресурсов. Ясно, что более важные проекты должны получать самых сильных людей в команду и, конечно же, больше внимания. После введения этого нехитрого принципа, завершилась постоянная практика ежедневного перераспределения персонала. Все хватались не за самый важный проект, а за тот, который горел ярче всех.
После наведения порядка “наверху”, следующим шагом стало внедрение SCRUM. В рамках первой волны, мы внедрили только некоторые элементы этой системы. Те элементы, которые должны были привести к желаемому результату максимально быстро. Речь идет о daily standups и iteration demo.
Daily Standups. Каждый день проектная команда собиралась, и каждый отвечал на три простых вопроса: Что сделал вчера? (гордость), С какими проблемами столкнулся? (просьба помощи), Что сделаешь сегодня? (обещание) Это простое нововведение помогло командам повысить эффективность общения. Пусть не сразу прижился Scrum Board, но стендапы заметно повысили координацию и понимание проекта. Например, вдруг пришло осознание, что узнать про отставание от сроков можно не в пятницу вечером, а во вторник утром.
Iteration Demo наглядно демонстрирует, в каком состоянии находятся этапы и компоненты разрабатываемого продукта. Введение этого элемента позволило наладить коммуникацию на уровне команда — руководство. Вовлеченность в проект и информированность о его состоянии значительно увеличило прозрачность и, тем самым, снизило общую нервозность.
Почему проблемы возникают снова?
По прошествии первых трех месяцев работы студии, мы обнаружили, что часто уже решенные проблемы появляются вновь. Причем, аналогичные проблемы могли возникать как и у одних и тех же людей, так и на разных проектах. Причина оказалась весьма тривиальна: рваное внимание к тому или иному проекту затормаживало развитие каждого из них. Хоть и небольшая, но незапланированная пауза в развитие проекта, – четкий шаг назад.
Поиск инструмента, который позволил бы поддерживать процесс постоянного развития, не занял много времени. Прежде всего, мы хотели выйти на другой уровень планирования. Решили апробировать практику итеративного обеспечения качества функционирования компании. Выглядит это так:
1. Группой директоров вырабатывается набор качественных критериев для каждого отдела (инжениринг, тестирование, арт, геймдизайн), соблюдение которых, по умолчанию, определяет весь процесс работы качественным и эффективным. Критерии могут выглядеть примерно вот так:
Engineering: Coding Style, Code Review, Refactoring
Testing: Co-Location with Engineering team, Test Cases, Defect Metrics, Feature Metrics
Art: design repository… и т.д.
2. Затем, раз в месяц, проходит процесс оценки каждого проекта по выработанным критериям. Качественно-численные метрики выглядят примерно так:
Или вот так, если вас интересуют детали:
3. Дальше руководители отделов анализируют полученную картинку действительности. В первую очередь – красные зоны в проблемных проектах. Анализ должен дать ответы на два главных вопроса: почему так произошло и что нужно предпринять, чтобы картинка изменилась к следующей встрече.
4. Через 1-2 месяца картинка, описывающая происходящее, стабилизируется. То есть почти все компоненты проектов постепенно переходят в зеленую зону. Это вовсе не означает, что теперь все будет хорошо (проект-то развивается!), просто настала пора вырабатывать новые критерии и повторять шаги 1-3, фактически загоняя проекты в красную зону.
Смысл этого инструмента не в том, чтобы график всегда был зеленым, а в том, чтобы компания развивалась без всяких “пинков” со стороны, используя лишь внутренние ресурсы.
Как не переусердствовать с бизнес анализом
Была попытка улучшить ситуацию с управлением проектами, внедрив систему SCRUM. Но чем больше мы “напирали” на эту систему, тем хуже становилось с геймдизайном. И наоборот, когда получался геймдизайн, проседало соответствие принципам SCRUM. В результате небольшого анализа была выявлена главная причина конфликта SCRUM vs GameDesign — ей оказался все тот же внутренний конфликт интересов сотрудника, совмещавшего функционалы руководителя проекта и геймдизайнера. Единственный выход, как мы решили – изменение организационной структуры. В частности, с геймдизайнеров волевым решением были сняты все управленческие функции — пусть занимаются тем, что у них получается лучше всего, – думали мы. Но кто-то управлять проектом-то должен? Для управления в каждый проект был внедрена новая роль – проектный координатор.
В результате получили вот такую структуру:
Заключение. Мы изобрели Lean Management
Преодолев путь по внедрению SCRUM, мы нашли решения всех тех проблем, которые стояли перед компанией год назад. Причем сложности возникали не только в процессе преодоления, а и в вопросах выбора направления движения. Естественно, мы полностью отдаём себе отчет, что развитие компании — штука непрерывная. Нельзя проснуться однажды, сказать :«Все. Моя компания развилась». Мы понимаем, что путей и развилок нам предстоит пройти бесчисленное количество, но, как говориться, «Дорогу осилит идущий». Мы продолжим искать новые проблемы, формулировать их описания, искать методы их решения и улучшать все, что не улучшено.
Ответ на вопрос, в каком состоянии находится компания, лежит не в оценке идеальности процессов, а в способности их быстро менять в контексте изменяющейся обстановки в индустрии и на рынке в целом. Действовать иначе не получится. Нужно постоянно искать и находить то, что помогает не только выживать стартапам, а и превращаться им в современный, молодой по духу и эффективный бизнес.
Автор: Room_8
