Трансформация
управления

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

Другое дело, когда идут кардинальные перемены, на которые, естественно, тратятся и деньги, и время, и силы. Ну, положим, затраты просчитать ещё можно, и даже довольно точно. А вот как измерить то, что в итоге получается? Можно, конечно, сойтись на том, что, мол, все постарались и это хорошо. Только это, по сути, — катастрофа, называемая потерей управляемости.

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

Конечно, в отдельной компании проблема выглядит не столь масштабно, но остаётся катастрофой, часто перерастающей в крах. А на самом деле, всё начинается с того, что люди попросту «на берегу» не договорились о том, что хорошо, а что плохо. А суть именно в том, чтобы изначально взять за основу единую систему измерений, всем понятную, прозрачную и принятую всеми участниками процесса.

Понятно, что самая естественная единица измерений в бизнесе — деньги: столько-то пришло, столько-то ушло, а разница (с плюсом или минусом) показывает, насколько успешно вы сработали. Однако в реальном бизнесе этого недостаточно. Нужно мерить что-то ещё, то, что приводит к деньгам, на что люди могут повлиять относительно простым способом. Иначе система управления не справится.

Яркий пример очень удачной и простой системы измерений описан в книге «От хорошего к великому» Джима Коллинза. Началось всё с одной аптеки. Боролись за средний размер чека. Аптек было много, товары идентичные. Лояльность клиента (повторные покупки) обеспечить было практически невозможно. Если клиент пришёл, нужно было из этого выжать по максимуму. Полки с товарами ставили так, чтобы покупатель, проходя путь от входа до кассы, мог увидеть все продукты, а наиболее популярные из них выкладывали на кассе. Ассортимент расширялся сопутствующими товарами (здоровое питание, уход за зубами, шампуни и прочее). За всё это отвечал управляющий. Он действительно мог увеличивать средний размер чека. И делал это, принося прибыль компании. Через 15 лет сеть аптек, которая выросла из одной аптеки, стала самой большой в США. Она росла в 15 раз быстрее рынка. Сейчас это стандарт аптечного бизнеса.

На том же примере можно пояснить ещё один принцип: система измерений должна быть устроена так, чтобы результат невозможно было исказить. То есть он должен быть абсолютно объективным и не зависеть от желания человека выглядеть лучше, чем на самом деле. Когда на весах «быть хорошим» и «быть честным», то обычно перевешивает первое.

Что ещё? Единая версия правды. Одни и те же вещи в компании нужно мерить одним и тем же способом. Несколько версий правды обычно появляются потому, что разные версии правды по-разному окрашивают работу людей. Сотрудники выбирают те, в свете которых они выглядят лучше. И искренне верят, что это и есть правда. А другие люди принимают решения, опираясь на другую правду. И получается, как в басне, когда лебедь, рак и щука изо всех сил тянут воз — но в разные стороны. Что из этого вышло, хорошо известно: «воз и ныне там».

Очень важно обеспечить непрерывность измерений. Чем чаще мы мерим, тем чаще и лучше управляем. Но делать измерения часто — это труд, поэтому управляем мы раз в год, раз в квартал или раз в месяц. Когда компания меняется, этого явно недостаточно. Нужно непрерывно контролировать и влиять, а для этого нужно непрерывно измерять. С переходом на agile наша система измерений претерпела существенные изменения, мы перешли на регулярные циклы измерений — раз в две недели. Однако измерения идут и внутри спринта, фактически ежедневно — каждый день проходят стендапы. Но agile — это для производственных команд, а в них работает только половина сотрудников компании. Остальные тоже активно вовлечены в процесс глобальных изменений, и для них нужно было трансформировать систему управления. Это привело к замене привычного MBO (Management by Objectives) — метода управления по целям (раз в квартал, год) на систему OKR (Objectives and Key Results), которая позволяет разбивать большие цели на ключевые результаты и двигаться по ним непрерывно.

Наверное, когда мы завершим трансформацию бизнеса в целом, выстроится и более совершенная модель измерений. Но в любом случае она будет основываться на принципах, о которых я уже говорил: простота, объективность, непрерывность, единая версия правды и ценность для компании.

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

Выполнять принятые правила, поддерживать существующие в компании процедуры и процессы — такая самостоятельность для большинства невозможна. Этим необходимо управлять. И было бы легче делать это в привычной атмосфере, когда вся команда и её лидер работают вместе, рядом, в одном помещении. Но наши команды распределены по филиалам. Мы даже не против, чтобы люди работали дома. Но много ли тех, кто, будучи на «удалёнке», может правильно организовать своё рабочее время?

Многие говорят о «внутренней» мотивации. Она есть в стартапах. Это ключ к «бирюзовой» культуре больших организаций. Но как её обеспечить? И пока исчерпывающего ответа на этот вопрос нет, приходится заниматься менеджментом и создавать «внешнюю» мотивацию.

Тем более важен регулярный менеджмент в процессе трансформации бизнеса. Система управления в это время только выстраивается. Люди пока привыкают и порой сопротивляются изменениям. Ясно, что без постоянного и жёсткого контроля результата не добиться. Анализируя успехи и промахи, мы пришли к убеждению, что на этом этапе страшней «недоменеджмент». Даже термин родился: «животворящая сила» регулярного менеджмента. Но всё же, всегда стоит вопрос о сбалансированном управлении и о том, как избавиться от «микроменеджмента».

