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

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

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

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

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

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

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

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

Пора подводить итоги года. В профессиональном плане для меня 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. Все тексты и картинки на демо такие, как они могли бы быть в реальной жизни. Потому что тем, кто не в контексте так проще понять суть. И на настоящих данных всегда что-то идёт не так: то вёрстка поедет, то вообще всё сломается. В процессе подготовки к демо это всплывёт и, в идеале, будет исправлено.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я вот иду сейчас за шампанским, чтобы порадоваться первому реальному шагу на пути к системным продажам в Tproger. Изменения, начатые в прошлом году докатились до менеджеров по продажам и это реально круто. Да, ещё очень многое предстоит сделать, но я очень рад за команду и себя самого. Не просто так я, значит, бонусы получаю :)

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

Рекомендую такой формат:

Суть задачи одним предложением.

Кто ответственный. Не обязательно исполнитель, но кто организует.

Срок. Если задачи не выделяются изначально на какую-то итерацию, то, конечно же, нужно обозначить дедлайн. Я обычно живу спринтами и задачи в любом случае на один спринт, так что сроки не указываю.

Образ результата. Что станет итогом, по которому вы поймёте, что задача решена?

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

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

На что влияет. Задача ради задачи никому не нужна. Хорошо бы указать на какую метрику она влияет, какую гипотезу позволяет проверить и т.п.

Кажется, что пунктов много, но со временем вы привыкните. И не потому что это рутина, а потому что поймёте, зачем это нужно. Например, если образ результата не получается описать, то как мы поймём, что задачу сделали? Никак? Тогда, может быть, и начинать не стоит, а как-то переформулировать?

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

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

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

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

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

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

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

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

На каждую зону стоит тратить не больше 5–10 минут, на последнем этапе можно задержаться чуть подольше, чтобы провести обзор всех озвученных мыслей. На встрече один ведущий, который даёт высказаться желающим и поддерживает атмосферу доверия.

А теперь несколько ошибок, которые я совершал на первых ретро. Постарайтесь их не повторять, потому что иначе ничего не получится.

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

Выводы в стиле «надо делать хорошо, а плохо делать не надо». Это прям классика. Как будто если что-то не успели, то значит надо времени больше заложить в следующий раз. Или лучше стараться. Меньше спать, может быть. Вы и так стараетесь, и так планируете с той точностью, с которой можете. Правильные ответы — декомпозировать, описать образ результата задачи, пойти чему-то научиться, привлечь эксперта и т.п. Какой-то инструмент, который даёт уверенность, что в следующий раз всё будет иначе.

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