План выхода на миллион
Давно читал статью про движение успешных стартапов, которые не стали брать инвестиции. Один из самых известных таких проектов — Mailchimp. Компания с огромным оборотом осталась в руках основателей. Идея мне очень понравилась. Мысль окупаться и зарабатывать без внешних инвесторов засела в голове.
Чтобы это получилось, мы (пока) не тратим время на привлечение инвестиций, а считаем, сходится ли экономика проекта. Сможем ли платить по счетам?
Мы запустили новое направление, которое должно стать основой нашего процветания.
Со средней покупки в этом направлении стартап зарабатывает 160 рублей — несколько процентов от сделки. Усилий по продаже практически нет, заказ оформляется клиентом без участия операторов и продавцов. Трафик условно бесплатный — мы уже получаем его через SEO. Чтобы заработать миллион, нам нужно продать 6500 заказов в месяц. Кажется, дохрена. Делим на 30 дней — примерно 220 заказов в день, теперь норм.
Инвентарь для заказов поставляют партнёры, они же получают львиную долю выручки и приводят часть трафика в воронку.
В данном проекте именно партнёры являются драйвером роста.
По опыту и анализу средний партнёр приведёт 200-300 заказов за месяц. Это почти совпадает с расчётом выше — 220 заказов в день. Условно, прикинем, что нам нужно 30 действующих средних партнёров в каждом месяце.
За прошлый год в нашей CRM было взаимодействие с 397 целевыми партнёрами, которым мы продали любую небольшую услугу. Задача ближайших месяцев — подключить 10% этой базы на новое направление.
Выглядит всё реально. Пойду делать.
Давно читал статью про движение успешных стартапов, которые не стали брать инвестиции. Один из самых известных таких проектов — Mailchimp. Компания с огромным оборотом осталась в руках основателей. Идея мне очень понравилась. Мысль окупаться и зарабатывать без внешних инвесторов засела в голове.
Чтобы это получилось, мы (пока) не тратим время на привлечение инвестиций, а считаем, сходится ли экономика проекта. Сможем ли платить по счетам?
Мы запустили новое направление, которое должно стать основой нашего процветания.
Со средней покупки в этом направлении стартап зарабатывает 160 рублей — несколько процентов от сделки. Усилий по продаже практически нет, заказ оформляется клиентом без участия операторов и продавцов. Трафик условно бесплатный — мы уже получаем его через SEO. Чтобы заработать миллион, нам нужно продать 6500 заказов в месяц. Кажется, дохрена. Делим на 30 дней — примерно 220 заказов в день, теперь норм.
Инвентарь для заказов поставляют партнёры, они же получают львиную долю выручки и приводят часть трафика в воронку.
В данном проекте именно партнёры являются драйвером роста.
По опыту и анализу средний партнёр приведёт 200-300 заказов за месяц. Это почти совпадает с расчётом выше — 220 заказов в день. Условно, прикинем, что нам нужно 30 действующих средних партнёров в каждом месяце.
За прошлый год в нашей CRM было взаимодействие с 397 целевыми партнёрами, которым мы продали любую небольшую услугу. Задача ближайших месяцев — подключить 10% этой базы на новое направление.
Выглядит всё реально. Пойду делать.
❤8👾5👀3
Скрипт для проброса UTM-меток через лендинг во внешний сервис
Ситуация:
На лендинг из разных каналов заливается трафик, размеченный utm-метками.
Оформление заказа происходит на внешнем сервисе. На лендинге размещены кнопки [КУПИТЬ], по нажатию на которые посетитель покидает лендинг. Внешний сервис тоже умеет учитывать utm-метки.
Задача:
Проставить в ссылки на кнопках действия те же метки, с которым посетитель пришёл на лендинг.
Решение:
Скрипт автомагически добавит utm-метки ко всем ссылкам с указанной базой на странице.
Укажите базовую ссылку в переменной
Если utm-меток в адресной строке нет, ничего не произойдёт.
Для Tilda вставляем скрипт в блок HTML-код.
Для остальных сайтов — добавляем скрипт в подвал сайта.
Ситуация:
На лендинг из разных каналов заливается трафик, размеченный utm-метками.
Оформление заказа происходит на внешнем сервисе. На лендинге размещены кнопки [КУПИТЬ], по нажатию на которые посетитель покидает лендинг. Внешний сервис тоже умеет учитывать utm-метки.
Задача:
Проставить в ссылки на кнопках действия те же метки, с которым посетитель пришёл на лендинг.
Решение:
Скрипт автомагически добавит utm-метки ко всем ссылкам с указанной базой на странице.
Укажите базовую ссылку в переменной
TICKET_URL_BASE.Если utm-меток в адресной строке нет, ничего не произойдёт.
Для Tilda вставляем скрипт в блок HTML-код.
Для остальных сайтов — добавляем скрипт в подвал сайта.
<script>
(function () {
const TICKET_URL_BASE = 'https://moneymachine.com/777';
const currentUrlParams = new URLSearchParams(window.location.search);
const utmParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content'];
const hasUTM = utmParams.some(param => currentUrlParams.has(param));
if (!hasUTM) return;
const links = document.querySelectorAll(`a[href^="${TICKET_URL_BASE}"]`);
links.forEach(link => {
const url = new URL(link.href);
utmParams.forEach(param => {
if (currentUrlParams.has(param)) {
url.searchParams.set(param, currentUrlParams.get(param));
}
});
link.href = url.toString();
});
})();
</script>
❤7
Почему 💾 обозначает Сохранить?
Удивительно, но в 2025 году мы всё ещё используем иконку дискеты как символ сохранения документов.
Но как дискета, прародитель флэшки из прошлого века, связана с сохранением файлов на моём компьютере?
Я начинал путь с ZX Spectrum, мне всё понятно и я сейчас объясню этот незаметный парадокс.
В первых компьютерах не могло закончиться место на жестком диске. Потому что совсем не было жесткого диска! 🤯 Пользователь включал компьютер и попадал в "чистую" операционную систему с заводскими настройками, которая ничего не знала про предыдущие сеансы. Сама операционная система была записана на чип. Хранить наши файлы в компьютере было негде.
Для хранения и перемещения информации использовали перфокарты, магнитную ленту, а позднее дискеты разного диаметра.
Созданный на компьютере файл нужно было "сохранять" — копировать из оперативной памяти на вставленную в дисковод дискету. Если этого не сделать, оперативная память стиралась при выключении и все труды терялись.
Для первых пользователей иконка дискеты была понятна, ведь она делала ровно то, что нарисовано — сохраняла на дискету. Образ менялся вместе с носителем и остановился на последнем массовом формате: 3,5-дюйма, 1,44 МБ.
В 90-х в персональных компьютерах появилась постоянная память — жёсткий диск. Теперь файлы чаще сохраняли на внутренний диск, вместо дискет, и они постепенно ушли из обращения. А иконка осталась. Так никто и не заменил знакомую дискету на значок жесткого диска. Пока не стало слишком поздно...
Сегодня мы видим, как подросток нажимает на иконку дискеты на айфоне в интерфейсе облачного приложения. Он никогда не держал дискету в руках. Что он думает про этот значок? Стала ли для него дискета абстрактным символом без смысла?
Удивительно, но в 2025 году мы всё ещё используем иконку дискеты как символ сохранения документов.
Но как дискета, прародитель флэшки из прошлого века, связана с сохранением файлов на моём компьютере?
Я начинал путь с ZX Spectrum, мне всё понятно и я сейчас объясню этот незаметный парадокс.
В первых компьютерах не могло закончиться место на жестком диске. Потому что совсем не было жесткого диска! 🤯 Пользователь включал компьютер и попадал в "чистую" операционную систему с заводскими настройками, которая ничего не знала про предыдущие сеансы. Сама операционная система была записана на чип. Хранить наши файлы в компьютере было негде.
Для хранения и перемещения информации использовали перфокарты, магнитную ленту, а позднее дискеты разного диаметра.
Созданный на компьютере файл нужно было "сохранять" — копировать из оперативной памяти на вставленную в дисковод дискету. Если этого не сделать, оперативная память стиралась при выключении и все труды терялись.
Для первых пользователей иконка дискеты была понятна, ведь она делала ровно то, что нарисовано — сохраняла на дискету. Образ менялся вместе с носителем и остановился на последнем массовом формате: 3,5-дюйма, 1,44 МБ.
В 90-х в персональных компьютерах появилась постоянная память — жёсткий диск. Теперь файлы чаще сохраняли на внутренний диск, вместо дискет, и они постепенно ушли из обращения. А иконка осталась. Так никто и не заменил знакомую дискету на значок жесткого диска. Пока не стало слишком поздно...
Сегодня мы видим, как подросток нажимает на иконку дискеты на айфоне в интерфейсе облачного приложения. Он никогда не держал дискету в руках. Что он думает про этот значок? Стала ли для него дискета абстрактным символом без смысла?
❤10🔥3👾2
Как быстро провести аудит чужого кода с помощью AI.
Я смотрю достаточно много репозиториев с чужим кодом. Нужно разобраться как работает, найти проблемные места и поговорить с разработчиком предметно.
Моя версия, как сделать аудит кода с помощью AI:
Клонируешь репозиторий.
Запускаешь Cursor AI — форк VS Code с встроенным AI.
Ждёшь пока Cursor проиндексирует код и построит локальную базу.
В это же время в чат с ChatGPT загружаешь файлы package.json, composer.json, requirements.txt, gitlab-ci.yml, docker-compose.yml или что у вас там в корне лежит.
Формулируешь задание написать промпт на английском языке для другого AI, который будет проводить аудит кода. Указываешь все аспекты и особенности, на которые хочешь обратить внимание. Можно попросить сфокусироваться на безопасности или тех долге.
GPT пишет промпт на пару страниц и этот промпт вставляешь в Cursor AI.
Cursor выдаёт гигантские подробные заключения с разбором стиля, архитектурных ошибок, технического долга, перегруженных классов, дырок в безопасности, нарушений паттернов проектирования и другими аспектами.
Результат получается с галлюцинациями, но экономит много времени. Точно понятно, что в коде смотреть и какие вопросы авторам задавать.
PS: Очень полезно запускать такой аудит на своём проекте.
Я смотрю достаточно много репозиториев с чужим кодом. Нужно разобраться как работает, найти проблемные места и поговорить с разработчиком предметно.
Моя версия, как сделать аудит кода с помощью AI:
Клонируешь репозиторий.
Запускаешь Cursor AI — форк VS Code с встроенным AI.
Ждёшь пока Cursor проиндексирует код и построит локальную базу.
В это же время в чат с ChatGPT загружаешь файлы package.json, composer.json, requirements.txt, gitlab-ci.yml, docker-compose.yml или что у вас там в корне лежит.
Формулируешь задание написать промпт на английском языке для другого AI, который будет проводить аудит кода. Указываешь все аспекты и особенности, на которые хочешь обратить внимание. Можно попросить сфокусироваться на безопасности или тех долге.
GPT пишет промпт на пару страниц и этот промпт вставляешь в Cursor AI.
Cursor выдаёт гигантские подробные заключения с разбором стиля, архитектурных ошибок, технического долга, перегруженных классов, дырок в безопасности, нарушений паттернов проектирования и другими аспектами.
Результат получается с галлюцинациями, но экономит много времени. Точно понятно, что в коде смотреть и какие вопросы авторам задавать.
PS: Очень полезно запускать такой аудит на своём проекте.
❤6🔥5
Открываем диджитал агентство — плюсы и реальные ограничения.
Для многих специалистов открытие агентства — это естественный путь развития, переход из найма в свой бизнес.
Плюсы для старта:
- Не требует стартового капитала — можно взять первый заказ и выполнить самому.
- Рынок насыщен заказами — многие находят первых клиентов через рекомендации знакомых. "Сарафан" — значимый источник денег для многих малых агентств.
- Легко найти исполнителей на фриланс, в найм, аутсорс, аутстафф или субподряд.
- Доход специалиста быстро начинает превышать доход в найме.
Вот только при всех этих плюсах в бизнес-модели агентств есть существенные ограничения.
Агентство не может кратно увеличить количество обслуживаемых клиентов без расширения штата. Профессиональные услуги масштабируются через "мозги", то есть через очень квалифицированных сотрудников. Чем более квалифицированный персонал нужен для выполнения проектов, тем сложнее будет вырастить агентство.
В случае успеха, вчерашний опытный специалист становится неопытным предпринимателем. А двойная нагрузка может быстро привести к выгоранию.
В агентство чаще всего не на что брать инвестиции. Самая популярная попытка "вложиться" в агентство — потратить бюджет на маркетинг самого агентства в новом рекламном канале.
Можно построить большой отдел продаж, но есть предельное количество клиентов и стеклянный потолок — подробнее в этом посте.
Всё, что создаёт агентство, остаётся у клиента. Поэтому ценный опыт уходит вместе с сотрудниками. Накопление и закрепление опыта требует дополнительных усилий (документирование, обучение).
Агентство (особенно маленькое) сложно продать — персонал и контракты могут быстро уйти на рынок после покупки. Покупатели это понимают.
Эти особенности типичны для рынка и известны на старте — хороший повод продумать стратегию заранее. В следующих постах я расскажу, как обойти многие из этих ограничений.
Для многих специалистов открытие агентства — это естественный путь развития, переход из найма в свой бизнес.
Плюсы для старта:
- Не требует стартового капитала — можно взять первый заказ и выполнить самому.
- Рынок насыщен заказами — многие находят первых клиентов через рекомендации знакомых. "Сарафан" — значимый источник денег для многих малых агентств.
- Легко найти исполнителей на фриланс, в найм, аутсорс, аутстафф или субподряд.
- Доход специалиста быстро начинает превышать доход в найме.
Вот только при всех этих плюсах в бизнес-модели агентств есть существенные ограничения.
Агентство не может кратно увеличить количество обслуживаемых клиентов без расширения штата. Профессиональные услуги масштабируются через "мозги", то есть через очень квалифицированных сотрудников. Чем более квалифицированный персонал нужен для выполнения проектов, тем сложнее будет вырастить агентство.
В случае успеха, вчерашний опытный специалист становится неопытным предпринимателем. А двойная нагрузка может быстро привести к выгоранию.
В агентство чаще всего не на что брать инвестиции. Самая популярная попытка "вложиться" в агентство — потратить бюджет на маркетинг самого агентства в новом рекламном канале.
Можно построить большой отдел продаж, но есть предельное количество клиентов и стеклянный потолок — подробнее в этом посте.
Всё, что создаёт агентство, остаётся у клиента. Поэтому ценный опыт уходит вместе с сотрудниками. Накопление и закрепление опыта требует дополнительных усилий (документирование, обучение).
Агентство (особенно маленькое) сложно продать — персонал и контракты могут быстро уйти на рынок после покупки. Покупатели это понимают.
Эти особенности типичны для рынка и известны на старте — хороший повод продумать стратегию заранее. В следующих постах я расскажу, как обойти многие из этих ограничений.
🔥6👍3❤1
Прибыльное агентство: Отказ от уникальных услуг.
Всё, что создаёт агентство, остаётся у клиента.
Большие деньги делаются на снижении издержек при масштабировании производства. Поэтому агентству выгодно выстраивать повторяемые процессы вместо разовых решений.
Один из способов победить эту проблему — перестать создавать полностью уникальные решения под каждого клиента.
Как превратить услугу во внутренний продукт:
- Берём одну типовую услугу, которую мы точно умеем оказывать и на которую есть спрос.
- Документируем весь процесс оказания.
- Выделяем шаги, которые требуют высокой квалификации.
- В этих шагах заменяем квалифицированного специалиста на полуфабрикаты — заготовки, готовые рецепты, чеклисты, шаблоны. Теперь он делает заготовки, а не уникальные решения.
- Добавляем границы кастомизации. За границы не выходим — это уже другой процесс.
- Обучаем менее квалифицированных сотрудников проходить по шагам весь процесс.
- Добавляем контроль качества — чтобы стандарт не падал при росте объёмов.
- Повторяем с правками и улучшениями до тех пор, пока процесс не будет работать без вмешательства специалиста и руководителя.
Для агентства — это конвейер. Внутри всё одинаковое, снаружи — кажется уникальным. Клиент может думать, что услуга уникальна — брендирование, выбор оформления из нескольких вариантов, пара уникальных страничек.
Очевидные плюсы:
- Увеличенная маржа — высокооплачиваемый специалист привлекается только к созданию конвейера.
- Услугу могут оказывать легко заменяемые сотрудники или начинающие специалисты.
- Просчитываемая экономика с точками масштабирования.
- Ниже риски, так как услуга проще.
- Можно построить бизнес, а не самозанятость.
Особенности:
Скучно. Крутому специалисту, который решил открыть агентство, нужны вызовы и достижения. Он хочет сложные проекты и большие чеки, вместо простых проектов с высокой маржой.
Конвейер интересен предпринимателю или бизнесмену. Чаще его организуют предприниматели без технического бэкграунда, которые сами услуги оказывать не умеют.
Агентство может взять заказ на индивидуальные работы и закрыть сделку с любым клиентом. Конвейер предполагает, что мы будем отказывать клиентам, которым нужны индивидуальные решения.
Я считаю, что лучшее решение — гибрид.
- Работает конвейер: основатель-специалист преодолел себя и построил скучную, но маржинальную услугу.
- Цены не потоковые, а чуть выше рынка.
- В отделе продаж происходит сортировка клиентов. Уникальные и сложные случаи переводятся в проектный отдел — с другими процессами, командой и бюджетом.
Всё, что создаёт агентство, остаётся у клиента.
Большие деньги делаются на снижении издержек при масштабировании производства. Поэтому агентству выгодно выстраивать повторяемые процессы вместо разовых решений.
Один из способов победить эту проблему — перестать создавать полностью уникальные решения под каждого клиента.
Как превратить услугу во внутренний продукт:
- Берём одну типовую услугу, которую мы точно умеем оказывать и на которую есть спрос.
- Документируем весь процесс оказания.
- Выделяем шаги, которые требуют высокой квалификации.
- В этих шагах заменяем квалифицированного специалиста на полуфабрикаты — заготовки, готовые рецепты, чеклисты, шаблоны. Теперь он делает заготовки, а не уникальные решения.
- Добавляем границы кастомизации. За границы не выходим — это уже другой процесс.
- Обучаем менее квалифицированных сотрудников проходить по шагам весь процесс.
- Добавляем контроль качества — чтобы стандарт не падал при росте объёмов.
- Повторяем с правками и улучшениями до тех пор, пока процесс не будет работать без вмешательства специалиста и руководителя.
Для агентства — это конвейер. Внутри всё одинаковое, снаружи — кажется уникальным. Клиент может думать, что услуга уникальна — брендирование, выбор оформления из нескольких вариантов, пара уникальных страничек.
Очевидные плюсы:
- Увеличенная маржа — высокооплачиваемый специалист привлекается только к созданию конвейера.
- Услугу могут оказывать легко заменяемые сотрудники или начинающие специалисты.
- Просчитываемая экономика с точками масштабирования.
- Ниже риски, так как услуга проще.
- Можно построить бизнес, а не самозанятость.
Особенности:
Скучно. Крутому специалисту, который решил открыть агентство, нужны вызовы и достижения. Он хочет сложные проекты и большие чеки, вместо простых проектов с высокой маржой.
Конвейер интересен предпринимателю или бизнесмену. Чаще его организуют предприниматели без технического бэкграунда, которые сами услуги оказывать не умеют.
Агентство может взять заказ на индивидуальные работы и закрыть сделку с любым клиентом. Конвейер предполагает, что мы будем отказывать клиентам, которым нужны индивидуальные решения.
Я считаю, что лучшее решение — гибрид.
- Работает конвейер: основатель-специалист преодолел себя и построил скучную, но маржинальную услугу.
- Цены не потоковые, а чуть выше рынка.
- В отделе продаж происходит сортировка клиентов. Уникальные и сложные случаи переводятся в проектный отдел — с другими процессами, командой и бюджетом.
🔥9🙏3❤1
Как измерять работу программистов.
CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить?
В среде программистов есть много мнений по поводу метрик и нужно ли измерять производительность разработчика.
Очевидные метрики, которые придумает HR:
- Присутствие на рабочем месте.
- Количество выполненных задач.
- Количество часов, затраченных на выполнение этих задач.
- Уложился ли в план.
Неочевидные метрики, которые добавит CTO:
- "Бизнес ценность" — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса.
- "Стори пойнты" — баллы трудоёмкости. Разработчики собираются на "Покер Планирования" и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32).
- Количество багов в коде, написанном разработчиком.
- Скорость — любые баллы делим на время.
- % отклонения от собственной или командной оценки.
Проблема заключается в том, что индивидуальный разработчик может провалить все эти метрики, но при этом положительно влиять на производительность команды. Или же выполнять план, но демотивировать группу.
Рассмотрим роль тимлида в качестве примера: индивидуальная отгрузка ниже среднего, но каждый разработчик под его влиянием работает быстрее и качественнее. Увольнять его на основании общих метрик просто преступно.
Наблюдатель меняет природу света. Программисты под надзором точно работают, без него — состояние неопределённое. Поэтому без внешнего контроля не обойтись.
Что с этим делать?
- Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку.
- Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них.
CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить?
В среде программистов есть много мнений по поводу метрик и нужно ли измерять производительность разработчика.
Очевидные метрики, которые придумает HR:
- Присутствие на рабочем месте.
- Количество выполненных задач.
- Количество часов, затраченных на выполнение этих задач.
- Уложился ли в план.
Неочевидные метрики, которые добавит CTO:
- "Бизнес ценность" — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса.
- "Стори пойнты" — баллы трудоёмкости. Разработчики собираются на "Покер Планирования" и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32).
- Количество багов в коде, написанном разработчиком.
- Скорость — любые баллы делим на время.
- % отклонения от собственной или командной оценки.
Проблема заключается в том, что индивидуальный разработчик может провалить все эти метрики, но при этом положительно влиять на производительность команды. Или же выполнять план, но демотивировать группу.
Рассмотрим роль тимлида в качестве примера: индивидуальная отгрузка ниже среднего, но каждый разработчик под его влиянием работает быстрее и качественнее. Увольнять его на основании общих метрик просто преступно.
Наблюдатель меняет природу света. Программисты под надзором точно работают, без него — состояние неопределённое. Поэтому без внешнего контроля не обойтись.
Что с этим делать?
- Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку.
- Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них.
❤6👍3
Матрица "Винни-Пух" для Отдела продаж.
Понять, как продавать клиенту, можно за 5 минут — если представить его героем «Винни-Пуха». Мы давно применяем эту матрицу в продажах и работе с клиентами. Подсмотрено у Павла Гительмана на курсе по маркетингу.
Итак, к нам пришёл новый клиент.
Определяем его положение в матрице по двум осям — открытый/закрытый и
уверенный/неуверенный.
Результат легко соотносим с персонажами сказки Винни-Пух и все-все-все.
Винни-Пух — Открытый + уверенный в себе.
Чтобы продать что-то Винни, достаточно указать на новую возможность — где-то там за холмом есть дуб с пчёлами. Медведь уже схватил Пятачка, взял ружьё и сам туда пошёл.
Пятачок — Открытый + неуверенный в себе. Чтобы Пятачок что-то купил, ему нужен Винни-Пух и его вера в успех.
Пятак, мы уже ходили за мёдом много раз, тут всё то же самое. Бери меня за руку, бери ружьё, оплачивай счёт и запускаем проект.
Ослик Иа — Закрытый + неуверенный в себе.
А вы точно не мошенники? Покажите сертификаты. Есть ли возврат денег? У вас там неточность в реквизитах. Ослик — самый сложный случай. Под него стоит сделать лендинг, подготовить список частых ответов, но продавать ему тяжелее всего.
Кролик или Сова — Закрытый + уверенный в себе. Этот клиент сам всё знает, он пришёл подготовленным. Расскажите про скидки и команду.
Типаж клиента легко определить — стоит спросить, как он принимает решения и что важно при выборе.
Менеджеры легко описывают клиента друг другу и адаптируют рабочие процессы, стиль общения и акценты коммуникации под его потребности.
Понять, как продавать клиенту, можно за 5 минут — если представить его героем «Винни-Пуха». Мы давно применяем эту матрицу в продажах и работе с клиентами. Подсмотрено у Павла Гительмана на курсе по маркетингу.
Итак, к нам пришёл новый клиент.
Определяем его положение в матрице по двум осям — открытый/закрытый и
уверенный/неуверенный.
Результат легко соотносим с персонажами сказки Винни-Пух и все-все-все.
Винни-Пух — Открытый + уверенный в себе.
Чтобы продать что-то Винни, достаточно указать на новую возможность — где-то там за холмом есть дуб с пчёлами. Медведь уже схватил Пятачка, взял ружьё и сам туда пошёл.
Пятачок — Открытый + неуверенный в себе. Чтобы Пятачок что-то купил, ему нужен Винни-Пух и его вера в успех.
Пятак, мы уже ходили за мёдом много раз, тут всё то же самое. Бери меня за руку, бери ружьё, оплачивай счёт и запускаем проект.
Ослик Иа — Закрытый + неуверенный в себе.
А вы точно не мошенники? Покажите сертификаты. Есть ли возврат денег? У вас там неточность в реквизитах. Ослик — самый сложный случай. Под него стоит сделать лендинг, подготовить список частых ответов, но продавать ему тяжелее всего.
Кролик или Сова — Закрытый + уверенный в себе. Этот клиент сам всё знает, он пришёл подготовленным. Расскажите про скидки и команду.
Типаж клиента легко определить — стоит спросить, как он принимает решения и что важно при выборе.
Менеджеры легко описывают клиента друг другу и адаптируют рабочие процессы, стиль общения и акценты коммуникации под его потребности.
❤14🔥7😁6👍2
Почему Fix Price — это ловушка
По данным PMI, средний большой IT-проект превышает бюджет на 45%, сроки на 7%, а выхлоп даёт на 56% меньше ожидаемого.
В исследовании Harvard Business Review, каждый шестой IT-проект обошёлся более чем на 200% дороже и вышел за сроки более чем на 70%.
Люди плохо оценивают трудозатраты. Не учтены все внешние факторы, слишком оптимистично оценивается время и ресурсы. В процессе работы с проектом приходит более глубокое понимание предметной области и деталей.
Мы интуитивно ожидаем нормальное гауcсово распределение по срокам, но в реальности у нас распределение с тяжёлым хвостом. Это значит, что редкие, но очень долгие проекты — не исключение, а закономерность.
Заказная разработка такая странная отрасль, где многие подрядчики берут на себя риски, которыми не управляют. Студии кажется, что в этот раз точно получится уложиться в бюджет и сроки. И на фиксированной цене очень настаивает клиент.
Чем это заканчивается:
- Клиент недоволен, что сроки не соблюдены. Прогноз всегда ошибочен, но клиенту пообещали эксперты.
- Не попадаем в оценку трудозатрат. Не редки случаи, когда студия уходит в минус просто чтобы довести проект до конца.
- На проекте тлеет, а затем разгорается пожар конфликта. Может дойти до суда.
- Все недовольны и демотивированы.
Проекты по модели Fix Price можно брать, но если есть ряд условий:
- Вы уверены, что в проекте нет рисков.
- В проекте очень мало неопределенности. Например, у вас уже почти всё готово, осталось прилепить логотип заказчика сверху стандартной заготовки.
- У вас наценка от 500% на качественно просчитанную себестомость.
Точная оценка нового проекта — иллюзия. Большой проект с неопределённостью нельзя брать по фиксированной цене. Каждый раз, когда вы берёте большой проект по Fix Price в надежде, что получится заработать, вы играете в рулетку.
По данным PMI, средний большой IT-проект превышает бюджет на 45%, сроки на 7%, а выхлоп даёт на 56% меньше ожидаемого.
В исследовании Harvard Business Review, каждый шестой IT-проект обошёлся более чем на 200% дороже и вышел за сроки более чем на 70%.
Люди плохо оценивают трудозатраты. Не учтены все внешние факторы, слишком оптимистично оценивается время и ресурсы. В процессе работы с проектом приходит более глубокое понимание предметной области и деталей.
Мы интуитивно ожидаем нормальное гауcсово распределение по срокам, но в реальности у нас распределение с тяжёлым хвостом. Это значит, что редкие, но очень долгие проекты — не исключение, а закономерность.
Заказная разработка такая странная отрасль, где многие подрядчики берут на себя риски, которыми не управляют. Студии кажется, что в этот раз точно получится уложиться в бюджет и сроки. И на фиксированной цене очень настаивает клиент.
Чем это заканчивается:
- Клиент недоволен, что сроки не соблюдены. Прогноз всегда ошибочен, но клиенту пообещали эксперты.
- Не попадаем в оценку трудозатрат. Не редки случаи, когда студия уходит в минус просто чтобы довести проект до конца.
- На проекте тлеет, а затем разгорается пожар конфликта. Может дойти до суда.
- Все недовольны и демотивированы.
Проекты по модели Fix Price можно брать, но если есть ряд условий:
- Вы уверены, что в проекте нет рисков.
- В проекте очень мало неопределенности. Например, у вас уже почти всё готово, осталось прилепить логотип заказчика сверху стандартной заготовки.
- У вас наценка от 500% на качественно просчитанную себестомость.
Точная оценка нового проекта — иллюзия. Большой проект с неопределённостью нельзя брать по фиксированной цене. Каждый раз, когда вы берёте большой проект по Fix Price в надежде, что получится заработать, вы играете в рулетку.
👍7❤3🔥2
К недавним воспоминаниям про ZX Spectrum добавились свежие новости и неизвестные факты.
В 1980-х игры и программы можно было получить по радио! Буквально записать FM-эфир на аудиокассету. Такие передачи выходили на BBC и других национальных радиостанциях по всей Европе.
Поскольку версии языка BASIC отличались на ZX, Commodore, Atari и других платформах, был создан универсальный стандарт BASICODE. В этом формате шло вещание. Для воспроизведения таких записей нужно было вначале загрузить BASICODE, а затем записанную программу.
В мае 2024 года игру для ZX Spectrum вновь передали в эфире Словенского радио.
А в октябре 2024 вышел документальный фильм про историю ZX Spectrum "Чудо с резиновыми кнопками", деньги на съемки которого собрали на Кикстартере.
Интересные ссылки:
- BASICODE на Wikipedia
- Новость об эфире с игрой
- Фильм The Rubber-Keyed Wonder (англ.)
- Фильм Чудо с резиновыми кнопками (перевод на русский язык)
В 1980-х игры и программы можно было получить по радио! Буквально записать FM-эфир на аудиокассету. Такие передачи выходили на BBC и других национальных радиостанциях по всей Европе.
Поскольку версии языка BASIC отличались на ZX, Commodore, Atari и других платформах, был создан универсальный стандарт BASICODE. В этом формате шло вещание. Для воспроизведения таких записей нужно было вначале загрузить BASICODE, а затем записанную программу.
В мае 2024 года игру для ZX Spectrum вновь передали в эфире Словенского радио.
А в октябре 2024 вышел документальный фильм про историю ZX Spectrum "Чудо с резиновыми кнопками", деньги на съемки которого собрали на Кикстартере.
Интересные ссылки:
- BASICODE на Wikipedia
- Новость об эфире с игрой
- Фильм The Rubber-Keyed Wonder (англ.)
- Фильм Чудо с резиновыми кнопками (перевод на русский язык)
❤5🔥2
Горшочек с мёдом
Honeypot — в переводе с английского "горшочек с мёдом". Красивое и безобидное название, которое в веб-разработке обозначает хитрую ловушку. Ловим роботов! Ловим в естественной среде обитания — на нашем сайте, на самую обычную форму регистрации, комментария или обратной связи.
Обычный пользователь видит свою обычную форму:
Робот не смотрит глазами на монитор — он читает исходный код. И видит робот ещё одно поле.
Ничего подозрительного, просто ещё одно поле. Нужно заполнить! А это и есть наш горшочек с мёдом.
Настоящий пользователь это поле не увидел — мы его скрыли с помощью CSS. Он отправил форму с пустой фамилией. А старательный робот фамилию заполнил.
Попался!
Мы его игнорируем: заполненная форма уничтожается, письма не отсылаются, аккаунт не регистрируется. Спам не прошёл!
Honeypot — в переводе с английского "горшочек с мёдом". Красивое и безобидное название, которое в веб-разработке обозначает хитрую ловушку. Ловим роботов! Ловим в естественной среде обитания — на нашем сайте, на самую обычную форму регистрации, комментария или обратной связи.
Обычный пользователь видит свою обычную форму:
Имя: ____________Email: ___________Ваш комментарий: ____________________Робот не смотрит глазами на монитор — он читает исходный код. И видит робот ещё одно поле.
Фамилия: __________Ничего подозрительного, просто ещё одно поле. Нужно заполнить! А это и есть наш горшочек с мёдом.
Настоящий пользователь это поле не увидел — мы его скрыли с помощью CSS. Он отправил форму с пустой фамилией. А старательный робот фамилию заполнил.
Попался!
Мы его игнорируем: заполненная форма уничтожается, письма не отсылаются, аккаунт не регистрируется. Спам не прошёл!
👏9❤2🔥1👨💻1
Печеньки в браузере — зачем они и почему нас о них предупреждают?
Начнём с того, что это не простые печенья, а китайские печенья с предсказаниями. Те самые, которые разламываешь и находишь бумажку с посланием. Браузер получает печеньку от сайта, но не читает её — послание для него не имеет смысла, это личные заметки сайта.
Куки пришли в браузеры в конце 90-х ради создания привычной нам корзины в интернет-магазинах. Сайт выдавал номер корзины пользователю. А после загрузки следующей страницы читал куки и находил корзину пользователя.
Печеньку откроет и прочитает не браузер, а сайт, который её выдал. Похоже на карты лояльности, номер которой ничего для покупателя не значит, но он носит её с собой и показывает продавцу.
Сайты не спрашивали пользователя, нужна ли ему печенька. Конечно нужна, зачем спрашивать? Без неё сохранить логин на сайте или корзину было невозможно.
А потом пришли они.... чужие куки от сторонних сайтов.
Сайты начали добавлять к себе чужой код — счетчики посещений, аналитика поведения, показы баннеров. Рекламные сети начали оставлять в браузере пользователя свои куки. И узнавать, что один и тот же пользователь зашёл на сайт с поиском работы, выбором медицинских услуг или ремонтом телефона.
Очень быстро рекламные сети стали знать слишком много. И показывать рекламу о том, о чём вы бы не стали им рассказывать.
Законотворцы узнали про это безобразие и начали выпускать законы 🤦♂️. Теперь мы смотрим на предупреждения, которые обязаны вешать владельцы сайтов, что они используют куки. Даже свои собственные — белые и пушистые — для запоминания вашей корзины. Но даже если предупреждения нет — куки вы, скорее всего, всё равно получите 👿.
Проблема должна решаться технологически на стороне браузера.
Safari, Firefox, Brave и Edge уже частично блокируют куки сторонних сайтов. Chrome блокирует их пока только в режиме инкогнито, ведь больше всего от этой технологии зарабатывает разработчик Chrome — Google 🙈.
Когда браузеры договорятся — предупреждения о кукисах уйдут в историю. А пока — терпим.
Начнём с того, что это не простые печенья, а китайские печенья с предсказаниями. Те самые, которые разламываешь и находишь бумажку с посланием. Браузер получает печеньку от сайта, но не читает её — послание для него не имеет смысла, это личные заметки сайта.
Куки пришли в браузеры в конце 90-х ради создания привычной нам корзины в интернет-магазинах. Сайт выдавал номер корзины пользователю. А после загрузки следующей страницы читал куки и находил корзину пользователя.
Печеньку откроет и прочитает не браузер, а сайт, который её выдал. Похоже на карты лояльности, номер которой ничего для покупателя не значит, но он носит её с собой и показывает продавцу.
Сайты не спрашивали пользователя, нужна ли ему печенька. Конечно нужна, зачем спрашивать? Без неё сохранить логин на сайте или корзину было невозможно.
А потом пришли они.... чужие куки от сторонних сайтов.
Сайты начали добавлять к себе чужой код — счетчики посещений, аналитика поведения, показы баннеров. Рекламные сети начали оставлять в браузере пользователя свои куки. И узнавать, что один и тот же пользователь зашёл на сайт с поиском работы, выбором медицинских услуг или ремонтом телефона.
Очень быстро рекламные сети стали знать слишком много. И показывать рекламу о том, о чём вы бы не стали им рассказывать.
Законотворцы узнали про это безобразие и начали выпускать законы 🤦♂️. Теперь мы смотрим на предупреждения, которые обязаны вешать владельцы сайтов, что они используют куки. Даже свои собственные — белые и пушистые — для запоминания вашей корзины. Но даже если предупреждения нет — куки вы, скорее всего, всё равно получите 👿.
Проблема должна решаться технологически на стороне браузера.
Safari, Firefox, Brave и Edge уже частично блокируют куки сторонних сайтов. Chrome блокирует их пока только в режиме инкогнито, ведь больше всего от этой технологии зарабатывает разработчик Chrome — Google 🙈.
Когда браузеры договорятся — предупреждения о кукисах уйдут в историю. А пока — терпим.
🔥7👍2❤1
Задача про византийских генералов
Представьте, что несколько средневековых армий осаждают город. Чтобы победить, все армии должны одновременно атаковать или оставаться на месте. В противном случае сил не хватит и при частичной атаке армии будут разбиты.
Коммуникация между армиями идёт через гонцов, которых могут перехватить и подменить послания.
Как договориться, если единичным сообщениям нельзя верить?
Решают это избыточными сообщениями — мы должны получить одни и те же команды из нескольких источников, чтобы начать им доверять. Но времени для избыточных сообщений мало.
Это и есть задача, которую решает блокчейн: как договориться, если нельзя доверять каждому сообщению?
Отсюда происходит триллема блокчейна — сложно совместить все три желаемые свойства: децентрализацию (все армии равны, нет главного), масштабируемость (чем больше армий, тем сложнее договориться) и безопасность (решения нельзя подделать).
В реальном мире решается через компромисс:
- Безопасно и децентрализовано — но медленно (Bitcoin, ранний Ethereum до L2).
- Быстро и безопасно — но большая централизация (Solana).
- Быстро и масштабируемо — но легче атаковать систему ложными сообщениями (корпоративные блокчейны, BSC).
Новое поколение блокчейнов (Cosmos, Avalanche, Polkadot, TON) пытаются обойти триллему за счет разных технологических ухищрений и разделения задачи на части. Победителя пока нет — и, возможно, не будет: разные задачи требуют разных компромиссов.
Представьте, что несколько средневековых армий осаждают город. Чтобы победить, все армии должны одновременно атаковать или оставаться на месте. В противном случае сил не хватит и при частичной атаке армии будут разбиты.
Коммуникация между армиями идёт через гонцов, которых могут перехватить и подменить послания.
Как договориться, если единичным сообщениям нельзя верить?
Решают это избыточными сообщениями — мы должны получить одни и те же команды из нескольких источников, чтобы начать им доверять. Но времени для избыточных сообщений мало.
Это и есть задача, которую решает блокчейн: как договориться, если нельзя доверять каждому сообщению?
Отсюда происходит триллема блокчейна — сложно совместить все три желаемые свойства: децентрализацию (все армии равны, нет главного), масштабируемость (чем больше армий, тем сложнее договориться) и безопасность (решения нельзя подделать).
В реальном мире решается через компромисс:
- Безопасно и децентрализовано — но медленно (Bitcoin, ранний Ethereum до L2).
- Быстро и безопасно — но большая централизация (Solana).
- Быстро и масштабируемо — но легче атаковать систему ложными сообщениями (корпоративные блокчейны, BSC).
Новое поколение блокчейнов (Cosmos, Avalanche, Polkadot, TON) пытаются обойти триллему за счет разных технологических ухищрений и разделения задачи на части. Победителя пока нет — и, возможно, не будет: разные задачи требуют разных компромиссов.
❤4👍1🔥1
Если у вас агентство, то на сессии у психотерапевта стоит обратить внимание на один из двух факторов.
1. Потребность в одобрении и внешней оценке. В подростковом возрасте вы не получили от отца поддержку при формировании вашей самооценки — независимой от мнения окружающих.
2. Холодный родитель. Если один из родителей был холодным, вы могли привыкнуть добиваться любви через успехи и работу на износ. Расшибаетесь в лепёшку, чтобы вас заметили и похвалили? Но любовь за успехи не выдают.
Надеюсь, это не ваши случаи на проработку. Возможно, вы сделали агентство по каким-то другим причинам. А получение оценки вашей работы и финансового подтверждения вашей состоятельности от рандомных незнакомых людей вас не раздражает и нужно вашей психике для чего-то ещё.
Но если это ваш случай — с вас пять тыщ.
1. Потребность в одобрении и внешней оценке. В подростковом возрасте вы не получили от отца поддержку при формировании вашей самооценки — независимой от мнения окружающих.
2. Холодный родитель. Если один из родителей был холодным, вы могли привыкнуть добиваться любви через успехи и работу на износ. Расшибаетесь в лепёшку, чтобы вас заметили и похвалили? Но любовь за успехи не выдают.
Надеюсь, это не ваши случаи на проработку. Возможно, вы сделали агентство по каким-то другим причинам. А получение оценки вашей работы и финансового подтверждения вашей состоятельности от рандомных незнакомых людей вас не раздражает и нужно вашей психике для чего-то ещё.
Но если это ваш случай — с вас пять тыщ.
👏10👍3😢1
Клуб для директоров диджитал-агентств
Отраслевой клуб Галера — лучшее, что со мной случилось за последние пару лет в профессиональном плане.
Если так уж случилось, что у вас агентство и (вероятно) есть психологические расстройства из прошлого поста. То лучше всего объединиться с такими же пациентами и вместе проживать этот опыт.
В Галере сейчас больше 600 директоров диджитал агентств разного размера и направлений — маркетологи, разработчики, сммщики, сеошники, дизайнеры и пиарщики. Десятки тематических чатов, обмен лидами, образовательный трек, еженедельные лекции и круглые столы — всё, для обмена опытом и взаимоподдержки от таких же директоров.
В общем, если вы ещё преодолеваете сложности фирмы, оказывающей профессиональные услуги в одиночку, то зря. Все вопросы можно решить, стеклянные потолки перерасти, а грабли обойти.
Запишитесь на экскурсию в клуб и присоединяйтесь к сообществу!
Отраслевой клуб Галера — лучшее, что со мной случилось за последние пару лет в профессиональном плане.
Если так уж случилось, что у вас агентство и (вероятно) есть психологические расстройства из прошлого поста. То лучше всего объединиться с такими же пациентами и вместе проживать этот опыт.
В Галере сейчас больше 600 директоров диджитал агентств разного размера и направлений — маркетологи, разработчики, сммщики, сеошники, дизайнеры и пиарщики. Десятки тематических чатов, обмен лидами, образовательный трек, еженедельные лекции и круглые столы — всё, для обмена опытом и взаимоподдержки от таких же директоров.
В общем, если вы ещё преодолеваете сложности фирмы, оказывающей профессиональные услуги в одиночку, то зря. Все вопросы можно решить, стеклянные потолки перерасти, а грабли обойти.
Запишитесь на экскурсию в клуб и присоединяйтесь к сообществу!
❤10👏6💘2
Internet Relay Chat
В эпоху web 1.0 не было социальных сетей. Сайты смотрели и читали, а основным местом для коммуникации были онлайн-чаты.
Чаты в IRC очень напоминали сегодняшние чаты в Телеграме.
Справа список пользователей. Текстовые сообщения от разных пользователей бегут на экране.
Любители ходили в чаты через сайты, а профессионалы сидели через IRC-клиенты — специальные программы. Зная адрес сервера, можно было подключиться и попасть в любой канал по интересам. Чаты были источником всего. И были "закрытые" серверы и чаты по приглашениям. Специальные боты хранили любые файлы, запросить которые можно было в переписке. Пишешь боту в личку !list — он присылал список файлов, а !get — начинал закачку.
В нулевых из чатов я качал всё то, чего было не достать в обычном вебе. Софт, музыка, видео.
Чтобы скачать альбом в mp3, нужно было провести на телефонной линии на скорости 33.6 kbps целую ночь. Что не помешало мне послушать первый альбом Linkin Park или новый альбом Metallica за месяц до его выхода в магазины.
Шли годы, основным каналом общения стал ICQ и форумы, а про чаты большинство людей позабыло. Одно время чат был синонимом дурного вкуса — завсегдатаи чатов были сродни любителям общаться по смс в телеэфире.
Но вот прошли годы и в 2025 году Телеграм удивительным образом напоминает тот самый IRC из 2000 года. Мы пишем в чаты и задаём цветовые предпочтения в клиенте. Добавились только стикеры — как в MSN, и эмодзи — как в ICQ.
Мы снова вернулись к основам?
В эпоху web 1.0 не было социальных сетей. Сайты смотрели и читали, а основным местом для коммуникации были онлайн-чаты.
Чаты в IRC очень напоминали сегодняшние чаты в Телеграме.
Справа список пользователей. Текстовые сообщения от разных пользователей бегут на экране.
Любители ходили в чаты через сайты, а профессионалы сидели через IRC-клиенты — специальные программы. Зная адрес сервера, можно было подключиться и попасть в любой канал по интересам. Чаты были источником всего. И были "закрытые" серверы и чаты по приглашениям. Специальные боты хранили любые файлы, запросить которые можно было в переписке. Пишешь боту в личку !list — он присылал список файлов, а !get — начинал закачку.
В нулевых из чатов я качал всё то, чего было не достать в обычном вебе. Софт, музыка, видео.
Чтобы скачать альбом в mp3, нужно было провести на телефонной линии на скорости 33.6 kbps целую ночь. Что не помешало мне послушать первый альбом Linkin Park или новый альбом Metallica за месяц до его выхода в магазины.
Шли годы, основным каналом общения стал ICQ и форумы, а про чаты большинство людей позабыло. Одно время чат был синонимом дурного вкуса — завсегдатаи чатов были сродни любителям общаться по смс в телеэфире.
Но вот прошли годы и в 2025 году Телеграм удивительным образом напоминает тот самый IRC из 2000 года. Мы пишем в чаты и задаём цветовые предпочтения в клиенте. Добавились только стикеры — как в MSN, и эмодзи — как в ICQ.
Мы снова вернулись к основам?
❤5⚡1🔥1
Пройти Тест Джоэля
В 2000 году Джоэль Сполски — сооснователь StackOverflow и Trello, написал список из 12 вопросов, известные как Тест Джоэля. Часто ссылаюсь на этот тест, поэтому прокомментирую эти вопросы.
1. Используете систему контроля версий?
Кажется, что git — уже обязательная вещь. Но до сих пор встречаются проекты без системы контроля версий.
Для тех, кто уже использует, вопрос всё ещё актуален, но теперь звучит так: Вы действительно используете систему контроля версий? У вас есть стратегия ветвления, процедура слияния веток, понятные правила для работы с репозиторием?
2. Сборка проекта происходит в один шаг?
Проект должен собираться в 1 команду и она должна быть написана в readme. Если для запуска проекта требуется поставить несколько сервисов, иметь нужную версию компилятора и запущенную базу данных — стоит прописать все эти зависимости в docker-compose и запускать одной командой. После прихода виртуализации оправданий для многошаговой сборки и зависимости от среды больше нет.
3. У вас настроен CI/CD?
В оригинале Джоэль говорит про daily build — оперативная сборка софта каждый день. Сейчас в большинстве команд нет нужды синхронизировать код раз в день, можно делать это автоматически каждый раз, когда код попадает в репозиторий.
Настройте автоматическую сборку и выкатку приложения на тестовый сервер.
4. У вас же есть база багов? Правда?
Громоздкая Джира не единственный вариант. Эксель тоже подойдёт! Если у вас есть общий зафиксированный список проблем, вы можете с ними работать и планировать их устранение.
5. Вы чините баги до написания нового кода?
Технический долг на проектах с горящими сроками не вызывает вопросы. Но когда сроки сгорели, вы же выделяете время на рефакторинг и устранение багов? Команду не просто демотивирует развивать новые фичи в продукте, когда в фундаменте есть проблемы. Это приводит к плохим архитектурным решениям и обрушению новых этажей.
6. У вас есть план работ со сроками?
План, который знают все и который связан с реальностью. Roadmap, этапы или просто дата, в которую надо запуститься.
Работа ведёт себя как газ — занимает всё выделенное время. Ставьте сроки.
7. У вас есть спецификация?
Банально, но без ТЗ результат ХЗ. Сейчас не нужно писать исчерпывающее финальное тех задание — требования поменяются по ходу разработки. Достаточно написать концепцию, сделать прототипы, записать user story и опубликовать. Задачи тоже нужно записать и поставить в трекер.
8. У разработчиков есть тихие рабочие места?
Ваш разработчик всё ещё сидит в опенспейсе? Зря-зря. Скорее всего, он уже обзавёлся наушниками и пытается от вас отвернуться. Помогите ему создать изолированную среду.
9. У разработчиков лучшая техника и инструменты?
Быстрый комп, 2ой монитор, современный софт, быстрые серверы — стоят копейки относительно времени программиста. Планка памяти стоит как час работы разработчика. Ускоряйте их всеми доступными способами, это очень дёшево.
10. У вас есть тестировщики?
Если баги ищут только разработчики — значит, баги находят пользователи.
Менеджеры и программисты проверяют, что код работает. Тестировщики проверяют, ищут где он не работает. У вас должен быть хотя бы 1 тестировщик в команде на нескольких разработчиков.
11. Пишут ли кандидаты код на собеседовании?
Это единственный пункт, с которым я сейчас не полностью согласен в его изначальной формулировке. Изучить код и мышление кандидата на собеседовании получится, а вот показать реальные навыки в стрессовой ситуации собеседования — вряд ли. Мой рецепт — выводить подходящих кандидатов на тестовую неделю и смотреть совместимость без давления в реальной обстановке.
12. Вы делаете usability тесты на добровольцах?
Соберите группу для тестирования. Первые 5 случайных пользователей укажут вам на 95% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.
Если вы фаундер или руководитель и у вас есть ответы "Нет" — их точно стоит обсудить с командой.
В 2000 году Джоэль Сполски — сооснователь StackOverflow и Trello, написал список из 12 вопросов, известные как Тест Джоэля. Часто ссылаюсь на этот тест, поэтому прокомментирую эти вопросы.
1. Используете систему контроля версий?
Кажется, что git — уже обязательная вещь. Но до сих пор встречаются проекты без системы контроля версий.
Для тех, кто уже использует, вопрос всё ещё актуален, но теперь звучит так: Вы действительно используете систему контроля версий? У вас есть стратегия ветвления, процедура слияния веток, понятные правила для работы с репозиторием?
2. Сборка проекта происходит в один шаг?
Проект должен собираться в 1 команду и она должна быть написана в readme. Если для запуска проекта требуется поставить несколько сервисов, иметь нужную версию компилятора и запущенную базу данных — стоит прописать все эти зависимости в docker-compose и запускать одной командой. После прихода виртуализации оправданий для многошаговой сборки и зависимости от среды больше нет.
3. У вас настроен CI/CD?
В оригинале Джоэль говорит про daily build — оперативная сборка софта каждый день. Сейчас в большинстве команд нет нужды синхронизировать код раз в день, можно делать это автоматически каждый раз, когда код попадает в репозиторий.
Настройте автоматическую сборку и выкатку приложения на тестовый сервер.
4. У вас же есть база багов? Правда?
Громоздкая Джира не единственный вариант. Эксель тоже подойдёт! Если у вас есть общий зафиксированный список проблем, вы можете с ними работать и планировать их устранение.
5. Вы чините баги до написания нового кода?
Технический долг на проектах с горящими сроками не вызывает вопросы. Но когда сроки сгорели, вы же выделяете время на рефакторинг и устранение багов? Команду не просто демотивирует развивать новые фичи в продукте, когда в фундаменте есть проблемы. Это приводит к плохим архитектурным решениям и обрушению новых этажей.
6. У вас есть план работ со сроками?
План, который знают все и который связан с реальностью. Roadmap, этапы или просто дата, в которую надо запуститься.
Работа ведёт себя как газ — занимает всё выделенное время. Ставьте сроки.
7. У вас есть спецификация?
Банально, но без ТЗ результат ХЗ. Сейчас не нужно писать исчерпывающее финальное тех задание — требования поменяются по ходу разработки. Достаточно написать концепцию, сделать прототипы, записать user story и опубликовать. Задачи тоже нужно записать и поставить в трекер.
8. У разработчиков есть тихие рабочие места?
Ваш разработчик всё ещё сидит в опенспейсе? Зря-зря. Скорее всего, он уже обзавёлся наушниками и пытается от вас отвернуться. Помогите ему создать изолированную среду.
9. У разработчиков лучшая техника и инструменты?
Быстрый комп, 2ой монитор, современный софт, быстрые серверы — стоят копейки относительно времени программиста. Планка памяти стоит как час работы разработчика. Ускоряйте их всеми доступными способами, это очень дёшево.
10. У вас есть тестировщики?
Если баги ищут только разработчики — значит, баги находят пользователи.
Менеджеры и программисты проверяют, что код работает. Тестировщики проверяют, ищут где он не работает. У вас должен быть хотя бы 1 тестировщик в команде на нескольких разработчиков.
11. Пишут ли кандидаты код на собеседовании?
Это единственный пункт, с которым я сейчас не полностью согласен в его изначальной формулировке. Изучить код и мышление кандидата на собеседовании получится, а вот показать реальные навыки в стрессовой ситуации собеседования — вряд ли. Мой рецепт — выводить подходящих кандидатов на тестовую неделю и смотреть совместимость без давления в реальной обстановке.
12. Вы делаете usability тесты на добровольцах?
Соберите группу для тестирования. Первые 5 случайных пользователей укажут вам на 95% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.
Если вы фаундер или руководитель и у вас есть ответы "Нет" — их точно стоит обсудить с командой.
👍7❤5
QWERTY — чтобы ты медленно печатал.
Почему клавиши на клавиатуре расположены так странно? Это не случайность, а наследие эры печатных машинок! Более того, буквы нарочно раскидали в неудобном порядке, чтобы замедлить набор текста.
Что смещает SHIFT? Он приподнимал литеру — металлическую лапку с буквой — и она била по бумаге заглавной версией символа.
Что блокируют клавиши Lock? Caps Lock на печатной машинке фиксировал механизм в режиме заглавных букв — лапки всегда били верхней частью.
Enter — символ из стрелки вниз, а затем влево — обозначает перевод бумаги на новую строку. Отсюда и странная форма этой кнопки на большинстве клавиатур. Такой кнопки не было — был рычаг возврата каретки: движение вниз и влево, чтобы перевести бумагу на новую строку.
Backspace — возвращал каретку на символ назад. Delete придумали позже — на печатной машинке ничего не удалить. Поэтому её отправили в дополнительный блок клавиш.
Каждое нажатие на клавишу с буквой выдвигало механическую "лапку", на конце которой находилась буква. Лапка била по чернильной ленте, оставляя отпечаток буквы на бумаге, а затем возвращалась на место. Если вы освоили печать на машинке и начали набирать текст достаточно быстро, то некоторые лапки не успевали вернуться на место и цеплялись за лапку, вылетающую из соседней позиции. Так производители печатных машинок догадались разместить часто встречающиеся сочетания букв подальше друг от друга, чтобы механические лапки не застревали.
Как можно догадаться, "пробег" пальцев при наборе текста был искусственно увеличен. Позже придумали альтернативные раскладки, где всё было логично и удобно. Самая популярная из них — раскладка Дворака. В любой операционной системе можно переключить клавиатуру на Dvorak, но купленная серийная клавиатура всё равно будет с qwerty-гравировкой.
За десятилетия все привыкли к QWERTY — и смена раскладки для производителей оказалась слишком рискованной. А мы потеряли скорость набора и обучаем следующие поколения на "плохой" раскладке.
А как быстро и точно вы набираете текст? Проверить можно на сайте https://monkeytype.com/
Присылайте ваши результаты в комментарии!
Почему клавиши на клавиатуре расположены так странно? Это не случайность, а наследие эры печатных машинок! Более того, буквы нарочно раскидали в неудобном порядке, чтобы замедлить набор текста.
Что смещает SHIFT? Он приподнимал литеру — металлическую лапку с буквой — и она била по бумаге заглавной версией символа.
Что блокируют клавиши Lock? Caps Lock на печатной машинке фиксировал механизм в режиме заглавных букв — лапки всегда били верхней частью.
Enter — символ из стрелки вниз, а затем влево — обозначает перевод бумаги на новую строку. Отсюда и странная форма этой кнопки на большинстве клавиатур. Такой кнопки не было — был рычаг возврата каретки: движение вниз и влево, чтобы перевести бумагу на новую строку.
Backspace — возвращал каретку на символ назад. Delete придумали позже — на печатной машинке ничего не удалить. Поэтому её отправили в дополнительный блок клавиш.
Каждое нажатие на клавишу с буквой выдвигало механическую "лапку", на конце которой находилась буква. Лапка била по чернильной ленте, оставляя отпечаток буквы на бумаге, а затем возвращалась на место. Если вы освоили печать на машинке и начали набирать текст достаточно быстро, то некоторые лапки не успевали вернуться на место и цеплялись за лапку, вылетающую из соседней позиции. Так производители печатных машинок догадались разместить часто встречающиеся сочетания букв подальше друг от друга, чтобы механические лапки не застревали.
Как можно догадаться, "пробег" пальцев при наборе текста был искусственно увеличен. Позже придумали альтернативные раскладки, где всё было логично и удобно. Самая популярная из них — раскладка Дворака. В любой операционной системе можно переключить клавиатуру на Dvorak, но купленная серийная клавиатура всё равно будет с qwerty-гравировкой.
За десятилетия все привыкли к QWERTY — и смена раскладки для производителей оказалась слишком рискованной. А мы потеряли скорость набора и обучаем следующие поколения на "плохой" раскладке.
А как быстро и точно вы набираете текст? Проверить можно на сайте https://monkeytype.com/
Присылайте ваши результаты в комментарии!
🔥9❤8🤯1
Почему не нужно нанимать джунов.
Кажется, чтобы сэкономить на разработчиках нужно брать в команду джунов. Кажется — но нет.
- Качество работы не дотягивает.
- Скорость работы не прогнозируемая — джун застревает в любом месте.
- Требуют квалифицированного наставника. А его время дорого, ведь наставник — хороший разработчик.
- За ними приходится исправлять код старшим разработчикам.
- Хотят "айтишную" ЗП и немедленно. Ведь на продаже курса обещали сотни тысяч!
- Воспринимают нашу компанию как ступеньку и быстро уходят.
Джун станет классным разработчиком только через пару лет усиленного труда. Он получит насмотренность и практический опыт решения ребусов. Будет не просто землекопом, который может работать на знакомом участке, а специалистом, способным решать реальные задачи.
Джуна нет смысла брать ради выгоды или "экономии" в небольшой коллектив — он сильно замедлит команду, ухудшит качество и реальной экономии не будет. Вместо выгоды будут убытки и потраченное время.
Зачем и когда можно брать джуна в команду, расскажу в следующем посте.
Кажется, чтобы сэкономить на разработчиках нужно брать в команду джунов. Кажется — но нет.
- Качество работы не дотягивает.
- Скорость работы не прогнозируемая — джун застревает в любом месте.
- Требуют квалифицированного наставника. А его время дорого, ведь наставник — хороший разработчик.
- За ними приходится исправлять код старшим разработчикам.
- Хотят "айтишную" ЗП и немедленно. Ведь на продаже курса обещали сотни тысяч!
- Воспринимают нашу компанию как ступеньку и быстро уходят.
Джун станет классным разработчиком только через пару лет усиленного труда. Он получит насмотренность и практический опыт решения ребусов. Будет не просто землекопом, который может работать на знакомом участке, а специалистом, способным решать реальные задачи.
Джуна нет смысла брать ради выгоды или "экономии" в небольшой коллектив — он сильно замедлит команду, ухудшит качество и реальной экономии не будет. Вместо выгоды будут убытки и потраченное время.
Зачем и когда можно брать джуна в команду, расскажу в следующем посте.
👍9💯3😢1
Почему нужно нанимать джунов
Вы мега корпорация. Рук не хватает настолько, что вы готовы вкладываться в обучение.
Вы ограничены локацией и вам очень нужны разработчики в вашем городе. Удаленка не подходит — например, безопасники требуют личного присутствия.
Компетентным разработчикам не хочется изучать ваш стек и развиваться в нём. Видел такое в больших легаси продуктах.
У вас большое производство и есть значительный объём однотипной работы с низкими требованиями к качеству — справятся джуны после небольшой подготовки.
Вы просто очень хотите обучать. Может быть тогда ваш бизнес — образование?
Мой вывод: большинству компаний и команд джуны не нужны.
А вы нанимаете джунов? Расскажите, зачем и что из этого выходит.
Вы мега корпорация. Рук не хватает настолько, что вы готовы вкладываться в обучение.
Вы ограничены локацией и вам очень нужны разработчики в вашем городе. Удаленка не подходит — например, безопасники требуют личного присутствия.
Компетентным разработчикам не хочется изучать ваш стек и развиваться в нём. Видел такое в больших легаси продуктах.
У вас большое производство и есть значительный объём однотипной работы с низкими требованиями к качеству — справятся джуны после небольшой подготовки.
Вы просто очень хотите обучать. Может быть тогда ваш бизнес — образование?
Мой вывод: большинству компаний и команд джуны не нужны.
А вы нанимаете джунов? Расскажите, зачем и что из этого выходит.
👍3😁2❤1
Куда отгружать излишки работы?
Лучший лайфхак по оптимизации найма в диджитал агентстве — вообще не нанимать сотрудника.
Нанимать нужно, когда сотрудник гарантировано будет загружен под завязку и ещё работа останется. Иначе есть риск, что специалист будет сидеть на скамейке и ждать начала проекта. А зарплату платить ему надо.
Человека взяли и загрузка у него 100%, как полагается. Что делать с тем, что не влезло?
Расскажу про наш личный опыт в агентстве.
Первый вариант — задачи, которые занимают много часов и при этом отчуждаемы от коллективного процесса. Сборка и кластеризация семантических ядер, заполнение в админке карточек товара, верстка под разные стандарты и носители, простая настройка сервера, дизайн лендинга и т.д.
Идём докупать на Kwork и там выбираем из каталога работ нашу специализацию. Нужна верстка — вот выбор типов верстки от разных исполнителей. Исполнитель переживает за рейтинг и должен уложиться в срок. Деньги от платформы он получит только после сдачи заказа. Для агентства куда меньше рисков, чем с пропадающими фрилансерами. Может выходить даже дешевле штатных сотрудников, хотя бы за счет фиксированной цены.
Второй вариант — отгрузить не нарезанные простые работы, а цельный кусок работы в субподряд. Тут лучше всего работают студии с одной услугой. У них более прогнозируемые сроки и весьма вероятно, что уж эта услуга достаточно хорошо проработана. Например, передать лендинг на Тильде "под ключ".
Удобно получается с дизайнерами, потому что на разные проекты нужен разный стиль и подход. Иногда нужно параллельно делать несколько проектов. Один дизайнер в штате не закрывает все эти потребности.
Главное, чтобы на стороне агентства была насмотренность выбрать подходящего дизайнера из каталога или у партнёров.
Менеджерить придётся всех, отдать заказ на сторону и забыть про менеджмент — фантастика. Отданное наружу надо менеджерить с двойным пристрастием и закладывать запас по срокам.
В общем, всё, что не помещается в основной поток, — разумно отдавать на сторону. И только когда поток вырос, думать о найме.
PS: упоминания площадок и продуктов не являются рекламой
Лучший лайфхак по оптимизации найма в диджитал агентстве — вообще не нанимать сотрудника.
Нанимать нужно, когда сотрудник гарантировано будет загружен под завязку и ещё работа останется. Иначе есть риск, что специалист будет сидеть на скамейке и ждать начала проекта. А зарплату платить ему надо.
Человека взяли и загрузка у него 100%, как полагается. Что делать с тем, что не влезло?
Расскажу про наш личный опыт в агентстве.
Первый вариант — задачи, которые занимают много часов и при этом отчуждаемы от коллективного процесса. Сборка и кластеризация семантических ядер, заполнение в админке карточек товара, верстка под разные стандарты и носители, простая настройка сервера, дизайн лендинга и т.д.
Идём докупать на Kwork и там выбираем из каталога работ нашу специализацию. Нужна верстка — вот выбор типов верстки от разных исполнителей. Исполнитель переживает за рейтинг и должен уложиться в срок. Деньги от платформы он получит только после сдачи заказа. Для агентства куда меньше рисков, чем с пропадающими фрилансерами. Может выходить даже дешевле штатных сотрудников, хотя бы за счет фиксированной цены.
Второй вариант — отгрузить не нарезанные простые работы, а цельный кусок работы в субподряд. Тут лучше всего работают студии с одной услугой. У них более прогнозируемые сроки и весьма вероятно, что уж эта услуга достаточно хорошо проработана. Например, передать лендинг на Тильде "под ключ".
Удобно получается с дизайнерами, потому что на разные проекты нужен разный стиль и подход. Иногда нужно параллельно делать несколько проектов. Один дизайнер в штате не закрывает все эти потребности.
Главное, чтобы на стороне агентства была насмотренность выбрать подходящего дизайнера из каталога или у партнёров.
Менеджерить придётся всех, отдать заказ на сторону и забыть про менеджмент — фантастика. Отданное наружу надо менеджерить с двойным пристрастием и закладывать запас по срокам.
В общем, всё, что не помещается в основной поток, — разумно отдавать на сторону. И только когда поток вырос, думать о найме.
PS: упоминания площадок и продуктов не являются рекламой
👍8🔥4👏1👌1