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

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

Вот навигация:

О проблеме

О авторском праве и гос. реестрах для IT

О юр. отношениях с командой

О бухгалтерии, налогах, фондах

О маркетинге

О управлении продуктами и проектами

О HR и процессах найма

Могу рассказать еще о процессах продаж, внедрения и финансовом управлении) Если продолжать кидайте 💩, если нет - сменю пластинку))

5АМ | #компания

Обещал про процессы) Прообещался, вот принёс😜)

В жизни стартапа наступает момент построения бизнеса. Это когда разработка и придумывание становятся не такой важной частью работы. Часто у предпринимателей стартапов может возникнуть ощущение, что "около" процессы выстроятся сами по себе)

В геймдеве есть (или я сам это выдумал, но не суть) "правило бочки". Его суть очень простая. В игре куча контента и если подойти в самый незаметный угол, который 99,9% всех игроков даже не увидит, то можно там найти 3D модель бочки. Эту бочку кто-то спланировал, кто-то нарисовал, разместил, протестировал. Смысл правила: "В действительности мы не осознаем как много вещей требует нашего внимания".

Процессы о том же. Каждую "бочку" часть процесса нужно продумать. При этом версионно разложить, вспомните пост про 1-2-3. Вот у Локео, допустим, цепь продажи выглядит вроде банально: "реклама/холодные продажи - звонок - выход на презентацию - прогрев - выход на внедрение - подписание лицензионного соглашения - выход на поддержку", но глубина и количество шагов огромная.

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

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

Скорость обратной связи должна быть максимально быстрой. Если долго, то это первый показатель, что что-то идет не так. Серьезный пост получился, настроение какое-то такое😠)) Всем бобра и классного вечера)) С вас 🔥, если нужно делиться результатами этого подхода)

5АМ | #компания

Автоматизировать или не автоматизировать, вот в чем вопрос?)🤔

Обычно ответ идет от оценки. Есть стоимость команды разработки, которая разработает автоматику, есть издержки на внедрение и поддержку автоматики. Берем период амортизации в 10 лет и сверяем стоимость разработки и стоимость ручного поддержания процесса. Если первое больше второго, то автоматику делать незачем… Так говорит теория.

Вот другие доводы, что автоматику все таки делать:

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

Автоматика может стать бизнесом
Если вы внедрили автоматику, то будте уверены, что это можно продать. Разработать и внедрить автоматику всегда задача не простая.

Автоматика как стратегия выживания
Все чаще это вижу. Дело уже даже не в издержках. Компания долгосрочно просто не сможет конкурировать. Сотрудникам и менеджменту нужно видеть данные, создавать другие процессы, которые недоступные без автоматики и обработки данных.

Цифра - это всегда стратегия, не тактика.

5АМ | #компания

Начну отвечать на вопросы из этого поста:

Как выделять оперативные проекты из этих таблиц?

После проведения сеанса связи с клиентом/ пользователем/ реальностью / виртуальностью😁 мы формируем запрос (работу). Чё надо ваще? на языке клиента, вне контекста конкретного продукта, но в рамках контекста его жизни. Заносим все запросы, которые можем нарыть и проставляем им приоритет и влияние (impact). Фильтруем.

Каждый запрос далее выходит на исследование: есть уже фичи, которые можем доработать, чтобы закрыть запрос или нужно делать заново? Тут входит в работу методики отработки гипотез и бизнес анализ. Не будем углубляться, но результатом всегда вылупляются новые фичи в работу либо версии старых фичей, то есть вторая таблица.

Фичи отслеживаются по готовности в разрезе конкретного направления: аналитика, дизайн, бэк, фронт и т.п. То есть происходит аналитика фичей запроса, дизайн фичей запроса и так далее.

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

Большой запрос
Проекты бьются по направлениям запроса. Например, проект "аналитика запроса REQ-345". Вывести фичи. 10 фичей, написать доку и задание на 10 фичей. Крупный результат. Делать 2-3 недели. На базе доки можно делать ux и tech исследование. Круто) Выглядит реально как проект, за который можно по голове погладить.

Маленький запрос
Просто сам запрос является проектом.

Как их выстроить в Roadmap-у то)

Дальше всё просто. Закидываем в табличку проектов-эпиков список, делим по приоритету и block. Закидываем на timeline в Notion. Периодически помешиваем обновляем.

PS. Все, о чем рассказываю, по завершении цикла покажу на видосе)

