Экономика IT-производства: часть 2. Определение бизнес-модели.
Попробую продолжить этот цикл статей. Начали мы в прошлой статье с азов. Но и продолжить мне придется базовыми терминами. Это необходимо, чтобы впоследствии можно было опираться на единый “понятийный аппарат” при обсуждении уже практических вопросов.
Для того, чтобы обсуждать любимые вопросы владельцев IT-бизнеса (себестоимость, ценообразование, учет часов и мотивация), хорошо бы для начала получить ответ на простые вопросы:
- В чем заключается экономика вашего бизнеса?
- Какова ваша бизнес-модель?
- Что именно является вашим центром прибыли и центром затрат?
Для примера возьмем небольшую региональную студию (занимается созданием “шаблонных сайтов” на 1С-Битрикс), нашу компанию (занимаемся разработкой сайтов на заказ) и компанию Tilda (производит конструктор по созданию сайтов).
Казалось бы, все компании заняты примерно одним и тем же — производят сайты. Давайте разбираться подробнее ...
Региональная студия, быстро и недорого делающая сайты на 1С-Битрикс, - это “фабрика”. Зарабатывают они на продаже сайтов. А тратят деньги, главным образом, на содержание “производственного персонала”. При такой экономике им стоит стремиться произвести как можно больше сайтов за единицу времени, затратив на это минимум денег и постараться продать как можно дороже.
Наша компания занимается заказной разработкой. Наша модель - это скорее “ателье по индивидуальному пошиву”. Такую модель часто называют "бутиковой". Мы продаем не “сайты”, а “решение проблемы конкретного заказчика”. И здесь важно помнить, что двух одинаковых проблем не бывает, а значит - мы вынуждены применять “персональный подход”.
Такая бизнес-модель плохо масштабируется. При этом, для того, чтобы решать сложные проблемы, мы вынуждены не только содержать “звездную” команду, но и непрерывно инвестировать в R&D (в нашем случае это — экспертиза и процессы). Тираж таких продуктов не может быть большим, а сами продукты получаются очень дорогими.
Наконец, третья компания (Tilda) разрабатывает конструктор, с помощью которого каждая домохозяйка может сделать сайт самостоятельно. Компания использует “подписную” бизнес-модель. Она продает платный доступ к своему программному обеспечению. А основные затраты лежат в области маркетинга и продвижения продукта (вспоминаем amoCRM с её знаменитыми ежегодными мероприятиями на огромных стадионах) и в сфере R&D — продукт должен быть функциональным и удобным, чтобы выигрывать конкуренцию у многочисленных аналогов. На разработку здесь тратят несопоставимо меньше, чем в студии или бутике, а сама модель превосходно масштабируется (произведя продукт один раз можно его продать неограниченное количество раз).
Пост получился длинным и, наверняка, немного “капитанским”. Извините. Но теперь, надеюсь, становится понятным, что ответ на вопрос о том “какой должна быть цена” невозможен без понимания того, какова ваша бизнес-модель и в чем центр прибыли и центр затрат именно вашего IT-производства.
Если эта тема интересна, попробую планомерно время от времени развивать её.
P.S. Ну и не могу не поделиться маленькой радостью - канал перешагнул отметку в первую сотню подписчиков! 🥳 Спасибо вам всем большое за то, что читаете. Это очень заряжает меня и мотивирует продолжать! 🙏
Попробую продолжить этот цикл статей. Начали мы в прошлой статье с азов. Но и продолжить мне придется базовыми терминами. Это необходимо, чтобы впоследствии можно было опираться на единый “понятийный аппарат” при обсуждении уже практических вопросов.
Для того, чтобы обсуждать любимые вопросы владельцев IT-бизнеса (себестоимость, ценообразование, учет часов и мотивация), хорошо бы для начала получить ответ на простые вопросы:
- В чем заключается экономика вашего бизнеса?
- Какова ваша бизнес-модель?
- Что именно является вашим центром прибыли и центром затрат?
Скажем, бизнес-модель автопроизводителя Toyota - производство продукции.Ну, достаточно, я думаю, теории. Вернемся к IT-производству. Тут тоже могут быть очень разные бизнес-модели ...
Зарабатывает она, продавая автомобили. А тратит деньги на их производство
(себестоимость) и продвижение на рынок (себестоимость продаж).
А вот автодилеры, насколько мне известно, зарабатывают, главным образом,
на продаже доп.опций и послепродажном обслуживании автомобиля. Т.е.
зарабатывают они на продаже продуктов и оказании услуг, а тратят деньги,
главным образом, на закупку этих самых продуктов и содержании персонала,
необходимого для оказания услуг.
Для примера возьмем небольшую региональную студию (занимается созданием “шаблонных сайтов” на 1С-Битрикс), нашу компанию (занимаемся разработкой сайтов на заказ) и компанию Tilda (производит конструктор по созданию сайтов).
Казалось бы, все компании заняты примерно одним и тем же — производят сайты. Давайте разбираться подробнее ...
Региональная студия, быстро и недорого делающая сайты на 1С-Битрикс, - это “фабрика”. Зарабатывают они на продаже сайтов. А тратят деньги, главным образом, на содержание “производственного персонала”. При такой экономике им стоит стремиться произвести как можно больше сайтов за единицу времени, затратив на это минимум денег и постараться продать как можно дороже.
Наша компания занимается заказной разработкой. Наша модель - это скорее “ателье по индивидуальному пошиву”. Такую модель часто называют "бутиковой". Мы продаем не “сайты”, а “решение проблемы конкретного заказчика”. И здесь важно помнить, что двух одинаковых проблем не бывает, а значит - мы вынуждены применять “персональный подход”.
Такая бизнес-модель плохо масштабируется. При этом, для того, чтобы решать сложные проблемы, мы вынуждены не только содержать “звездную” команду, но и непрерывно инвестировать в R&D (в нашем случае это — экспертиза и процессы). Тираж таких продуктов не может быть большим, а сами продукты получаются очень дорогими.
Наконец, третья компания (Tilda) разрабатывает конструктор, с помощью которого каждая домохозяйка может сделать сайт самостоятельно. Компания использует “подписную” бизнес-модель. Она продает платный доступ к своему программному обеспечению. А основные затраты лежат в области маркетинга и продвижения продукта (вспоминаем amoCRM с её знаменитыми ежегодными мероприятиями на огромных стадионах) и в сфере R&D — продукт должен быть функциональным и удобным, чтобы выигрывать конкуренцию у многочисленных аналогов. На разработку здесь тратят несопоставимо меньше, чем в студии или бутике, а сама модель превосходно масштабируется (произведя продукт один раз можно его продать неограниченное количество раз).
Пост получился длинным и, наверняка, немного “капитанским”. Извините. Но теперь, надеюсь, становится понятным, что ответ на вопрос о том “какой должна быть цена” невозможен без понимания того, какова ваша бизнес-модель и в чем центр прибыли и центр затрат именно вашего IT-производства.
Если эта тема интересна, попробую планомерно время от времени развивать её.
P.S. Ну и не могу не поделиться маленькой радостью - канал перешагнул отметку в первую сотню подписчиков! 🥳 Спасибо вам всем большое за то, что читаете. Это очень заряжает меня и мотивирует продолжать! 🙏
Делегирование - часть 4. Контроль результатов.
#процессы
Воскресный день — прекрасная возможность продолжить наш разговор о делегировании. Предыдущие части здесь: первая (https://news.1rj.ru/str/doingdigital/35), вторая (https://news.1rj.ru/str/doingdigital/37) и третья (https://news.1rj.ru/str/doingdigital/42).
Делегирование, как передача полномочий по решению задачи, не работает без обязательного контроля.
Обратите внимание, я не написал “контроля результатов”. Сделал я это потому, что контроль бывает разный. Про это много статей написано, но здесь я расскажу о собственной классификации, которая может не совпадать с “академической базой”.
Итак, с моей точки зрения, бывают следующие виды контроля:
🔹 Предварительный.
🔹 Промежуточный (или поэтапный).
🔹 Контроль результата выполнения.
Для сложных и длительных поручений важны все три вида контроля. Для небольших тактических задач промежуточным контролем можно пожертвовать. Этим же этапом не стоит злоупотреблять, если сотрудник достаточно квалифицирован для данного вида работ и мотивирован на решение задачи.
Предварительный контроль. На данном этапе важно убедиться, что исполнитель корректно понял задачу и условия её решения (крайне желательно, чтобы они были измеримыми), обладает необходимыми полномочиями и ресурсами, а также понимает и принимает сроки, отведенные для её решения и ответственность за невыполнение задачи.
Промежуточный контроль. В том случае, если задача комплексная, полезно бывает её разбить на небольшие подзадачи и определить для каждой из них конечный результат и сроки достижения. Получившуюся, таким образом, “дорожную карту” и “календарный план-график” необходимо контролировать поэтапно — от подзадачи к подзадаче.
В относительно простых, но трудоёмких задачах, выполнение поэтапного контроля сводится к регулярной проверке текущих достигнутых результатов. Здесь работает принцип: “покажи, что готово на текущий момент”.
Контроль результата выполнения. Тут все понятно без дополнительных комментариев. В назначенных срок важно не забыть проверить, выполнено ли поручение, достигнут ли запланированный результат, отрефлексировать вместе с исполнителем процесс решения задачи и обязательно дать обратную связь (об этом я расскажу подробнее в одной из следующих публикаций).
В заключение, хотелось бы добавить несколько слов о форме контроля.
В целом, вы можете выбирать удобную вам форму контроля: устную или письменную, в свободной форме или в форме, регламентированной используемым сервисом автоматизации постановки задач (таск-менеджером).
Лично мне комфортнее комбинированная форма из обязательного письменного отчета с фиксацией достигнутых результатов и устной его презентацией с ответами на мои вопросы.
Я долго относился к типу руководителей, исповедующих стиль, кем-то метко прозванный “чайка-менеджментом”. Такие руководители, подобно чайкам, могут долго “кружить” по офису и вдруг, внезапно “налететь” на подчиненного, имевшего неудачу столкнуться с боссом у кофе-машины, и начать засыпать вопросами о результатах задач, порученных сто лет назад.
Чайка-менеджмент — это когда “налетел, нагадил, улетел”. Избегайте такого стиля делегирования.
Контроль должен быть регулярным и обязательным. Без этого делегирование не работает.
#процессы
Воскресный день — прекрасная возможность продолжить наш разговор о делегировании. Предыдущие части здесь: первая (https://news.1rj.ru/str/doingdigital/35), вторая (https://news.1rj.ru/str/doingdigital/37) и третья (https://news.1rj.ru/str/doingdigital/42).
Делегирование, как передача полномочий по решению задачи, не работает без обязательного контроля.
Обратите внимание, я не написал “контроля результатов”. Сделал я это потому, что контроль бывает разный. Про это много статей написано, но здесь я расскажу о собственной классификации, которая может не совпадать с “академической базой”.
Итак, с моей точки зрения, бывают следующие виды контроля:
🔹 Предварительный.
🔹 Промежуточный (или поэтапный).
🔹 Контроль результата выполнения.
Для сложных и длительных поручений важны все три вида контроля. Для небольших тактических задач промежуточным контролем можно пожертвовать. Этим же этапом не стоит злоупотреблять, если сотрудник достаточно квалифицирован для данного вида работ и мотивирован на решение задачи.
Предварительный контроль. На данном этапе важно убедиться, что исполнитель корректно понял задачу и условия её решения (крайне желательно, чтобы они были измеримыми), обладает необходимыми полномочиями и ресурсами, а также понимает и принимает сроки, отведенные для её решения и ответственность за невыполнение задачи.
Промежуточный контроль. В том случае, если задача комплексная, полезно бывает её разбить на небольшие подзадачи и определить для каждой из них конечный результат и сроки достижения. Получившуюся, таким образом, “дорожную карту” и “календарный план-график” необходимо контролировать поэтапно — от подзадачи к подзадаче.
В относительно простых, но трудоёмких задачах, выполнение поэтапного контроля сводится к регулярной проверке текущих достигнутых результатов. Здесь работает принцип: “покажи, что готово на текущий момент”.
Контроль результата выполнения. Тут все понятно без дополнительных комментариев. В назначенных срок важно не забыть проверить, выполнено ли поручение, достигнут ли запланированный результат, отрефлексировать вместе с исполнителем процесс решения задачи и обязательно дать обратную связь (об этом я расскажу подробнее в одной из следующих публикаций).
В заключение, хотелось бы добавить несколько слов о форме контроля.
В целом, вы можете выбирать удобную вам форму контроля: устную или письменную, в свободной форме или в форме, регламентированной используемым сервисом автоматизации постановки задач (таск-менеджером).
Лично мне комфортнее комбинированная форма из обязательного письменного отчета с фиксацией достигнутых результатов и устной его презентацией с ответами на мои вопросы.
Я долго относился к типу руководителей, исповедующих стиль, кем-то метко прозванный “чайка-менеджментом”. Такие руководители, подобно чайкам, могут долго “кружить” по офису и вдруг, внезапно “налететь” на подчиненного, имевшего неудачу столкнуться с боссом у кофе-машины, и начать засыпать вопросами о результатах задач, порученных сто лет назад.
Чайка-менеджмент — это когда “налетел, нагадил, улетел”. Избегайте такого стиля делегирования.
Контроль должен быть регулярным и обязательным. Без этого делегирование не работает.
Telegram
Digital-кухня
Заметка про выстраивание управленческой структуры вызвала неожиданно большой отклик, поэтому мне пришла в голову мысль немного углубиться в тему делегирования. В нашей компании это был довольно болезненный и сложный процесс. Так что надеюсь, что наш опыт…
Как повысить точность оценки сроков и бюджета проекта?
Наша компания известна на рынке, как один из самых аккуратных и дисциплинированных разработчиков. Сегодня хотели поделиться небольшим “инсайтом”, который мы получили, работая в свое время над вечным вопросом выхода проектов из запланированных сроков и бюджета (в профессиональной терминологии это называется “выходом за базовый план проекта”).
Проанализировав несколько десятков проектов, мы выявили два наиболее часто встречающихся фактора, оказывающих критическое влияние на риски в проекте:
- Размер проекта;
- Степень инновационности проекта.
Размер проекта — это привычная длительность и объем работы в проекте, с которым вы обычно имеете дело. Так, если ваш типичный проект выполняется за 3 месяца, а вам предложили заняться проектом, который по вашим предварительным прикидкам займет 12 месяцев — это фактор риска.
Степень инновационности проекта — это процент совершенно незнакомых для вас видов работ в общем составе работ проекта. Например, если вы прекрасно делаете промо-сайты, и в какой-то момент решили взяться за e-commerce проект, степень инновационности такого проекта для вас явно будет крайне высокой.
Для каждого из этих факторов мы рекомендуем умножать сроки и стоимость проекта на коэффициент x1.5. Проще говоря, если вам кажется, что такой проект можно сделать за 3 месяца, смело планируйте 4,5 месяца.
Если же в проекте встречаются оба фактора, использование в качестве коэффициента числа Пи (3,14) позволит вам получить оценку, приближенную к реальной.
Наша компания известна на рынке, как один из самых аккуратных и дисциплинированных разработчиков. Сегодня хотели поделиться небольшим “инсайтом”, который мы получили, работая в свое время над вечным вопросом выхода проектов из запланированных сроков и бюджета (в профессиональной терминологии это называется “выходом за базовый план проекта”).
Проанализировав несколько десятков проектов, мы выявили два наиболее часто встречающихся фактора, оказывающих критическое влияние на риски в проекте:
- Размер проекта;
- Степень инновационности проекта.
Размер проекта — это привычная длительность и объем работы в проекте, с которым вы обычно имеете дело. Так, если ваш типичный проект выполняется за 3 месяца, а вам предложили заняться проектом, который по вашим предварительным прикидкам займет 12 месяцев — это фактор риска.
Степень инновационности проекта — это процент совершенно незнакомых для вас видов работ в общем составе работ проекта. Например, если вы прекрасно делаете промо-сайты, и в какой-то момент решили взяться за e-commerce проект, степень инновационности такого проекта для вас явно будет крайне высокой.
Для каждого из этих факторов мы рекомендуем умножать сроки и стоимость проекта на коэффициент x1.5. Проще говоря, если вам кажется, что такой проект можно сделать за 3 месяца, смело планируйте 4,5 месяца.
Если же в проекте встречаются оба фактора, использование в качестве коэффициента числа Пи (3,14) позволит вам получить оценку, приближенную к реальной.
Дорогие ошибки сквозной аналитики
Наша компания занимается не только созданием успешных интернет-проектов, но и увеличением продаж через digital-каналы, а также помогает выстроить правильные метрики интернет-маркетинга.
На прошлой неделе с нами произошел любопытный случай — из-за ошибок в настройках сквозной аналитики нашими предшественниками мы едва не разрушили отношения с клиентом.
Что, собственно, случилось? Бюджет на рекламу расходуется, трафик есть, а лидов, если верить системе сквозной аналитики, нет.
Начали разбираться. Оказалось, лиды есть, но из-за ошибок при настройке метрик, в отчетах сквозной аналитики такие лиды не учитываются. В итоге - нули в отчете, расстроенный клиент, нервы наших специалистов по контекстной рекламе.
Мы сейчас готовим статью с описанием решения данной ошибки. А пока статья готовится, мне на глаза попался превосходный материал Ильи Красинского о частых ошибках при настроек метрик сквозной аналитики, который способны привести к потерям огромных денег и даже разорить компанию.
Посмотрите сами и покажите вашим контрагентам, отвечающим за digital-маркетинг. Илью я знаю давно и он — один из лучших в Рунете специалистов в области управления продуктом и юнит-экономики.
https://rick.ai/blog/10-most-common-mistakes-in-sales-forecasting-ultimate-guide-by-rick-ai/
Наша компания занимается не только созданием успешных интернет-проектов, но и увеличением продаж через digital-каналы, а также помогает выстроить правильные метрики интернет-маркетинга.
На прошлой неделе с нами произошел любопытный случай — из-за ошибок в настройках сквозной аналитики нашими предшественниками мы едва не разрушили отношения с клиентом.
Что, собственно, случилось? Бюджет на рекламу расходуется, трафик есть, а лидов, если верить системе сквозной аналитики, нет.
Начали разбираться. Оказалось, лиды есть, но из-за ошибок при настройке метрик, в отчетах сквозной аналитики такие лиды не учитываются. В итоге - нули в отчете, расстроенный клиент, нервы наших специалистов по контекстной рекламе.
Мы сейчас готовим статью с описанием решения данной ошибки. А пока статья готовится, мне на глаза попался превосходный материал Ильи Красинского о частых ошибках при настроек метрик сквозной аналитики, который способны привести к потерям огромных денег и даже разорить компанию.
Посмотрите сами и покажите вашим контрагентам, отвечающим за digital-маркетинг. Илью я знаю давно и он — один из лучших в Рунете специалистов в области управления продуктом и юнит-экономики.
https://rick.ai/blog/10-most-common-mistakes-in-sales-forecasting-ultimate-guide-by-rick-ai/
Блог Rick.ai: как искать точки роста в аналитике
Ошибки на миллионы: как считать метрики и не выйти на план продаж
Из кейсов клиентов, маркетологов и агентств мы разобрали самые частые ошибки анализа рекламных кампаний и конверсий воронки продаж. Часто 2 или 3 ошибки дают расхождение в расчете плана продаж на несколько миллионов рублей.
Привет всем. Извините меня за то, что давно не писал. Не люблю писать ради дисциплины, а голова с апреля была забита немного другими вопросами. Буду возвращаться к ведению канала постепенно.
Провёл незабываемые 2 дня в гостеприимном Питере на конверенции #3Dconf — это профессиональная конференция для специалистов digital, которую организовывали известные эксперты отрасли (Дима Румянцев, Наташа Франкель, Аня Караулова).
Я там был с докладом - рассказывал о ценообразовании в digital-разработке. Да еще и был одним из "хедлайнеров" мероприятия. Очень почётно и, по-моему, это вообще в первый раз за 22 года моей деятельности, когда я не просто в числе участников, а один из ключевых участников ивента. Большая честь для меня ... надеюсь, оправдал ожидания и организаторов и слушателей.
Но я сам, как слушатель других докладов, получил гораздо больший профит! Было море очень полезных докладов!
🔹 Женя Чуранов из WebCanape.ru рассказывал о том, как у них устроен HR (и они разрослись на моих глаза буквально с 25-40 человек до 90 буквально за пару лет)!
🔹 Николай Фетюхин из MST Digital очень откровенно рассказал, какие стеклянные потолки он лично пробивал для того, чтобы вырасти с 2-х человек до 200 (до ДВУХСОТ, КАРЛ!!!)
🔹 Василий Баранов из ГК Снег рассказывал, как они оценивают и покупают другие агентства (а у них, на секундочку, уже наверное 8-10 приобретений за последние 3-5 лет)
🔹 Виталий Чесноков из QSoft очень подробно рассказывал о том, как работать с тендерами. Прямо очень и ряд вещей, возможно, не стоило говорить под запись, так что, с одной стороны я надеюсь организаторы это удалят из итогового монтажа, а с другой — будет очень жаль, т.к. доклад потеряет свою исключительную ценность.
В общем, что я перечисляю-то - вот полный перечень докладов, посмотрите сами:
https://3dconf.ru/program
Ну и организация! Организация была исключительной! На мой вкус - это было лучшее отраслевое мероприятие за последние годы. Нигде еще я не видел такой четкой организации, такого гостеприимства, такого профессионализма в каждом мелком нюансе! Браво организаторам! 👏
Я, к чему, в общем ... если вы работаете в digital, и в этом году не смогли посетить эту конференцию по тем или иным причинам, я очень рекомендую, во-первых, купить доступы к записям, которые появятся недели через две (я редко рекомендую такое, вы наверняка успели это заметить).
И во-вторых, я приглашаю вас в следующем году на следующее такое мероприятие. Надеюсь, оно обязательно будет и, даже если меня в следующий раз не позовут "говорящей головой", я непременно приеду как простой участник - т.к. этот ивент я точно пропустить не хочу!
Провёл незабываемые 2 дня в гостеприимном Питере на конверенции #3Dconf — это профессиональная конференция для специалистов digital, которую организовывали известные эксперты отрасли (Дима Румянцев, Наташа Франкель, Аня Караулова).
Я там был с докладом - рассказывал о ценообразовании в digital-разработке. Да еще и был одним из "хедлайнеров" мероприятия. Очень почётно и, по-моему, это вообще в первый раз за 22 года моей деятельности, когда я не просто в числе участников, а один из ключевых участников ивента. Большая честь для меня ... надеюсь, оправдал ожидания и организаторов и слушателей.
Но я сам, как слушатель других докладов, получил гораздо больший профит! Было море очень полезных докладов!
🔹 Женя Чуранов из WebCanape.ru рассказывал о том, как у них устроен HR (и они разрослись на моих глаза буквально с 25-40 человек до 90 буквально за пару лет)!
🔹 Николай Фетюхин из MST Digital очень откровенно рассказал, какие стеклянные потолки он лично пробивал для того, чтобы вырасти с 2-х человек до 200 (до ДВУХСОТ, КАРЛ!!!)
🔹 Василий Баранов из ГК Снег рассказывал, как они оценивают и покупают другие агентства (а у них, на секундочку, уже наверное 8-10 приобретений за последние 3-5 лет)
🔹 Виталий Чесноков из QSoft очень подробно рассказывал о том, как работать с тендерами. Прямо очень и ряд вещей, возможно, не стоило говорить под запись, так что, с одной стороны я надеюсь организаторы это удалят из итогового монтажа, а с другой — будет очень жаль, т.к. доклад потеряет свою исключительную ценность.
В общем, что я перечисляю-то - вот полный перечень докладов, посмотрите сами:
https://3dconf.ru/program
Ну и организация! Организация была исключительной! На мой вкус - это было лучшее отраслевое мероприятие за последние годы. Нигде еще я не видел такой четкой организации, такого гостеприимства, такого профессионализма в каждом мелком нюансе! Браво организаторам! 👏
Я, к чему, в общем ... если вы работаете в digital, и в этом году не смогли посетить эту конференцию по тем или иным причинам, я очень рекомендую, во-первых, купить доступы к записям, которые появятся недели через две (я редко рекомендую такое, вы наверняка успели это заметить).
И во-вторых, я приглашаю вас в следующем году на следующее такое мероприятие. Надеюсь, оно обязательно будет и, даже если меня в следующий раз не позовут "говорящей головой", я непременно приеду как простой участник - т.к. этот ивент я точно пропустить не хочу!
Cуровый Питерский Форум Эпизод ХI
Суровый Питерский форум XI - главный форум по Digital маркетингу. 18-19 октября 2025. Офлайн+онлайн, более 150 спикеров
Минутка юмора в канале ...
Подслушал на прошлой неделе диалог нашего специалиста с клиентом. Входящий звонок. Ребята рассказывают о том, что им нужен сайт для продвижения SaaS-продукта.
— Сайт для SaaS-продукта, понятно. Скажите пожалуйста, а сам продукт у вас уже реализован? Можно ли на него взглянуть?
— Да, у нас есть МЖП.
— Что простите у вас есть?
— Эм Жэ Пэ!
— Вы, наверное, имели в виду MVP- Minimum Viable Product?
— Нет! Именно МЖП! Название отражает наше отношение к тому, что у нас получилось.
🤷♂️😂
Хорошей субботы вам.
Подслушал на прошлой неделе диалог нашего специалиста с клиентом. Входящий звонок. Ребята рассказывают о том, что им нужен сайт для продвижения SaaS-продукта.
— Сайт для SaaS-продукта, понятно. Скажите пожалуйста, а сам продукт у вас уже реализован? Можно ли на него взглянуть?
— Да, у нас есть МЖП.
— Что простите у вас есть?
— Эм Жэ Пэ!
— Вы, наверное, имели в виду MVP- Minimum Viable Product?
— Нет! Именно МЖП! Название отражает наше отношение к тому, что у нас получилось.
🤷♂️😂
Хорошей субботы вам.
Очень обидно вчера слили вместе с нашим менеджером по продажам Женей крупный тендер. В четыре руки слили, и даже мое личное участие в продаже не помогло. 😞
Готовились к нему несколько дней. Собрали, как водится, 10 000 документов. Выполнили все дебильные требования, отсканировали, разложили их по папочкам и правильно назвали. В день тендера оба встали в 6 утра и пришли на работу к 08.00, чтобы успеть все подгрузить в систему и подписать ЭЦП до времени закрытия приёма заявок в 10.00.
И вот, на завершающей стадии за 10 минут до закрытия приёма заявок, мы натыкаемся на какой-то дополнительный непонятный файл, который нужно подгрузить в систему. И по нему нет никаких инструкций заполнения. А автоматическая его проверка есть. И при каждой нашей новой попытке его загрузить, система ругается на всё новые и новые ошибки ... То "страна-производитель" должна быть числом (а мы "Российская Федерация" написали), то "единица измерения" должна быть заполнена ... Ну ок - заполнили, указав "час", но после этого система стала ругаться на то, что поле заполнено неверно.
Дальше всё, как в голливудских триллерах - когда обратный отсчет на бомбе с часовым механизмом тикает, а главный герой лихорадочно носится, пытаясь хотя бы что-то предпринять 🤯
В 09:59 мы решили проблему и система "съела" злополучный файл. Счастливые мы подписываем нашу заявку ЭЦП, на экране лоадер, а часы предательски переключаются на 10:00 ... Спустя секунду мы видим злополучное "Приём заявок завершен" 😫
Я сейчас не буду писать про дебилов, которые разрабатывали эту систему. И про удобство интерфейса я ничего писать не буду. И про несовершенство системы тендеров тоже.
Я напишу о том, что нам в отделе продаж есть, над чем поработать. Очевидно, что мы плохо подготовились к этому тендеру. Да, мы впервые участвовали в закупках именно на этой площадке. Но кто помешал нам нанять консультанта для первого опыта? Почему мы даже не попробовали посмотреть обучающие видео, которых (я уверен) в YouTube вагон и маленькая тележка? Почему мы были настолько самоуверенны? Вопрос!
И ведь самое обидное, что две недели назад я в первом ряду сидел на докладе Виталия Чеснокова (из QSoft), где он делился наработками его команды по участию в тендерах 🤦♂️ ...
Кстати, я делал небольшие конспекты по ходу каждого выступления. Попробую в этом канале часть опубликовать. Там, конечно, мысли обрывочные и сам доклад такой конспект ни в коем случае не заменит, но кое-какие мысли, надеюсь, вы тоже для себя сумеете выудить даже из таких обрывочных записей.
Готовились к нему несколько дней. Собрали, как водится, 10 000 документов. Выполнили все дебильные требования, отсканировали, разложили их по папочкам и правильно назвали. В день тендера оба встали в 6 утра и пришли на работу к 08.00, чтобы успеть все подгрузить в систему и подписать ЭЦП до времени закрытия приёма заявок в 10.00.
И вот, на завершающей стадии за 10 минут до закрытия приёма заявок, мы натыкаемся на какой-то дополнительный непонятный файл, который нужно подгрузить в систему. И по нему нет никаких инструкций заполнения. А автоматическая его проверка есть. И при каждой нашей новой попытке его загрузить, система ругается на всё новые и новые ошибки ... То "страна-производитель" должна быть числом (а мы "Российская Федерация" написали), то "единица измерения" должна быть заполнена ... Ну ок - заполнили, указав "час", но после этого система стала ругаться на то, что поле заполнено неверно.
Дальше всё, как в голливудских триллерах - когда обратный отсчет на бомбе с часовым механизмом тикает, а главный герой лихорадочно носится, пытаясь хотя бы что-то предпринять 🤯
В 09:59 мы решили проблему и система "съела" злополучный файл. Счастливые мы подписываем нашу заявку ЭЦП, на экране лоадер, а часы предательски переключаются на 10:00 ... Спустя секунду мы видим злополучное "Приём заявок завершен" 😫
Я сейчас не буду писать про дебилов, которые разрабатывали эту систему. И про удобство интерфейса я ничего писать не буду. И про несовершенство системы тендеров тоже.
Я напишу о том, что нам в отделе продаж есть, над чем поработать. Очевидно, что мы плохо подготовились к этому тендеру. Да, мы впервые участвовали в закупках именно на этой площадке. Но кто помешал нам нанять консультанта для первого опыта? Почему мы даже не попробовали посмотреть обучающие видео, которых (я уверен) в YouTube вагон и маленькая тележка? Почему мы были настолько самоуверенны? Вопрос!
И ведь самое обидное, что две недели назад я в первом ряду сидел на докладе Виталия Чеснокова (из QSoft), где он делился наработками его команды по участию в тендерах 🤦♂️ ...
Кстати, я делал небольшие конспекты по ходу каждого выступления. Попробую в этом канале часть опубликовать. Там, конечно, мысли обрывочные и сам доклад такой конспект ни в коем случае не заменит, но кое-какие мысли, надеюсь, вы тоже для себя сумеете выудить даже из таких обрывочных записей.
С очень интересным докладом выступил на конференции Николай Фетюхин — основатель MST Digital. У Никиты Михеенкова в канале прочел пост, явно навеянный мыслями после этого доклада. Поэтому свою серию конспектов решил начать именно с него ...
Николай управляет коллективом, который за 17 лет прошел путь от 2-х до 200-х человек и оборот о нуля до 350 млн. рублей в год. В своем рассказе Фетюхин рассказал о ключевых переломных моментах, о проблемах, с которыми сталкивался, и о том, как их преодолевал.
🔹В момент первого кризиса начали заниматься системными продажами. До этого продажи были хаотическими. Многие продажи осуществлялись друзьям и друзьям друзей.
🔹Самый простой способ быстро нарастить продажи — задавать вопрос клиентам: чем еще мы можем вам помочь?
🔹Программа-минимум для дальнейшего роста любого микро-бизнеса: финансовая модель + системные продажи.
🔹Следующий ограничитель роста – личные страхи основателя. После первого кризиса 2008-го, в 2013-2014-м уже перестраховывался, «дул на воду», боялся нанимать тогда, когда весь рынок не только не падал, но и рос. В итоге отстал от ближайших конкурентов вдвое.
🔹Стало понятно, что одной финансовой модели и системных продаж – недостаточно. Стала нужна стратегия. Стратегическому планированию пришлось учиться.
🔹В этот момент начал жадно учиться. Почти всему, чему мог и почти везде, где только мог.
🔹Следующее ограничение – управленческая команда (менеджмент).
🔹Руководителей формировали из лучших специалистов, они совершенно не умели управлять, а если и умели, то каждый управлял в своем ключе – так, как считал верным. Тогда стало понятным, что нужно заниматься обучением руководителей.
🔹Поначалу преподавал сам. Потом отправляли на курсы, приглашали наставников, покупали курсы: Фридман, Тарасов, Тысленко, Молвинский.
🔹В результате сформировали 50-страничное пособие начинающего руководителя. В нем ссылки примерно еще на 500-страниц обучающего материала.
🔹Как итог, управленческая команда добрала навыков, стала действовать в одном ключе и единой системе координат.
🔹В управленческой иерархии нужна постоянная ротация, люди не должны засиживаться. Новая кровь должна "подпирать снизу" старые кадры.
🔹Самоорганизация и умение поддерживать «ресурсное состояние» - главные компетенции лидера.
🔹У вас лично и у организации всегда должны быть новые цели. Глобальные цели должны лежать за пределами жизни (должны быть недосягаемыми при жизни основателя).
🔹Нужно рисковать! Без риска серьезного развития не будет. Бизнес – это в целом про риски.
Заходит такой формат? Или бесполезно? Дайте знать пожалуйста. Если заходит, постепенно выложу еще несколько конспектов.
Николай управляет коллективом, который за 17 лет прошел путь от 2-х до 200-х человек и оборот о нуля до 350 млн. рублей в год. В своем рассказе Фетюхин рассказал о ключевых переломных моментах, о проблемах, с которыми сталкивался, и о том, как их преодолевал.
🔹В момент первого кризиса начали заниматься системными продажами. До этого продажи были хаотическими. Многие продажи осуществлялись друзьям и друзьям друзей.
🔹Самый простой способ быстро нарастить продажи — задавать вопрос клиентам: чем еще мы можем вам помочь?
🔹Программа-минимум для дальнейшего роста любого микро-бизнеса: финансовая модель + системные продажи.
🔹Следующий ограничитель роста – личные страхи основателя. После первого кризиса 2008-го, в 2013-2014-м уже перестраховывался, «дул на воду», боялся нанимать тогда, когда весь рынок не только не падал, но и рос. В итоге отстал от ближайших конкурентов вдвое.
🔹Стало понятно, что одной финансовой модели и системных продаж – недостаточно. Стала нужна стратегия. Стратегическому планированию пришлось учиться.
🔹В этот момент начал жадно учиться. Почти всему, чему мог и почти везде, где только мог.
🔹Следующее ограничение – управленческая команда (менеджмент).
🔹Руководителей формировали из лучших специалистов, они совершенно не умели управлять, а если и умели, то каждый управлял в своем ключе – так, как считал верным. Тогда стало понятным, что нужно заниматься обучением руководителей.
🔹Поначалу преподавал сам. Потом отправляли на курсы, приглашали наставников, покупали курсы: Фридман, Тарасов, Тысленко, Молвинский.
🔹В результате сформировали 50-страничное пособие начинающего руководителя. В нем ссылки примерно еще на 500-страниц обучающего материала.
🔹Как итог, управленческая команда добрала навыков, стала действовать в одном ключе и единой системе координат.
🔹В управленческой иерархии нужна постоянная ротация, люди не должны засиживаться. Новая кровь должна "подпирать снизу" старые кадры.
🔹Самоорганизация и умение поддерживать «ресурсное состояние» - главные компетенции лидера.
🔹У вас лично и у организации всегда должны быть новые цели. Глобальные цели должны лежать за пределами жизни (должны быть недосягаемыми при жизни основателя).
🔹Нужно рисковать! Без риска серьезного развития не будет. Бизнес – это в целом про риски.
Заходит такой формат? Или бесполезно? Дайте знать пожалуйста. Если заходит, постепенно выложу еще несколько конспектов.
Спасибо за фидбэк по формату конспектов. Искренне рад, что вам зашло! Тогда понемногу продолжу ...
Следующим, кто впечатлил меня на 3DConf стал Александр Щербина — основатель iTECH Group. Вы вот, например, знали, что помимо iTECH, хорошо известной на рынке веб-разработки и SEO-продвижения, он успел основать еще Лайфхакер.ру, ZeBrains и еще с десяток компаний, суммарная капитализация которых сейчас составляет 1,5 - 2,0 млрд. рублей?
Вот и я не знал. А он смог. И получилось это благодаря опыту выхода из операционной деятельности — того, о чем мы, руководители небольших агентств, можем пока только мечтать. Об этом опыте он и рассказывал в своем докладе:
🔹Идеальный момент выхода из операционки тогда, когда команда выросла и начинает сама вытеснять основателя (то есть ты приходишь с умными советами, а выясняется, что все уже без тебя давно сделано и все просто снисходительно смотрят на тебя и улыбаются).
🔹Для того, чтобы этого достигнуть, нужна соответствующая корп.культура и атмосфера в компании, а именно:
— Доверие и делегирование.
— Позволять делать собственные ошибки и не расстреливать за это.
— Поддержка (собственник активно делится опытом и энергией).
🔹Если нанимается топ-менеджер извне - у него есть строго 3 месяца на то, чтобы доказать свою полезность для компании (не успел - на фиг с пляжа).
🔹Компанию можно оставить только на партнера (совладельца доли в бизнесе), нанятый ген.директор всегда будет справляться хуже.
🔹Бизнес = Человек (Лидер) (вот это мне прямо очень понравилось!)
🔹Совет директоров:
— Ключевая задача этого органа: рост компании и её капитализации.
— Орган должен быть полезен для генерального директора.
— Совет Директоров не может состоять только из сотрудников компании.
— В СД должны входить люди, сильнее вас, извне, которые будут помогать делать компанию лучше.
🔹Идеальный трек появления партнеров:
Адвайзер > Член Совета Директоров > Акционер
🔹Людям, которых вы не можете нанять, можно продать долю в бизнесе.
🔹Структурирование бизнеса:
— Акционерное соглашение (drag-alone, liquidation fee, и т.д.)
— Структурирование компании (юр.лицо, налоговая белизна, и т.д.)
— Систематическая оценка стоимости бизнеса (капитализация должна расти)
— One pager (презентация компании на одной странице)
— Полноценная презентация компании
— Модель масштабирования бизнеса
🔹Продажей компании нужно заниматься так же системно, как другими процессами (случайно это не происходит).
🔹Развиваясь медленнее рынка можно остаться за бортом (если рынок вырос на 20%, а вы выросли на 10%, скорее всего вы потеряли половину своей доли рынка).
🔹CEO выделяется доля в размере от 5 до 15%, в зависимости от того, на какой стадии развития бизнеса он её получает (seed - 15%, если уже платят дивиденды - 5%).
🔹Но вообще … не в процентах дело! Что лучше - 30% от 1 млн. долларов или 10% от 10 млн. долларов?
🔹В iTech все члены Совета Директоров “бесплатные” (являются акционерами), а вот адвайзеры - платные.
🔹Если человек хочет уйти - нужно дать ему уйти, нельзя его удерживать, отдавая ему долю.
Такие вот мысли нам всем на "подумать". Хороших выходных!
Следующим, кто впечатлил меня на 3DConf стал Александр Щербина — основатель iTECH Group. Вы вот, например, знали, что помимо iTECH, хорошо известной на рынке веб-разработки и SEO-продвижения, он успел основать еще Лайфхакер.ру, ZeBrains и еще с десяток компаний, суммарная капитализация которых сейчас составляет 1,5 - 2,0 млрд. рублей?
Вот и я не знал. А он смог. И получилось это благодаря опыту выхода из операционной деятельности — того, о чем мы, руководители небольших агентств, можем пока только мечтать. Об этом опыте он и рассказывал в своем докладе:
🔹Идеальный момент выхода из операционки тогда, когда команда выросла и начинает сама вытеснять основателя (то есть ты приходишь с умными советами, а выясняется, что все уже без тебя давно сделано и все просто снисходительно смотрят на тебя и улыбаются).
🔹Для того, чтобы этого достигнуть, нужна соответствующая корп.культура и атмосфера в компании, а именно:
— Доверие и делегирование.
— Позволять делать собственные ошибки и не расстреливать за это.
— Поддержка (собственник активно делится опытом и энергией).
🔹Если нанимается топ-менеджер извне - у него есть строго 3 месяца на то, чтобы доказать свою полезность для компании (не успел - на фиг с пляжа).
🔹Компанию можно оставить только на партнера (совладельца доли в бизнесе), нанятый ген.директор всегда будет справляться хуже.
🔹Бизнес = Человек (Лидер) (вот это мне прямо очень понравилось!)
🔹Совет директоров:
— Ключевая задача этого органа: рост компании и её капитализации.
— Орган должен быть полезен для генерального директора.
— Совет Директоров не может состоять только из сотрудников компании.
— В СД должны входить люди, сильнее вас, извне, которые будут помогать делать компанию лучше.
🔹Идеальный трек появления партнеров:
Адвайзер > Член Совета Директоров > Акционер
🔹Людям, которых вы не можете нанять, можно продать долю в бизнесе.
🔹Структурирование бизнеса:
— Акционерное соглашение (drag-alone, liquidation fee, и т.д.)
— Структурирование компании (юр.лицо, налоговая белизна, и т.д.)
— Систематическая оценка стоимости бизнеса (капитализация должна расти)
— One pager (презентация компании на одной странице)
— Полноценная презентация компании
— Модель масштабирования бизнеса
🔹Продажей компании нужно заниматься так же системно, как другими процессами (случайно это не происходит).
🔹Развиваясь медленнее рынка можно остаться за бортом (если рынок вырос на 20%, а вы выросли на 10%, скорее всего вы потеряли половину своей доли рынка).
🔹CEO выделяется доля в размере от 5 до 15%, в зависимости от того, на какой стадии развития бизнеса он её получает (seed - 15%, если уже платят дивиденды - 5%).
🔹Но вообще … не в процентах дело! Что лучше - 30% от 1 млн. долларов или 10% от 10 млн. долларов?
🔹В iTech все члены Совета Директоров “бесплатные” (являются акционерами), а вот адвайзеры - платные.
🔹Если человек хочет уйти - нужно дать ему уйти, нельзя его удерживать, отдавая ему долю.
Такие вот мысли нам всем на "подумать". Хороших выходных!
Forwarded from ТАТУЛОВА (Анастасия Татулова)
#фб
#волошин
Прекрасный пост от Волошина сегодня. Под каждым словом подписываюсь, но чуда все равно хочется каждый раз))).
Чуда не будет. Такого чуда, чтобы раз, и все хорошо. Не будет, как ни читай умные советы.
Пригласи ты хоть Гейтса на роль CEO, все равно чуда не будет.
Нет чудес в бизнесе.
Нет серебрянных пуль и универсальных решений.
Нет гуру и экспертов, которые дадут спасающие советы.
Даже книг, дающих ответы, нет. Все, как водится, решаешь ты сам.
Что у тебя в голове накопилось, твоя энергия, вера и удача. Замечено, что чем больше веришь в чудо, тем меньше энергии и удачи. А зачем суетится, если сейчас само попрет? Верно? Нет, мой друг, чуда не будет.
Нет чудес в продажах.
Есть долгая и нудная работа. В продажах главное - менеджеры. Как их найти? Как научить? Как помогать материалами, сервисами, условиями? Мотивировать как? И вот когда ты создашь эту систему, когда она заработает, когда не выполнит первый план, и второй, и третий. Когда уйдет твой долго выращиваемый РОП. Когда ты запутаешься в цифрах и графиках. Вот тогда и начнется самое интересное.
Тогда начнешь соображать и действовать. А не ждать, что сейчас придет крупный заказчик и сделает весь план одним платежом.
Нет чудес с продуктом. Есть въедливая и обстоятельная работа.
В продукте главное - клиенты. Как их выбрать?
Как с ними поговорить?
Как анализировать их ответы? Что учесть, а что отбросить? Когда ты начнешь говорить с ними, когда получишь первую обратную связь, когда на ее основе увеличится отток. Когда снизятся конверсии. Когда поползет вниз eNPS. Вот тогда наступит просветление. Тогда ты начнешь крутить мозгом и строить гипотезы. А не фантазировать в одиночку по поводу того, что ты за продукт пилишь.
Нет чудес и в организации. Есть ежедневная и методичная работа. В организации работы главное - цифры. Что есть результат? Как его измерить? Как собрать данные и их обобщить? Как только ты начнешь думать в цифрах, когда определишь первые KPI, когда выяснится, что все не так. Когда осознаешь, что твои руководители не обладают системным мышлением. Когда поймешь, что их реальные результаты на порядок хуже транслируемых ими. Когда выяснишь, что цифры результативности не бьются с моделью бизнеса. Вот тогда начнешь размышлять и налаживать процессы. А не надеяться на здравый смысл и порядочность своих сотрудников.
Я общаюсь с фаундерами. И примечаю одну закономерность. Среди тех, кому везет, большинство тех, кто везет. Они размеренно и спокойно делают дело. Разумеется, они читают книги. Но без фанатизма, а для подумать. Разумеется, они посещают конференции и форумы. Но не для «напитаться атмосферой», а чтобы узнать что-то конкретное, по-бизнесу. Они прагматичны и расчетливы. Они ценят свое время. Поэтому редко или никогда не предаются мечтам. Мечтам о том, как им сейчас повезет. Какое чудо случится.
#волошин
Прекрасный пост от Волошина сегодня. Под каждым словом подписываюсь, но чуда все равно хочется каждый раз))).
Чуда не будет. Такого чуда, чтобы раз, и все хорошо. Не будет, как ни читай умные советы.
Пригласи ты хоть Гейтса на роль CEO, все равно чуда не будет.
Нет чудес в бизнесе.
Нет серебрянных пуль и универсальных решений.
Нет гуру и экспертов, которые дадут спасающие советы.
Даже книг, дающих ответы, нет. Все, как водится, решаешь ты сам.
Что у тебя в голове накопилось, твоя энергия, вера и удача. Замечено, что чем больше веришь в чудо, тем меньше энергии и удачи. А зачем суетится, если сейчас само попрет? Верно? Нет, мой друг, чуда не будет.
Нет чудес в продажах.
Есть долгая и нудная работа. В продажах главное - менеджеры. Как их найти? Как научить? Как помогать материалами, сервисами, условиями? Мотивировать как? И вот когда ты создашь эту систему, когда она заработает, когда не выполнит первый план, и второй, и третий. Когда уйдет твой долго выращиваемый РОП. Когда ты запутаешься в цифрах и графиках. Вот тогда и начнется самое интересное.
Тогда начнешь соображать и действовать. А не ждать, что сейчас придет крупный заказчик и сделает весь план одним платежом.
Нет чудес с продуктом. Есть въедливая и обстоятельная работа.
В продукте главное - клиенты. Как их выбрать?
Как с ними поговорить?
Как анализировать их ответы? Что учесть, а что отбросить? Когда ты начнешь говорить с ними, когда получишь первую обратную связь, когда на ее основе увеличится отток. Когда снизятся конверсии. Когда поползет вниз eNPS. Вот тогда наступит просветление. Тогда ты начнешь крутить мозгом и строить гипотезы. А не фантазировать в одиночку по поводу того, что ты за продукт пилишь.
Нет чудес и в организации. Есть ежедневная и методичная работа. В организации работы главное - цифры. Что есть результат? Как его измерить? Как собрать данные и их обобщить? Как только ты начнешь думать в цифрах, когда определишь первые KPI, когда выяснится, что все не так. Когда осознаешь, что твои руководители не обладают системным мышлением. Когда поймешь, что их реальные результаты на порядок хуже транслируемых ими. Когда выяснишь, что цифры результативности не бьются с моделью бизнеса. Вот тогда начнешь размышлять и налаживать процессы. А не надеяться на здравый смысл и порядочность своих сотрудников.
Я общаюсь с фаундерами. И примечаю одну закономерность. Среди тех, кому везет, большинство тех, кто везет. Они размеренно и спокойно делают дело. Разумеется, они читают книги. Но без фанатизма, а для подумать. Разумеется, они посещают конференции и форумы. Но не для «напитаться атмосферой», а чтобы узнать что-то конкретное, по-бизнесу. Они прагматичны и расчетливы. Они ценят свое время. Поэтому редко или никогда не предаются мечтам. Мечтам о том, как им сейчас повезет. Какое чудо случится.
Этот пост навеян постом моего товарища — замечательного предпринимателя, основателя супер-проекта EpicGrowth Алексея Писаревского.
Вкратце, ситуация такая: для выхода на англоязычную аудиторию Алексею нужно начать генерировать контент на английском языке. Делать это непросто, все это отжирает время, к тому же — его англоязычные блоги пока никто не читает и это демотивирует (к слову, я его прекрасно понимаю, и помню, как тяжело было писать, когда канал читало 20 человек).
Развилка следующая: продолжать, прекратить, нанять кого-то, кто это сделает за тебя (но денег жалко). Вот на этой развилке, мне кажется, ярко проявляются отличия предпринимателя от специалиста.
Предприниматель, в моем понимании — это человек, основная задача которого заключается в эффективной организации ресурсов для достижения той или иной цели.
Ресурсы эти могут быть различными: время наёмных специалистов или свое собственное, материалы, связи. Но в конечном счёте, почти все ресурсы можно привести к единому знаменателю — деньгам.
И, если это сделать, задача предельно упрощается. Сколько стоит час моего времени, которое я трачу на ведение англоязычного Twitter? Насколько я эффективно это делаю (особенно с учетом того, что судя по посту Алексея, удовольствия мне это не доставляет)? Насколько эффективнее это будет делать приглашенный специалист? Смогу ли я заработать больше денег, если потрачу высвободившееся время на что-то другое?
После такого диалога с собой, все сводится к обычному фин.моделированию ситуации, значительно упрощающему принятие решения.
Несколько лет назад, когда я учился в Сколково, меня как-то раз спросили:
— Знаешь, чем отличается предприниматель от обычного человека?
— Чем? — спросил я.
— Обычный человек, столкнувшись с задачей, думает, как её решить. А предприниматель думает, кто для него может решить эту задачу наиболее эффективно.
Этот разговор очень круто поменял мою жизнь. Надеюсь, этот пост поможет и кому-то из тех предпринимателей, кто его прочтет.
Вкратце, ситуация такая: для выхода на англоязычную аудиторию Алексею нужно начать генерировать контент на английском языке. Делать это непросто, все это отжирает время, к тому же — его англоязычные блоги пока никто не читает и это демотивирует (к слову, я его прекрасно понимаю, и помню, как тяжело было писать, когда канал читало 20 человек).
Развилка следующая: продолжать, прекратить, нанять кого-то, кто это сделает за тебя (но денег жалко). Вот на этой развилке, мне кажется, ярко проявляются отличия предпринимателя от специалиста.
Предприниматель, в моем понимании — это человек, основная задача которого заключается в эффективной организации ресурсов для достижения той или иной цели.
Ресурсы эти могут быть различными: время наёмных специалистов или свое собственное, материалы, связи. Но в конечном счёте, почти все ресурсы можно привести к единому знаменателю — деньгам.
И, если это сделать, задача предельно упрощается. Сколько стоит час моего времени, которое я трачу на ведение англоязычного Twitter? Насколько я эффективно это делаю (особенно с учетом того, что судя по посту Алексея, удовольствия мне это не доставляет)? Насколько эффективнее это будет делать приглашенный специалист? Смогу ли я заработать больше денег, если потрачу высвободившееся время на что-то другое?
После такого диалога с собой, все сводится к обычному фин.моделированию ситуации, значительно упрощающему принятие решения.
Несколько лет назад, когда я учился в Сколково, меня как-то раз спросили:
— Знаешь, чем отличается предприниматель от обычного человека?
— Чем? — спросил я.
— Обычный человек, столкнувшись с задачей, думает, как её решить. А предприниматель думает, кто для него может решить эту задачу наиболее эффективно.
Этот разговор очень круто поменял мою жизнь. Надеюсь, этот пост поможет и кому-то из тех предпринимателей, кто его прочтет.
Telegram
Ночной Писаревский
Немного разрываюсь между тем, чтобы писать на русском и на английском.
⁃ Я не настолько блогер, чтобы писать на двух языках. Это занимает кучу времени. Я точно не готов столько уделять.
⁃ Долгосрочно лучше писать только на английском. На горизонте 10…
⁃ Я не настолько блогер, чтобы писать на двух языках. Это занимает кучу времени. Я точно не готов столько уделять.
⁃ Долгосрочно лучше писать только на английском. На горизонте 10…
Проблема сметчика
В нашу компанию ежемесячно поступает порядка 20-30 запросов на расчет новых проектов. И еще от внутренних заказчиков поступает дополнительно сопоставимое количество.
На то, чтобы подготовить квалифицированный расчет сложного проекта, нужно, как минимум:
— Изучить бриф.
— Провести проблемное интервью.
— Сделать экспресс-анализ рынка и конкурентного окружения.
— Придумать решение (у нас это выглядит, как mindmap со структурой будущего проекта).
— Подготовить смету затрат и календарный план-график его реализации.
И вот только на эту часть у опытного руководителя проекта (РП) может уйти от 6 до 20 часов на ОДИН проект. Это я еще не приплюсовал сюда время по сборке КП и его защите перед клиентом. А еще сюда можно приплюсовать потери от стоимости работ, которые РП мог бы выполнить вместо того, чтобы готовить расчет (упущенная прибыль).
В общем, стоимость пресейла в нашем бизнесе огромна! Мы сейчас решаем задачу по сокращению этих потерь в компании, с одной стороны и повышению эффективности продаж - с другой. Ведь клиент тоже не хочет ждать расчета по 2-3 недели, ему нужна информация быстро, в идеале - в тот же или на следующий день. Как быть?
Квалификация лидов у нас давно введена. Правда, прямо вот чёткой карты квалификации с баллами за каждый пункт, какие я видел у некоторых агентств, — такого пока нет. Но квалификацию по бюджету, продуктовому соответствию и культурному коду клиента наши сейлзы делают. Что еще можно улучшить?
Была идея посадить отдельного “сметчика” — человека, который бы только и делал, что считал сметы. Это помогло бы не отвлекать РП-шников на расчеты. Но мне эта идея не нравится, если честно. По нескольким причинам, главная из которых заключается в том, что я не верю, что такие специалисты на рынке есть вообще.
Пока пришли к такому решению: проводить подготовку расчета в два этапа.
Первый этап — диагональный грубый расчет, который готовится в течение 24 часов на основе брифа и предыдущего опыта наших РП. На него тратится, как правило, не более 1-2 человекочасов.
С результатами этого расчета, наши сейлзы идут к клиенту и, если получают предварительное одобрение клиента, возвращаются к сметчикам за подробным расчетом.
Второй расчет готовится уже “по всей форме” - на него тратятся все те чудовищные часы, о которых я написал выше. Но здесь уже трудозатраты оправданы предварительным одобрением сметы и сроков со стороны клиента. Такого расчета клиенту приходится уже подождать около 2-3 рабочих дней.
Кажется, схема выглядит вполне работоспособной. Если у вас есть более эффективные схемы, поделитесь пожалуйста — точно знаю, что среди подписчиков этого канала много людей, умнее меня :-)
В нашу компанию ежемесячно поступает порядка 20-30 запросов на расчет новых проектов. И еще от внутренних заказчиков поступает дополнительно сопоставимое количество.
На то, чтобы подготовить квалифицированный расчет сложного проекта, нужно, как минимум:
— Изучить бриф.
— Провести проблемное интервью.
— Сделать экспресс-анализ рынка и конкурентного окружения.
— Придумать решение (у нас это выглядит, как mindmap со структурой будущего проекта).
— Подготовить смету затрат и календарный план-график его реализации.
И вот только на эту часть у опытного руководителя проекта (РП) может уйти от 6 до 20 часов на ОДИН проект. Это я еще не приплюсовал сюда время по сборке КП и его защите перед клиентом. А еще сюда можно приплюсовать потери от стоимости работ, которые РП мог бы выполнить вместо того, чтобы готовить расчет (упущенная прибыль).
В общем, стоимость пресейла в нашем бизнесе огромна! Мы сейчас решаем задачу по сокращению этих потерь в компании, с одной стороны и повышению эффективности продаж - с другой. Ведь клиент тоже не хочет ждать расчета по 2-3 недели, ему нужна информация быстро, в идеале - в тот же или на следующий день. Как быть?
Квалификация лидов у нас давно введена. Правда, прямо вот чёткой карты квалификации с баллами за каждый пункт, какие я видел у некоторых агентств, — такого пока нет. Но квалификацию по бюджету, продуктовому соответствию и культурному коду клиента наши сейлзы делают. Что еще можно улучшить?
Была идея посадить отдельного “сметчика” — человека, который бы только и делал, что считал сметы. Это помогло бы не отвлекать РП-шников на расчеты. Но мне эта идея не нравится, если честно. По нескольким причинам, главная из которых заключается в том, что я не верю, что такие специалисты на рынке есть вообще.
Пока пришли к такому решению: проводить подготовку расчета в два этапа.
Первый этап — диагональный грубый расчет, который готовится в течение 24 часов на основе брифа и предыдущего опыта наших РП. На него тратится, как правило, не более 1-2 человекочасов.
С результатами этого расчета, наши сейлзы идут к клиенту и, если получают предварительное одобрение клиента, возвращаются к сметчикам за подробным расчетом.
Второй расчет готовится уже “по всей форме” - на него тратятся все те чудовищные часы, о которых я написал выше. Но здесь уже трудозатраты оправданы предварительным одобрением сметы и сроков со стороны клиента. Такого расчета клиенту приходится уже подождать около 2-3 рабочих дней.
Кажется, схема выглядит вполне работоспособной. Если у вас есть более эффективные схемы, поделитесь пожалуйста — точно знаю, что среди подписчиков этого канала много людей, умнее меня :-)
Вчера в ночи уже с партнером обсуждали тему качества продукта.
Штука в том, что мы оба — инженеры до мозга костей, и очень заморочены на создании “правильных” цифровых продуктов для наших клиентов. Наши продукты выдерживают высокие нагрузки, хорошо масштабируются, их непросто взломать, ну и так далее. Но часто мы проигрываем тендеры коллегам, которые (по нашему же собственному мнению), делают не слишком классный продукт. Да еще и денег просят в несколько раз больше, чем мы. Но заказчики с упрямство леммингов снова и снова выбирают эти компании.
И вот вчера в пылу спора с партнером меня осенило! Между нашим собственным мнением (то есть мнением производителя) и мнением заказчика (то есть потребителя) о том, что такое качество, может быть пропасть.
Для заказчика может быть важно то, что для нас самих совершенно неважно. При этом гипотеза о том, что “спелый желудь — его каждая свинья съест” (в том смысле, что хороший продукт продает себя сам), он ошибочен. Далеко не каждый продукт, захвативший наибольшую долю рынка (или имеющий наилучший финансовые показатели среди сопоставимых компаний) является лучшим по качеству с точки зрения производителя.
McDonalds - однозначно самый успешный фастфуд, но самая ли качественная там еда? Многие костерят, на чем свет стоит, 1С но это — однозначно самый распространенный бухгалтерский софт в стране. Wildberries точно не назовешь образчиком классного E-commerce, но по оборотам он - крупнейший в России. Список можно продолжать до бесконечности ...
Возвращаясь к нашей компании, я вчера осознал, что мы очень плохо понимаем собственного покупателя и то, что на самом деле важно ДЛЯ НЕГО, а не для нас - разработчиков. При этом у нас — классный бизнес и, как правило, с людьми, любящими инженерное дело так же, как и мы, у нас складываются долгие и продуктивные отношения. А проигрываем тендеры мы (опять же — как правило) в тех случаях, когда клиента представляет человек, далекий от инженерии и не способный оценить всю крутость наших продуктов.
Наверное, это и есть первый шаг к тому, о чем я так долго и часто слышал от разных людей, пытавшихся помогать мне на разных этапах моего жизненного пути, — к позиционированию.
Следующий шаг — точно понять, кто является нашим клиентом и поговорить с ним о том, что для него значит понятие “качественный продукт”.
Штука в том, что мы оба — инженеры до мозга костей, и очень заморочены на создании “правильных” цифровых продуктов для наших клиентов. Наши продукты выдерживают высокие нагрузки, хорошо масштабируются, их непросто взломать, ну и так далее. Но часто мы проигрываем тендеры коллегам, которые (по нашему же собственному мнению), делают не слишком классный продукт. Да еще и денег просят в несколько раз больше, чем мы. Но заказчики с упрямство леммингов снова и снова выбирают эти компании.
И вот вчера в пылу спора с партнером меня осенило! Между нашим собственным мнением (то есть мнением производителя) и мнением заказчика (то есть потребителя) о том, что такое качество, может быть пропасть.
Для заказчика может быть важно то, что для нас самих совершенно неважно. При этом гипотеза о том, что “спелый желудь — его каждая свинья съест” (в том смысле, что хороший продукт продает себя сам), он ошибочен. Далеко не каждый продукт, захвативший наибольшую долю рынка (или имеющий наилучший финансовые показатели среди сопоставимых компаний) является лучшим по качеству с точки зрения производителя.
McDonalds - однозначно самый успешный фастфуд, но самая ли качественная там еда? Многие костерят, на чем свет стоит, 1С но это — однозначно самый распространенный бухгалтерский софт в стране. Wildberries точно не назовешь образчиком классного E-commerce, но по оборотам он - крупнейший в России. Список можно продолжать до бесконечности ...
Возвращаясь к нашей компании, я вчера осознал, что мы очень плохо понимаем собственного покупателя и то, что на самом деле важно ДЛЯ НЕГО, а не для нас - разработчиков. При этом у нас — классный бизнес и, как правило, с людьми, любящими инженерное дело так же, как и мы, у нас складываются долгие и продуктивные отношения. А проигрываем тендеры мы (опять же — как правило) в тех случаях, когда клиента представляет человек, далекий от инженерии и не способный оценить всю крутость наших продуктов.
Наверное, это и есть первый шаг к тому, о чем я так долго и часто слышал от разных людей, пытавшихся помогать мне на разных этапах моего жизненного пути, — к позиционированию.
Следующий шаг — точно понять, кто является нашим клиентом и поговорить с ним о том, что для него значит понятие “качественный продукт”.
Продолжаю разбираться с продажами в своей компании. Решил проанализировать проигранные за последние 1,5 года сделки, чтобы постараться найти основную причину падения конверсии за последнее время.
Внутренне я был уверен, что главным фактором “отвала” у нас будет цена. Все-таки мы — крутое инженерное бюро, с сильными и дорогими специалистами, способными решить практически любую задачу в интернет-проектах, если ее вообще возможно решить на сегодняшний день.
Результаты получились такими:
🎲 21% - проект отложен или отменен;
🎲 20% - заказчик “пропал” (перестал отвечать на письма и звонки);
🎲 17% - дорого;
🎲 13% - проиграли тендер (выбрали другого подрядчика, не всегда по ценовому признаку);
🎲 13% - мы отказались от проекта (да, у нас это — не редкость, например, задача не соответствует нашей специализации; в этом случае мы просто рекомендуем тех, кто справится лучше нас);
🎲 3% - “тянут резину” (у нас есть правило закрывать сделку, если заказчик 3 раза подряд не дает внятного ответа и не способен сформулировать сроки принятия решения).
Смотрю вот я на эти цифры и … думаю, что с ними теперь делать? )))
С одной стороны — вроде бы проблема очевидна: 21% проектов отваливаются потому, что планы собственников меняются или готовность стартовать проект была изначально очень низкой и спросили скорее ради интереса, а не ради дела. А если приплюсовать к этому еще 20% тех. кто просто перестал отвечать и 3% тех, кто тянет время изо всех сил, выходит целых 44% — добрая половина всех отвалов.
Тут, наверное, вопросы у меня должны быть к нашей системе квалификации лидов (хотя я пока ума не приложу, как можно оценить то, что заказчик … не передумает?)
Но, с другой стороны, среди тех, кто отвечает про отмену проекта или попросту перестает отвечать, могут быть и те, кому мы не подошли по бюджету, но кто, с психологической точки зрения, не готов заявить об этом прямо? И тогда математика будет совсем другой: к 17% тем, кто вслух говорит о том, что мы дороговаты, добавляются еще процентов 5-10% тех, кто постеснялся сказать об этом вслух, предпочитая просто не отвечать на наши письма и звонки. И тогда строчка “дорого” выходит на уверенное первое место.
Да и вообще — полезна ли такая статистика? Если взять представителей дорогих (не люксовых, а именно дорогих) сегментов — вероятно “дорого” тоже является подавляющей причиной отказа потенциального покупателя от сделки?
В общем, в очередной раз надеюсь на наш с вами коллективный разум. Уверен — вместе разберемся ;-)
Внутренне я был уверен, что главным фактором “отвала” у нас будет цена. Все-таки мы — крутое инженерное бюро, с сильными и дорогими специалистами, способными решить практически любую задачу в интернет-проектах, если ее вообще возможно решить на сегодняшний день.
Результаты получились такими:
🎲 21% - проект отложен или отменен;
🎲 20% - заказчик “пропал” (перестал отвечать на письма и звонки);
🎲 17% - дорого;
🎲 13% - проиграли тендер (выбрали другого подрядчика, не всегда по ценовому признаку);
🎲 13% - мы отказались от проекта (да, у нас это — не редкость, например, задача не соответствует нашей специализации; в этом случае мы просто рекомендуем тех, кто справится лучше нас);
🎲 3% - “тянут резину” (у нас есть правило закрывать сделку, если заказчик 3 раза подряд не дает внятного ответа и не способен сформулировать сроки принятия решения).
Смотрю вот я на эти цифры и … думаю, что с ними теперь делать? )))
С одной стороны — вроде бы проблема очевидна: 21% проектов отваливаются потому, что планы собственников меняются или готовность стартовать проект была изначально очень низкой и спросили скорее ради интереса, а не ради дела. А если приплюсовать к этому еще 20% тех. кто просто перестал отвечать и 3% тех, кто тянет время изо всех сил, выходит целых 44% — добрая половина всех отвалов.
Тут, наверное, вопросы у меня должны быть к нашей системе квалификации лидов (хотя я пока ума не приложу, как можно оценить то, что заказчик … не передумает?)
Но, с другой стороны, среди тех, кто отвечает про отмену проекта или попросту перестает отвечать, могут быть и те, кому мы не подошли по бюджету, но кто, с психологической точки зрения, не готов заявить об этом прямо? И тогда математика будет совсем другой: к 17% тем, кто вслух говорит о том, что мы дороговаты, добавляются еще процентов 5-10% тех, кто постеснялся сказать об этом вслух, предпочитая просто не отвечать на наши письма и звонки. И тогда строчка “дорого” выходит на уверенное первое место.
Да и вообще — полезна ли такая статистика? Если взять представителей дорогих (не люксовых, а именно дорогих) сегментов — вероятно “дорого” тоже является подавляющей причиной отказа потенциального покупателя от сделки?
В общем, в очередной раз надеюсь на наш с вами коллективный разум. Уверен — вместе разберемся ;-)
Мы тут с коллегами по цеху (Анна Караулова, Василий Баранов и Иван Гринкевич) замутили дайджест по тематике digital-менеджмента.
У Ани очень давно есть Сообщество, объединяющее владельцев digital-агентсв, команд веб- и мобильной разработки (кстати, если вы - один из них и всё еще не в нём, очень рекомендую: https://news.1rj.ru/str/agencyboss).
Материалов со всех сторон валится много, а времени у руководителей всё меньше. Поэтому мы долго обсуждали и это и, наконец, решились - сделать рассылку, которая была бы дайджестом наиболее интересных материалов на тему около-digital-менеджмента, вышедших за последнее время.
В рассылке будут подборки по темам, о которых нас в Сообществе спрашивают чаще всего — просьбы посоветовать таск-трекер или систему для управленческого учета финансов, описать мотивации менеджеров по продажам или РМ-ов, дать примеры контрактов и описания бизнес-процессов, и так далее и тому подобное.
Сейчас мы тестируем гипотезу и хотим набрать early-birds-подписчиков. Если всё получится, то в январе мы выпустим первый выпуск, уже с февраля планируем перейти на режим 2 выпуска в месяц, а там, даст бог, и до формата еженедельника дорастем.
Если гипотеза не подтвердится - мы вернем деньги всем early-birds.
В общем, если вам эта тема интересна - оплачивайте и подписывайтесь: https://event.annakaraulova.ru/knowledge_base.
990 рублей в месяц - это в нынешних деньгах 5 чашек кофе. В обмен на годный контент по наболевшим для digital-руководителей темам - по-моему вполне себе сделка!
Такие дела ;-)
У Ани очень давно есть Сообщество, объединяющее владельцев digital-агентсв, команд веб- и мобильной разработки (кстати, если вы - один из них и всё еще не в нём, очень рекомендую: https://news.1rj.ru/str/agencyboss).
Материалов со всех сторон валится много, а времени у руководителей всё меньше. Поэтому мы долго обсуждали и это и, наконец, решились - сделать рассылку, которая была бы дайджестом наиболее интересных материалов на тему около-digital-менеджмента, вышедших за последнее время.
В рассылке будут подборки по темам, о которых нас в Сообществе спрашивают чаще всего — просьбы посоветовать таск-трекер или систему для управленческого учета финансов, описать мотивации менеджеров по продажам или РМ-ов, дать примеры контрактов и описания бизнес-процессов, и так далее и тому подобное.
Сейчас мы тестируем гипотезу и хотим набрать early-birds-подписчиков. Если всё получится, то в январе мы выпустим первый выпуск, уже с февраля планируем перейти на режим 2 выпуска в месяц, а там, даст бог, и до формата еженедельника дорастем.
Если гипотеза не подтвердится - мы вернем деньги всем early-birds.
В общем, если вам эта тема интересна - оплачивайте и подписывайтесь: https://event.annakaraulova.ru/knowledge_base.
990 рублей в месяц - это в нынешних деньгах 5 чашек кофе. В обмен на годный контент по наболевшим для digital-руководителей темам - по-моему вполне себе сделка!
Такие дела ;-)
Telegram
Чат «Управление агентством»
Чат для дружеского общения, вопросов и взаимопомощи руководителей агентств и веб-студий
Правила https://news.1rj.ru/str/agencyboss/111255
Для поиска подрядчиков и сотрудников https://news.1rj.ru/str/digital_partners_chat
Канал с новостями https://news.1rj.ru/str/agencymanagement
Правила https://news.1rj.ru/str/agencyboss/111255
Для поиска подрядчиков и сотрудников https://news.1rj.ru/str/digital_partners_chat
Канал с новостями https://news.1rj.ru/str/agencymanagement
Привет всем.
Спасибо за то, что не отписались от этого канала. Очень интенсивный получился конец прошлого года. Про начало этого года вообще молчу — тут всем все понятно.
Безусловно, это не слишком оправдывает мое молчание. Но сейчас, кажется, мне удалось немного расставить приоритеты и снова должно хватить сил и времени на регулярное ведение канала. Поэтому, продолжу здесь описывать будни IT-предпринимательства.
За то время, пока мы с вами не виделись, в жизни нашей компании произошли следующие изменения:
- Мы закрыли один из наших стартап-проектов (сервис аналитики маркетплейсов). Если честно, закрыли его еще в сентябре-октябре. Я тяжело переживал эту неудачу и это стало одной из причин того, что канал был заброшен на некоторое время — о победах писать легко, а вот о факапах и неудачах писать не хочется. Это тяжело и неприятно. Но я обязательно напишу в одном из следующих постов небольшую рефлексию о том, какие ошибки я лично совершил, работая над этим продуктом.
- Вместо него мы запустили новый стартап (да, я упрямый). Это вписывается в стратегию нашей компании — помимо услуг заказной разработки мы достаточно давно приняли решение реинвестировать прибыль в развитие собственных продуктов. Но для того, чтобы не увлечься и контролировать риски, приняли решение, что параллельно будем заниматься не более, чем двумя такими продуктами в том случае, если оба продукта пока не вышли на стадию самоокупаемости.
- Я успел написать курс для Яндекс.Практикум. Достаточно неожиданный для меня опыт. Ребята из Яндекс попросили меня стать их преподавателем. Преподавать я люблю, а умение объяснять сложные вещи простым языком — моя суперсила. Поэтому я с радостью согласился, но был крайне удивлен тем, что именно меня попросили преподавать. Короче говоря, я написал курс по аргументации, который Яндекс сейчас активно рекламирует. Так что если вы хотели повысить свои навыки в ведении полемики, споров и умении убеждать клиентов — я вместе с крутой командой редакторов, методологов, продюсеров и иллюстраторов Яндекс.Практикум, сделал все для того, чтобы научить вас этому за несколько небольших уроков.
- Мы с командой в очередной раз перестроились и провели компанию через первые месяцы военного кризиса. Как и всем, нам было очень страшно и сложно. Но сейчас, когда итоги первого квартала подведены, можно смело сказать, что с первыми месяцами мы справились более, чем успешно - рост выручки год к году составил чуть более 100%, не только сохранили весь ключевой персонал и не резали зарплаты, но и активно продолжаем нанимать, закрыли первый квартал с условной, но всё-таки прибылью, полностью выполнили план по продажам.
Так что, как видите, без дела я не сидел. И сейчас постараюсь рассказывать о получаемом опыте регулярно.
Еще раз спасибо за то, что вы все еще со мной.
Спасибо за то, что не отписались от этого канала. Очень интенсивный получился конец прошлого года. Про начало этого года вообще молчу — тут всем все понятно.
Безусловно, это не слишком оправдывает мое молчание. Но сейчас, кажется, мне удалось немного расставить приоритеты и снова должно хватить сил и времени на регулярное ведение канала. Поэтому, продолжу здесь описывать будни IT-предпринимательства.
За то время, пока мы с вами не виделись, в жизни нашей компании произошли следующие изменения:
- Мы закрыли один из наших стартап-проектов (сервис аналитики маркетплейсов). Если честно, закрыли его еще в сентябре-октябре. Я тяжело переживал эту неудачу и это стало одной из причин того, что канал был заброшен на некоторое время — о победах писать легко, а вот о факапах и неудачах писать не хочется. Это тяжело и неприятно. Но я обязательно напишу в одном из следующих постов небольшую рефлексию о том, какие ошибки я лично совершил, работая над этим продуктом.
- Вместо него мы запустили новый стартап (да, я упрямый). Это вписывается в стратегию нашей компании — помимо услуг заказной разработки мы достаточно давно приняли решение реинвестировать прибыль в развитие собственных продуктов. Но для того, чтобы не увлечься и контролировать риски, приняли решение, что параллельно будем заниматься не более, чем двумя такими продуктами в том случае, если оба продукта пока не вышли на стадию самоокупаемости.
- Я успел написать курс для Яндекс.Практикум. Достаточно неожиданный для меня опыт. Ребята из Яндекс попросили меня стать их преподавателем. Преподавать я люблю, а умение объяснять сложные вещи простым языком — моя суперсила. Поэтому я с радостью согласился, но был крайне удивлен тем, что именно меня попросили преподавать. Короче говоря, я написал курс по аргументации, который Яндекс сейчас активно рекламирует. Так что если вы хотели повысить свои навыки в ведении полемики, споров и умении убеждать клиентов — я вместе с крутой командой редакторов, методологов, продюсеров и иллюстраторов Яндекс.Практикум, сделал все для того, чтобы научить вас этому за несколько небольших уроков.
- Мы с командой в очередной раз перестроились и провели компанию через первые месяцы военного кризиса. Как и всем, нам было очень страшно и сложно. Но сейчас, когда итоги первого квартала подведены, можно смело сказать, что с первыми месяцами мы справились более, чем успешно - рост выручки год к году составил чуть более 100%, не только сохранили весь ключевой персонал и не резали зарплаты, но и активно продолжаем нанимать, закрыли первый квартал с условной, но всё-таки прибылью, полностью выполнили план по продажам.
Так что, как видите, без дела я не сидел. И сейчас постараюсь рассказывать о получаемом опыте регулярно.
Еще раз спасибо за то, что вы все еще со мной.
🔥8👍4👏4
Стартап — история провала или как мы закрыли собственный продукт
В сентябре 2020 года мы начали работу над собственным стартапом — сервисом аналитики маркетплейсов mpAdvisor. И ровно через год в сентябре 2021 года мы его закрыли, потеряв на этом ощутимую сумму денег и, как минимум, одного классного специалиста нашей команды.
Все любят хвастаться успехами, но лишь немногие рассказывают о своих провалах. Я решил поделиться нашей историей, чтобы заодно её отрефлексировать самому и понять, как нам не повторить эту историю с нашим новым продуктом, о котором я расскажу в одном из следующих постов.
Итак, хроники пикирующего бомбардировщика:
📅 В августе мы находим классную идею - рынок аналитики для торговцев на маркетплейсах Wildberries и OZON. Маркетплейсы растут, как на дрожжах, появляется потребность в хороших инструментах, на рынке уже появилось несколько игроков и кажется, у нас есть сильная техническая команда и партнер, знающий все о маркетплейсах. Кажется, у нас нет ни единого шанса на провал.
📅 В сентябре мы собираем команду фрилансеров. Все из них трудятся в нашей основной команде и соглашаются работать над проектом в свободное время в рамках отдельной оплаты. Мы разрабатываем план за 3 месяца сделать MVP продукта и начать продажи для того, чтобы протестировать гипотезу.
📅 В октябре мы теряем отраслевого эксперта (того самого, который знает всё о маркетплейсах). Не беда — решаю я, и подключаюсь к проекту в качестве владельца продукта (product owner) в надежде, что сам легко разберусь в нюансах этого рынка.
📅 В том же октябре мы понимаем, что нам нужно сменить ключевую технологию проекта и принимаем решение использовать на проекте диковинный в то время Golang. Появляются подозрения, что за 3 месяца мы можем не уложиться.
📅 В марте ценой героических усилий (разработчики, работают по 8 часов на основном месте работы и потом еще по 4-6 часов на проекте) мы выпускаем MVP с опозданием в 3 месяца. Это приводит к тому, что вся команда разработки изрядно выгорает и уже в апреле мы теряем ключевого разработчика.
Первые продажи показывают, что мы ошиблись с основной гипотезой. Наши конкуренты - mpStats (ведущий на сегодняшний день сервис аналитики в России) сфокусировались на функции анализе конкурентов, а мы - на функции оптимизации поставок. Все клиенты просят анализ конкурентов.
📅 В мае мы нанимаем первого фултайм специалиста в команду и форсируем работы, в надежде, что если мы добавим качественную аналитику в проект, мы сможем наверстать отставание от конкурента.С мая же мы выделяем деньги на привлечение трафика на сайт, в надежде нарастить выручку и сократить скорость прожигания денег в проекте.
📅 Июнь. Мы снова теряем golang-разработчика. К этому моменту выясняется, что такие разработчики в огромном числе нужны OZON и цены на них выросли в 2-3 раза. Мы начинаем терять деньги с утроенной скоростью. Новые клиенты по-прежнему требуют функционал анализа конкурентов и не готовы платить за те функции, что предоставляет наш сервис. В это же время mpStats, получая все больший финансовый поток, наращивает команду и начинает убегать от нас по функциональным возможностям семимильными шагами. На рынке вместое 3-5 игроков уже присутствует 15-20 команд.
📅 Июль. Мы понимаем, что двигаться дальше, без отраслевого эксперта — невозможно. Деньги начинают заканчиваться, поэтому мы ищем партнера, способного закрыть компетенцию и дать недостающее проекту финансирование. Есть план пивота продукта, но на него потребуется дополнительно 4-6 месяцев, собственного бюджета на которые у нас уже нет
📅 Август. К концу августа становится понятным, что мы не смогли оперативно найти партнера. Еще один член команды — на этот раз руководитель проекта, окончательно выгорает и покидает не только проект, но и нашу “головную” компанию.
📅 Сентябрь. Я принимаю непростое решение зафиксировать убыток и ликвидировать проект, признав поражение и высвободив силы и средства для новой попытки.
В сентябре 2020 года мы начали работу над собственным стартапом — сервисом аналитики маркетплейсов mpAdvisor. И ровно через год в сентябре 2021 года мы его закрыли, потеряв на этом ощутимую сумму денег и, как минимум, одного классного специалиста нашей команды.
Все любят хвастаться успехами, но лишь немногие рассказывают о своих провалах. Я решил поделиться нашей историей, чтобы заодно её отрефлексировать самому и понять, как нам не повторить эту историю с нашим новым продуктом, о котором я расскажу в одном из следующих постов.
Итак, хроники пикирующего бомбардировщика:
📅 В августе мы находим классную идею - рынок аналитики для торговцев на маркетплейсах Wildberries и OZON. Маркетплейсы растут, как на дрожжах, появляется потребность в хороших инструментах, на рынке уже появилось несколько игроков и кажется, у нас есть сильная техническая команда и партнер, знающий все о маркетплейсах. Кажется, у нас нет ни единого шанса на провал.
📅 В сентябре мы собираем команду фрилансеров. Все из них трудятся в нашей основной команде и соглашаются работать над проектом в свободное время в рамках отдельной оплаты. Мы разрабатываем план за 3 месяца сделать MVP продукта и начать продажи для того, чтобы протестировать гипотезу.
📅 В октябре мы теряем отраслевого эксперта (того самого, который знает всё о маркетплейсах). Не беда — решаю я, и подключаюсь к проекту в качестве владельца продукта (product owner) в надежде, что сам легко разберусь в нюансах этого рынка.
📅 В том же октябре мы понимаем, что нам нужно сменить ключевую технологию проекта и принимаем решение использовать на проекте диковинный в то время Golang. Появляются подозрения, что за 3 месяца мы можем не уложиться.
📅 В марте ценой героических усилий (разработчики, работают по 8 часов на основном месте работы и потом еще по 4-6 часов на проекте) мы выпускаем MVP с опозданием в 3 месяца. Это приводит к тому, что вся команда разработки изрядно выгорает и уже в апреле мы теряем ключевого разработчика.
Первые продажи показывают, что мы ошиблись с основной гипотезой. Наши конкуренты - mpStats (ведущий на сегодняшний день сервис аналитики в России) сфокусировались на функции анализе конкурентов, а мы - на функции оптимизации поставок. Все клиенты просят анализ конкурентов.
📅 В мае мы нанимаем первого фултайм специалиста в команду и форсируем работы, в надежде, что если мы добавим качественную аналитику в проект, мы сможем наверстать отставание от конкурента.С мая же мы выделяем деньги на привлечение трафика на сайт, в надежде нарастить выручку и сократить скорость прожигания денег в проекте.
📅 Июнь. Мы снова теряем golang-разработчика. К этому моменту выясняется, что такие разработчики в огромном числе нужны OZON и цены на них выросли в 2-3 раза. Мы начинаем терять деньги с утроенной скоростью. Новые клиенты по-прежнему требуют функционал анализа конкурентов и не готовы платить за те функции, что предоставляет наш сервис. В это же время mpStats, получая все больший финансовый поток, наращивает команду и начинает убегать от нас по функциональным возможностям семимильными шагами. На рынке вместое 3-5 игроков уже присутствует 15-20 команд.
📅 Июль. Мы понимаем, что двигаться дальше, без отраслевого эксперта — невозможно. Деньги начинают заканчиваться, поэтому мы ищем партнера, способного закрыть компетенцию и дать недостающее проекту финансирование. Есть план пивота продукта, но на него потребуется дополнительно 4-6 месяцев, собственного бюджета на которые у нас уже нет
📅 Август. К концу августа становится понятным, что мы не смогли оперативно найти партнера. Еще один член команды — на этот раз руководитель проекта, окончательно выгорает и покидает не только проект, но и нашу “головную” компанию.
📅 Сентябрь. Я принимаю непростое решение зафиксировать убыток и ликвидировать проект, признав поражение и высвободив силы и средства для новой попытки.
👍11
Какие ключевые ошибки мы допустили, на мой взгляд?
⚠️ Для успешного проекта, помимо хорошей идеи нужны, как минимум хипстер (лидер продукта) + хакер (технический лидер) + хастлер (продаван). У нас было только два компонента из трех, да и “хипстера” мы потеряли почти на старте проекта.
⚠️ Выделенные ресурсы и команда под проект. На проект должны быть выделены отдельные люди. Сразу. С первого дня. Да, они могут работать у вас part-time первое время, но следите за тем, чтобы их общая загрузка не превышала 8-10 часов. В противном случае команда очень быстро выгорает и разваливается.
⚠️ Быстрое тестирование гипотезы и быстрые пивоты. Продажи можно было начинать гораздо раньше — тогда мы бы почти сразу поняли, что уверовали в идею, за которую никто не хочет платить. И даже когда мы поняли, что сделали не то, мы продолжали упорствовать и гнуть свою линию.
⚠️ Ставка на дефицитный технологический ресурс. Мы нашли классную технологию (Golang), но забыли оценить уровень доступности и стоимость специалистов на рынке и, в результате, не смогли вовремя заменить ушедшего разработчика.
Я очень горд тем, что мы сумели реализовать проект, вывести его на рынок и сделать первые продажи. Конечно же, по моему самолюбие был нанесен мощный удар — проигрывать неприятно и больно.
Но я стараюсь относиться к этому, как к опыту. Как к обучению, которое мы получили, пусть и за достаточно высокую цену. В конце-концов за одного битого двух небитых дают :-)
К тому же, работать над проектом было по-настоящему круто! Это было незабываемое приключение!
Поэтому, рук мы не опустили, постарались учесть ошибки, и уже в марте 2022 года запустили на рынок свой следующий продукт, траектория которого, верю, будет гораздо успешнее именно благодаря бесценному опыту, полученному на этом, увы, провальном для нас проекте.
⚠️ Для успешного проекта, помимо хорошей идеи нужны, как минимум хипстер (лидер продукта) + хакер (технический лидер) + хастлер (продаван). У нас было только два компонента из трех, да и “хипстера” мы потеряли почти на старте проекта.
⚠️ Выделенные ресурсы и команда под проект. На проект должны быть выделены отдельные люди. Сразу. С первого дня. Да, они могут работать у вас part-time первое время, но следите за тем, чтобы их общая загрузка не превышала 8-10 часов. В противном случае команда очень быстро выгорает и разваливается.
⚠️ Быстрое тестирование гипотезы и быстрые пивоты. Продажи можно было начинать гораздо раньше — тогда мы бы почти сразу поняли, что уверовали в идею, за которую никто не хочет платить. И даже когда мы поняли, что сделали не то, мы продолжали упорствовать и гнуть свою линию.
⚠️ Ставка на дефицитный технологический ресурс. Мы нашли классную технологию (Golang), но забыли оценить уровень доступности и стоимость специалистов на рынке и, в результате, не смогли вовремя заменить ушедшего разработчика.
Я очень горд тем, что мы сумели реализовать проект, вывести его на рынок и сделать первые продажи. Конечно же, по моему самолюбие был нанесен мощный удар — проигрывать неприятно и больно.
Но я стараюсь относиться к этому, как к опыту. Как к обучению, которое мы получили, пусть и за достаточно высокую цену. В конце-концов за одного битого двух небитых дают :-)
К тому же, работать над проектом было по-настоящему круто! Это было незабываемое приключение!
Поэтому, рук мы не опустили, постарались учесть ошибки, и уже в марте 2022 года запустили на рынок свой следующий продукт, траектория которого, верю, будет гораздо успешнее именно благодаря бесценному опыту, полученному на этом, увы, провальном для нас проекте.
👍6
Три ошибки, приводящие к проектам бесконечной разработки
Вчера встречался со знакомым владельцем одного из крупнейших российских e-commerce проектов. Он столкнулся со сложной и, увы, частой проблемой — невозможностью перезапустить огромный проект.
В двух словах — есть огромный e-commerce, технологии и архитектура которого давно устарели. Поддерживать и развивать его больно, дорого и оооочень долго: из-за устаревшей архитектуры каждая новая функция разрабатывается вчетверо дольше обычного и требует тщательного тестирования, которое все равно не защищает на 100% от поломок в уже работающих частях системы.
Было принято, казалось бы, правильное решение - разработать современную архитектуру силами приглашенной команды талантов и переключить клиентский поток со старого проекта на новый.
В результате потрачено несколько лет, космическая сумма денег, по пути сменено три супер-коллектива (реально топовые команды рунета), а воз и ныне там.
Знакомо? Что пошло не так и как, на мой взгляд, такую проблему можно было бы решить более эффективно?
1️⃣ Самая главная ошибка, которую, как мне кажется, совершила команда моего друга - категорическое несогласие на урезание функциональности (MVP).
Текущий проект строили не один год. И ожидать, что “девять женщин выносят ребенка за месяц”, как минимум, наивно. Бизнес утверждает: “мы не можем согласиться на выпуск проекта с неполным функционалом — нам нужен весь функционал”. Разработка пожимает плечами и … постепенно закапывается в нюансах, превращая разработку проекта в “вечнострой”.
Более эффективным было бы согласиться на реализацию неполного функционала и запуск обновленной версии проекта в “фоновом режиме”. Да, это удорожило бы разработку: наряду с постепенным вводом в строй новых функций пришлось бы обслуживать уже выпущенные. Но проект стал бы более управляемым и заметить ощутимые отклонения от графика можно было бы гораздо раньше (а значит и минимизировать потери).
При грамотном руководстве проектом, “next-gen версия” постепенно набрала бы функционал, достаточный для “переключения версий”. И даже тут я бы не рекомендовал спешить — новую версию я бы вводил в строй, постепенно переводя на неё трафик (например, сперва переключив только самую лояльную часть аудитории, готовую прощать ошибки).
2️⃣ Вторая ошибка — слишком мягкий контроль дорожной карты проекта.
Со слов моего товарища даты первой демонстрации продукта переносились уже бесчисленное количество раз. За годы разработки руководство видело лишь бесконечные презентации.
Хорошего руководителя продукта (Product Owner) такая ситуация должна была бы, как минимум, насторожить. Чем чаще нарушаются обещания, тем плотнее и чаще осуществляется контроль — для меня это одно из главных правил проектного менеджмента.
Каждый раз, когда обещание нарушено, нужно проводить “разбор полетов”, который должен помочь понять, что именно пошло не так и, главное, как не допустить этого в следующий раз. В проект при этом должны вноситься соответствующие изменения — вплоть до замены технологий, руководителя проекта, команды разработки.
3️⃣ Третья ошибка — слишком мягкий риск-менеджмент.
Насколько я понял из разговора с товарищем — проект давно и кратно вышел за пределы изначально выделенного на него бюджета.
Здесь у меня нет какого-то однозначно верного решения. Действительно бывают ситуации, когда бесконечные инвестиции в проект в конце-концов окупаются (расскажу в одном из последующих своих постов об игровом проекте другого своего знакомого, который сорвал сроки и бюджет в разы, но … при этом в конце-концов вышел в плюс и стал очень успешным игровым проектом).
Но в целом всё-таки у проекта должны быть бюджетные ограничения, которые не могут расширяться бесконечно. Особенно, если динамика проекта не очевидна или отсутствует вовсе (вспоминаем о бесконечных презентациях). В какой-то момент решение остановить проект и зафиксировать убыток может спасти инвестору гораздо бОльшие средства в перспективе, чем выделение очередного транша финансирования в надежде спасти уже вложенные средства.
Вчера встречался со знакомым владельцем одного из крупнейших российских e-commerce проектов. Он столкнулся со сложной и, увы, частой проблемой — невозможностью перезапустить огромный проект.
В двух словах — есть огромный e-commerce, технологии и архитектура которого давно устарели. Поддерживать и развивать его больно, дорого и оооочень долго: из-за устаревшей архитектуры каждая новая функция разрабатывается вчетверо дольше обычного и требует тщательного тестирования, которое все равно не защищает на 100% от поломок в уже работающих частях системы.
Было принято, казалось бы, правильное решение - разработать современную архитектуру силами приглашенной команды талантов и переключить клиентский поток со старого проекта на новый.
В результате потрачено несколько лет, космическая сумма денег, по пути сменено три супер-коллектива (реально топовые команды рунета), а воз и ныне там.
Знакомо? Что пошло не так и как, на мой взгляд, такую проблему можно было бы решить более эффективно?
1️⃣ Самая главная ошибка, которую, как мне кажется, совершила команда моего друга - категорическое несогласие на урезание функциональности (MVP).
Текущий проект строили не один год. И ожидать, что “девять женщин выносят ребенка за месяц”, как минимум, наивно. Бизнес утверждает: “мы не можем согласиться на выпуск проекта с неполным функционалом — нам нужен весь функционал”. Разработка пожимает плечами и … постепенно закапывается в нюансах, превращая разработку проекта в “вечнострой”.
Более эффективным было бы согласиться на реализацию неполного функционала и запуск обновленной версии проекта в “фоновом режиме”. Да, это удорожило бы разработку: наряду с постепенным вводом в строй новых функций пришлось бы обслуживать уже выпущенные. Но проект стал бы более управляемым и заметить ощутимые отклонения от графика можно было бы гораздо раньше (а значит и минимизировать потери).
При грамотном руководстве проектом, “next-gen версия” постепенно набрала бы функционал, достаточный для “переключения версий”. И даже тут я бы не рекомендовал спешить — новую версию я бы вводил в строй, постепенно переводя на неё трафик (например, сперва переключив только самую лояльную часть аудитории, готовую прощать ошибки).
2️⃣ Вторая ошибка — слишком мягкий контроль дорожной карты проекта.
Со слов моего товарища даты первой демонстрации продукта переносились уже бесчисленное количество раз. За годы разработки руководство видело лишь бесконечные презентации.
Хорошего руководителя продукта (Product Owner) такая ситуация должна была бы, как минимум, насторожить. Чем чаще нарушаются обещания, тем плотнее и чаще осуществляется контроль — для меня это одно из главных правил проектного менеджмента.
Каждый раз, когда обещание нарушено, нужно проводить “разбор полетов”, который должен помочь понять, что именно пошло не так и, главное, как не допустить этого в следующий раз. В проект при этом должны вноситься соответствующие изменения — вплоть до замены технологий, руководителя проекта, команды разработки.
3️⃣ Третья ошибка — слишком мягкий риск-менеджмент.
Насколько я понял из разговора с товарищем — проект давно и кратно вышел за пределы изначально выделенного на него бюджета.
Здесь у меня нет какого-то однозначно верного решения. Действительно бывают ситуации, когда бесконечные инвестиции в проект в конце-концов окупаются (расскажу в одном из последующих своих постов об игровом проекте другого своего знакомого, который сорвал сроки и бюджет в разы, но … при этом в конце-концов вышел в плюс и стал очень успешным игровым проектом).
Но в целом всё-таки у проекта должны быть бюджетные ограничения, которые не могут расширяться бесконечно. Особенно, если динамика проекта не очевидна или отсутствует вовсе (вспоминаем о бесконечных презентациях). В какой-то момент решение остановить проект и зафиксировать убыток может спасти инвестору гораздо бОльшие средства в перспективе, чем выделение очередного транша финансирования в надежде спасти уже вложенные средства.
👍6🔥1🤔1
Привет всем. Снова пропал. Знаю. Простите.
Нескончаемый завал дел. А всё потому, что я тащу на себе уже четыре проекта (компании по своей сути).
Основной компании уже 23 года - это компания по заказной веб-разработке. В 2014-м году мне "по наследству" от бывшего партнера досталось агентство интернет-маркетинга, в которое я никак не могу подобрать генерального директора и регулярно вынужден там подруливать.
А после того, как я закончил Московскую Школу Управления Сколково, я ударился в продуктовую разработку. Один проект мы уже успели закрыть - я про него тут писал. В 2020-м году мы стартовали другой стартап с основателями сети магазинов Мосигра. Сегодня этому проекту уже два года и хотя по духу это всё еще стартап, по своей сути это, пусть всё еще убыточная, но уже вполне оборотистая компания. Расскажу о ней как-нибудь отдельно обязательно. Этот продукт, как мне кажется, очень близок к тому, чтобы стать прорывом и, как минимум, пройти точку безубыточности еще до конца этого года.
Следующий стартап мы запустили буквально в середине марта - на волне известных и очень печальных событий, которые продолжаются по сей день. Это пока в прямом смысле стартап, но и у него есть уже первые успехи - всего за несколько месяцев. И происходит это потому, что каждый предыдущий провал, каждая предыдущая неудачная попытка, делала нас сильнее, опытнее и злее. Так что пока получается очень бодро, но тоже все еще убыточно )) Об этом проекте я постараюсь прямо на днях рассказать.
Я надеялся, что смогу более или менее полноценно заниматься этими продуктами, уделяя им дополнительно по паре часов к своему основному рабочему времени. Но стартап растет, превращается в компанию и, если не успеть выйти из операционной деятельности хотя бы в одном из проектов, начинает, как растущий ребенок, требовать все большего и большего внимания и времени.
В результате фокус снижается, а длительность рабочего дня увеличивается. С конца февраля и вот уже на протяжение пяти месяцев я работаю по 10-14 часов в будни и по 4-5 часов в выходные дни. Нездоровая фигня конечно. Но заставляет всерьез изучать вопросы построения процессной компании и формирования управленческих команд. За эти полгода как управленец я вырос больше, чем за предыдущие года три вместе взятые.
Такие дела.
Нескончаемый завал дел. А всё потому, что я тащу на себе уже четыре проекта (компании по своей сути).
Основной компании уже 23 года - это компания по заказной веб-разработке. В 2014-м году мне "по наследству" от бывшего партнера досталось агентство интернет-маркетинга, в которое я никак не могу подобрать генерального директора и регулярно вынужден там подруливать.
А после того, как я закончил Московскую Школу Управления Сколково, я ударился в продуктовую разработку. Один проект мы уже успели закрыть - я про него тут писал. В 2020-м году мы стартовали другой стартап с основателями сети магазинов Мосигра. Сегодня этому проекту уже два года и хотя по духу это всё еще стартап, по своей сути это, пусть всё еще убыточная, но уже вполне оборотистая компания. Расскажу о ней как-нибудь отдельно обязательно. Этот продукт, как мне кажется, очень близок к тому, чтобы стать прорывом и, как минимум, пройти точку безубыточности еще до конца этого года.
Следующий стартап мы запустили буквально в середине марта - на волне известных и очень печальных событий, которые продолжаются по сей день. Это пока в прямом смысле стартап, но и у него есть уже первые успехи - всего за несколько месяцев. И происходит это потому, что каждый предыдущий провал, каждая предыдущая неудачная попытка, делала нас сильнее, опытнее и злее. Так что пока получается очень бодро, но тоже все еще убыточно )) Об этом проекте я постараюсь прямо на днях рассказать.
Я надеялся, что смогу более или менее полноценно заниматься этими продуктами, уделяя им дополнительно по паре часов к своему основному рабочему времени. Но стартап растет, превращается в компанию и, если не успеть выйти из операционной деятельности хотя бы в одном из проектов, начинает, как растущий ребенок, требовать все большего и большего внимания и времени.
В результате фокус снижается, а длительность рабочего дня увеличивается. С конца февраля и вот уже на протяжение пяти месяцев я работаю по 10-14 часов в будни и по 4-5 часов в выходные дни. Нездоровая фигня конечно. Но заставляет всерьез изучать вопросы построения процессной компании и формирования управленческих команд. За эти полгода как управленец я вырос больше, чем за предыдущие года три вместе взятые.
Такие дела.
👍13🔥3🤯2
Привет всем этим субботним днем.
Давно обещал вам рассказать о проектах, над которыми мы сейчас работаем. Сегодня расскажу об одном из них. Пост будет в результате немного походить на рекламный. Это потому, что часть информации для него я взял из наших маркетинговых инструментов. Но это не реклама — это наш собственный продукт, которым мы очень гордимся и в который вкладываем много сил и времени.
Зайду издалека ...
Вчера стало известно, что в «Почте России» подтвердили частичную утечку данных пользователей у подрядчика. Буквально на днях стало известно о том, что суд оштрафовал «Гемотест» на 60 тысяч рублей за утечку данных пользователей. В конце февраля 2022 года произошла утечка данных клиентов СДЭК, а 1 марта об утечке сообщила «Яндекс Еда», 20 мая об утечке телефонов и данных о заказах пользователей рассказал Delivery Club. Этот печальный список можно было бы продолжать еще долго.
Знаете ли вы, что в мире только в 44% случаев причиной утечки данных стали внешние атаки, а в 56% случаев был задействован внутренний нарушитель, из которых в 44,8% случаев виновными оказались непривилегированные действующие сотрудники (по данным InfoWatch). Иными словами, почти 60% потери важных данных стало небрежное отношение рядовых сотрудников к корпоративным “секретам”.
Решить эту проблему помогает наш новый продукт: BearPass.ru — это корпоративный “сейф” для централизованного хранения и организации доступа к паролям для систем и сервисов, используемых компанией или организацией. Пароли хранятся и передаются в зашифрованном виде, а само решение — коробочное, а значит хранится на сервере организации и не может “утечь” в сеть при очередном взломе популярного облачного сервиса.
Когда вам пора задуматься о внедрении корпоративного менеджера паролей?
— Ваша компания использует большое количество внутренних и внешних сервисов для собственных нужд или хранит секреты чужих компаний в силу профессиональной деятельности (например, вы оказываете аутсорсинговые услуги).
— Сотрудники постоянно делятся паролями в электронных письмах и мессенджерах.
— При увольнении сотрудника вы не можете в течение 1-2 минут получить ответ на вопрос о том, к каким сервисам ему был предоставлен доступ.
— Самый распространенный пароль в компании 12345 или qwerty (sic!)
В чем преимущества BearPass?
— Это “коробочный” (Self Hosted) продукт. Это означает, что он устанавливается на ваши сервера и вы полностью контролируете собственные секреты.
— Это российский продукт - его легко оплачивать безналичным способом и он не уйдет с рынка под давлением санкций.
— Все пароли хранятся централизованно и надежно защищены алгоритмами шифрования стандарта AES-256.
— Сервис создан на базе open source технологий (PHP Laravel и PostgreSQL). Вы можете самостоятельно проверить каждую строку кода и убедиться в его надежности и отсутствии “жучков”.
— Благодаря удобной древовидной структуре и мощному поиску, сотрудникам легко находить и использовать пароли.
— С помощью расширения для браузера, ваши сотрудники перестанут “набивать” пароли. А значит программы-шпионы вроде “кейлоггеров” вам больше не страшны.
— В продукте реализован очень гибкий сценарий управления распределенном доступом — можно настроить доступ для отдельных ролей или даже для каждого сотрудника по отдельности.
— Подсистема журналирования событий позволит точно восстановить хронологию событий и обнаружить, кто именно совершил те или иные действия в системе.
— Ну и, наконец, система автоматически следит за тем, не попали ли ваши пароли в базы данных Даркнета и за тем, чтобы пароли соответствовали внутренним политикам безопасности и своевременно обновлялись.
Этот продукт мы запустили, увидев в марте активный уход ключевых зарубежных игроков, занимавших до этого доминирующее положение на российском рынке. Знаменитые 1Password, LastPass и Bitwarden — это иностранные компании, оплачивать услуги которых с некоторого времени стало неудобно, а иногда и невозможно.
Давно обещал вам рассказать о проектах, над которыми мы сейчас работаем. Сегодня расскажу об одном из них. Пост будет в результате немного походить на рекламный. Это потому, что часть информации для него я взял из наших маркетинговых инструментов. Но это не реклама — это наш собственный продукт, которым мы очень гордимся и в который вкладываем много сил и времени.
Зайду издалека ...
Вчера стало известно, что в «Почте России» подтвердили частичную утечку данных пользователей у подрядчика. Буквально на днях стало известно о том, что суд оштрафовал «Гемотест» на 60 тысяч рублей за утечку данных пользователей. В конце февраля 2022 года произошла утечка данных клиентов СДЭК, а 1 марта об утечке сообщила «Яндекс Еда», 20 мая об утечке телефонов и данных о заказах пользователей рассказал Delivery Club. Этот печальный список можно было бы продолжать еще долго.
Знаете ли вы, что в мире только в 44% случаев причиной утечки данных стали внешние атаки, а в 56% случаев был задействован внутренний нарушитель, из которых в 44,8% случаев виновными оказались непривилегированные действующие сотрудники (по данным InfoWatch). Иными словами, почти 60% потери важных данных стало небрежное отношение рядовых сотрудников к корпоративным “секретам”.
Решить эту проблему помогает наш новый продукт: BearPass.ru — это корпоративный “сейф” для централизованного хранения и организации доступа к паролям для систем и сервисов, используемых компанией или организацией. Пароли хранятся и передаются в зашифрованном виде, а само решение — коробочное, а значит хранится на сервере организации и не может “утечь” в сеть при очередном взломе популярного облачного сервиса.
Когда вам пора задуматься о внедрении корпоративного менеджера паролей?
— Ваша компания использует большое количество внутренних и внешних сервисов для собственных нужд или хранит секреты чужих компаний в силу профессиональной деятельности (например, вы оказываете аутсорсинговые услуги).
— Сотрудники постоянно делятся паролями в электронных письмах и мессенджерах.
— При увольнении сотрудника вы не можете в течение 1-2 минут получить ответ на вопрос о том, к каким сервисам ему был предоставлен доступ.
— Самый распространенный пароль в компании 12345 или qwerty (sic!)
В чем преимущества BearPass?
— Это “коробочный” (Self Hosted) продукт. Это означает, что он устанавливается на ваши сервера и вы полностью контролируете собственные секреты.
— Это российский продукт - его легко оплачивать безналичным способом и он не уйдет с рынка под давлением санкций.
— Все пароли хранятся централизованно и надежно защищены алгоритмами шифрования стандарта AES-256.
— Сервис создан на базе open source технологий (PHP Laravel и PostgreSQL). Вы можете самостоятельно проверить каждую строку кода и убедиться в его надежности и отсутствии “жучков”.
— Благодаря удобной древовидной структуре и мощному поиску, сотрудникам легко находить и использовать пароли.
— С помощью расширения для браузера, ваши сотрудники перестанут “набивать” пароли. А значит программы-шпионы вроде “кейлоггеров” вам больше не страшны.
— В продукте реализован очень гибкий сценарий управления распределенном доступом — можно настроить доступ для отдельных ролей или даже для каждого сотрудника по отдельности.
— Подсистема журналирования событий позволит точно восстановить хронологию событий и обнаружить, кто именно совершил те или иные действия в системе.
— Ну и, наконец, система автоматически следит за тем, не попали ли ваши пароли в базы данных Даркнета и за тем, чтобы пароли соответствовали внутренним политикам безопасности и своевременно обновлялись.
Этот продукт мы запустили, увидев в марте активный уход ключевых зарубежных игроков, занимавших до этого доминирующее положение на российском рынке. Знаменитые 1Password, LastPass и Bitwarden — это иностранные компании, оплачивать услуги которых с некоторого времени стало неудобно, а иногда и невозможно.
👍9