Многие предприниматели верят в то, что масштабирование возможно только через IT. И поэтому вкладывают в разработку своего IT-продукта. И часто сначала это продукт для своего бизнеса: предприниматель пытается решить какие-то конкретные проблемы своего бизнеса, чтобы потом продать IT-решение другим предпринимателям и на этом заработать. Иначе говоря, IT-продукт разрабатывается как часть другого не-IT продукта, но с прицелом выделиться в самостоятельное IT-решение.

В такой ситуации есть два варианта разработки:
1. нанять разработчиков и управлять разработкой самостоятельно
2. найти уже готовую команду разработчиков (студию) и договориться с ними

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

Причем эти проблемы появляются при любом из двух вышеупомянутых вариантов. Конечно, бывают толковые команды без этих проблем. Но это если повезет - вероятность 2 или даже 1 из 10-ти.

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

Получается, что из-за отсутствия опыта управления разработкой в iT предприниматель рискует в итоге получить чемодан без ручки - и нести практически невозможно, и бросить жалко (уже столько денег вложил в него).

Как можно предотвратить появление этих проблем без необходимости на годы уходить в дорогостоящий образовательный процесс? Каков минимально необходимый набор знаний? Где приобрести эти знания?

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

Итак, чтобы IT-продукт стал управляем, нужно сначала расписать карту продукта (его смыслы, внутрянку):
- Ценность продукта. Зачем это всё надо бизнесу, в чем измеримая выгода.
- Функционал максимум. Это картинка целевого состояния - к чему идем.
- Функционал минимум. Чем можно обойтись на начальном этапе.
- Промежуточные этапы функционала (если необходимо).
Затем, на каждом этапе исходя из функционала прикидываем, какие ресурсы и в каком объеме нужны. И уже из этого рассчитываем расходы и бюджет на разработку и поддержку. Уже здесь появляются интересные инсайты и принимаются решения.

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

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

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

Многие из вас знают меня, как Scrum Master из компании MSTLab24. Я пришел в эту компанию в 2016 году под запрос CEO на Agile. И вроде бы всё логично: продукт уже есть, продажи уже есть - можно выделить роль PO/CPO и делегировать ему оптимизацию продукта по метрикам. Но как оказалось, метрик ещё нет, как и проблем в бизнесе, но есть проблемы с продуктом и его разработчиками:
- есть критичные баги, которые не исправляются месяцами
- обещанные сроки по фичам регулярно и местами сильно продалбываются
- фичи выходят не совсем такими (или совсем не такими), как договаривались с CEO
- разработчики пугают CEO непонятными словами и часто отказываются делать как надо
- разработчики сидят в разных комнатах одного помещения, но координируются друг с другом через CEO или руководителя саппорта (который находится в другом городе!)
- большинство разработчиков не могут уйти в отпуск (незаменимые)
- и др.

За несколько месяцев мне удалось стабилизировать команду разработчиков, потушить пожары. CEO с радостью углубился в продажи и компания выросла по выручке в несколько раз. Переформатирование команд разработчиков из компонентных в кросс-компонентные системно решило проблему коммуникаций и незаменимости. Затем мы заменили Scrum-фреймворк на Kanban-метод в управлении разработкой, и это дало кратное сокращение по времени поставки, количество дефектов вместе со временем их исправления также сильно снизились.

Однако, улучшения в разработке не дали ожидаемого улучшения в бизнесе. CEO хотел кратный рост по капитализации, но было очевидно, что этого не происходит. А происходило следующее.

На демо продукта при продажах потенциальные клиенты указывали на отсутствие нужного им функционала. Часто после закрытия сделки запросы на эти доработки становились частью договора вместе со сроками и ответственностью за их невыполнение (особенно в случае среднего и крупного b2b). Даже после их добавления в продукт, клиенты генерировали ещё (время идёт, их компании меняются). И поскольку CEO понимал, что может потерять их бюджеты, он был вынужден соглашаться на новые доработки. Бэклог продукта по сути состоял из множества разных, часто ломающих архитектуру продукта, хотелок разных клиентов со сроками, спущенными команде сверху.

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

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

Я до сих пор помню, как на моих глазах один из разработчиков за ненадобностью удалил из кодовой базы около половины (!) работающего покрытого тестами кода, чтобы сократить расходы на его поддержку при разработке. Это через 3 года после начала разработки. Это десятки миллионов рублей!

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

