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

Статья предназначена для начинающих IT-предпринимателей и SPM (software project/product manager). Если вы успешный предприниматель, но вам не хватает IT-экспертизы, то для вас статья также может быть полезна. Осторожно, лонгрид.

Кейс боли

Итак, представьте себе успешного предпринимателя, у которого уже есть бизнес в какой-то достаточно консервативной отрасли. Он там неплохо зарабатывает на продаже услуг в крупный b2b - вытаскивает несколько десятков миллионов рублей каждый год в виде чистой прибыли. И ему хочется следующий порядок цифр, хочет заработать миллиард. Давно наблюдает за предпринимательской движухой в IT, и наконец созрел, чтобы сделать что-то самому.

Глядя на опыт товарищей-предпринимателей, которые успешно зарабатывают на заказной разработке с помощью Agile, он находит себе условного CTO, который берет на себя найм команды и организацию разработки. А сам CEO ищет экспертов из отраслей и начинает с ними генерить идеи стартапов на основе подписных SaaS продуктов. Когда хорошая идея найдена, CTO подбирает команду. Эксперт подключается к работе в роли постановщика задач, команда пилит продукт. CEO нанимает директора по продажам, маркетолога, и вместе с ними ищет клиентов.

Таким образом CEO запускает несколько разных проектов. Внезапно, на один из проектов находится первый клиент - из крупного b2b, приносит сразу в районе 1 млн руб MRR. CEO останавливает остальные проекты, и перебрасывает все силы и всю команду на этот проект, организует для него всю операционку по аккаунтингу и техподдержке. И его нисколько не смущает, что несколько десятков миллионов рублей, потраченных на остановленные проекты выброшено в мусорку. Ведь один из проектов оказался успешным!

Если раньше разработчики не спеша пилили условно чистый код, то тут у них начинает откровенно подгорать: баги, конфликты, продолбанные сроки, несоответствующие договоренностям фичи, и т.п. CEO успешно решает эти все проблемы в разработке, наняв нормального SPM. А сам берет в охапку директора по продажам и маркетолога и идет в рынок продавать, притаскивая всё новых и новых b2b-клиентов. Если клиент крупный, то CEO сам продает, рассказывая какая у него замечательная команда разработчиков, которая умеет пилить классные продукты. Если мелкий - его закрывает продавец с помощью ключевых фич.

На клиентов из малого b2b никто внимания особо не обращает - они тихо покупают и пользуются. Всё внимание коллектива CEO направляет на крупных b2b-клиентов, которые приносят больше всего выручки и генерят больше всего хотелок. Доходит до "смешного" - хотелки зашиваются в договор оказания услуг на этапе продажи вместе с дедлайнами и штрафами за их невыполнение. В какой-то момент CEO всерьез начинает задумываться о том, чтобы упаковывать продукт в виде коробочных решений, потому что крупный b2b это просит. Команда недоумевает - мы всё ещё делаем свой SaaS-продукт? Но продолжает пилить, потому что CEO так сказал.

В продукте огромный техдолг, в том числе из-за того, что продукт пилился под небольшой b2b (потому что эксперт был из небольшого b2b, и продукт изначально делался под небольшой b2b), а клиент пришел из крупного b2b. В какой-то момент разработчики выпиливают из кодовой базы около половины кода, потому что соответствующий функционал тупо не восстребован. Это ещё несколько десятков миллионов рублей выброшено на ветер! Не беда, ведь проект в целом вроде бы неплохо развивается.

Но чем больше крупных b2b, тем больше растет бэклог. А дедлайны заставляют масштабировать разработку. В результате стоимость владения продуктом растет гораздо сильнее, чем выручка. В какой-то момент один из функциональных блоков, который пилился под одну из таких хотелок крупного b2b, выходит в продакшн, а клиент сливается от слова совсем. Более того, независимая проверка гипотез по этому блоку не выявляет реальной потребности. Получается, что крупный b2b просто проверяет свои фантазии и безумные идеи в счет стоимости SaaS-подписки за уже имеющийся функционал. Дешево и сердито.

