Полевые заметки

Клиент — не внешний заказчик

Консалтинг разваливается, когда клиент становится тем, кому вы сдаёте работу, а не тем, с кем вы думаете вместе. Вот чего мне это стоило и что это мне дало.

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

Потом в Aghigh я поставил это на промышленные рельсы. Я выстроил рабочую модель: приём брифа, определение результата, распределение, отслеживание, обратная связь, доработка, сдача. Я вёл постоянный портфель параллельных клиентских проектов и их результатов. Это работало. Но, если честно, это была машина по превращению внешних заказов в результаты в промышленном масштабе. Организация перестала быть такой машиной, только когда мы повели её к собственным цифровым продуктам — Bamana, Ketabno, HisTory, NoJahan, Mehrabani, Soha и Mastoura. Сдвиг был не от услуг к софту. Он был от получения проблемы к владению ею.

Проблема заказчика — это проблема знаний

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

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

Как это выглядит, когда работает

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

Shalize — то же самое на коммерческом рынке. Бизнес по торговле физическим золотом и серебром, работавший на сообщениях в WhatsApp, памяти и доверии. Объёмы росли быстрее, чем процесс мог их удержать. Мы перестроили операционную систему от начала до конца — запрос, заказ, выставление счетов, проверка оплаты, исполнение, сопровождение и обратный выкуп — и положили под неё CRM. Дневной объём вырос с 0,5 до 10 кг/день, а число подтверждённых покупателей превысило 4000. Эти цифры сообщены компанией и не проходили аудит, и я лучше скажу об этом сам, чем потом услышу это в свой адрес.

Фраза, которая объясняет Shalize, находится на странице с моим подходом, а не в цифрах: продажам пришлось перестать работать по памяти, и настоящим запуском было внедрение CRM, а не сайт. Это третий из моих пяти вопросов: кому придётся изменить своё поведение, чтобы это сработало? Клиенту-заказчику никогда не приходится на него отвечать. Он заказывает систему, поведение остаётся прежним, а потом во всём винят систему.

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

Что не сработало

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

Я хочу быть точным в том, что это доказывает, потому что эту историю легко рассказать как историю о клиенте, который не слушал. Это не так. Переход к физическим операциям был реальным бизнес-решением, и я был внутри группы в роли её директора по продукту и развитию бизнеса (Chief Product & Business Development Officer), а не кричал на неё снаружи. На самом деле произошло вот что: архитектура и рыночная модель уцелели и вошли в операционную систему Shalize. Сданный артефакт умер бы вместе с тем решением. Общее понимание — нет. Это самый сильный аргумент в пользу этого принципа, который у меня есть, и он пришёл из проекта, который провалился.

WritingChex — более узкая версия той же истории. Я вёл продукт от определения проблемы через проектирование MVP, разработку и валидацию, формировал логику обратной связи на основе ИИ и помогал привлечь первых платящих клиентов — первое свидетельство того, что за обратную связь, сгенерированную ИИ, вообще готовы платить. Больше всего я горжусь там не продуктом. А тем, что был честен с командой в том, где модели нельзя доверять. В 2025 году проект всё равно был свёрнут. Быть тем, кто говорит, что не работает, не спасает каждую компанию. Это просто делает вас человеком, которого стоит иметь в комнате.

Практическая версия

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

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