Треугольника Кийосаки. Часть вторая
В прошлой части поста я рассказал про треугольник Кийосаки — принцип разложения бизнеса на составляющие Роберта Кийосаки, который помогает ему оценивать предприятия, в которые он инвестирует, или запускать свои. В этой части расскажу, как я изменил его подход под себя.
Мне нравится подход Роберта, но со временем я заметил, что использую его немного в другом виде. Некоторые сферы я объединил, а некоторые разделил. Вот что получилось в итоге, и на что я опираюсь сейчас:
- Люди и системы. Я считаю, что не может быть лидера без команды, поэтому объединил их. Системы неразрывно связаны с людьми, то есть при планировании процессов сразу думаешь какой человек нужен на какой позиции.
- Продажи, маркетинг и поддержка. Из раздела общения выделил только их, потому что остальное общение это часть процессов. А вот маркетинг, продажи и поддержка — это общение во вне с клиентом, которое формирует образ компании в их глазах.
- Финансы и метрики. К денежному потоку прибавились метрики, потому что деньги в общем показывают состояние бизнеса, но не показывают где и почему появилась проблемы, а продуктовые метрики это делают. Верный набор показателей помогает принимать более взвешенные решения.
- Продукт. Миссию я отношу к этому разделу, потому что бизнес создаёт продукты как раз ради чего-то — это и есть миссия.
- Право
Я не согласен с идеей Кийосаки, что в бизнесе есть какое-то однозначное деление на более и менее важные сферы. Просто в разные этапы развития компании одни сферы имеют приоритет над другими. Например, когда бизнес только начался, больше вкладываешься в продажи и привлечение денег, а когда он уже большой и устойчивый — воюешь за лучших работников и защищаешься от плагиата.
Поэтому я представляю себе схему не в виде треугольника, а лепестковой диаграммой, как в играх, когда у персонажа сила на 10, ловкость на 2, а точность на 5. Если так же условно оценить каждую сферу от 1 до 10, сразу видно что проседает — чем ровнее фигура, тем устойчивее бизнес.
На практике же это просто список. Вот как он выглядит в моём «Ноушене» на примере проекта «Анима»:
На главной миссия и те самые сферы. Акселерацию не вносил куда-то конкретно, потому что это с одной стороны это привлечение денег, а с другой и обучение, поэтому решил выделить отдельно. Уверен, в некоторых сферах могут быть какие-то похожие смежные разделы и это нормально.
Внутри каждая сфера выглядит так:
Вверху написаны цели и принципы этой сферы, то есть что мы делаем в этом направлении, зачем и как. Памятка, чтобы люди не забывали что важно, а что нет. Ниже текущие задачи, планы, результаты аналитики и исследований, полезные ссылки, видео и подкасты по теме, в общем всё, что может пригодится для того, чтобы достичь целей.
Как это работает на практике. Например, мы решаем запустить новую большую функцию в «Аниме». В самом старте разработки мы собираемся всей командой и рассматриваем её в каждой сфере отдельно:
- Продукт. Какую проблему решает эта функция, почему она появилась, как мы видим решение, почему именно так, почему уверенны, что это решение сработает, как мы узнаем, что всё получилось, кто уже делал что-то подобное, как они это делали, что мы узнали от пользователей по поводу такой функции?
- Люди и процессы. Как мы будем реализовывать функцию, как процесс процесс, как новая функция повлияет на другие части программы, как изменит процесс работы, кто будет её делать, какие инструменты понадобятся, как будем запускать, какие инструкции нужны после запуска, чтобы люди начали её пользоваться?
- Финансы и метрики. Сколько понадобится на разработку, сколько мы можем заработать, что будем делать, если денег понадобится больше, как мы можем заработать больше, какие метрики будем смотреть, чтобы оценить эффективность?
- Продажи, маркетинг и поддержка. Как расскажем о новой функции, как заинтересуем, чтобы больше пользователей начало пользоваться, с какими каналами продвижения будем работать, как оценим эффективность рекламы, что будем делать, если не будет отдачи, какие проблемы могут возникнуть, как мы их будем решать, как организуем поддержку пользователей?
- Право. Нужны ли какие-то дополнительные договора с пользователями, нужны ли изменения в оферту, как нам защитить разработку, чтобы конкуренты её не скопировали, не задеваем ли мы чьих-то патентов, что с авторским правом?
В примере оценка отдельной функции программы, но точно такой же принцип будет и с целым бизнесом, отличаться будут только вопросы и их количество. Подход работает как автомат «Калашникова» — просто и безотказно — проверено мной лично уже не на одной задаче и не на одном проекте.