Чем он плох? Да уже тем, что мелочная опека отнимает массу времени, ведёт к неуверенности и несамостоятельности сотрудников и, по сути, препятствует профессиональному и личностному росту. С другой стороны, не менее опасен «недоменеджмент» — отдавая всё на волю волн, можно полностью потерять управление. Так что выработка управленческого баланса — своего рода путь между Сциллой и Харибдой. Соотношение такого баланса индивидуально и зависит от зрелости новых практик, от компетенций и уровня осознанности действий лидеров и их команд, от того, как эти практики влияют на внутреннюю мотивацию, насколько они полезны.

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

Довольно стройно складывается регулярный менеджмент в agile: сама модель задумана так, чтобы «внешний» контроль был раз в две недели, зато «внутренний» — ежедневно. Так что микроменеджмент, в основном, — забота командных лидеров, как, собственно, и должно быть. Если ситуация того требует, менеджеры верхнего звена могут вмешиваться в процесс. Обычно это делается во время специальной процедуры — ретроспективы, которая проводится в конце спринта и требует анализа и выработки мер, направленных на улучшение процесса разработки. Кроме этого, центры компетенции, отвечающие за выработку и выполнение правил, периодически проводят аудит и обучение в командах.

Конечно, по мере трансформации бизнеса потребность в менеджменте повысилась. Уже хотя бы потому, что сегодня у нас больше сотни команд, и все — кросс-функциональные. То есть вместо привычной вертикальной структуры, когда руководителями назначали самых опытных профессионалов, команду теперь составляют специалисты разных направлений, и выделить среди них лидера — задачка нетривиальная. Тем более, когда в команде работают представители разных филиалов и территориально они разобщены.

Поэтому для руководителя команды эффективные методы контроля — чёткого и ненавязчивого — крайне важны.

И вот в такой ситуации простая и понятная система измерений становится фундаментом для эффективного контроля. А разрабатывать её пришлось с нуля: то, что удалось почерпнуть из книг, было либо слишком примитивно, либо не подходило под нашу специфику.

Самая большая иллюзия третьего тысячелетия — то, будто бы мы делаем жизнь проще. Да, конечно, на уровне конечного потребителя жизнь и проще, и комфортнее, но за этой простотой стоит невероятно сложное производство, которое от года к году становится всё сложнее.

Это происходит во всех отраслях экономики, но на себе мы ощутили это особенно остро. Проекты стали неподъёмными и поэтому нередко неэффективными: изначально задача плохо понятна, и к ней вырабатывается соответствующее отношение, что-то вроде «всё равно не получится, слишком сложно и рискованно». К тому же, при «водопадной» модели любой большой проект приходится перетаскивать из этапа в этап полностью, постоянно накапливая ошибки (а они, само собой, обязательно случаются) и выдыхаясь уже к середине этого марафона.

Поэтому логика agile: делить проект на части и двигаться к цели короткими галсами — в новой ситуации это пришлось очень кстати. «Сверяя часы» с заказчиком каждые две недели, команда получает возможность вовремя скорректировать задачу и контролировать её выполнение. Как правило, в зрелых коллективах внешнего контроля не требуется (разве что в критических случаях) — вполне достаточно внутреннего. Да и работу лидер команды обычно распределяет между сотрудниками самостоятельно.

Главная проблема этого подхода к управлению разработкой — объединить результаты труда разных команд в одно целое, в работающее решение, а в дальнейшем эффективно его развивать. Уровень сложности банковских приложений таков, что количество команд может вырасти до нескольких десятков. А банки создавали сотни команд, работающих в одном направлении, и управление ими было неподъёмной задачей.

Команда работает с полностью независимыми компонентами по коду, базе данных, системному окружению. И это здорово! Это обеспечивает независимость разработки, а значит, скорость. Но эти независимые компоненты начинают «общаться», влиять друг на друга и «взаимозависеть» в рамках общего решения. Надо сделать так, чтобы соединённые вместе, эти компоненты стали единой программой. Понятно, если каждая команда будет делать свою часть работы без оглядки на задачи других участников проекта, в финале получится неудобоваримая каша, и ничего не заработает. Этим нужно управлять.

Главным принципом в решении этой задачи становится так называемый contract first. Фактически, в начале пути команды должны договориться об интерфейсах (языке общения) создаваемых ими отдельных компонентов. И заключить контракт, который предполагает обязательное его выполнение. Игнорирование этого принципа приводит к катастрофическим последствиям.

Мы так много говорим о проектах разработки, что можно подумать, ими всё и ограничивается. Но мы, вендоры, стремимся даже в новых, инновационных проектах создать тиражируемый продукт. Это основа, которая позволяет нам реализовать нашу основную миссию: делать дёшево. Поэтому и типов проектов, и специфики у нас предостаточно. Мы делим нашу деятельность на пять направлений: продвижение, разработка, внедрение, сопровождение и развитие. У каждого есть свои особенности, практики, компетенции и лидеры. Как проектная компания, деятельность свою мы ведём проектным способом. И измеряем, и управляем всем, как проектами — затраты, доходы, сроки, этапы и прочее. Это наш способ разделить всё то сложное, чем занимается компания, на простые части. За каждым направлением стоят лидеры и целевые показатели, которые окрашиваются (в зависимости от результата) в пять цветов (чёрный, красный, жёлтый, зелёный, синий). Целевой цвет — зелёный, но можно сделать лучше или хуже. От «цвета» цели зависят премии руководителей проекта и лидеров направлений. Это на постоянной основе контролируется правлением компании. Идея проста: если в каждом проекте добиваться целевых показателей, то и всё в целом будет хорошо. Мы смотрим, как эти показатели меняются во времени, анализируем негативные тенденции, стараемся реагировать на них своевременно, думаем, что и как можно изменить, находим решения.

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

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

