1Если заказчик хочет, чтобы вы разработали что-то с нуля специально под них — эффективнее внедрить существующее стороннее решение.

2Если заказчик хочет непременно внедрить стороннее решение — эффективнее разработать решение под эту конкретную задачу с нуля.

Идея проверена, рынок найден, каналы работают. Удвоились за год. Может ли нас что-то остановить? Может.

1Планирование и управление финансами, Растущая компания сжигает растущее количество денег. Чем больше денежные потоки, тем выше риски облажаться. Нет внутренней системы, которая оперативно контролирует продуктовые метрики по выручке, расходы по статьям бюджета и не сопоставляет одно с другим — кассовые разрывы с последующим падением в убыток неминуемы.

2Система учета и контроля На этапе стартапа не до оптимизации внутренних процессов. Главное — нащупать рынок и получать клиентов. Все занимаются всем, некоторые — непонятно чем и для чего. Если продолжить такой подход на этапе роста — неизбежно разрастание количества сотрудников без четких KPI. Нет внутренней системы, которая укладывает сотрудников в рамки бизнес-процессов, учета и контроля — ФОТ начнет расти быстрее, чем выручка, прибыль падает, а потом исчезает совсем.

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

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

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

6Как ни удивительно, даже простые внедрения внутренних продуктов способны приносить существенный результат. Вот рассказ об опыте внедрения Slack, который экономит для SkyEng полмиллиона рублей в месяц: https://habr.com/ru/company/skyeng/blog/328252/. Не хочется использовать платные продукты? Не проблема — Uber взял для построения своей системы внутрикорпоративных коммуникаций опенсорсный Mattermost: https://eng.uber.com/uchat/.

7Вывод простой. Растете? Самое время начать внимательно заниматься внутренними продуктами, иначе все деньги потеряются по дороге. Ровно об этом наша новая программа «Разработка внутренних продуктов компании»: https://productuniversity.ru/product-developer. Начинается она уже через 2 недели — 22 июля.

8Кстати, в качестве учебно-практического кейса мы будем рассматривать как раз внедрение Mattermost. Куратор программы — Roman Pavlushko, который прошел от разработчика до CTO весь путь превращения Avito из небольшого стартапа в единорога. Именно он и занимался, в том числе, разработкой и внедрением внутренних продуктов.

1Начнем с простого утверждения. Если наш бизнес основан на законах реальности, то его развитие непременно будет происходить по так называемой S-кривой. Сначала экспоненциальный рост после попадания в целевой рынок, потом стагнация, потом падение. Любые действия, которые мы можем предпринять, могут лишь приподнять и растянуть эту кривую — но не могут убрать неизбежное плато и угасание.

2Законы реальной жизни, по которым подобный путь развития неизбежен:
3Сценарий №1. Если мы выделяем на маркетинг постоянный процент от выручки. После быстрого роста в первые года три компания выходит на плато с минимальным ростом. Почему? Потому что стоимость привлечения каждого последующего пользователя постоянно увеличивается. Через некоторое время отток пользователей сравняется с количеством новых пользователей, несмотря на то, что абсолютное значение маркетинговых затрат увеличивается.

4Сценарий №2. Если мы увеличиваем процент выручки, выделяемый на маркетинг. Пиковый размер выручки увеличится и выход на плато несколько отодвинется. Однако стоимость привлечения пользователя начнет сильно расти, потому что эластичность маркетинга по-прежнему меньше 100%, а тратим на маркетинг мы все больше и больше.

5Сценарий №3. Если мы добиваемся улучшения удержания (retention), то есть процент оттока пользователей будет меньше, чем в предыдущих сценариях. Кривая будет похоже на предыдущий сценарий, то есть мы увеличиваем пиковую выручку и отодвигаем плато, причем без драматического увеличения стоимости привлечения. Однако выход на плато опять неизбежен.

6Выводы:
7И главный вывод. Если мы хотим продолжать расти, не выходя на плато — нам надо либо а) периодически выходить на новые рынки, где рост будет начинаться с нуля, либо б) запускать новые продукты на старых рынках. Никакие другие ухищрения не помогут нам против стагнации. Во всех других стагнацию можно только отодвинуть, но нельзя избежать.

Описание математики, лежащей в основе сценариев, включая простую модель на языке R, можно посмотреть по ссылке: https://blog.usejournal.com/the-tyranny-of-the-s-curve-b791772ba8af.