Справился ли я с IT-разработкой в бизнесе? Да, безусловно. Об этом красноречиво свидетельствует отзыв самого CEO:

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

Доволен ли я своей работой? Нет, потому что моему работодателю легче от этого не стало. Я понял, что какой бы эффективной ни была разработка, проблемы в бизнесе могут свести к нулю весь положительный эффект. Поэтому в 2020 году я ушел в трекинг предпринимателей и стартапы супер-ранней стадии, чтобы приобрести максимум продуктовой экспертизы.

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

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

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

Или нужно было выявить узкий сегмент рынка, который соответствует изначальной экспертизе и запиленному продукту. Затем выявить работающее в нем ценностное предложение и, перенастроив весь маркетинг и продажи только в него, активно расти, заворачивая всех остальных в какую нибудь автоворонку. Добежав до ТБУ в сегменте, переключаемся на следующий: делаем продукт для него и растем. Затем также следующий и так далее. Если надо, привлекаем нужных экспертов по пути.

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

Если ты коммерческий директор в производстве фармацевтических товаров и твоя компания успешно вышла в одну или больше торговых сетей, то наверняка у тебя проседают продажи из-за несоответствия выкладки товара в точках твоим стандартам (особенно по драйверам продаж). Это бывает как по вине твоей торговой команды (торговые представители, мерчендайзеры), так и по вине торговой сети. Ты делаешь периодический недешевый аудит состояния выкладки, но проблема в том, что аудиторами можно покрыть 3-5% территории за раз. В результате, ты не можешь эффективно воздействовать на продажи, потому что банально нет актуальной картинки по территории.

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

Достоверность данных гарантируется системами защиты от подмены фото и местоположения. Техподдержка для тебя и твоей команды работает на телефоне с 8 утра до 8 вечера.

Цена: 100 руб за торговую точку. Вот тебе демо приложений - бесплатно попробуй на небольшой части твоей территории. Затем можно платить картой в приложении.

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

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

1. Кто будет покупать мой продукт? (клиент, ЦА)
2. Какую задачу клиента решает мой продукт?
3. Как сейчас клиент решает эту задачу без моего продукта? (существующее решение)
4. Чем существующее решение его не устраивает?
5. Как выглядит идеальный клиент, которого оно не устраивает так сильно, что он пробует состряпать своё решение или активно ищет альтернативу, приготовив бюджет? (ядро ЦА)
6. Как у него устроен процесс принятия решения о покупке? (кто и как влияет)
7. Как я предлагаю клиенту решать задачу с моим продуктом? (моё решение)
8. Сколько денег и времени клиент потратит на моё решение (включая затраты на мой продукт)?
9. Что изменится у идеального клиента в результате покупки моего решения? (выгода)
10. Почему клиент захочет использовать в решении именно мой продукт? (core-экспертиза)
11. Какие факты у меня есть в подтверждение ответов на эти 10 вопросов?

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

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

Есть расхожее выражение - без ТЗ результат ХЗ. Да, если совсем не писать ТЗ, то на выходе получим непредсказуемый результат за непредсказуемые сроки и вложения. Но если неправильно писать ТЗ, то результат будет не лучше.

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

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

Ближе к сдаче у разработчиков стали вылазить вопросы по ТЗ, ответы на которые сдвигали сроки. Иногда это происходило по вине студии - чего-то недопоняли и приходилось переделывать. Иногда по вине заказчика, который вместе с ответами уточнял и корректировал ТЗ. Исходное ТЗ в итоге во многом стало неактуальным. В системе контроля множились новые задачи, которые по неведомой для заказчика причине, делались в разы медленнее, чем раньше. Печальный итог выше описан. Подробное ТЗ не помогло заказчику избежать проблем.

Причины две:

1. Сломаный телефон, который возник из-за необходимости два раза переводить ТЗ с языка бизнеса на язык технарей. Заказчик говорил менеджеру, тот говорил с техническим директором, а тот уже ставил задачи на разработку.

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

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

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

Но стандартный формат ТЗ по ГОСТ 19 или 34 не годится в этом случае. Мы либо не сможем описать весь функционал и будем вынуждены писать ТЗ только на ближайшую поставку, рискуя нарваться на конфликты и переделку в последующем. Либо ТЗ просто потеряет актуальность, потому что обновлять его по ходу дела очень сложно.