Та же история с клиентским зданием. Мы делаем для клиентов самые разные проекты. Обычно их много: проекты по развитию уже установленных решений, новым разработкам, сопровождению и другие. Для нас важен суммарный результат по каждому клиенту в отдельности. Есть клиенты, работая с которыми мы получаем прибыль, а есть те, что генерят убытки. Научившись измерять, мы научились и управлять —так, чтобы исключить «плохие» проекты, но и терпимо стали относиться к дополнительным затратам в некоторых проектах у «хороших» клиентов.

Уверен, что именно такой подход — деление сложного на простые части, качественное измерение простых частей и распределение ответственности по способным, компетентным и мотивированным лидерам — стал основой того финансового чуда, которое произошло в компании в 2018 году.

Об ошибках мы уже говорили в первой части книги, но есть смысл взглянуть на эту тему в другом ракурсе. Думаю, нет на свете человека, который не совершал бы ошибок в своей жизни, и совершенно точно — нет бизнеса, который развивался бы совершенно, безошибочно. Сказано же: не ошибается только тот, кто ничего не делает. И управляем мы всё-таки не системами, а живыми людьми, и каждый из нас может (и даже имеет право) ошибаться. А в условиях трансформации или по мере освоения новых областей деятельности ошибок становится гораздо больше — что вполне закономерно.

Поскольку трансформация управления в нашей компании уже не первая (хотя прошлые, наверное, не были столь масштабными), мы выработали правила, как к этому относиться.

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

То же в отношениях с клиентами. Объективно, результат зависит от усилий двух сторон: нас и нашего заказчика. Но клиент для нас — это внешняя сторона. Если он что-то делает не так или не делает совсем — это риски. Бесполезно после отрицательного результата разбираться, кто виноват. Надо по ходу проекта прилагать все усилия к правильному управлению. Если результат плохой, то это мы должны что-то изменить в себе, научиться делать свою работу по-новому.

По-другому это можно выразить так: ответственность не делится. Она всегда на сто процентов на каждой стороне — на конкретном сотруднике, менеджере или компании. Признание такого положения дел позволяет двигаться вперёд и становиться лучше.

Если мы признаём право на ошибку, то надо понимать, что за ошибки нельзя наказывать. Понятно, ошибки болезненны и отрицательно влияют на успех проекта и компании. И на чувства людей, но это нормально. Не надо только придавать этому личный окрас, а тем более — это не должно влиять на мотивацию людей. Главное и единственное наказание за ошибку — это обучение.

Что действительно плохо, так это не прилагать усилий для того, чтобы не повторять те же ошибки в будущем. Вот это, можно сказать, сродни преступлению. Вот за это можно наказывать и демотивировать. Необходимо анализировать и вырабатывать планы мероприятий, направленных на улучшение процессов и правил, повышение качества автоматизации, обучения и т. д. Например, в agile такая практика обязательна в конце каждого спринта и называется — ретроспектива.

Менеджеру любого уровня приходится иметь дело не столько со своими, сколько с чужими ошибками. И именно на нём лежит ответственность за то, чтобы сотрудник, с одной стороны, не впадал в истерику от любой оплошности, а с другой — правильно бы её понимал. Да, нередко менеджеру среднего звена, лидеру команды приходится, что называется, с головой влезать в задачу сотрудника, вместе с ним разбирать её по деталям, добиваться осознанности. А потом отслеживать, всё ли человек понял правильно и как он справляется с задачей на следующем этапе.

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

Проблема выбора — пожалуй, самая трудная, как в жизни, так и в управлении. Причём выбирать приходится довольно часто и нередко —из взаимоисключающих вариантов. К примеру, в повседневной жизни: поехать в отпуск на море — или купить новый холодильник. Тем не менее, есть способ примирить подобные противоречия, в бизнесе — точно есть. Просто надо заменить «или» на «и». Сознаю, не так-то это и просто. Но возможно. Надо понимать, что в нестабильные времена подобный «невыбор» приходится делать всё чаще. Конечно, для этого нужно напрягаться, искать и находить варианты, включать все внутренние резервы — только в таком случае можно добиться успеха.

На самом деле, в ситуациях, когда выбора нет, оказывались многие компании, в том числе — знаменитые и успешные. О том, как они справлялись в этих безвыходных положениях, хорошо рассказал Джим Коллинз в книге «Построенные навечно». Суть в том, что в сложное время они буквально продирались сквозь трудности, не оставляя себе иного выбора, кроме как справиться.

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

Для нашей компании выбор между прибылью сегодня и прибылью завтра никогда не стоял. Мы всегда много вкладывали в будущее. Как-то сразу так повелось — и спасало компанию не раз. По нашим оценкам, мы находимся в четвёртом цикле Адизеса. Вместе с нами в начале девяностых начали свой путь десятки компаний, но только несколько из них дожили до нашего времени. Спросите, почему? Отвечаю: они выбирали, в них не было силы «И».

