Как разработчику упаковать консультацию
Продукт разработчика — не «могу написать код». Это техническое решение с понятной границей и артефактом на выходе.
Одна встреча вокруг одного решения. До встречи клиент присылает контекст; после получает зафиксированный следующий ход. Подходит, когда человеку важнее твой взгляд на его конкретную ситуацию, чем универсальная инструкция. На выходе у клиента остаётся письменное резюме решения, приоритеты и следующий шаг.
Три продукта, которые не стыдно показать
Разбор: архитектурный разбор MVP
Когда: нужно выбрать архитектуру до дорогой разработки.
На выходе: архитектурная записка.
Разбор: code review критичного модуля
Когда: код работает, но менять его страшно.
На выходе: отчёт code review.
Разбор: карта роста разработчика
Когда: специалист готовится к техническому росту.
На выходе: план технического развития.
Пять вопросов распаковки
Не «в чём твоя уникальность», а вопросы, после которых можно собрать продукт и провести его.
Подсказка из профессии: нужно выбрать архитектуру до дорогой разработки.
Подсказка из профессии: код работает, но менять его страшно.
Подсказка из профессии: специалист готовится к техническому росту.
Подсказка из профессии: архитектурная записка.
Подсказка из профессии: не обещать безопасность без полноценного аудита.
Как проходит работа
контекст до встречи
разбор и выбор решения
фиксация действий после разговора
Что показать вместо громких обещаний
- стек и тип нагрузки
- роль в архитектурных решениях
- примеры компромиссов, а не только красивого кода
Границы — часть продукта
не обещать безопасность без полноценного аудита. И ещё: не превращать консультацию в скрытую разработку. Отдельно напиши, что не входит в консультацию, и когда нужна другая помощь.
Частые вопросы
Подходит ли консультация для разработчика?
Да, если человеку важнее твой взгляд на его конкретную ситуацию, чем универсальная инструкция. Если для результата нужно несколько циклов внедрения или большая предварительная работа, выбери другой формат или честно расширь объём работы.
Что обещать клиенту?
Не внешний исход, а управляемый результат работы: письменное резюме решения, приоритеты и следующий шаг. Это понятнее и честнее обещания денег, оффера или мгновенной трансформации.
Какие доказательства добавить?
Подойдут факты: стек и тип нагрузки; роль в архитектурных решениях; примеры компромиссов, а не только красивого кода. Не раскрывай закрытые данные и не приписывай себе результат всей команды.
Когда превращать это в курс?
После нескольких живых проведений, когда вопросы и последовательность повторяются. Курс до практики часто фиксирует гипотезу, а не метод.
Собери консультацию из своего опыта
Ответишь на вопросы — увидишь готовый продукт и страницу. Потом поправишь формулировки своими словами.