Наконец, после общения с профессионалами из венчура по поводу этой проблемы, CEO осознает всю бессмысленность этой гонки и резко сокращает расходы. Компания также резко становится прибыльной, естественно. Но прибыль эта такова, что совокупные инвестиции он будет возвращать по меньшей мере 50 лет. Самое грустное - CEO не получил то, зачем всё это делал. Никакого миллиарда там нет, и навряд ли когда нибудь будет.

Немного теории

Мораль этой истории в том, что даже если у вас супер классные delivery-процессы и действительно крутая команда разработки, но при этом у вас проблемы где-то в бизнесовой части, вам это всё не поможет. Я считаю, что профессионализм SPM заключается в первую очередь в том, что он умеет предотвращать неадекватный возврат инвестиций в разработку. SPM-профессионал от SPM-специалиста отличается не наличием большого практического опыта применения модных Agile-фреймворков и/или проектных методологий, а умением понимать реальные потребности бизнеса в разработке, отличать его хотелки от реальных проблем.

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

Бизнес

Разработка всегда делается для бизнеса. Даже если представить, что заказчиком разработки является частное лицо, то он/она явно хочет сделать какой-то бизнес. Scrum-фреймворк побуждает измерять бизнес-ценность и совокупную стоимость владения продуктом в разработке.

И если одним словом, то бизнес - это деньги, прибыль. Целью любого бизнеса является прибыль, которая в пределе = выручка минус расходы. Выручка (она же оборот, revenue) - это количество денег, которое бизнес собирает с рынка за определенный период. В самом простом варианте это средний чек за продукт, помноженный на кол-во продаж. Когда мы отнимаем расходы определенного типа из выручки, получается определенный тип прибыли.

Например, есть переменно-прямые расходы (ППР). Они же прямые расходы, расходы по прямым, переменные расходы, варкосты (varcost), себестоимость. Это такие расходы, которые прямо-пропорционально зависят от продаж. Есть продажи - есть ППР. Нет продаж - ППР равны нулю. Для примера, в традиционном бизнесе это сырье, закупочная стоимость. В IT-бизнесе это CAC (цена привлечения платящего клиента), процент продавцу. После вычета ППР образуется валовая прибыль. Она же валовый доход, маржинальный доход (gross margin).

Есть условно-постоянные расходы (УПР). Они же косвенные расходы, операционные расходы, фикскосты (fixcost), опэксы (OpEx). Есть продажи или нет продаж - УПР всё равно есть. Но без них бизнес в принципе не работает, потому что кто-то (что-то) должен делать (обеспечивать, поддерживать) оборот. Обычно это офис, фонд оплаты труда, и т.п. Эти расходы всё же зависят от продаж, но не напрямую, а косвенно. Например, чем больше у вас торговых точек, тем больше нужно персонала. После вычета УПР из валовой прибыли образуется операционная прибыль. Она же EBIT/DA, операционный доход. Ну и дальше вычитаются все остальные расходы, но для нас сейчас это не так важно. Все это надо рассчитывать не кассовым методом, а методом начисления.

Есть ещё один важный для нас сейчас вид расхода: капитальные затраты. Они же капэксы (CapEx). Они бывают разные. Нас интересует те, которые про основные средства (ОС). Их ещё можно назвать инвестициями в основные средства. Если вы закупите какой нибудь коробочный софт, например, bitrix24, то в бухгалтерии он скорее всего пройдет как закупка основных средств. Если же вы купите тот же bitrix24 в виде подписки, то она пойдет в УПР.

И если все вышеперечисленные расходы бизнес несет для того, чтобы получить соответствующий вид прибыли, то инвестиции в основные средства не предназначены для получения прибыли в моменте. Они нужны для того, чтобы увеличить эффективность бизнеса за счет сокращения УПР. Это очень важно понять. Дело в том, что средний чек, ППР и, соответственно, маржинальность бизнеса целиком и полностью диктуется рынком и поделать с этим ничего нельзя. Можно сделать ресегментацию, сменить рынок, но невозможно изменить маржинальность бизнеса в конкретном сегменте. Как предприниматель, вы можете в существующем продукте/сегменте существенно влиять только на два параметра: УПР и кол-во продаж. Любые успешные усилия по изменению ППР или среднего чека приводят к появлению нового продукта технологически (continuous innovations) или рыночно (discontinuous innovations).