К сожалению, выбирать приходится, и довольно часто. Например, в современной теории мотивации большой акцент делается на внутреннюю мотивацию. Это когда людям интересно и хочется работать, их не нужно пинать и контролировать. Они лояльны и ответственны. И мы понимаем, что это правильно и надо приложить все усилия, чтобы этого добиться. Нужно предоставить людям свободу выбора: где работать, с кем, когда, на каких технологиях и прочее. Но, в то же время, у нас, в большой компании, много правил и процессов. И свободы выбора у нас не так много. Мы должны быть дисциплинированными, эффективными, должны хорошо считать и хорошо делать то, за что нам платят. А клиенты платят за то, что готовы оценивать. Как это сочетать? Какой сделать выбор? Да никакой. Надо находить силы делать и то, и другое. И делать это хорошо.

То же самое в менеджменте. «Микроменеджмент» — плохо. «Недоменеджмент» — плохо. Нужно искать баланс между этими двумя подходами и делать это индивидуально, точечно, с учётом зрелости отдельных практик и людей. Менеджмент можно ограничить контролем результатов, постепенно расширяя окна делегирования ответственности.

Существует вечная проблема между работой (проектами) и обучением. Известно, что мир так быстро меняется, что любые компетенции могут «протухнуть». Учиться теперь нужно всю жизнь. И это не только ответственность отдельных людей, но и компании в целом. Необходимо встраивать процесс обучения в жизнь компании и обеспечивать его качество и непрерывность. Мы, в компании, всегда много занимались обучением сотрудников.

Я тоже приложил к этому руку: разработал собственный сорокачасовой курс «Эмоциональное лидерство», который за три года прошли более 500 человек. Хотя самое эффективное обучение проходит, конечно, в реальных проектах. И хорошо, что проекты у нас разные и постоянно сменяют друг друга: люди получают очень разносторонний опыт. А так как работа всегда напряжённая, стрессовая, то и обучение очень эффективное. Мы гордимся тем, что рынок признаёт наших специалистов как лучших. Конечно, это создаёт нам определённые проблемы: на наших сотрудников охотятся, в том числе и наши клиенты. Но это жизнь, и никуда от неё не денешься, поэтому мы расстаёмся в хороших чувствах, связь с ними не теряем, что очень помогает нам потом, в совместных проектах. Это же хорошо, вдвойне ценно — иметь дело с такими сильными специалистами заказчика! И наконец: личное. На самом деле, целесообразно мыслить силой «И» и в обычной жизни. Есть такая проблема — проблема выбора между карьерой и семьёй. Хочется и то, и другое. Тот, кто делает выбор или ищет компромисс, проигрывает. Иногда не получается ни то, ни другое. А можно хорошо делать и успевать всё — примеры такие есть. Семья, здоровье, спорт, отдых и работа. Всё на отлично. Дерзайте! Наполняетесь энергией и идите вперёд!

Не первый раз в этой книге я говорю об agile. Сейчас я предлагаю взглянуть на эту методологию сквозь призму задач управления компанией. Собственно, agile и есть гибкая система управления проектами, то есть ничего здесь специально привязывать не надо. Другое дело, что agile, как я уже говорил, требует пересмотра практически всех аспектов деятельности компании. Тот самый случай, когда приходится «менять всё». Вопрос — зачем такие сложности?

И снова вернусь к тому, с чего начинал: мир меняется не только глобально, но так быстро, как никогда прежде, и в этом, если хотите, — вызов эпохи. Здесь как нельзя лучше годится поговорка: кто не успел, тот опоздал. Что это значит — и для бизнеса, да и для всех нас? А это значит, что мы должны быть готовы не только принять эти изменения, но и меняться сами. Причём меняться быстро, поспевая за всеми ведущими трендами.

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

А что делать большим компаниям? Где команда не одна, а десятки или сотни? И нужно собирать результаты работы этих команд в одно большое, сложное решение и обеспечить его эффективное развитие? Внедрение этих подходов в условиях нашей компании стало нетривиальной задачей. Нам пришлось пройти путь проб и ошибок, потребовалось много времени и усилий, чтобы все элементы пазла сложились в стройную картину. В результате, родился устойчивый термин: осознанный agile.

В основе этой осознанности — потребности бизнеса клиента. Business First, то есть всё, что мы делаем и делают ИТ-специалисты банка, делается для того, чтобы бизнес справлялся со своими задачами, не только сложными, но и ещё и новыми. Конкуренция-то в бизнесе очень острая, и всё делать нужно как можно скорее. Без agile в этой ситуации не обойтись, и понятно: чем лучше видение, чем больше компетенций, тем лучше будет результат. Просто собрать команды, которые должны что-то сделать, чтобы бизнес непрерывно развивался, — это утопия. Требуются компетенции в новых технологиях, архитектуре, бизнесе, управлении, коммуникациях и прочее. Чем лучше и с самого начала продуманы цели, видение конечного результата, чем точнее оценка компетенций команды, тем более предсказуемым будет результат, тем более доволен будет бизнес. Если раньше активная работа с бизнесом велась в начале и в конце проекта, то сейчас это можно и нужно делать непрерывно, однако «волшебной палочки», то есть тщательной начальной проработки проекта никто не отменял.

