ИТ-сообщества давно перестали быть площадками для обмена мнениями. Теперь это сложные экосистемы, где сталкиваются и рождаются новые смыслы. Но в этой живой, пульсирующей среде есть фундаментальная проблема: участники часто говорят на одном языке, но живут в разных реальностях. Один делится опытом «успешного внедрения Agile» в стартапе, другой — «создания отказоустойчивой архитектуры» в банке. Оба правы, но их опыт зачастую непереносим, потому что скрыт главный компонент — контекст.
В интервью с «Компьютеррой» Владислав Котов, руководитель направления бизнес-анализа ВТБ рассказывает об авторском инструменте «Крест Котова» — модели, которая родилась из попыток структурировать выступления спикеров и стала универсальным инструментом понимания контекста в ИТ и других областях.
Задача и контекст
— Какую задачу вы пытались решить и почему инструмент получил такое название?
Изначально я искал решение не для себя — я пытался улучшить качество общения внутри ИТ-сообществ. Ведь конференции, митапы, хакатоны — это не просто мероприятия, а среда, где знания должны трансформироваться в практику. Но без общего языка о контексте даже самые яркие кейсы остаются «витриной», а не инструментом. «Крест Котова» стал попыткой дать сообществу такой язык — не для сравнения, а для сопоставления.
Я начал искать способ помочь спикерам четко описывать, откуда они берут свои выводы. Постепенно у меня сформировался инструмент — схема, которая помогает понять, в каком мире ИТ работает человек или команда, и каким именно опытом делится спикер.
Коллеги, друзья, с кем я делился этим подходом, начали называть его «Крест Котова». Так и закрепилось — в честь меня и формы схемы, которая действительно похожа на крест.
— В каких ситуациях вы использовали этот инструмент и какие выводы сделали за годы практики?
Основное применение этот инструмент нашел при подготовке выступлений и на собеседованиях.
Схема помогала спикерам быстрее понять, о чем они на самом деле говорят. Вместо общих фраз вроде «мы делаем продукт» они начинали уточнять: для себя или для клиента, свой ресурс или чужой, массовый продукт или индивидуальный заказ. Это делало доклады точнее и полезнее.
Но самое интересное началось, когда я стал использовать этот подход на собеседованиях. За свою карьеру я провел огромное количество интервью — и как кандидат, и как интервьюер, и почти всегда навыки оценивались без контекста. Например:
— Вы знаете SQL?
— Да.
— Отлично.
Но потом оказывалось, что один человек писал запросы для BI-аналитики в продуктовой команде, а другой делал отчеты для Project Manager. Один работал с миллионами строк, другой — с одним готовым скриптом. Один оптимизировал запросы, другой — просто копировал шаблоны. Один и тот же навык был основан на совершенно разном опыте.
Без понимания контекста нельзя понять, подойдет ли человек, рассматриваемой для него роли, команде и стоящим вызовам. Я начал задавать вопросы: «А где вы это делали?», «Для кого?», «С какими ограничениями?» — и все становилось на свои места.
Ценность для ИТ-команд
— В чем заключается значимость этого подхода для ИТ-бизнеса?
В ИТ все давно говорят про «продукт», «гибкость», «разработку», «цифровизацию», «автоматизацию». Но за одинаковыми словами часто скрываются совершенно разные реальности.
Команда, которая строит внутреннюю систему для банка, работает в других условиях, чем та, что выпускает мобильное приложение для миллионов пользователей. Разработка под заказ — это не то же самое, что создание SaaS-продукта. То, что сработало в одной компании, может провалиться в другой — просто потому, что контекст другой.
Именно это и делает подход ценным: он помогает не просто восхищаться чужим опытом, а понимать — подойдет ли он вам и в какой мере. Вместо слепого копирования практик вы получаете возможность задать правильные вопросы: «А в каких условиях это работало?», «Какие цели стояли?», «Какие ограничения были?»
Особенно это важно сейчас, когда ИТ-сообщества стали основной средой обмена знаниями. Конференции, митапы, онлайн-дискуссии — все это не просто площадки для общения, а место, где формируются профессиональные ориентиры. Но если в таком пространстве нет общего способа описывать контекст, то даже самый полезный кейс остается непереносимым. Вы слушаете: «Мы внедрили CI/CD и ускорили релизы в 5 раз» — но не знаете, была ли у них команда из 5 человек или 200, регулируемый ли это сектор, внутренний ли продукт или внешний. Без этого информация теряет львиную долю своей ценности.
То же самое — и при найме. Сегодня резюме и интервью зачастую строятся вокруг общих формулировок: «опыт в бизнес-анализе», «работал с Agile», «делал аналитику данных». Но что это на самом деле значило? Один кандидат вел согласования в условиях жесткого регулирования, другой — гибко менял требования в стартапе. Один работал с готовыми метриками, другой — сам их придумывал и внедрял. Без понимания контекста невозможно оценить, насколько опыт релевантен вашей задаче и роли.
Используя «Крест Котова» при подготовке вакансий и собеседований, мы можем точнее сформулировать ожидания и быстрее находить тех, чей опыт действительно совместим с нашей реальностью. Это снижает риски несоответствия, экономит время всех участников процесса и помогает кандидатам честно понимать — подходит ли им эта работа, а не просто «звучит престижно».
— В каких сферах за пределами ИТ этот подход также может быть полезен?
На самом деле, идея простая: один и тот же навык в разных условиях — это разные вещи.
Представьте, что вы ищете репетитора по математике. Один преподавал в школе, другой — готовил к ЕГЭ, третий — обучал студентов в вузе, четвертый — проводит курсы онлайн. Все «преподают математику», но контекст разный. И если вы хотите подготовить ребенка к экзамену — вам подойдет не каждый из предлагающих свои услуги.
То же самое с менеджерами, дизайнерами, инженерами, врачами. Опыт без контекста — это как рецепт без указания, как ингредиенты блюда использовать.
«Крест Котова» — это попытка сделать такую «упаковку» к опыту: не просто «я умею», а «я умею — и вот в каких условиях». Этот инструмент можно переформулировать для любой отрасли и задачи.
Система координат
— Какие ключевые элементы включает этот инструмент?
Схема построена так, чтобы начинать с самого главного — с цели — и постепенно переходить к конкретике.
В центре всей системы находится сам ИТ-бизнес. Не технологии, не команда, не проект, а именно бизнес, цели его существования, ценности, целевая аудитория и задачи, которые он решает. Это фундамент, ведь без четкого ответа на вопрос «Зачем?» любая деятельность теряет ориентиры, а опыт становится непереносимым. Именно отсюда начинается вся классификация.
Сразу после центра идет первый уровень — данные, которые нужны, чтобы понять, как работает этот бизнес и на основе чего в нем принимаются решения.
Важно понимать, что данные не универсальны. То, что критично для одного типа деятельности, может быть совершенно нерелевантным для другого. Например, команда, которая делает внутренние инструменты, будет смотреть на метрики эффективности, простои и нагрузку сотрудников. Продуктовая команда, выходящая на рынок, анализирует поведение пользователей, удержание, конверсию. А команда, работающая на заказ, — ориентируется на сроки, бюджет и обратную связь от клиента.
Контекст определяет, какие данные имеют значение, а какие — шум.
Следующий уровень — это способы анализа и финансовые инструменты. Здесь проявляется еще одна грань различий. В зависимости от типа бизнеса, используются разные подходы к оценке эффективности. Если вы создаете продукт для массового рынка, вы считаете LTV, CAC, ROI. Если вы оптимизируете внутренние процессы, вы смотрите на TCO — общую стоимость владения решением. Если вы реализуете заказной проект, вас интересует рентабельность, маржа, сроки выполнения.
То же самое с методами. A/B-тесты уместны там, где много пользователей, но бессмысленны в проекте для одного клиента. Анализ затрат важен для внутренних инициатив, но может не учитывать волатильность рынка. Выбор инструментов анализа — не только технический вопрос, а следствие контекста.
Четвертый уровень — классификация спонсоров и пользователей. В этом секторе находится ответ на вопрос «Кто финансирует деятельность и кто ею пользуется?». Иногда это один и тот же человек, а иногда — совершенно разные стороны.
Внутренняя система может финансироваться руководством, а использоваться сотрудниками отдела. Заказной проект оплачивает клиент, а пользуются им его клиенты. Продукт на рынке может покупать один человек, а использовать — целая команда.
Понимание этой разницы помогает правильно ставить задачи, выстраивать приоритеты и оценивать успех. Не все пользователи — платящие, не все платящие — конечные пользователи. И это напрямую влияет на то, как вы проектируете, развиваете и измеряете результат.
Внешний слой схемы — это четыре основных направления ИТ-деятельности, образующие крест:
- Сверху — разработка для себя, когда команда создает решения для внутренних нужд компании. Ее цель в улучшении своих процессов, снижении издержек и повышении эффективности.
- Снизу — разработка для клиентов, когда работа ведется на заказ. Это может быть внедрение, доработка или создание уникального решения под конкретные требования.
- Слева — стандартизированный продукт, масштабируемый на рынок. Это коробочное ПО, SaaS, приложения, которые продаются многим и приносят доход как самостоятельный бизнес.
- Справа — разовое решение, уникальная разработка, созданная для того, чтобы закрыть конкретную задачу или боль. Оно может быть одноразовым, а может стать основой для будущего продукта.
Вся схема работает как единое целое. Вы начинаете с цели, затем смотрите, какие данные и инструменты анализа уместны, понимаете, кто вовлечен, и, наконец, определяете, в каком из четырех миров вы находитесь. Это позволяет не просто описывать деятельность, а осознанно позиционировать ее, сравнивать с другими, оценивать применимость опыта.
При этом в больших корпорациях часто смешиваются разные типы ИТ-бизнеса: инженеры даже внутри одной компании живут в разных контекстах и обладают разным опытом — кто-то работает в поддержке или сопровождении, кто-то в Change или Run, кто-то ориентирован на стратегию. Именно поэтому важно понимать, в каком «мире» и с какими практиками работает конкретная команда или специалист.
Пусть инструмент ветвится
— Планируете ли вы развивать инструмент? Если да, то каким образом сообщество может участвовать в развитии и адаптации этого инструмента?
Я не считаю, что «Крест Котова» — это законченная схема. Наоборот, инструмент должен расти и меняться. Мне важно, чтобы:
- люди пробовали его применять в своих компаниях;
- придумывали свои версии — например, для команд ML-инженеров, DevOps, HR;
- делились кейсами о том, где он помог, где не подошел, что можно улучшить;
- развивали его, делали шаблоны, анкеты и интерактивные версии.
Хочется представить, что любой доклад на митапе или конференции начинался не с «привет, меня зовут…», а с краткого указания позиции на «Кресте Котова»: «Мы — команда в B2B-секторе, делаем продукт для внешнего клиента, с фиксированным бюджетом и регуляторными рамками». Это заняло бы 30 секунд, но сэкономило бы часы недопонимания.
Я не хочу «запатентовать» идею, а нацелен на то, чтобы она стала полезной для всех. Потому что когда мы начинаем понимать контекст, мы перестаем спорить о том, кто прав. Мы начинаем понимать, почему кто-то делает именно так и какой опыт можно переиспользовать.