Как же надо писать ТЗ, чтобы оно было полным и при этом его можно было легко менять в процессе?

В любом ТЗ есть 5 слоев информации:
1. Измеримый бизнес-результат разработки. Это ответ на вопрос - зачем это надо заказчику?
2. Текущий пользовательский опыт. Как сейчас заказчик обходится без продукта?
3. Целевой пользовательский опыт. Кем и в каких ситуациях будет использоваться продукт?
4. Функционал. Как будет работать программный продукт?
5. Спецификация. Как технически будет реализован продукт?

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

Для описания функционала уже лучше применить более специализированные, User Story Map совместимые инструменты (Kaiten, StoriesOnBoard и др.), которые разработчики уже могут связать со своей системой контроля и сделать необходимую оценку по затратам. Текстовый файл по ГОСТ из этого делается на раз-два, а вот наоборот уже сложно.

Самое важное. Приоритеты по функционалу (что делается сначала, а что потом) должны исходить не от технарей, а от заказчика. Для этого в ТЗ и присутствуют слои 1-3, в которых закопано большинство подводных камней.

Заказчику заранее следует спросить себя - какие 20% функционала дают 80% бизнес-результата? Ответы чаще всего влекут изменения в ТЗ вплоть до удаления некоторых элементов. Работа ещё не началась, а заказчик уже сэкономил деньги.

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

Кстати, план поставок продукта можно отразить в User Story Map с помощью релизов, по каждому из которых заказчик получит отдельный срок и бюджет.

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

Друзья, используйте правильный формат описания ТЗ, чтобы получить нужный результат в ожидаемый срок и бюджет.

Я часто вижу, как предприниматель поднимает инвестиции в разработку IT-продукта, который потом не окупается. Буквально сегодня на лэндинге одной студии разработки смотрел около 20-ти кейсов мобильных приложений, из которых на рынке нет ни одного. А это значит, что инвесторы скорее всего не смогли вернуть вложения.

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

Даже если мы делаем дизайн-макеты перед разработкой и собираем по ним обратную связь от пользователей, то мы снижаем риски на тему “сделали неудобно”. А основной источник потерь кроется в бизнес-ценности - когда “сделали не то”. Часто функционал не решает никакую конкретную проблему. И даже если проблема реальная, часто эта проблема имеет слишком маленькое влияние на бизнес.

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

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

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

Тут важно понять, что если вы и есть бизнес (вы - заказчик разработки), то первые самые важные вопросы про бизнес-ценность вы должны задавать сами себе. В этом некоторая сложность. Объективно разговаривать с самим собой не получится. Поэтому гораздо лучше найти кого-то с продуктовой экспертизой и попросить его в качестве спаринг-партнера помочь оцифровать бизнес-ценность и поработать с решением.

Когда мы убедились, что без разработки не обойтись:
1. Разбиваем ТЗ на элементы функционала. Например, в формате плоского бэклога продукта или User Story Map.
2. Держа в уме бизнес-ценность, проставляем всем элементам функционала бизнес-ценность в относительных единицах. Например, от 1 до 1000.
3. Просим команду разработки выбрать какой-то элемент в качестве эталона трудоемкости и измерить по нему трудоемкость всех остальных элементов также в относительных единицах.
4. Меняем приоритет элементов функционала, пока первая версия продукта не получит максимум ценности при минимуме трудозатрат. Важно это делать с разработчиками, чтобы получить не только ценную, но и работоспособную версию продукта.
5. Настраиваем процесс разработки так, чтобы получать действительно готовый к бою продукт достаточно часто (не реже 1 раза в месяц).

В результате, когда будет потрачена примерно половина срока и бюджета, с высокой долей вероятности у вас в бою уже будет продукт, который содержит 80% нужного функционала.

Друзья, правильно измеряйте бизнес-ценность в разработке, чтобы радовать своих инвесторов.

Когда целью разработки являются фичи (функционал продукта), неизбежно происходит бесконечная перегрузка в разработке. Из-за чего в космос улетает T2M (time to market), а затем падает качество. Фичи пилятся месяцами, критичные баги бесконечно висят в бэклоге. Владелец продукта указывает на состояние продукта как причину низкой эффективности бизнеса.