Очень важно разогнать мощность команд. Известно, что ИТ-специалисты приблизительно одного и того же уровня компетенции могут выдавать в разы больше или меньше результатов. Это зависит от очень многих факторов: и от среды разработки — насколько она помогает, а не мешает, и от компетенций в технологиях — а технологический стек новый и активно развивается, и от компетенций в предметной области — понимание бизнеса избавляет от многих ошибок. И от умения и мотивации работать без ошибок — часто до 70−80% времени уходит на исправление ранее сделанных ошибок, а допустимо не более 20−30%. И от культуры, атмосферы, которая помогает работать интенсивно и делать с каждым разом больше. Фокусировка на всех этих аспектах разработки увеличивает эффективность команд в разы, а иногда в десятки раз.

Словом, как отражается на бизнесе грамотная и актуальная система управления, мы осознали на практике. Ещё вчера мы готовы были согласиться с тем, что право на успех принадлежит умным и, главное, сильным. Конечно, сила и ум никому не помешают и сегодня, но не они становятся приоритетными. Побеждает тот, кто не боится перемен и принимает их, проявляя гибкость.

Никаких особенных секретов в методологии DevOps нет — всё на поверхности. А двумя словами её можно объяснить так: непрерывная поставка. То есть ты программируешь — и тут же доставляешь софт заказчику. Звучит, согласитесь, привлекательно, но добиться такой цели не слишком просто.

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

Поясню на примере. Предположим, программист пишет код. Поскольку у нас модульный подход, скажем точнее: свою часть кода. И мало того, что код надо написать хорошо, он ещё должен быть совместим с другими модулями, а их в системе — множество. В прежней методике надо было по окончании работы над всеми частями кода собрать их на стенде воедино, посмотреть, что получится, протестировать и дальше уже принимать решение, что со всем этим теперь делать. Сложно, долго, дорого — и, в конечном счёте, не очень надёжно.

В DevOps дело обстоит по-другому. Разработчик обретает существенную независимость. После завершения кодирования он может одной кнопкой развернуть стенд с индивидуальной средой, где запустятся автотесты на все возможные несоответствия. Таким образом, отдельный разработчик может намного раньше реализовать свою ответственность «программировать без ошибок» и быть более эффективным. То же происходит, когда нужно объединить усилия команды, где разработчиков несколько, или усилия многих команд. И всё это разные задачи: в первом случае подставляется большое количество заглушек (интерфейсов, оговорённых в contract fest), а в последнем — создаётся стенд с полностью готовым решением.

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

Идеальный ли это метод? Конечно, нет. Бывают такие ошибки, которые в автоматическом режиме не обнаружить. Например, некачественное программирование может привести к существенному снижению производительности. Но даже для этих случаев можно создавать «инспекторы» кода, которые будут выявлять возможные проблемы на самых ранних этапах. То, против чего нужно бороться за пределами этой технологии управления — это ошибки в постановке.

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

Понятно, что при такой «безлюдной» технологии скорость разработки возрастает в разы, и это особенно ценно для цифровых платформ, нацеленных на высокую скорость поставки изменений в рамках микросервисного стека технологий, где при непрерывном обслуживании клиентов нет возможности делать технологические перерывы. Ни банк, работающий в режиме 7/24, ни круглосуточно торгующий Amazon подобной роскоши позволить себе не в состоянии.

Эффективность DevOps особенно наглядна в сравнении с обновлениями core banking — там пока всё по-старому, разве что сроки сократились с года до двух-трёх месяцев. Наверное, пройдёт время, появится особая нужда в срочности изменений — тогда и появится своя непрерывная технология «первого этажа» банковских систем.

До сих пор помню, как в институте меня три года безжалостно ломали, приучая к тому, что писать код надо сразу хорошо — без ошибок. «Делай красиво!» — твердили мне, а я сопротивлялся. И так почему-то делали все. Хотелось сэкономить усилия в начале пути, и казалось, что более эффективно быстро сляпать начальный код и отправить всё на отладку. Уже тогда было довольно много отладчиков, которые подскажут, что не так, что надо исправить, и «вуаля» — работа закончена. Только много практики и давление преподавателей переубедили меня в этом. Самым эффективным оказался путь «сухой» отладки — предварительный тщательный анализ кода с использованием только своего собственного мозга. Зато какую гордость я испытал, написав безошибочную программу, аж на две тысячи строк… и даже без синтаксических ошибок. И это была боевая программа, которая стала востребована в реальной жизни. Это был 1987 год, и я тогда работал в Центре управления полётами. С тех пор вошло в привычку, пожалуй, даже в образ жизни — делать всё и сразу красиво. Не помню, кто сказал, что красота — это высшая целесообразность, но, наверно, так оно и есть.

Сегодня главным принципом разработки является быстрое исправление ошибок, а это прямая противоположность другому принципу: делай сразу правильно. Для этого всё есть: программы, тесты, методики и средства разработки. Уверен, что это в корне неправильно и является основной причиной неудач. В частности, это приводит к безответственности. Все участники процесса разработки надеются либо друг на друга, либо на средства автоматизации, а не на себя.

Ну, вроде как, зачем учить таблицу умножения, когда есть калькулятор? Или зачем иметь твёрдые знания, если главное — знать, как найти ответы в Интернете?

Начнём с того, что если писать, как Бог на душу положит, а потом поспешно исправлять, то какой-то процент ошибок проскочит и никакая программа их не обнаружит. А что такое ошибка в коде? Чем раньше ты её сделаешь, тем с каждым этапом она становится дороже. Потому что на исходную ошибку накручиваются следующие — и в конце концов приходится возиться с их исправлением по всей цепочке (что отнимает время и, следовательно, деньги), часто возвращаясь к началу. И сами исправления делаются в этой же парадигме, что приводит к новым ошибкам. Часто это может быть непреодолимой проблемой, особенно, когда ошибки плодятся — много разработчиков, много команд, много модулей в решении.