Если вы не имеете предпринимательского опыта, то это всё может показаться сложным. Поэтому я приведу простой пример. Кофейный автомат, в котором многие из вас когда нибудь покупали горячий вкусный кофе утром по дороге на работу. Давайте представим, что у вас нет кофейного автомата, но вы хотите заработать на продаже свежего кофе. Средний чек - 35 руб, это цена вашего продукта (одного стаканчика кофе). Допустим в сутки покупатели выпивают 40 таких стаканчиков. В месяце 28 рабочих дней, значит месячная выручка с бизнеса на одной точке: 35 * 40 * 28 = 39.2 тыс руб. Себестоимость одного стаканчика кофе - 8 руб 75 коп. Это значит, что с каждой проданной порции кофе вы забираете в виде валовой прибыли 75% (8.75 руб себестоимости поделить на 35 руб цена порции кофе и умножить на 100%). Вроде бы очень крутая маржинальность. Но не спешите с выводами, посмотрите на УПР такой точки.

Аренда - 5.8 тыс руб, прочие УПР (бензин и т.п.) - 1.5 тыс руб, зарплата баристы - 15 тыс руб (кто будет работать за такую ЗП???). Итого УПР точки - 22.3 тыс руб. Операционная прибыль точки: 39.2 тыс руб (месячная выручка) минус 9.8 тыс руб (ППР) минус 22.3 тыс руб (УПР) = 7.1 тыс руб. Операционная доходность точки, её ещё можно назвать рентабельностью, рассчитывается также в процентах, как и маржинальность: 18% (7.1 тыс руб операционной прибыли делить на 39.2 тыс руб выручки и умножить на 100%). Вроде бы всё ещё в пределах нормы для российских реалий. Путем увеличения кол-ва торговых точек, вы можете растить бизнес. Например, с 10 таких точек вы уже будете зарабатывать 71 тыс руб операционной прибыли.

Но вот вы смотрите на зарплату, с позволения сказать, баристы, который забирает 38% выручки (15 тыс руб ЗП делить на 39.2 тыс руб), не считая всяких соц взносов, НДФЛ и геморроя с текучкой (найм, обучение и т.д.). Что если купить кофейный автомат и сэкономить на зарплате?

Нормальный кофейный автомат стоит 450 тыс руб. Также является продуктом, а с точки зрения бизнеса - основным средством производства, эксплуатируется 5 лет (потом надо покупать новый). Полностью заменяет баристу, то есть снижает УПР. В данном случае сильно снижает. Расчет возврата инвестиций в пределе отвечает на вопрос "Как быстро вернутся вложения в этот автомат?". Делим инвестиции на зарплату баристы и получаем кол-во месяцев: 450/15 = 30 месяцев (2.5 года). Получается, что заменив баристу на автомат, вы повысили рентабельность точки с 18% аж до 56%, но вы её увидите только через 2.5 года, когда инвестиции в автомат полностью вернутся в виде сэкономленной операционной прибыли.

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

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

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

По моему скромному мнению, это зависит от роли разработчиков в конкретный момент времени. Если они уже запилили продукт, и работают в качестве второй/третьей линии техподдержки, время от времени подчищая баги и архитектуру продукта, то это УПР. Если они находятся в процессе разработки какого-то важного бизнес-заказа, то это инвестиции. Логично и систему вознаграждения построить соответствующую. Например, если продукт в бой пока ещё не выведен (идет разработка первой версии), логично платить только из бюджета конкретного релиза (проекта). Когда продукт уже в бою, то нужно вводить какой-то фикс за его сопровождение и поддержку из соответствующих фондов УПР. Если одновременно и активная разработка релиза (проект) и поддержка продукта в бою, то это одновременно и вознаграждение из бюджета проекта и фикс из фондов УПР.

Я уже несколько раз употребил слово продукт, и пока ещё не дал его определения. Но это слово уже прозвучало в двух совершенно разных контекстах. Стаканчик кофе - продукт, и кофейный автомат тоже продукт, который производит стаканчик кофе, как продукт. Если представить себе разработчиков кофейного автомата, то какой продукт они пилят? Может быть они пилят одновременно оба? Для кофейного автомата вопрос может быть и абсурдный. Но если мы посмотрим на то, чем занимаются современные продуктовые команды в IT-разработке, то абсурдным может показаться не вопрос, а ответ на него.

