Это субъективная статья. Тезис простой: лучшие практики работают по-разному в зависимости от среды, а иногда не работают вовсе. Если вы IT-лидер или хотите им стать, вам будет интересно. Здесь мой опыт за десять с лишним лет.
Треугольник скорости, риска и доверия
IT-лидер, Head of IT, всегда находится в треугольнике скорости, риска и доверия. Это похоже на известный треугольник проектного управления «скорость – скоуп – качество». Полностью не совпадает, но общие признаки есть.
Среда определяет приоритеты: куда двигаться и что делать. Баланс этих трех величин не универсален. Представьте, что вы строите идеальный IT: супербыстрая скорость, минимальный риск и полное доверие со стороны всех вокруг и внутри и снаружи. Тут два варианта. Либо вы гений, и умеете достигать всех целей сразу, либо вы «порветесь» сами и «порвете» команду.
Поэтому все время приходится выбирать. Выбирать по факторам и переменным, которые меняются каждый день, это и есть контекст. Цена ошибки в разных средах разная. Одни и те же практики дают разный эффект. Значит, надо постоянно балансировать, думать, выбирать.
Скорость – это то, чего хотят все. Скорость изменений, ее называют time to market (TTM). Чем короче time to market, тем лучше. Чем быстрее вы делаете продукт и запускаете сервис, тем все довольнее. Скорость требуют всегда и все.
Я не видел ни одного руководителя, который сказал бы иначе. Все говорят: «У нас в приоритете time to market, хотим быстро и хорошо». Никто ни разу не сказал: «Давайте подольше, но качественнее». Тренд такой: все хотят быстро, качественно, и не готовы к проблемам на пути.
Но у скорости есть цена – это риски. Если совсем упростить, риск – это цена вашего кресла, репутации и должности. Это все те события, которые могут произойти из-за того, что вы активно двигаетесь. Развиваетесь, строите или, наоборот, не строите процессы.
Доверие – вещь эфемерная. Но все, кто был на executive-позиции, знают, о чем речь. Это эмоциональная оценка вас лично, вашей команды и продукта. Ее дают клиенты, внутренние заказчики, CEO, бизнес-заказчики, рынок. Отношение к IT, или, флер, сентимент – за этим важно наблюдать постоянно. Такое наблюдение и есть залог успеха.
Дальше – от общих слов к конкретным примерам. У меня есть практический опыт в трех средах. Первая – жестко регулируемый банк. Вторая – стартап. Третья – внутренний стартап в банке, тоже регулируемом. Последнее часто называют цифровой трансформацией: корпорация выделяет отдельное подразделение под новые рынки и продукты. Это три разные среды, и дальше я буду к ним возвращаться.
Мысль очевидная: стартап требует скорости, максимальной скорости. Скорость здесь в приоритете. Если вы в стартапе строите корпоративные банковские правила с релизами раз в квартал, вы уже проиграли. На этапе запуска это никого не устроит.
Пример из практики. Сейчас наша компания приближается к 200 тысячам активных клиентов, это уже 150 тысяч MAU. По меркам рынка бизнес еще маленький. Но есть планы вырасти до миллиона к концу года. И как только начинаются такие планы, а также требования к бесперебойности решения, контекст сразу меняется.
Теперь про банк. Заказчики приходят и говорят: надо быстро, как в стартапе, там за неделю-две все сделали. Но важно понимать одну вещь. Скорость – это не только скорость разработки и не только скорость процессов. Написать код сейчас можно быстро. Можно использовать LLM и сгенерировать приложение за 10 минут. В банке скорость упирается в другое – в процессы и правила регулируемой организации. То есть в бюрократию. О ней поговорим отдельно.
Если перестать про нее думать и не следовать правилам, вы быстро потеряете доверие. А уровень риска вырастет. В банке приходится жить по правилам. Это тоже прожито на практике. Дальше я расскажу, как можно немного за эти правила выйти. Не полностью, а чуть-чуть, за флажки.
А во внутреннем стартапе, когда большая корпорация открывает новый бизнес, самое главное другое. Это сильный бизнес-лидер. Человек, с которого все начинается. Без него ничего не выйдет. Я видел несколько примеров. Один и тот же, по сути, бизнес (но разные страны, конечно): в одном случае расцвел, в другом – откровенно валился. Вся разница, на мой взгляд, была в лидере, хотя и рынок тоже важен.
Стратегия: какую модель предлагать
Перейдем к конкретным доменам. Базовые вещи объяснять не буду. То, что стратегия отражает цели бизнеса, понятно всем. IT-стратегия светит отраженным светом от бизнес-стратегии, как луна.
Напомню о другом. Не учитывать в стратегии скорость, риск и доверие – тоже непростительная ошибка.
Приведу пример из консалтинга. Мне дают проект, я прихожу и смотрю на среду. Если это регулируемая организация – классический банк с избеганием рисков, аудитами, внутренним контролем, процедурами и заявками, – стратегия будет одна. Если это среда с единым акционером, который готов брать риск и действовать, – стратегия будет совсем другая.
Главное – понять одну вещь. Речь не про технологичность процессов и не про набор задач, инструментов, команд и вендоров. Речь про то, какую модель вообще предлагать. Какая модель приживется в конкретном месте и будет работать.
Тут есть закономерность. Скорость и качество процессов – вещи противоположные. Когда пытаешься нарастить скорость, качество процессов и бюрократии начинает страдать.
И наоборот. Там, где я видел идеальные процессы, скорость изменений низкая. Заявки заводятся, все попадает в систему управления, SLA выполняются, все работает красиво. Но медленно.
Здесь есть ловушка. IT-руководитель хочет и процессы построить, и остаться быстрым. Я сам попадал в нее много раз. Надо понимать: это палка о двух концах. Нужен баланс – минимальный набор процессов, без которых нельзя жить прямо сейчас.
На ранней стадии не нужно предлагать весь спектр ITSM-процессов под ключ. Все регламенты и правила со всеми этапами – лишнее. На зрелой стадии - наоборот.
В регулируемых организациях вы столкнетесь с процедурами принятия решений. Тендеры, аудиты, комитеты, согласования. Как лидер вы должны доносить важную мысль. Именно это чаще всего ограничивает time to market. Не разработка и не релизные процессы.
Об этом надо говорить прямо. Ограничение для скорости – это бюрократия. Lead time to decision. Если человека нанимаешь по три месяца, а сервер покупаешь две недели, скорости не будет. Говорить об этом надо очень рано. Иначе все будут смотреть не туда.
Люди и среда
Дальше – про людей.
В лидерстве я столкнулся с простой вещью: в разных средах нужны разные люди. В стартапе кажется, что можно взять экспертов из корпорации. Опытные профессионалы, хотят попробовать новое – вроде бы все получится. На самом деле нет.
Практика показывает обратное. Люди, привыкшие к бюрократической процессной структуре, плохо приживаются в стартапе. В стартапе решения принимаются на звонках и плохо протоколируются. Сегодня решили одно, завтра переопределили. A/B-тест, быстро побежали, попробовали, не получилось – сделали пивот, переобулись. Так живет стартап.
Люди из процессной среды попадают сюда и начинают стрессовать. У меня так и было. Очень сильные специалисты с хорошей экспертизой просто не приживались.
Отсюда мое личное правило по подбору команды. Для стартапов и рискованных внутренних стартапов ищите людей под неопределенность. И просите HR искать именно таких. Нестабильность – это новая стабильность. Такие люди спокойно принимают ежедневные изменения. Это отдельное качество. С HR по нему надо работать отдельно.
Есть и обратная сторона. В банках я видел очень зрелые команды. Люди по 15-20 лет на одном месте. Но безынициативные и привыкшие к процессам. Сдвинуть с ними что-либо почти невозможно.
Если вы видите такую команду, а задача – что-то менять, говорите об этом сразу. На уровне борда и первых лиц. Придется резать и принимать кадровые решения.
Две скорости IT
Есть тема, про которую вы наверняка слышали или читали. Первым тут я не буду. Это две скорости, бимодальная IT-модель.
Ситуация такая. Внутри организации, например банка, хотят что-то ускорить. Приходят акционеры и говорят: «Давай, мы готовы. Трансформируй, меняй, делай быстрее».
Ускорять всю организацию опасно. Особенно если это legacy, старый банк. Ускорять надо не все. Надо выделить два контура – бимодальную модель IT.
Суть из практики. Вы выделяете две среды. Первая - платформа: core banking, малоизменяемые и сильно зарегулированные системы. Команды здесь живут на одной скорости, медленной. Вторая – продуктовые команды. Продуктовые лидеры, продуктовый подход, другие правила и другая скорость.
Но самое важное – все это регламентировать. Записать в ВНД и правилах. Нельзя оставлять это на уровне презентации или устной договоренности: «Делаем два контура, здесь работаем так, там – эдак».
Потом прибежит аудит или проверка. И спросит: «Где документация? На основании чего приняли решение? Где регламент разработки? Где правила процесса?» По практике вероятность этого – процентов 90-95.
Поэтому в бимодальной модели уделите внимание юридически-регуляторному контуру. Это касается банка, корпорации, любой регулируемой организации. Стартапа не касается – там надо просто бежать. А в регулируемой среде это важный практический момент.
Цена ошибки
Цена ошибки везде разная. Звучит банально. Но принять это на практике тоже надо уметь.
На входе вам никто не скажет, что в стартапе приложение может лежать несколько часов и это нормально. Все будут говорить: «Нужна стабильность, бесперебойность, беспрецедентное качество». Но если вы делаете упор на скорость, часть контролей можно осознанно пропускать.
Пример. Нефункциональные требования по производительности я до какого-то момента осознанно не тестировал каждый спринт. Потом это ударило. Но ударило уже на росте. К тому времени это была другая организация и другая команда. С проблемой уже можно было работать.
На ранней стадии цена ошибки все равно сильно меньше. Вслух этого никто не признает. Но по факту это так.
В крупной организации все иначе. Цена ошибки огромная. Работает правило: лучше медленно, но хорошо. Что вы сделали медленно, все забудут. Что сделали хорошо – запомнят.
При этом и там, и там требуют и скорость, и качество. Риторика везде одинаковая. Но как идти – зависит от вас и вашего лидерства. Получить сразу все, погнаться за всеми зайцами, на практике не выходит.
Информационная безопасность
То же самое с информационной безопасностью. Про защиту думать надо с самых ранних этапов. Насколько защищен сам продукт и насколько защищен инфраструктурный периметр.
Стоит закрыть базовые сценарии: защиту от DDoS, penetration-тесты. Но сразу внедрять DLP, тяжелые процедуры и Security Operation Center не нужно. На ранней стадии это нецелесообразно.
Двигайтесь по минимуму. Сначала – практики безопасной разработки. И внимательно следите за толерантностью к риску.
Задача лидера – почувствовать момент. Прийти и сказать: «Мы дозрели, нужен следующий шаг». В этом и есть искусство управления IT.
Технологии, коробочные решения и вендоры
С технологиями та же логика. Хотя это вообще отдельная история.
Многие любят коробочные решения. Но для начинающего продукта коробка – скорее зло, чем благо. Проверено на своем опыте. Лучше делать самому на open-source-стеке, насколько это возможно, тем более, используя LLM модели и Open Source стек, можно сильно ускориться.
А для банка и корпорации коробка – зло неизбежное. Многие регуляторные требования уже закрыты готовыми инструментами. Их проще внедрить, чем писать свое, и здесь важна полнота требований и конфигурируемость решения.
Есть заблуждение, что ответственность за работоспособность можно переложить на вендора. Практика показывает обратное. Ответственность никуда не уходит. В конечном счете она остается на руководителе IT.
Пример из корпорации. Антифрод-платформу выбирали через международный двухэтапный тендер. Плюс пилот на полтора года. А в итоге она уже не пригодилась.
Поэтому с учетом бюрократии и процедур выбора подумайте десять раз. Покупать и выбирать – или все-таки попробовать внутреннюю разработку, если она возможна.
SaaS и exit-план
Есть еще SaaS. Любители SaaS в стартапах – это отдельная история.
Приведу пример. В молодом стартапе решили прикрутить готовую платформу лояльности. Чтобы не писать баллы для кредитного продукта самим.
И тут выбор. Взять зрелый выросший сервис – дорого. Взять маленький и развивающийся – надо сразу думать об exit-плане и exit-сценарии.
Маленькие сервисы часто покупают. Они и сами стартапы: продаются, меняют бизнес-модель. В какой-то момент ребята пришли и сказали: «Лояльность дальше не развиваем, нас покупает другая компания». Дело было за рубежом, не в России.
И встает вопрос: как жить дальше? Переписывать, развивать самим? Вот поэтому exit-план нужен сразу.
Такой план нужен и при выборе вендора в банке. Там надо думать о worst-case-сценариях. Нужен он и при покупке SaaS. SaaS даст быстро запуститься и запартнериться. Но уверены ли вы в партнерах на горизонте 2-3 года? Что будет, если они перестанут развивать продукт? Мысль важная.
Баланс для стартапа, банка и внутреннего стартапа
Дальше базовые вещи. Но они прожитые. И все они про баланс.
Вы начинаете новый продукт в стартапе, в нерегулируемой среде. Сильных ограничений нет. Тогда в первую очередь – скорость и продукт. Все остальное вторично.
Но несколько вещей держите на контроле обязательно.
Первое – базовая информационная безопасность.
Второе – масштаб. Что будет, если мы вырастем в два-три раза? Думать об этом надо сразу. Проектировать и разрабатывать с учетом роста.
Третье – технический долг. Его рост должен быть красным флагом сразу. Я видел много CTO, которые умеют запускать продукты и быстро выходить на рынок. Но потом долг и проблемы копятся. Продукт начинает требовать нового человека. И фаундеры или акционеры зовут таких, как я, чтобы это поправить.
Четвертое – зависимости. От SaaS-решений, внутренние и внешние. Об этом думайте каждый день.
С регулируемым банком все проще. Что бы ни говорили, управляемость, качество и стабильность важнее героизма. Документирование и процессы важнее, чем «любой ценой и намного быстрее». Даже если есть commitment. Обязательно сохраняйте след для аудитов и проверок. И требуйте того же от команды.
Про внутренний стартап скажу отдельно. Два примера, оба – массовый бизнес. Один в России, другой в Казахстане. Ситуация похожая, продукт вроде бы хороший. Но полетел только один. Потому что там был сильный бизнес-лидер. Он умел строить сам бизнес, понимал модели привлечения и добился результата. При небольшом размере банка – второе место в стране по числу привлечений новых клиентов в месяц.
Второй пример – обратный. Тот же формат внутреннего стартапа. Купили большую инфраструктуру, вложили много денег. Но с бизнес-лидером не сложилось. И бизнес не пошел.
Идея простая. Берете новую тему, которой в компании раньше не было, – сразу смотрите, с кем ее делать. Успех сильно зависит от бизнес-лидера. И от того, верите ли вы в него. Чуйка подскажет, справится человек или нет.
Хотите сохранить репутацию внутри – по возможности не работайте со слабыми бизнес-лидерами.
А под сильного лидера как раз стройте бимодальную структуру. Выделяйте отдельные процессы, регламентируйте и документируйте их. Делайте иначе, чем в основном контуре. Но документацию не забрасывайте. В такие стартапы все равно приходят сделки по поглощению, аудиты и контроль.
Контекст сильнее практик
На объективность не претендую. Это просто личный опыт.
Без рыночного преимущества и без сильного лидера IT-инвестиции не окупаются.
Еще одна вещь. В классической корпорации скорость создается контурами и бимодальностью. А не попыткой ускорить все сразу и продавить это мотивацией в стиле firedriving и жесткими KPI.
По мере роста финтеха появляются вопросы доверия – и банковского, и клиентского. Тогда практики из книжек начинают работать. Но внедрять их надо постепенно, а не с самого начала.
SaaS вас ускорит. Но сразу думайте про exit-план. Это касается и SaaS, и вендора в целом. Escrow-счета, передача кода в случае банкротства, работа с юристами.
IT-лидер все время мониторит среду: скорость, риск, доверие. Адаптивность здесь – ключевое.
Я каждый день задаю себе вопросы. Появился ли новый стейкхолдер? Вышел ли новый человек в компанию? Какие у него интересы, что он привнес? CEO бывают разные. Одни агрессивные и готовы рисковать. Другие осторожные и склонны к контролю.
Из-за этого рычажки между скоростью, риском и доверием надо менять в моменте. Подстраивать презентацию, контент и мышление.
Без этого не выжить. IT – такая штука: пока все работает, все довольны. Чуть что-то не совпало с ожиданиями – копится негатив. Скорость распада IT-директоров на нашем рынке высокая. Скорость высокая, а срок жизни низкий.
Главная мысль такая: контекст компании всегда сильнее практик. Мониторьте контекст и под него адаптируйте свои практики. Прикладным образом, каждый день. Вы, как флюгер, должны чувствовать смену контекста.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