Разрабатывая систему управления качеством проектов, мы делали ставку на «красивую» работу. И это не прихоть — это основа эффективной разработки. Любой пришедший к нам программист сразу же получает долгосрочное задание: писать качественный код сразу. Мы стараемся освобождать его от всех побочных обязательств, которыми, как правило, нагружают программистов, автоматизируем рутинные процессы — всё ради того, чтобы он «делал красиво». Не скажу, что это легко, выдерживают наши требования не все, но большинство ребят всё-таки включается в эту битву с самим собой.

… Сделаю лирическое отступление. Когда-то в 1970-х, на заре создания информационных технологий, программист был персоной весьма уважаемой. Вообще, программирование зародилось в научной среде, соответственно, требовались и образование, и способность к анализу, и творческий подход. Первые программы писали десятки и сотни сотрудников, старались — и несмотря на это, провал следовал за провалом. Не хватало ни опыта, ни умения, ни терпения. Вот тогда и были выработаны принципы качественного проектирования и разработки. Они получили название SOLID.

Сегодня профессия программиста стала обычной, её началам учат в средней школе. Что, тем не менее, не отменяет прошлых и вовсе не устаревших требований. Если ты хочешь чего-то достичь и продвинуться с позиции ремесленника как минимум на ступеньку выше, придётся «делать красиво», иначе никак. Эта культура — она, как говорится, в голове, этому можно и нужно учить. Я уверен, что мы к этому вернёмся. Пока же, увы, в голове у новичка совсем другое: быстро «наклепать» код, а там хоть трава не расти.

В одной из книг Джошуа Кериевски приведён перечень атрибутов плохого кода, среди которых — вязкость и сложность, закрепощённость и неподвижность, неустойчивость и неопределённость. Если сказать совсем простыми словами, то код должен быть таким, чтобы в нём смог разобраться и, если надо, продолжить над ним работу любой «сторонний» программист.

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

Хоть и сказано, что «серебряной пули нет», мне кажется, нормативы — как раз та самая «серебряная пуля» для бизнеса. Начиная тему управления, мы говорили об измерениях, а в этой главе поднимемся на более высокую ступень. Эта тема хорошо описана Элияху Голдраттом в книгах «Критическая цепь» и «Цель».

Мы уже говорили о том, как трудно, а порой невозможно управлять большим и сложным. Зато простое — будь то модуль проекта или agile-команда из семи человек — вполне поддаётся управлению. При увеличении числа элементов системы в два раза сложность управления возрастает в четыре. Это хороший ориентир для того, чтобы постоянно думать, как сложное делить на простые части. Когда речь идёт об управлении производством, всегда надо иметь в виду, что работают в нём совершенно разные люди: быстрые и медлительные, спокойные и нервные, открытые и интроверты… И обладатели различных профессий — от аналитиков до внедренцев. Всё это ещё более усложняет процесс управления. И как в таком случае планировать и просчитывать работу?

Так что задача перед управлением стоит тяжёлая — выделить из массы постоянно меняющихся факторов то, на чём нужно сфокусировать внимание, и сделать его простым и понятным всем без исключения. Вот как раз таким «кирпичиком мироздания» и стали нормативы.

Проще всего объяснить назначение нормативов в строительстве. Когда-то создание сложных объектов приводило к неуправляемому хаосу. Вот, предположим, начали строить небоскрёб. Как рассчитать, сколько для него понадобится панелей, кирпичей, паркетной доски, электрических розеток? И, главное, сколько нужно строителей и какая сумма пойдёт на оплату работы? И сколько времени всё это займёт? Ведь раньше такого не строили. Можно, конечно, подсчитать приблизительно — а потом, в процессе строительства, окажется, что рабочих то не хватает, то они простаивают. А в оценке стоимости материалов и рабочей силы явно попали мимо, и денег нужно гораздо больше. Ну, может, не так, как на «Зенит-Арену», но сопоставимо…

Элияху Голдратт сделал прорыв в управлении строительством, когда предложил сложный объект разложить на простые составляющие — розетки, паркетную доску, стоимость работ по их установке… На всё это были созданы нормативы, а поправочные коэффициенты учитывали разные особенности. Далее процесс строительства раскладывался на последовательные и параллельные работы, после чего можно было определить стоимость и сроки строительства всего объекта. Вроде, ничего сложного, но это была революция, которая привела к полностью управляемому процессу в целой индустрии по всему миру. Теперь строителей не спрашивают, в какие сроки они построят объект. Их просят разложить сложное на простые, нормированные части. И если кто-то может уложиться в эти нормативы, то остальным придётся учиться, чтобы дотянуть до рыночных стандартов.

В начале двухтысячных этот подход активно начали рассматривать в ИТ-индустрии. Здесь свои небоскрёбы. Уникальные и неповторимые. И если спрашивать специалистов, как скоро они сделают свою работу, то каждый умножит собственную оценку на два. Это чисто психологически, на всякий случай, потому что, как известно, сроки имеют обыкновение затягиваться. А опыт подсказывает, что всю работу можно сделать за 20% отпущенного времени. Особенно в нашей «ржаной» культуре, когда мы привыкли долго запрягать и быстро ехать. В начале любой работы мы долго раскачиваемся, говорить о какой-то эффективности не приходится. Нагонять, работать эффективно мы начинаем уже ближе к концу, поэтому сколько бы времени ни выделялось, его всё равно не хватает.

