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

Давайте я приведу пример на базе Tproger. Это один из бизнесов который я менторю, а до этого был гендиректором. IT-медиа с аудиторией 2 миллиона человек, веб-сайтом, соцсетями и 22 телеграм-каналами. Tproger помогает нанимать программистов, набирать учеников в онлайн-школы и продавать инфраструктурные решения. Штат из 30 человек, с этого месяца все удалённые.

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

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

Каждый месяц демо отделов: руководитель рассказывает об успехах с ориентиром на метрики, об изменениях в команде, планах на следующий месяц. Есть одно исключение для команды разработки, у них демо раз в 2 недели, по длительности спринтов.

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

Стратегические встречи пока что не периодические, потому сама стратегия появилась только летом этого года. Но в планах раз в квартал проводить town hall и минимум раз в год повторно вещать про стратегию.

Кроме того есть Rocket Chat с каналами random — для мемов и болтовни не по делу, thank_you — для благодарностей коллегам, отдельные пространства для ключевых команд и куча других чатов в которые углубляться не буду, вы наверняка тоже в каком-то мессенджере общаетесь и организовали там структуру.

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

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

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

Зачем они нужны? У меня есть девять пунктов полезности, но выделю три основных:

Задавать ритм работы. Цикличность позволяет находить зависшие задачи, измерять свою эффективность и поощряет декомпозицию больших задач. Да и просто показывает, что команда работает, а не уходит на месяц валяться на шезлонгах до следующего отчёта.

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

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

Несколько неочевидных моментов:

1. Стендапы эффективны в командах из 5–7 человек, самый максимум — 9. Если вам нужно больше, то разбивайтесь на несколько команд и проводите отдельные встречи. Можно выстраивать иерархию, когда представитель одной группы собирает саммари и рассказывает в другой обобщённый стендап своей команды.

2. В пункте про то, что вам мешает выполнить планы нужно говорить про зависимости от других людей и обстоятельств, мешающих планам. «Не выспался» — идите и поспите ещё, команда с этим ничего не сделает.

3. Вопросы стоит задавать только ко всем участникам сразу, никаких личных обращений.

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

Одна из самых важных вещей — правильные формулировки. Используйте глаголы для обозначения задач, т.е. действия, а не описания. И запомните три правила:

1. Задача должна быть понятна всем участникам стендапа.

2. Задача должна сообщать цель своего выполнения, а не констатировать факт работы.

3. Если задача измеряется количественно или влияет на какую-то метрику, то это количество должно быть указано.

Ограничения на этапе внедрения:

1. Проводить встречи устно: все подключаются к звонку и включают камеры.

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

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

Если вы соблюдаете все правила в течение двух недель и стендап стал занимать не больше 5 минут, то поздравляю, вы всё сделали правильно. Если же остались какие-то сомнения — напишите, обсудим. Рассказать всё в одном посте довольно сложно, материала по постановке стендапов у меня на небольшой вебинар хватит.

Дополнение для блока «правильные формулировки»: несколько примеров, основанных на реальных стендапах

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

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

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

Исходя из всего этого предлагаю три признака хорошего программиста:

— Никогда не скажет, что что-то сделать невозможно. Он просто назовёт большие сроки, чтобы успеть разобраться и что-то изучить.

— Не будет предлагать всё переписать на новом языке или технологии, просто потому что так принято и все вокруг уже используют.

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

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

Пора подводить итоги года. В профессиональном плане для меня 2022 был очень насыщенным.

Создал стратегию своего бизнеса. Описал продукт, текущее положение вещей, цель и как к ней прийти. Создал P&L до 2026 года и силами топ-менеджмента объёмный план на 2023.

Назначил директора и начал менторить свой бизнес. Тот самый «выход из операционки», который на самом деле просто переход на другой уровень деятельности.

Начал писать. Про бизнес, менторинг, личную эффективность, разработку. Создал канал в Telegram, опубликовал больше 70 постов, получил первую сотню подписчиков.

Стал ментором. Начал помогать предпринимателям растить бизнесы, выстраивать стратегию и решать тактические вопросы. Сейчас у меня один активный менти с годовым контрактом и периодические общения по разовым запросам.