Первая мысль, которая приходит в голову как менеджменту, так и разработчикам: нам надо больше ресурсов! И начинаются всякие масштабирования продуктовой разработки через модные фреймворки (SAFe, LESS, Nexus). А как же ROI? Расходы то мы увеличим, но насколько это адекватно ожидаемой динамике по бизнесу? Меня всегда поражает то, как расточительно бизнес тратит деньги на разработку.

Более правильный подход - ограничивать WIP, из-за чего владелец продукта будет вынужден измерять ценность в бэклоге. Но есть и более прямой способ - пролечить целеполагание в разработке и убрать лишнее из бэклога. Это практическое применение Simplicity (10-го принципа Agile): "Простота - искусство минимизации лишней работы - крайне необходима."

Хоть бизнес и говорит (в лице владельца продукта), что ему нужен функционал, на самом деле это не так. Бизнесу нужна динамика по P&L. У владельца продукта есть бизнес-план, который состоит из всяких мероприятий по росту бизнеса. И его там ждут две группы ограничений:

1. Рост доли на рынке означает привлечение всё более и более капризных клиентов.

2. Операционка ломается при увеличении нагрузки на неё

Соответственно, надо с одной стороны точечно повышать удовлетворенность клиента, а с другой стороны последовательно автоматизировать узкие места в операционных процессах. Это и есть реальная цель IT-разработки. Проясняя цель и ее контекст от P&L до бэклога, мы тем самым можем отделить и выкинуть ненужное.

Есть много разных способов сделать это на практике. Вот один из них:

1. Описываем продукт с помощью формулы PPVVC. Если у нас несколько продуктов, то делаем это всё для каждого отдельно.

2. Глядя на блок Vision рисуем Customer Journey Map, чтобы увидеть точки падения удовлетворенности клиента.

3. Рисуем карту операционного процесса (например, в виде Service BluePrint), чтобы найти там узкие места, мешающие росту клиентской базы.

4. Глядя на выявленные на двух предыдущих шагах точки приложения усилий в разработке, рисуем User Story Map, отражающий развитие продукта согласно бизнес-плану.

5. Ищем и правим в бэклоге то, что есть в User Story Map, а остальные фич-реквесты из бэклога удаляем.

Используйте Simplicity, чтобы правильно лечить проблемы в разработке.

Здравствуйте, дорогие подписчики моего канала!

Многие меня знают, но не все. Поэтому пришло время представиться, и рассказать о себе и об этом канале.

Меня зовут Антон. Я консультант по IT-управлению в бизнесе, помогаю инвесторам и предпринимателям из СМБ повышать качество управления в IT-проектах.

За 20+ лет я поучаствовал в реализации около сотни IT-проектов в разных компаниях. Сначала это были 15 лет в сугубо технических ролях по разработке и администрированию. И когда я видел неудачи в проектах, то я всегда ощущал человеческую боль. Боль технарей, которые зря потратили свой профессионализм. Боль разочарованных клиентов. Боль инвесторов, которые потеряли свои деньги.

Я видел, что основная причина не в технике, а где-то в управлении. Я задавал себе вопрос про ребят, которые ставят технарям задачи. Откуда они знают, что именно надо сделать?

Именно поэтому 8 лет назад я перешел в IT-менеджмент. Сначала частично, немного, затем сильнее. Я хотел разобраться в IT-менеджменте, чтобы успешных проектов стало больше. В результате за 8 лет я прошел путь от тимлида команды разработчиков до консультанта по управлению.

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

С другой стороны, когда система управления позволяет организации адекватно воспринимать эту обратную связь из процесса автоматизации и IT-разработки, качество управления в самом бизнесе и организации сильно повышается. Управление в организации приобретает иное качество, более высокий уровень. Я назвал его IT-управлением. И поскольку фокус моего профессионального интереса находится в продуктах/рынках, то в моём случае это IT-управление в бизнесе.

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

Спасибо, что вы со мной. Желаю вам успешных и масштабных IT-проектов!

Предприниматель всегда ищет способы повысить маржу: купить подешевле, продать подороже. Это и есть его основная работа - растить бизнес. Остальную работу он хочет делегировать. Пусть наемные работники крутят бизнес, а он будет заниматься развитием.

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

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

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