Вывод: не надо людей спрашивать, какое время им понадобится на работу. Точного ответа вы не получите. Особенно, если задачу выполняет большое количество людей, объединённых в иерархическую структуру управления. Те, кто в этой иерархии снизу, закладывают двойной коэффициент к своим собственным оценкам, а те, кто сверху, умножают эти цифры ещё на два. И все эти сроки всё равно «проезжаются».

Выход из этого один: пойти по пути нормативов. В ИТ-сфере это не более сложно, чем в строительстве. Просто непривычно. Но как там есть розетки, у нас есть экранные формы со счётным количеством полей и понятной сложностью каждого поля. Как там есть инструменты, и от их качества зависит скорость работы, так и у нас есть инструменты разработки, развивая которые мы можем уменьшать нормативы на работы. Всегда есть специалисты, которые в силу своей компетенции и/или мотивированности могут делать работу лучше и быстрее. Если работа сравнима, то их результаты могут лечь в основу нормативной базы и стать примером и целью для других. А если работа проста, то риск не уложиться в нормативы минимален. Всё это даёт возможность построить простую и эффективную модель разработки, которая имеет свойство постоянно улучшаться. Потому что понятно, куда нужно направить усилия: на средства автоматизации, чтобы люди могли делать больше за меньшее время, на мотивацию и соревновательность с поощрением передовиков, на рост компетенций там, где их не хватает.

Такой подход к организации труда требует построения хорошей системы учёта затрат. Нужно уметь непрерывно, не искажая результаты, считать затраты в разрезе каждой простой задачи, на которую есть норматив. А это очень непросто. Непросто сделать это дёшево, встроить в процесс разработки, сломать психологический барьер неприятия контроля, не нарушить внутреннюю мотивацию и прочее. Но это жизненно необходимо. Это основа успеха. На практике доказано, что с таким подходом эффективность разработки растёт даже не в разы, в десятки раз.

Чем ещё хороша система нормативов? Она заставляет шевелиться не только рядовых сотрудников, но и менеджеров: искать средства автоматизации, совершенствовать структуру, внедрять самые современные технологии, грамотно планировать и так далее. Словом, с какой стороны ни посмотри, а нормативы и есть та самая «серебряная пуля».

Что нужно повышать: производительность или эффективность? Производительность — это объём продукции, которую предприятие выпускает за единицу времени. Конечно, мы хотим делать больше, если то, что мы делаем, на рынке востребовано. И люди тут — самый критичный ресурс. Компетентных специалистов на рынке мало, за ними идёт большая охота. Тех, кто способен эффективно работать у нас, с нашими управленческими практиками, в нашей системе ценностей — нет совсем. Их приходится выбирать, учить, адаптировать к работе в компании. Это сложно и долго. Но приходится в это серьёзно вкладываться, потому что в нашем деле без людей — никуда.

Мечты о том, что искусственный интеллект будет создавать зрелые решения, при нашей жизни останутся только мечтами. А потребность в том, что мы делаем, растёт с каждым годом. Компания заключает всё больше контрактов, в том числе за пределами финансовой сферы. Пример цифровой трансформации банков оказался заразительным. Компания выросла по доходам в 2018 году более чем на 30%, и 2019-й не разочаровывает. Если мы будем справляться с текущими контрактами, то рост продолжится.

И большой проблемой становится задача масштабирования бизнеса. А это в существенной степени зависит от того, как быстро мы сможем набрать людей и сделать всё, чтобы их работа была высокоэффективной. В жизни нашей компании уже был пример, когда мы за полгода набрали 500 сотрудников, но способность их положительно влиять на бизнес наступила нескоро, и это привело к большим убыткам.

Поэтому везде, где можно убрать или облегчить труд людей, это нужно делать. Но вкладываться в развитие людей необходимо: в развитие их компетенций, в их мотивацию, облегчение их труда там, где это возможно. Нам не нужна производительность любой ценой. Эффективность, а именно делать всё дешево — нынче в почёте, и не только для нас, но и для наших клиентов.

Основные драйверы достижения этой цели — автоматизация рутинных операций и DevOps, внедрение нормативов, создание и развитие культуры программирования на основе принципов SOLID, развитие архитектурного и системного мышления. Одним из важных принципов стал принцип владения кодом. У кода должен быть хозяин — тот, кто любит и заботится о нём, как о своём жилище или домашнем животном. Если кто-то (например, клиент) допущен к этому коду, то только под присмотром хозяев. Хозяева — это команды, которые состоят из конкретных людей. Принцип владения распространяется на все артефакты продукта — не только на код, но и на постановки, документацию и прочее. Согласитесь, это так естественно — заботиться о своём, и так трудно об общем. Поэтому, наверное, в совхозах и колхозах был такой бардак, и так крепки были индивидуальные хозяйства. Все наши усилия не пропали даром. Только за 2018 год нам удалось поднять производительность вдвое — при том же количестве сотрудников, и этот результат мы хотим удвоить к концу 2019-го. Я уверен, что мы добьёмся цели, потому что идём к ней быстро и осознанно.