Видео. Фреймворк для создания и анализа продукта.

1Новое — это старое

2Конкурент есть всегда

3Капитализация изменения

4Метод проб и ошибк

5Бизнес — это зарабатывать

6Рост как цель

Смотреть: https://youtu.be/FDhgz7oBBJQ

1KPI отличается от метрики тем, что KPI — это метрика, на которую можно влиять. Метрика же — это просто метрика. Ее можно только считать.

2«Наш колл-центр обеспечивает в среднем конверсию 4.23% из звонка в визит в офис». И что? Это метрика. Прямо на нее повлиять мы не можем. Чтобы она она изменилась мы должны влиять на «хвосты». Либо уменьшать количество сотрудников с низкой конверсией, либо увеличивать количество сотрудников с высокой.

3Хотим отрезать слабый хвост? Бьем на команды, устраиваем среди них соревнование. Проигравшую команду штрафуем. Оцениваем результативность по армейскому принципу — по члену команды с самой низкой конверсией. Дальше начинает работать воспитание через коллектив — слабого либо подтянут, либо он сам уволится.

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

5В среднем в лучшем случае получится как в среднем по индустрии. То есть, никак — ибо средняя маржинальность любого бизнеса на конкурентном рынке равна нулю. Зарабатывают хорошие деньги только те венчурные фонды, у которых есть несколько процентов сильно выстреливших проектов. Прибыль SaaS-сервисам генерит малое количество необычно долго живущих клиентов.

6Средняя температура по больнице обычно 36.6. Хотите получать результаты выше, чем в среднем по рынку — работайте по хвостам. Делайте дешевое еще более дешевым, а дорогое — еще более дорогим. Либо увольняйте отстающих, либо сильнее стимулируйте отличников. Не занимайтесь подтягиванием всех и вся до среднего уровня — там нет денег, зато есть геморрой.

Прочитал хороший текст для тимлидов-программистов «Методология как конструктор». Полезно для прочтения руководителям команд любых профессий, но с техническим складом ума.

1Все методики основаны на страхе. Разные страхи приводят к разным методологиям. Страх переплатить ведет к найму дешевых разработчиков, которых просто менять — это SCRUM. Страх ошибки приводит к ГОСТам или RUP с кучей формализованных документов.

2Обычно бизнес хочет все и сразу. Когда собираете требования — придерживайтесь предположения, что «пациент всегда врет». Когда бизнес хочет все, он врет. Попытайтесь понять, что бизнес действительно хочет и попытайтесь ему это продать. Это не самый стандартный для тимлида набор умений. Но если вы не умеете выяснять реальные требования бизнеса, то необходимо найти человека, который умеет.

3Каждый сотрудник имеет право спросить про любую задачу: зачем ее делать, зачем делать именно так и кому она вообще нужна? Как только начинаете спрашивать «зачем» на всех уровнях, включая бизнес, в разы уменьшается объем задач и так же увеличивается мотивация. Люди понимают смысл работы и выполняют ее быстрее и экономнее, срезая углы.

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

5Чек-лист — это ритуал, который разгружает мозг и дает возможность в 3 часа ночи сделать выкладку на продакшн и его не уронить. Чек-лист позволяет не думать.

6Вообще весь Agile — это про увеличение нормы эксплуатации разработчиков, потому он и востребован бизнесом. Бизнесу нравится, что люди работают быстрее и дешевле. Если бы у программистов был профсоюз, то Agile, SCRUM и XP запретили бы.

7Review before code. Регулярно слышу, как человеку дали ответственность за большую фичу, а он сделал не то и надо переделывать. Прежде, чем писать код, сотрудник в Jira описывает план решения задачи на две строки или два абзаца текста. Такая практика позволяет тимлиду или архитектору быть в курсе всех изменений в большом проекте. Он читает не кривой код, а два абзаца о том, что вообще происходит в системе, и быстро ловит людей за руку.

8Создание методики — это инженерная задача. Ровно такая же, как программирование и проектирование модулей системы. Именно так к этому и подходите. Вы умеете хорошо решать инженерные задачи — так используйте все свои знания в этой новой практике.

9Главное достоинство программиста — его лень. Постройте процессы так, чтобы люди тратили на них еще меньше времени, и разработчики первыми побегут их внедрять. Если люди не стремятся внедрять процессы, значит они не поняли зачем.

Источник: https://habr.com/ru/company/oleg-bunin/blog/456514/Крутейший/