Продукт

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

Таким образом, продукт - это то, что можно обменять на деньги. Добровольно эти деньги отдадут за какую-то ощутимую пользу, выгоду, ценность. Этим продукт существенно отличается от проекта. Проект по существу имеет лишь три параметра: объем работ, бюджет и срок. Тогда как у продукта может быть много важных параметров, которые отражают его ценность для заказчика. Более подробно о 4-х основных рыночных типа продукта я рассказываю в отдельной статье про бизнес-модель. В этой же статье мы подразумеваем, что IT-разработка - это всегда 1-й тип продукта, проект.

Коль скоро в проекте есть бюджет, то есть деньги, значит там также есть продукт? Вроде бы логично. Но почему тогда так много успешных проектов, результаты которых либо не восстребованы совсем, либо возврат инвестиций мог бы быть явно получше? Я уверен, в большинстве случаев причина в том, что качество управления проектом в части его бизнес-ценности оставило желать сильно лучшего. Поскольку ценность - это результат решения проблемы, бизнес-ценность - это бизнес-результат решения проблемы бизнеса. Какие проблемы бизнеса решаются с помощью IT-разработки?

Одну категорию я уже упомянул: высокий УПР. Например, биллинг 30-ти b2b-клиентов ежемесячно требует на 2-3 дня выключить секретаря и старшего менеджера техподдержки, которые вручную выгружают и обрабатывают статистику поведения клиентов в системе, чтобы затем сгенерировать и выставить счета на оплату. Да, они жалуются CEO, что этот ручной мартышкин труд содержит риск ошибки, из-за чего всё приходится по нескольку раз перепроверять, и поэтому давно уже пора всё автоматизировать. CEO в свою очередь успешно "кормит их завтраками", потому что он вообще-то им за эту работу платит зарплату.

Но главное - CEO понимает, что возврат инвестиций от этой разработки будет неадекватный по следующей причине. Допустим разработка биллинга будет стоить 1 млн руб. После внедрения трудозатраты сотрудников на биллинг будут сокращены до нуля. В результате, сотрудники выдохнут и распределят освободившееся время на отдых и другие задачи. Зарплата у них не изменится, увольнять их никто не собирается. Какой был смысл тратить 1 млн руб? В чем выгода? Непонятно.

Друге дело, когда бизнес активно растет и в течение года в вышеприведенном примере количество клиентов вырастет в 10 раз (30 -> 300). Тогда биллинг становится проблемой, узким местом, блокирующим рост бизнеса. Скорее всего, биллинг будет не единственной проблемой, поэтому есть смысл говорить о некотором перечне узких мест, которые заблокируют рост на разных этапах в некоторой последовательности. Это уже вполне конкретная потребность бизнеса в интеграции каких-то средств автоматизации конкретных бизнес-процессов с понятной бизнес-ценностью. Причем решением этих проблем могут быть как своя кастомная разработка, так и готовые решения, подписные сервисы. А может быть и некоторый микс.

Помимо внутренних операционных проблем, рост бизнеса может быть заблокирован также плохим пользовательским опытом клиентов бизнеса, а точнее пользователей клиента, что также является узким местом. Например, MVP стоматологической CRM-системы выглядит как списки пациентов на возврат в клинику, которые формируются вручную из их мед карточек вместе со скриптами звонка. Администратор клиники работает по списку в течение 1-2 недель, затем получает новый список и т.д. Помимо очевидной потребности в автоматизации процесса генерации списков, чтобы брать на борт большее кол-во стоматологий, собственникам и глав врачам клиник хочется наблюдать за процессом возврата пациентов не раз в 1-2 недели с бумажного отчета, а каждый день и час с мобильного телефона. Администратору клиники хочется всегда иметь перед глазами актуальную картинку по загрузке в виде матрицы кресел. У пациентов случается вау-эффект, когда им показывают план лечения на понятном для них языке и им хочется сохранить его себе в телефон и актуализировать по мере лечения. И так далее, и тому подобное.

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