Есть такая социал-дарвинистская теория, будто полуграмотными людьми управлять гораздо легче, нежели образованными. Лично я её не разделяю, потому что для меня управление — не «вожжи», а сотрудничество. Это не отменяет ни дисциплины, ни определённой служебной иерархии (хоть и принят в компании стиль «без галстука») — всему есть своё место. И ставка на непрерывное образование никак не мешает компании быть вполне управляемой и стройной.

Да, мы любим учиться. Если кто-то и не любит, общее настроение в конце концов ему передаётся, и человек с азартом неофита начинает «вгрызаться в гранит науки». На одной из корпоративных конференций по итогам 2018 года были обнародованы цифры, показывающие интенсивность обращения сотрудников компании к нашей базе знаний. В день у нас, в «Диасофт», прочитывали более пяти тысяч страниц текста, тысячу страниц редактировали и не меньше ста — комментировали. Последние две цифры особенно показательны — они говорят об активности мышления. Наша база знаний построена на Confluence. Мы вложили много сил, чтобы спроектировать её прозрачно и понятно для всех. Здесь каждый месяц появляются новые разделы, и всё больше сотрудников компании видят в ней единый источник знаний, который обеспечивает быстрый доступ к информации. Здесь «по полочкам» разложено всё, что касается продуктов и архитектуры, постановок и готовых решений, мероприятий и обсуждений. Доступно всё — выбирай и читай, думай, делись размышлениями. Эта среда позволяет быстро вводить и делать эффективными новых сотрудников и организовывать командную работу. В 2018 году это стало для нас настоящим прорывом.

Кроме этого, «Диасофт» — читающая компания. У нас есть внутренний ресурс, где выложены сотни интересных книг по бизнесу, информационным технологиям, а ещё — по психологии и управлению. Сотрудники отмечают себя под теми книгами, которые уже прочитали, и отметки эти говорят о том, что ресурс высоко востребован. Тон, конечно, задают менеджеры компании, но есть и много рядовых сотрудников, которые не отстают. То есть мы не зацикливаемся на внутренних задачах и проблемах: снаружи мир намного богаче — его идеи и опыт сегодня открыты для всех неравнодушных и любознательных.

Никогда не устану повторять: ключевая ценность компании — наши люди. Та развивающая среда, которую мы создаём, помогает сотрудникам постоянно быть в фокусе всего самого нового и передового. Высокий уровень компетенций требует непрерывного развития — это очевидно не только для нашей компании, но и для всего рынка.

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

На самом деле, этой части книги можно было бы предпослать девиз, который стал заголовком первой главы: управляем тем, что измеряем. Потому что все так называемые секреты управления нанизываются на него, как на шампур. Посмотрите: о чём бы мы ни говорили, всё так или иначе крутится вокруг измерений. Без них невозможно рассчитать нормативы, выстроить работоспособную структуру, наладить непрерывную поставку софта заказчику, повысить производительность труда — и в целом сделать работу компании эффективной и надёжной.

То, о чём я сказал, нисколько не противоречит традиционному «гуманитарному» взгляду на управление. Потому что процессы и процедуры не бывают обезличенными — везде во главе угла стоит человек. Сама по себе управленческая иерархия столь же условна, сколь и логична. Условна, потому что в ней ценится не диктатура, не голая сила, а авторитет — интеллектуальный, профессиональный, личностный. Когда мы переходили от «водопада» к agile, самым сложным было выделить лидера в каждой из сотни кросс-функциональных команд. Если прежде это было классическое вертикальное управление, где лидером становился опытный профессионал, то сейчас действуют иные критерии, и не факт, что в каждой команде одинаковые. Казалось бы, такие критерии совсем не поддаются измерению. В цифрах — да, их не сосчитаешь. Только ведь недаром мы в обиходной речи говорим: я на него рассчитываю, по нашим расчётам и так далее. Потому что здесь тоже есть измерение, но оно не из арифметики, а из высшей, если можно так выразиться, «психологической математики».

Конечно, реформа системы управления даже средней по численности компанией в пору перемен становится серьёзным испытанием. Здесь нельзя рубить сплеча: управление —дело тонкое и деликатное. Но откладывать на потом, «когда всё образуется», тем более неправильно. И в этом тоже должен быть расчёт — разумный и логичный. Есть смысл проанализировать текущую систему, познакомиться с позитивным опытом трансформации управления, почитать те самые умные книги — и из всего этого синтезировать свою идею, которая легла бы точно (или хотя бы почти точно) на ту почву, которая ей подготовлена. Как сочетать смелость и осторожность, каждый решает сам. Но когда решение принято, его уже не обсуждают, иначе вместо реформы получится перманентный митинг, так что работать станет некому и некогда. Отсюда ещё одна тонкость: управляющий менеджер, затевая перестройку, не только сам должен меняться, но и обязан полностью принять ответственность на свои плечи. Как правило, реформу проводит не он один, а вместе с единомышленниками, но отвечать в случае чего — ему, лично. Это, знаете, как в работе с заказчиком: в случае успеха, делим его пополам, зато неудача целиком ложится на совесть вендора.

И последнее, о чём подробнее мы будем говорить в последней части книги. Не верьте тем, кто утверждает, будто «серыми личностями» управлять легче. Ничего подобного! Наш опыт убедил меня, что в хорошем коллективе, в атмосфере внимания к человеку вырастают яркие личности, работать с которыми — одно удовольствие. Так же, как и управлять ими. Потому что такое управление является сотрудничеством.