Вступил в Клуб менторов. Веду там встречи с проектами на начальных стадиях. Пообщался лично с фаундерами более 30 очень разных бизнесов, а ещё больше отсмотрел в рамках подготовки к выступлениям. Познакомился с замечательными членами Клуба, которые делятся опытом и помогают в практически любых вопросах по бизнесу ❤️

Прошёл два образовательных курса и один в процессе. «Ментор стартапов», «Технология управления стратегией бизнеса», «Система продаж».

И, конечно же, подведение итогов было бы не полным без набросков планов на будущий год. Для меня это три основных пункта:

1. «Докрутка» модели своего бизнеса. Чтобы объёмный план не сильно расходился с фактом и задавал контролируемый рост.

2. Построение системы продаж. Чтобы они стали драйвером роста компании и позволили вернуться к удвоению выручки год-к-году.

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

Обожаю IrfanView. Это такая программа на Windows для просмотра картинок, впервые выпущенная аж 26 лет назад. Знает кучу форматов, умеет между ними конвертировать, изменять размеры, оптимизировать. И всё это в том числе в пакетном режиме, когда надо одинаковые настройки применить к более, чем одному файлу.

Недавно мне понадобилось на десктопе открыть файл HEIC, переданный с iPhone. Photoshop отправляет в магазин купить кодек за доллар, аналогично поступают инструкции с первой страницы гугла. Мол проще купить и забыть. А вот FAQ к IrfanView предлагает ещё два варианта — быстрые и бесплатные. Применил второй, файл успешно открылся, пересохранил его в JPEG. И всё, ничего не надо платить.

Планировать финансы можно от продаж, от маркетинга или от продукта. Есть ещё способ, когда все планируют одновременно, а потом пытаются совместить, но акцент всё же лучше делать на чём-то одном.

Как понять на чём? Очень просто: на том, где самое узкое место.

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

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

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

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

Мысль дня — фаундер у стартапа незаменим. Всех остальных можно уволить и нанять с нуля, а вот основатель нужен в здравом уме и ресурсе для движения вперёд. И если не получается бежать быстро, то лучше притормозить и перестать винить себя в недостаточной скорости. Уже писал про это и не раз, но не устану повторять: свой бизнес — это марафон, а не спринт.

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

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

Дмитрий превосходно систематизирует материал и даже если вы уже имеете опыт построения продаж — всё равно будет полезно. А домашние работы на этом курсе стали для меня основным способом получения практической ценности: я внедрял изменения прямо в процессе обучения.

Основные мысли, которые я отметил для себя:

1. Без правильного описания продуктов и УТП продажи не полетят. Это кажется очевидным, но у многих бизнесов с которыми я работаю на этом этапе серьёзные проблемы. На курсе найдёте практические шаблоны и пояснения как это нужно делать.

2. Юнит-экономика считается для масштабирования. Хотите верьте, хотите нет, но именно на этом курсе я по настоящему понял что же это такое и перестроил то, что я раньше называл «моделью» в полезный инструмент для принятия управленческих решений.

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

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

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

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

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

Показывать нужно на боевом продукте. Если что-то только на тестовой машине разработчика — считай, что этого ещё нет. Лучше сразу приучать, что задача считается сделанной только тогда, когда бизнес начинает получать пользу. Не успели выкатить — не показываем.

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

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

— Как ты мог завалить проект?
— Почему вчера не выкатили релиз?
— Неделю назад было понятно, что не получится.

Знакомые фразы? Бесят? Да, так и должно быть. Потому что все они атакуют прошлое. А у прошлого есть одна интересная особенность — его нельзя изменить. На эти фразы невозможно адекватно ответить, проект уже завален, релиз уже не состоялся. А машину времени ещё не изобрели.

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

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

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

Этот пост я написал на основе советов из книги «Джедайские техники конструктивного общения» Александра Орлова. Если хотите подробнее разобраться — рекомендую, для меня было очень полезно.

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

Некоторые руководители вместе с ростом начинают считать ниже своего достоинства погружаться в детали. Не работают продажи — ну вот есть же коммерческий директор, поговорю с ним, пусть разбирается. А по его словам всё хорошо. Но роста с нужной скоростью при этом нет. И что делать?

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

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

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