Дело в том, что любой сегмент/рынок поделен на категории клиентов по степени осведомления, проблематизации. Можно выделить 5 основных категорий:

1. Приготовили бюджет, активно ищут решение, вследствие чего неплохо знают рынок.
2. Состряпали своё решение, рынок знают плохо.
3. Признают наличие проблемы, но ничего не делают для её решения.
4. Отрицают наличие проблемы, хотя при её выявлении соглашаются потратить деньги на решение.
5. Отрицают наличие проблемы, и не хотят покупать решение, даже если проблема проявляется.

Рынок естественным образом переключается на новое решение последовательно по этим 5-ти категориям: от 1 к 5. И чем ниже по списку, тем меньше острота проблемы и, соответственно, меньше готовности менять свои привычки и потребительский опыт. И если первые/вторые жаловались на неудобства, но покупали и пользовались неудобными версиями продукта (как, например, вышеупомянутый MVP стоматологической CRM-системы), то третьи и дальше жалуются и отказываются переключаться с текущих проблемных решений на предлагаемое. Им требуется сильно повышать скорость, привлекательность, удобство и т.п. составляющие пользовательского опыта.

Кроме сугубо рыночной классификации клиентов, в которой один и тот же человек может вести себя совершенно по разному в зависимости от конкретной потребности и контекста/момента, есть ещё личностная потребительская характеристика, которая принадлежит каждому человеку и не меняется с течением времени:

1. Технологические энтузиасты. Эти клиенты покупают и пользуются продуктом, даже если не получают никакой ценности. Их привлекает сам подход, новая технология. В любом рынке есть 1-2% таких клиентов. Они очень любопытные и всегда охотно экспериментируют.
2. Ранние последователи. В отличие от технологических энтузиастов, эти клиенты хотят получить радикальное преимущество за счет нового продукта. На рынке есть 12-15% таких клиентов. Они хотят и любят быть первопроходцами, и по этой причине достаточно легко принимают риск и меняют свои привычки.
3. Ранний массовый рынок. 30-35% клиентов на рынке. Держат нос по ветру, позитивно реагируют на новые продукты. Но, в отличие от ранних последователей, они не готовы рисковать, чтобы получить какую-то выгоду для себя. Они ищут мягкий безопасный эволюционный путь развития.
4. Поздний массовый рынок. Также 30-35% клиентов. Негативно реагируют на инновации. Однако, когда распробуют, без проблем расстаются со своими привычками и принимают новое.
5. Отстающие. ~15% клиентов. Покупают новый продукт только потому, что больше не могут пользоваться старым.

Каждая следующая категория требует всё более и более хорошего пользовательского/потребительского опыта, а также расходов на привлечение. Казалось бы, зачем заморачиваться с 3-5 типами? Причины две: там находится 85% рынка и они будут вас поддерживать деньгами даже тогда, когда 1-2 убегут в другой рынок. Более подробно про эти типы клиентов рекомендую почитать в книге Джеффри Мура, "Преодоление пропасти".

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

Заказчик

Может ли физическое лицо заказать разработку? Нет, если только он (она) не преследует какие-то бизнес-цели, пусть даже самые далекие. Поэтому IT-разработка всегда про бизнес. К какому типу продукта из вышеперечисленных 4х относится IT-разработка? К проекту, очевидно. Поэтому всегда приходится объяснять ценность и измерять возврат инвестиций.

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

Таким образом, причина проблем в разработке в том, что заказчик, который реально отвечает за возврат инвестиций в разработке:

1. В полной уверенности, что расходы на разработчиков - это УПР, и поэтому видит проблему неадекватного возврата инвестиций слишком поздно.
2. Отгорожен от принятия решений в разработке на 1+ человек, и поэтому не может увидеть всю абсурдность этих решений, ошибочно полагая, что причины неадекватного возврата инвестиций заключаются в низкой квалификации персонала.

Поиск такого заказчика на стороне бизнеса и включение его в работу является основным фактором успеха IT-разработки. Давайте разберем эту роль подробнее и попытаемся ответить на вопрос о том, как его находить.

Статья в разработке...