Один из моих клиентов пришел ко мне с таким запросом. Помоги, говорит, мне внедрить bitrix24. Какой-то бардак бесконечный. Все работают, а толку нет. Не хватает системы, регламентов. Битрикс им купил, sharepoint, google таблички рисуем. Но мы как будто не знаем, как это всё правильно делать. Научи нас этим пользоваться. Надо оптимизировать весь этот рабочий процесс.

Я расспросил про бизнес - оказалось, они недавно запустились. Увидели нишу и побежали туда. В воронке десятки лидов, со всеми идет какая-то коммуникация, но ни одной сделки ещё нет. И так уже почти полгода.

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

Через полгода он возвращается с 5-ю полностью закрытыми сделками + ещё 5 у него заключены и в работе. Что самое интересное - он показал мне схему своего операционного процесса в miro, которую сам нарисовал. Мы её вместе докрутили: выделили продукт, поток создания ценности с контрольными точками, создали формы управленческой отчетности и это позволило в том числе подобрать IT-инструментарий.

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

Когда меня просят настроить воронку продаж в bitrix24 или amocrm для b2b, то часто проблема не в том, чтобы настроить интеграцию телефонии, месенеджеров, соцсетей, продающих ботов и прочих обвесов. Хотя все это я тоже делаю. Часто бывает так, что заказчик уже всё это купил и интегрировал. У него проблема в другом.

Масса карточек, которые не двигаются неделями, месяцами и даже годами. Среди них есть от силы 20% актуальных. Но и они используются только для того, чтобы хранить историю общения с клиентом и отчитываться перед начальством о проделанной работе: позвонил, написал, отправил КП, ждем. В результате, до продажи добегает только тот клиент, которому очень надо и сотрудники работают с ним в пассивном режиме “запрос-ответ”. Остальные клиенты пассивно ждут, и, как правило, не дожидаются. А это подавляющее большинство клиентов.

Заказчик думает, что проблема в том, что CRM неправильно настроена, и поэтому она не дает бизнес-результат. Помимо удобства для сотрудников, типа всех каналов в одном месте, прозрачности для начальства, заказчик ожидает увидеть заметное повышение эффективности работы отдела продаж. CRM должна помогать управлять сотрудниками. Но она не помогает.

И в этом заключается причина проблем. На самом деле CRM нужна для управления клиентами, а не сотрудниками. И когда её применяют для управления сотрудниками, появляются колонки вроде “формирование КП”, “КП направлено”, “изготовление договора”, “договор направлен” и т.д. Вместо того, чтобы вести клиента к сделке, менеджеры начинают работать работу. И какой бы крутой ни была цифровая CRM, бизнесу она не поможет.

А как надо использовать CRM, чтобы управлять клиентами?

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

Во-вторых, удобство - это не субьективный комфорт для сотрудников, а сокращение затрат времени и усилий на перевод клиента с одного этапа на другой. Какой смысл в интеграциях и автоматизациях, если это не помогло бизнесу сократить операционные затраты?

Вот пример адаптации CRM для b2b, который можно взять за основу:

1. Пишем последовательность состояний клиента с момента первого контакта до закрытия сделки. Например: заявка, решение, размещение заказа.

2. Для каждого состояния формулируем цель, которую нужно достичь, чтобы клиент перешел в следующее состояние. Например: дать КП, получить отказ или готовность идти в сделку, получить предоплату.

3. Ежедневно просматриваем воронку справа налево, задавая вопрос “Что нужно сделать, чтобы [цель этапа из п.2]?”. Можно это делать вместе с сотрудниками. Ответы записываем в виде задач (или пунктов чек-листа) со сроками и ответственными. Со временем выработается регламент, который можно будет автоматизировать.

4. Еженедельно смотрим аналитику по воронке - конверсию. Узкое место видно по сильному падению конверсии в соответствующей колонке. Чтобы расшить его, нужно найти то, что мы всё ещё не знаем о своём бизнесе и внести соответствующие изменения в воронку и регламент, чтобы повысить конверсию.

Каденции (периодичность встреч) нужно скорректировать под длинну сделок и кол-во точек касания в каждой. Кстати, можно использовать методологию Solution Selling, чтобы упростить расшивку. Если вам нужны методические материалы - напишите мне в личку, я вам бесплатно вышлю ссылки.

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