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