Алексей Макин, Максим Волошин.
«Принципы управления ИТ-компанией в условиях интенсивного роста и развития».
Меня зовут Макин Алексей, я один из руководителей компании Redmadrobot. Наш доклад будет состоять из двух частей, первую часть сделаю я, а вторую сделает мой партнёр, Цель доклада больше отчётная, мы хотели выложить результат нашей работы за три года в рамках развития компании, которой мы занимаемся. С некоторого времени нам очень активно помогает Андрей Георгиевич, поэтому, в том числе, это и его заслуга тоже.
Мы активно использовали СМД-методологию и другой инструментарий, который мы на разных участках жизненного пути смогли получить. Хотим показать, как это работает на практике в нашей сфере.
Но в первую очередь пара слов о компании. Мы существуем с 2008 года, компания специализируется на разработке мобильных приложений по большей части в сфере финансов и телекома.
За те три года, которые мы активно занимаемся развитием компании, мы смогли добиться позиции номер один в России во всех отраслевых рейтингах, так и стать top-of-mind среди технологических компаний. Также мы уже вошли сейчас в 50 лучших компаний в мире, и, я думаю, очень быстро будем подниматься по этому списку вверх. Также мы смогли увеличить оборот компании в 10 раз за 3 года.
Муж14. В последней десятке очень тяжело подниматься.
Макин. Да. В России мы смогли это сделать, я думаю, что сможем и в мире. На данный момент в компании около 100 сотрудников, штат вырос в 7 раз за 3 года, три с половиной года назад нас было чуть больше 10. Сейчас я расскажу, за счёт чего мы этого достигали и какой инструментарий использовали.
Прежде всего, мы использовали базовый инструментарий. Мы смотрели на то, каким объектом мы управляем, использовали инструментарий шагов развития и многое другое для того, чтобы – первое – регулярно проектировать то, как нам надо развиваться, куда идти и какими стать. Второе: мы регулярно проводили ревизии того, в каком состоянии находится компания и чего нам не хватает для того, чтобы получать конкурентные преимущества, лидерство в отрасли и целевые показатели.
В результате мы выделили большой список технологий, которые нам необходимо было транслировать в компанию. Нам пришлось перенести эти технологии как из сферы IT, так и из смежных сфер. Список у нас сейчас выглядит полным, но вначале мы очень многие технологи даже не видели.
Мы не будем подробно обсуждать все технологии, я покажу только несколько примеров, в которых мы сделали самый серьёзный прорыв. Когда мы анализировали, какими технологиями мышления пользуются в IT-отрасли, оказалось, что в некоторых местах IT находится на передовом крае, а в некоторых местах оказалось, что отрасль довольно незрелая. Из-за этого нам пришлось технологии мышления транслировать из смежных отраслей, и даже некоторые из них проектировать и внедрять самим.
Стратегия - это один из важнейших инструментов, который мы смогли транслировать из промышленности, в том числе из опыта тех людей, которые нам помогали развиваться. Это использование инструментов стратегического управления для развития компании. Есть ещё один инструмент - совет директоров. Как оказалось, в крупных компаниях это очень банальные инструменты, которыми пользуются все, но в маленьких компаниях в России и даже, в принципе, в мире этот инструментарий совершенно не освоен. И как только мы внедрили этот инструмент у себя в компании, то сразу стало понятно, что у нас появляются очень серьёзные конкурентные преимущества по сравнению с другими компаниями в нашей отрасли.
Второй инструмент, вторая технология, которую мы перенесли из других отраслей – это управление коммуникациями, скажем так, управление коммуникациями с целью обеспечения сбыта. Эта технология была перенята нами из медиа-сферы, по большей части именно из международной, и её применение дало нам просто поразительный эффект по сравнению с другими компаниями.
И есть ещё часть технологий, которые по факту в мире ещё не до конца опробованы и просто высказываются некоторыми авторами как гипотезы. Есть такое смешное слово «метод тыквы», но я хотел вам проиллюстрировать, что на примере таких технологий мы проводим эксперименты в том числе и с некоторыми, идеями или гипотезами, которые ещё не получили мировое признание, но применение этих технологий уже даёт значительный эффект.
Возьмем, к примеру, конкретно «метод тыквы», ещё раз повторюсь, смешное название, но это очень радикальная идея, которая высказывается некоторым количеством предпринимателей в мире, идёт вразрез со стандартами и привычками общепринятых маркетинговых стратегий. Согласно этому методу вместо диверсификации и расширения продуктовых линеек, расширения типов рынков, наоборот, применяется концентрация, приоритизация и отрезание менее эффективных или менее перспективных направлений. Проведённый нами два года назад эксперимент показал отличный результат.
Некоторые технологии мы заимствовали, в том числе и в компаниях типа «Генериум», например технологии по запуску новых продуктов. Мы в течение двух лет обсуждаем технологии работ на совместных собраниях в рамках МШУ. Мы адаптировали и начали применять у себя элементы их технологии, что позволило нам сильно увеличить эффективность запуска продуктов.
Все те технологии, которые я показывал сейчас, – это технологии, которые в IT развиты не так хорошо, как в других отраслях. Можно говорить, например, о биотехнологических компаниях, у них конверсия или эффективность запуска продуктов на порядок выше, чем сейчас наблюдается в IT-отрасли, в том числе и в стартапах, о которых только что говорили. Как ни странно, биотехнологические стартапы, они на порядок эффективнее, чем IT, только за счёт применения более правильных управленческих технологий.
Есть классические технологии управления, в том числе финансового управления. Их освоение не требует особого труда, потому что они применяются везде в мире и в России довольно хорошо. Сейчас будет раскрыта вторая часть технологий, которые в IT наоборот оказались сильно развитыми и более передовыми, чем в других отраслях, о них расскажет Максим.
Волошин. Я, наверное, прежде всего расскажу про стандарты. Начну с CMMI (Capability Maturity Model Integration), хотя это скорее не стандарт, а методология. Собственно, в нашей отрасли, в IT, для того, чтобы вообще внедрять и осуществлять трансфер технологий, нужно иметь некий каркас для того, чтобы эти технологии можно было туда закладывать. И если для какого-нибудь там, например, молочного завода это стандартизация по ISO, и она вполне работает, то в IT это работает очень ограниченно.
В 1980 году, в США, на базе института Карнеги-Меллона в SEI (Software Engineering Institute), была разработана модель CMM, которая позволяла работать внутри IT-компании и выстраивать там процессы зрелости и понимания того, как они должны быть устроены для того, чтобы в компанию можно было внедрять дополнительные технологии, уже соответствующие их деятельности. Как мы видим, здесь точно так же присутствует гейтовая система, есть пять уровней зрелости, и переход с каждого уровня зрелости подразумевает наличие определённых вещей.
Если смотреть на эти уровни, то на первом уровне процесс, он такой достаточно хаотичный, то есть что-то получается, мы получаем какой-то результат, но он не всегда повторяемый. На втором уровне можно уже достичь повторяемости на уровне проектов. Третий уровень подразумевает зрелость уже на уровне процессов организации, на четвёртом уровне находится уже управление компанией на уровне метрик, которые собираются внутри. И пятый уровень, самый высокий, позволяет компании системно и периодически обновляться, модифицировать свои процессы, раз в полгода или раз в год в зависимости от того, в какой отрасли компания работает.
В нашем случае, в мобильных решениях нам приходится делать это обновление ещё чаще, просто потому, что отрасль развивается так быстро. Вплоть до того, что каждые полгода выходит новая мобильная операционная система, новые устройства и так далее, и нам нужно за этим следить и адекватно реагировать. Также, есть требования рынка к партнерам, например, если мы говорим про разработку программного обеспечения для таких компаний, как Boeing, для этого нужно иметь уровень зрелости 5 по CMMI, иначе просто не получится заключить с ними контракт. То есть это такой, с одной стороны, стандарт в отрасли, а, с другой стороны, это каркас, в который можно закладывать другие технологии.
Одна из важных технологий, трансфер которой нам также пришлось осуществить, это система управления проектами. В Redmadrobot вся работа проектная, то есть мы, с одной стороны, выполняем проекты для клиентов, когда мы разрабатываем на заказ для них программные продукты, с другой стороны, мы разрабатываем собственные продукты и решения. Это всегда проектный подход, и в рамках управления этим проектным подходом точно так же в США, начиная с 96-го года, Project Management Institute разрабатывает свод знаний, который называется PMBoK (Project Management Body of Knowledge), наверное, он многим вам знаком.
PMBoK включает в себя 10 основных областей знаний, которые нужно знать управленцам, то есть тем людям, кто управляют проектами, для того, чтобы делать эти проекты качественно и в срок. Понятно, что это скорее такой большой справочник и, отчасти стандарт. Мы его обогатили собственным опытом и своей спецификой, но он прекрасно ложится в модель CMMI, то есть встаёт таким модулем, который позволяет нам выполнять проекты в соответствии с планом.
Есть ещё одна базовая технология, трансфер которой мы осуществили. То, о чём уже говорили, - принципы Toyota Production System и вообще принцип бережливого производства. В IT он также работает, правда с некоторыми изменениями. Это, в том числе и известная многим гибкая разработка - agile, которая позволяет двигаться короткими итерациями, за счёт которых позволяет сократить количество НЗП (незавершённого производства), и выдавать продукт с минимальным time to market.
Это, в том числе, и развитие концепции minimum value и её продолжение как MVP (minimum viable product), тот продукт, который мы можем сделать достаточно быстро, выпустить его на рынок, проверить, получить обратную связь, доработать, опять пустить на рынок, опять доработать, вот это как раз и есть технология гибкой разработки. И в отличие от классического waterfall-подхода, большого и неповоротливого, она помогает двигаться как в новых проектах и в их развитии, так и в собственных продуктах. То есть это такая ещё одна технология, которая ложится в каркас концепции CMMI.
У нас такая сфера, что всё то, что мы делаем – это продукты интеллектуальной деятельности наших работников, по западной терминологии – company of knowledge workers. И для работы с такими людьми нам пришлось так же технологизировать и HR. И HR не только с точки зрения входа, но и на всём процессе, то есть это и воронка, и продвижение человека внутри компании, и его выход из компании. Собственно, здесь такой же гейтовый подход, для перехода с уровня на уровень нужно соблюдать определённые условия.
И здесь каждый работник находится в формате трёх основных векторов, то есть у него есть задачи, связанные с функционированием, с развитием и с утилизацией. Всё это связано с целями компании. Мы контролируем не каждый шаг, но за счёт гейтовой системы мы понимаем, где каждый человек находится, чего он хочет, как он приносит value нашей компании.
Далее. Мы ранее говорили о корпоративном университете, и если возвращаться опять-таки к модели CMMI как к каркасу, корпоративный университет должен входить в неё обязательно уже на третьем уровне зрелости. Это как раз обязательный инструмент трансфера технологий, инструмент развития внутри компании, и по факту он позволяет все цели, которые ставит перед собой компания, каскадировать до конечного сотрудника и позволяет сотрудниками этих целей добиваться за счёт обеспечения необходимыми знаниями.
Тот же самый agile, если нужно его внедрить в компанию, для этого используется корпоративный университет. Основа в виде CMMI-каркаса, и люди достаточно быстро этой технологией овладевают. То есть, с одной стороны, мы можем быстро нужных людей брать с рынка за счет HR-технологий, а с другой стороны, мы должны достаточно быстро за счёт корпоративного университета их погрузить и позволить им уже сразу заниматься основной деятельностью и приносить value компании.
Также, в рамках всей компании встроена система анализа деятельности, которая работает постоянно и выносится на верхний уровень раз в квартал. Мы проводим анализ первопричин, то есть мы в рамках нашей ежедневной, еженедельной деятельности собираем метрики как ключевых показателей компании, так и показателей отдельных подразделений, в том числе и на проектных ретроспективах, которые мы проводим по завершению ключевых этапов.
Всё это даёт нам картину проблем, которые у нас есть в организации. Дальше мы анализируем до причин и уже начинаем работать с ними. Те самые пресловутые «пять почему», которые используются, в том числе и в бережливом производстве для того, чтобы докопаться до причин, они все здесь и мы работаем с этой технологией, которая позволяет нам понять текущую ситуацию. И я сейчас передаю микрофон обратно Алексею.
Макин. Для того чтобы удержать тот темп, те скорости роста и практически одновременное внедрение такого огромного количества технологий нам пришлось разработать правильную систему внедрения, чтобы нас не разорвало при такой скорости. Что это такое? Анализируя и рефлектируя то, каким образом мы работаем, наблюдая за тем, чего нам не хватает, мы всегда старались подниматься на несколько уровней. Первое – пересмотреть уже какие-то готовые технологии в нашей отрасли или в смежных, отвечая себе на вопрос, каким образом мы можем их себе забрать.
И если мы оказывались в такой ситуации, что ответа в принципе нет, или он нам недоступен, нам приходилось уходить ещё выше, собственно, самим себе формулировать вопрос, каким образом, допустим, осуществлять управление коммуникацией или каким образом переходить от разработки на заказ к разработке продуктов. И уже на эти вопросы мы отвечали в рамках проектно-аналитических сессий. Собственно, использовали этот инструмент, привлекая весь интеллектуальный потенциал нашей команды для того, чтобы самим находить ответы на эти вопросы. Это та система, через которую мы определяли проблемы или то, чего нам не хватает, находили ответ.
После того, как ответ найден и появлялась высказанная гипотеза, мы пытаемся ее реализовать. Для этого мы создали специальный орган, мы его назвали «комитет изменений». Орган, который состоит из проверенных сотрудников среднего менеджмента, через них мы системно могли осуществлять внедрение изменений в компанию. Допустим, мы на проектно-аналитической сессии выработали какое-то решение или нашли какой-то ответ на вопрос, сформулировали гипотезу, после этого нам необходимо это решение или эту гипотезу превратить уже в конкретный проект. Набор проектов нам необходимо превратить в программу, и убедиться, что эти изменения будут потом в компании внедрены, и потом посмотреть, к чему эти внедрения привели.
Собственно, для этого мы создали этот комитет изменений, скажем так, это был второй проектный офис, в котором мы между ПАСами, которые мы проводили раз в квартал, за три месяца изменения производили, после этого на следующей ПАС смотрели (в том числе), к чему привели те решения и изменения, которые мы собрались внедрять 3 месяца назад. И, соответственно, цикл корректировки повторялся или появлялись новые вопросы.
Даже эту технологию мы заимствовали, не сами придумали. Конечно же, брали за образец те наработки или ту работу, которую проделала команда Андрея Георгиевича в Оборонпроме, изучали, анализировали, выясняли и, скажем так, прототипировали с них, используя тот опыт, который уже наработала команда Реуса. На этом всё, спасибо большое, готовы отвечать на вопросы.
Вадим Маркович. Очень интересный доклад, очень содержательный, но вот какой парадокс возникает: а что, собственно, собой представляет в этом случае управление? Вот вы говорите «управление проектами», «управление коммуникациями». А если опустить слово «управление»: проектирование, организация коммуникаций и так далее, ведь что у вас получается? Такая парадоксальная вещь: вы всё время развиваете, вы проектируете, организуете и так далее. Но тогда в чём у вас функция управления?
Собственно говоря, почему не опустить – я так парадоксально – это слово и обсуждать, как вы развиваете, как вы организуете коммуникации, как вы проектируете и так далее? По-другому ещё: а чем вы, собственно говоря, управляете? Это первый вопрос. А второй вопрос: когда вы всё это делаете, когда вы развиваете всё это, вы на что ориентируетесь? На конкуренцию, на прозрачность производства, то есть у вас какие критерии самого развития, движения этого?
Макин. Спасибо за вопрос. Хорошее уточнение. Давайте я отвечу на вторую часть, она касается всё-таки целеполагания. Так мы занимаемся коммерческой деятельностью (я являюсь руководителем и совладельцем компании), одной из основных целей является извлечение прибыли на определённом промежутке времени, Для достижения результата у нас есть инструмент – стратегия и совет директоров как тот орган, которому собственники доверили стратегическое управление компанией.
Собственно, у компании есть цели, которые заданы в первую очередь собственниками, программа развития. Всё развитие компании идёт для того, чтобы этих целей достигать. Это ответ номер два. А ответ номер один? Здесь не хочется подниматься слишком высоко в дискуссию по формированию правильных понятий.
После того, как я организовал коммуникацию, мне, наверное, надо ей начать управлять, так как это и есть процесс коммуникации. Поэтому когда я ставлю везде слова «управление», «стратегическое», «управление коммуникацией», то, конечно, здесь я подразумеваю набор действий, которые я произвожу. После того, как я спроектировал, мне всё это надо организовать. После того, как я всё это организовал, дальше – это управление, анализ того, как объект работает, что в нём нужно изменить и внедрение изменений. Я могу, в принципе, выложить ещё схему управления, которой я пользуюсь. Надеюсь, я вам ответил.
Левенчук: А был ли у вас опыт управления этими технологиями, когда вы выводите на следующее поколение технологии, которые вы тщательно внедряли-внедряли, впендюривали, как я иногда говорю, осваивали, давайте такое? Например, вы берёте допотопный PMI и вдруг, обнаруживаете, есть PTM(?), вам начинается с того, что PMI – прежнее поколение. Вы берёте Scrum, который у вас там agile обозван, и говорите: «Ух ты, уже Kanban софтверный», и вот Scrum мимо или там начинаете интегрировать с Kanban?
Макин. Отвечу. Конечно, у нас присутствуют оба процесса. Первое: мы всё-таки прототипируем, мы не берём и не внедряем технологии, как есть. Раз уж вы такими классными терминами можете оперировать типа Scrum и Kanban, то надеюсь, что вы поймете мое следующее высказвание. Мы не используем ни чистый agile, ни чистый Scrum, внутри спринтов у нас waterfall. И специфика нашей деятельности требует от нас очень осознанного подхода к внедрению конкретно этих технологий. Это раз.
Второе. Конечно же, прототипируя, мы начинаем эти технологии сами усовершенствовать. Мы очень чётко отслеживаем, когда их пора утилизировать, в том числе утилизировать уже в понятии схемы функционирования, развития и захоронения. В том числе.
Довольно много захораниваем.
Левенчук: Пример?
Макин. Кладбище большое. Я могу Вам привести какой-то набор примеров, мы их называем «неудавшиеся эксперименты». В рамках где-то от третьего до шестого ПАСа, проектно-аналитической сессии, у нас из 15 активностей выживет пять.
Левенчук: А, то есть они просто не взлетают?
Макин. Есть те, которые просто не взлетают, а есть те, которые мы принудительно или убираем, останавливаем, или заменяем в том числе.
Муж15. Хоронят молодыми.
Левенчук: Вот CMMI планируете хоронить и когда?
Волошин. Я могу как раз ответить. Если мы говорим про тот же самый PMI и PMBoK, то мы его похоронили в чистом виде достаточно быстро, то есть мы его похоронили буквально через 3-4 месяца после начала использования. И мы его очень сильно поменяли, потому что по сути PMBoK – это просто справочник, который говорит о том, что есть 10 областей знаний, которые нужно знать и нужно уметь ими управлять. Но дальше в чистом виде это всё не работает, работает только в применении к конкретной ситуации.
И по факту у нас получился микс между этими технологиями, потому что понятно, что если мы говорим про управление проектами, всё равно управлять стейкхолдерами нужно, и никуда от этого не уйти. Управлять сроками, качеством нужно, то есть эти области знаний, они никуда не денутся, поэтому в чистом виде похоронить PMBoK нельзя. А часть, конечно, можно сохранить, обогатив её новыми гибкими технологиями, например.
Сначала нам надо дойти хотя бы до четвёртого уровня, потому что мы себя пока всё-таки оцениваем не однозначно по этой метрике. Если рассматривать, декомпозировать всю компанию, то есть где-то у нас второй уровень, где-то четвёртый, где-то третий, то есть мы в этом году как раз будем проходить сертификацию. На самом деле, CMMI в том виде, в котором он есть и представлен сейчас, его основное преимущество – то, что он может обновляться сам по себе. И если у вас внедрён CMMI на пятом уровне, то через 2-3 года это уже не тот CMMI, который у вас был 2-3 года назад. Это его основное отличие от других технологий. Тот же самый стандарт ISO, он всё-таки немного другой в этом плане.
Реус. Так, всё, коллеги, на этом мы этот… Я единственное, не могу удержаться, потому что когда говорят «ну, зачем слово "управление"»? Всё работает у тебя, иди домой, спи. Но просто можешь потом проснуться, и как бы ничего не будет.
Муж16. Да нет, можешь просто не проснуться.
Реус. Или не проснуться.
Вадим Маркович. Это не ответ, дорогой мой. Это не ответ.
Реус. Ну, как не ответ? Это ответ.
Вадим Маркович. Это не ответ.
Реус. Что значит «уберите управление»? Что значит?
Вадим Маркович. Что вы понимаете под управлением? Вот непонятно из того, что…
Реус. Системную интеграцию. Хорошо? Системную интеграцию и руководство теми, кто…
Вадим Маркович. А, вот начинается. Так это же не… Вы же про другое рассказывали. Вы же рассказывали про то, как вы проектируете, организуете и так далее, но тогда, получается, вы не рассказывали про собственно управление.
Реус. Нарисовал объект и управляй себе. В котором есть проектирование, в котором есть…
Вадим Маркович. Это не автомобиль.
Реус. Как не автомобиль? Вот рисуй его и рисуй всё время.
Вадим Маркович. Есть же technology management, есть engineering management, там разные управления.
Реус. Послушайте, вот есть технология. Управление делится на две части: одна часть технологизирована уже, слава Богу, не надо думать ни о чём. Не надо думать на 80-90%, если управленец не имеет отчуждённых конструкций, которые ему позволяют принимать решение сразу, а не собирать совещание, то он просто как-то уже не работает. И есть эта частичка, там процентов 10, на которые он тратит всё больше времени. На системную интеграцию, на построение объекта, на его изменение, на, соответственно, ту работу, которую обсуждали. Но она есть ключ ко всему.
Вадим Маркович. Понятие у вас не работает.
Реус. Понятие не работает?
Муж17. И хрен с ним, раз не работает.