5АМ | #компания

В чем сложность управления студией полного цикла разработки ПО?

Дам сразу ответ и потом раскрою. Сложность в наборе последовательных самостоятельных услуг.

На рынке часто есть просто отдельные студии: дизайна, тестирования, девопса. Чисто кодо-разработки вроде не видел, но не суть. Так вот, студия полного цикла должна замыкать в себе целиком все направления. Она должна:

- Провести глубокую аналитику продукта
- Разработать дизайн
- Разработать код (по направлениям: бэк, фронт сайт, фронт мобильного приложения)
- Протестировать и выпустить

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

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

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

Я думаю, что одним из ключевых навыков лидов PM-ов или руководителя студии - уметь достигнуть синхронизации в самое короткое время)

5АМ | #компания

Пирамида развития монетизации крупного продукта

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

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

С каждым уровнем растет точность расчета и гибкость внедрения новых платных продуктов. Одно но: растет и сложность такого расчета. Растут именно административные затраты на монетизацию и её поддержку. Чем ближе к основанию пирамиды, тем глубже монетизация внедряется в сам продукт - бэкенд должен быть покрыт точками сбора данных, выключением/включением функций, подсчета затраченных купленных «баллов».

В случае с B2B очень важно актирование. С ростом сложности у продукта должна быть своя автоматизация быстрого формирорвания счета и акта (как и какие данные в них попадут). Чем сложнее и мелочнее становится монетизация, тем дороже поддерживать её не только административно, но и системно.

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

5АМ | #компания

Про лицензионные соглашения

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

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

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

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

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

Чуть позже расскажу про политику конфиденциальности и пользовательские соглашения. Тоже важный момент в развитии продукта)

5АМ | #компания

Эмерджентность

Мне нравится это понятие из теории систем. Коротко суть: это свойство системы, которое возникает только во время работы всех ее компонентов. То есть каждый компонент системы по отдельности это свойство не имеет.

Очень интересно рассматривать эмерджентность больших b2b продуктов с точки зрения сложности продаж. Вот допустим возьмем различные подсистемы Локео. Дам примеры, чтобы вы поняли смысл этой сложности.

🟣 Первая подсистема - процесс оформления клиента в УК. Выполняет сотрудник №1, допустим продажник.

🟣 Вторая подсистема - комплекс финансовых операций для изменения баланса лицевого счета. Выполняет сотрудник №2, допустим кассир. Имеет свои интеграционные подсистемы.

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

🟣 Четвертая подсистема - комплекс операций по созданию пропуска на КПП. Выполняет сотрудник №3, допустим менеджер по сервису. Имеет свои интеграционные подсистемы.

🟣 Пятая подсистема - комплекс операций по управлению оповещением: email, sms, push, новости в личном кабинете. Может выполнять сотрудник №3. Имеет свои интеграционные подсистемы.

🟣 Шестая подсистема - комплекс операций по системе управления долгом клиентов. Выполняет сотрудник №4 - допустим юрист или администратор.

С подсистемы 1-5 фактически выполняют самостоятельные задачи и закрывают боли конкретных пользователей сотрудников 1-4 и клиента. Для каждого сотрудника - это самостоятельная программа, заканчивающаяся в его зоне ответственности. Боли каждой по отдельности могут быть не такими существенными, чтобы согласиться на покупку.

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

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

Что помогает: аналитика карт ГПР (групп принимающих решения), отдельные воронки для подсистем-продуктов, глубокое понимание болей принимающих решение на уровне подсистемы, понимание психологии людей, их потребности и типов личности.

5АМ | #компания

Про хештеги канала

Как пользоваться: нажимаете на хештег → в списке нажимаете на мой канал → читаем посты по теме тега.

Рубрика - экспертные
#разработка - как делать ПО
#управление - командой
#предпринимательство - о бизнесе
#загородом - про недвижимость
#компания - и её процессы
#стартап - как их делать

Рубрика - легкое
#цитаты - любимое 🙂
#мемы - поржать
#life - узнать меня поближе

Рубрика - полезное
#философия - сознания и ИИ
#мотивация - и заряд энергией
#рекомендации - как действовать
#развитие - своей личности

Рубрика - от компании
#вакансии - к нам в команду
#кейсы - что делала студия
#дайджест - крутые посты
#ретроспектива - подвожу итоги

5АМ | #дайджест