Виктор Козлов01Начинаю с видения продукта и первого сценария
До подключения разработчика мне нужно сформулировать, для кого продукт, какую задачу он решает и как должен выглядеть результат. Видение задаёт направление, а этапы переводят его в работу. Иначе можно быстро выдать доступы и всё равно потратить следующие дни на выяснение, что именно делать первым. На старте я хочу получить общий ответ на этот вопрос.
В сервисе визуального контента первый маршрут строю вокруг результата для клиента: передать исходные материалы, описать задачу, получить изображение и оценить, подходит ли оно для коммерческого использования. Из этого выбираем ближайший участок разработки. Фотографии, видео, редактор и разные модели генерации раскладываем по этапам, чтобы весь список возможностей не превратился в одну огромную первую версию.
В CRM отправная точка другая: запрос клиента должен стать карточкой, получить ответственного и следующий шаг. Дальше к нему можно присоединять историю коммуникации, задачи и результат работы менеджера. Продукты разные, но принцип одинаковый: описать путь пользователя, выбрать первый проверяемый результат и зафиксировать, что пока откладываем. С этим разработчик уже может принимать конкретные технические решения.
02Онбординг разработчика: контекст в Git и материалы в HQHub
При подключении разработчика я хочу передать ему логику продукта вместе с доступом к коду. Для этого нужны короткая вводная, текущие решения, ограничения и ссылки на материалы. Общий контекст я храню в Git: стартовый файл помогает выбрать проект, карточка проекта объясняет его назначение и где искать продолжение. Git сохраняет историю изменений.
В HQHub собираю точку входа: описание продукта, документы, исследования и разборы встреч. У каждого продукта свой проектный раздел. Для сервиса контента там нужны вводные о результате генерации и пользовательском сценарии; для CRM — логика работы с запросом и передачи между участниками. Разработчик получает материалы своей задачи и понимает, где искать продолжение.
Практический смысл проявляется при следующей задаче. Вместо повторного рассказа «что мы вообще строим» можно дать ссылку на сценарий и конкретное изменение. Если договорённость поменялась, обновляем её источник. И человек, и AI-сессия получают актуальные вводные. Сам факт наличия документа недостаточен: из него должно быть понятно, с чего продолжить работу.
03На старте собираю один и тот же рабочий комплект
Процесс у меня унифицирован: карточка продукта, проектный хаб, репозиторий, рабочая среда, доска задач и канал обсуждения. Этот комплект не приходится каждый раз придумывать заново. Для двух продуктов меняются сценарии, материалы и код, а способ подключения человека и передачи работы остаётся знакомым. Поэтому запуск не упирается в новую организационную схему.
В Pult связываю продуктовые решения, разработку и ближайшую проверку с пользователем. В сервисе контента это может быть проверка результата на исходных материалах клиента. В CRM — прохождение запроса от создания карточки до назначенного следующего действия. Так понятно, какая техническая задача нужна для проверки и что ещё зависит от меня: пример данных, решение по сценарию или обратная связь.
На мне остаются видение, приоритеты и приёмка со стороны пользователя. Разработчик отвечает за техническую реализацию в своей среде. Если подключается партнёр или ещё один участник команды, я показываю его участок в том же процессе: какие вводные он получает, что должен подготовить и кому передать результат. Роли связываются через работу, а не через бесконечные вводные встречи.
04Задачу ставлю через действие пользователя и критерий готовности
Фраза «сделать загрузку» оставляет слишком много решений между строк. Я стараюсь описать задачу через действие и результат. Например, для такого продукта задача может звучать так: пользователь добавляет исходный файл, видит, что загрузка завершилась, и может перейти к следующему шагу. Если формат не подходит, он получает понятное сообщение и возможность исправить вводные.
Для CRM аналогичная постановка: менеджер создаёт запрос, назначает ответственного и сохраняет следующее действие; после повторного открытия карточки данные остаются на месте. Это примеры формата задач: действие, ожидаемое поведение и проверка. В Pult добавляю исходные материалы и исполнителя. По такой карточке можно принять результат, не споря о том, что подразумевалось под «готово».
Сложную работу делю на части, у каждой из которых есть проверяемый выход. Сначала можно проверить передачу данных, затем обработку, затем отображение результата. Если задача застряла, фиксируем, какой информации или решения не хватает. Следующий шаг становится конкретным: уточнить сценарий, предоставить пример или поправить реализацию.
05AI превращает обсуждение в рабочие материалы
У меня AI включён прежде всего в переходы между этапами. Из записи рабочего разговора получаю расшифровку, затем выделяю решения, вопросы и поручения. По этому материалу можно обновить вводную, подготовить описание сценария и собрать задачи. Иначе хороший разговор рискует остаться только разговором, а разработчик продолжит работать по старой версии вводных.
Здесь важна проверка смысла. Если на встрече обсуждали вариант интерфейса, AI не должен записать его как окончательное решение. Если договорились исследовать интеграцию, это ещё не обещание её выпустить. Я смотрю, какие формулировки действительно можно передавать в работу и где нужно оставить вопрос открытым.
Для кода использую Codex: передаю контекст проекта, сценарий и ограничения, получаю изменения и проверяю результат. В одном продукте это может быть участок работы с исходным изображением, в другом — логика карточки клиента. Разработчик сохраняет техническую ответственность за свою часть. Подготовленный контекст помогает и ему, и AI продолжать работу без повторного восстановления всех вводных.
06Даю разработчику самостоятельность в пределах продукта
Если каждый обычный релиз требует моего отдельного разрешения, я сам становлюсь очередью. Поэтому заранее договариваемся, какие изменения разработчик выпускает самостоятельно, а какие требуют моего решения. В выделенном контуре продукта технический партнёр может вести разработку и выпуск без согласования каждого релиза. Этот порядок закладываю в процесс подключения, чтобы дальше он не зависел от моей доступности в чате.
Для этого есть отдельный репозиторий и изолированная среда на Pult. Доступ к продукту не означает доступ к соседним сервисам, их базам или секретам. Новые расходы и изменения общей инфраструктуры остаются отдельными решениями. Разработчик получает рабочие полномочия там, где отвечает за результат, и понимает, где требуется обсуждение.
Такой доступ проверяется действием: можно ли получить код, внести изменение и выпустить версию в своём контуре. Отправленное приглашение само по себе онбординг не завершает. Если дальнейшая работа останавливается на правах или непонятном порядке выпуска, нужно исправить процесс подключения, иначе эта задержка будет повторяться на каждой задаче.
07Принимаю задачу по работающему сценарию
Готовый код, слитое изменение и доступная пользователю версия — разные состояния. При приёмке мне нужен адрес нужной версии и понятный маршрут проверки. Я прохожу действие пользователя, смотрю результат и сверяю его с задачей. Для интерфейса проверяю также телефон: экран, удобный на большом мониторе, может мешать пройти тот же путь на мобильном.
Если обнаружилась проблема, возвращаю её разработчику с воспроизводимым описанием: какое действие выполнил, что ожидал и что произошло. «Что-то не работает» заставляет сначала повторить всё исследование. Конкретный сценарий помогает сразу перейти к причине и повторной проверке после исправления.
После выпуска важно проверить именно опубликованную версию. Локально всё может работать, а по рабочему адресу остаться предыдущий вариант. Поэтому завершение задачи для меня включает доставку результата получателю. В карточке должны остаться ссылка и сведения, по которым понятно, что проверено и какое ограничение ещё существует.
08За пару часов подключаю человека и запускаю работу
Когда видение сформулировано и рабочий комплект подготовлен, за пару часов можно пройти весь старт: обсудить первый сценарий, открыть карточку проекта и материалы, проверить доступ к коду и среде, выбрать первую задачу и договориться о приёмке. На выходе разработчик понимает, что строим, в какой последовательности и какой результат показывает первым. Он уже может работать самостоятельно.
Эти пару часов относятся к онбордингу и началу разработки. Выпуск продукта дальше идёт по этапам: первый рабочий сценарий, проверка, исправления и следующий участок. Для сервиса визуального контента и CRM последовательность наполнена разными задачами, но проходит через одинаковые точки: решение, постановка, реализация, приёмка и обратная связь. В каждой понятно, кто отвечает за продолжение.
Партнёра подключаю по той же логике, с материалами под его роль. Ему нужны предложение, вводные для клиента и порядок передачи запроса. После первой задачи поправляем обнаруженные пробелы в документах и доступах. Следующий участник получает более точную вводную, а процесс остаётся тем же.
Главное здесь — моё видение продукта и этапность. Git удерживает решения, HQHub даёт доступ к материалам, Pult связывает исполнителей и задачи, Telegram помогает обсуждать, AI ускоряет подготовку и реализацию. Когда направление и ближайший результат понятны, этим набором можно быстро запускать работу над разными продуктами.