Глава 4. Первый шаг к команде: разделить профессии

Сейчас ответ кажется почти очевидным: разработчик должен разрабатывать, тестировщик — тестировать, диагност — искать причину проблемы, а кто-то ещё должен смотреть на проект целиком и решать, что вообще делать дальше.

Команда начинается не с количества участников, а с разделения ролей, ответственности и полномочий

Но мы пришли к этому не за один вечер (заметили, как я написал "мы", а не "я"?).

Не было такого, что после факапа Спина 5 я сел, нарисовал красивую оргструктуру, открыл пять новых чатов и с понедельника у меня заработал полноценный виртуальный отдел разработки. Наоборот, разделение происходило постепенно и довольно утилитарно: очередная проблема показывала, какие функции опасно оставлять в одних руках, и под неё появлялась новая граница ответственности.

Первой стала сама идея отделить поиск причины от исправления.

Это важнее, чем может показаться. Когда что-то ломается, очень велик соблазн сразу спросить: «Как это починить?» Но между «система ведёт себя неправильно» и «нужно изменить вот эту функцию» лежит довольно большой кусок работы. Надо сначала установить, что именно произошло, посмотреть фактический код, состояние базы, журналы, иногда содержимое реального письма, проверить одну гипотезу, отбросить другую, и только потом решать, нужно ли вообще менять код.

Так постепенно появился отдельный диагностический контур. Его задача была не написать очередной патч, а ответить на вопрос: что мы на самом деле знаем? Иногда результатом нескольких часов диагностики становилось: да, дефект найден, вот конкретное место, где он возникает, вот факты, которыми это подтверждается. А иногда — наоборот: код работает правильно, проблема находится в другом месте и выпускать новый релиз вообще не надо. Для проекта, который уже работает в реальной эксплуатации, второй ответ бывает не менее ценным, чем первый.

Следом стала отделяться разработка.

И здесь довольно быстро выяснилось, что само слово «разработчик» ещё ничего не решает. Можно открыть новый чат, написать сверху «Ты программист» — и через несколько сообщений он всё равно начнёт советовать, как перестроить архитектуру, какие ещё функции стоит улучшить заодно, какие проверки достаточно считать успешными и что неплохо бы поменять в соседнем модуле.

ИИ вообще очень любит быть полезным, если видит проблему рядом — хочет исправить и её. Если знает способ сделать «красивее» — предлагает. Если задача сформулирована не до конца — достраивает недостающую часть сам. Для разовой работы это часто плюс, а вот для живого проекта часто беда.

Поэтому настоящим открытием для меня стало даже не разделение обязанностей, а разделение полномочий. Разработчик получил не только инструкцию, что он должен делать, но и длинный список того, чего он делать не имеет права: не расширять задачу самостоятельно, не менять бизнес-логику, не заниматься рефакторингом «заодно», не чинить соседний дефект только потому, что заметил его по дороге.

Это уже было очень похоже не на работу с ChatGPT, а на работу с нормальным специалистом в нормальной компании. Причём с хорошим специалистом. Хороший разработчик ведь не тот, кто молча выполняет любую глупость из технического задания. Он должен заметить противоречие, предупредить о риске, предложить решение. Но последнее слово по изменению задачи принадлежит не ему.

Третьим появился независимый тестировщик.

Казалось бы, зачем? Разработчик и так проверяет собственный код. Более того, он знает его лучше всех и способен придумать технические проверки, которые я сам никогда бы не придумал. Так и есть, разработчик обязан проверять свою работу, но это не то же самое, что принять её. У автора решения есть одна неизбежная слабость: он знает, как всё должно работать. Он помнит архитектуру, знает, где поставил защиту, какие данные ожидает функция, почему выбрал именно такой алгоритм. И совершенно естественно строит проверку вокруг этой картины.

Поэтому тестировщику я стал давать другую задачу. Не «посмотри, правильно ли разработчик написал функцию», а примерно: вот что система должна была сделать с точки зрения пользователя и бизнеса; вот установленный релиз; докажи, что произошло именно это.

И здесь стало происходить кое-что интересное. Один ChatGPT вполне способен спорить сам с собой, проверять собственные выводы и даже специально искать контраргументы. Я именно так и пытался работать раньше. Но два разных чата с разными задачами и разными запретами ведут себя иначе:

Разработчик смотрит на систему вопросом: «Как реализовать это требование?»

Диагност: «Что фактически произошло и почему?»

Тестировщик: «Соответствует ли результат тому, что было заказано?»

Вопросы похожи, ответственность совершенно разная.

Позднее появились отдельные разработчик и тестировщик для браузерной части системы, потому что работа с интерфейсом amoCRM, JavaScript и поведением страницы оказалась отдельной профессией со своими проблемами. Для каких-то больших функциональных направлений создавались собственные ветки. Одни чаты заканчивали работу и передавали состояние следующим. Так проект постепенно перестал быть одним длинным разговором с ChatGPT и начал становиться командой. И именно здесь меня ждало ещё одно открытие.

Создать несколько специалистов оказалось значительно проще, чем заставить их работать как одну систему.

Пока был один универсальный чат, у него хотя бы не возникало вопроса, кто принимает окончательное решение: я написал ему — он ответил — я что-то сделал. Теперь диагност мог доказать одну причину, разработчик предложить несколько вариантов исправления, тестировщик заблокировать готовый релиз, а рядом появлялась ещё одна проблема, которая тоже казалась срочной. У каждого была своя правда в границах его задачи.

И чем лучше я разделял роли, тем острее становился новый вопрос: а кто теперь должен видеть всю картину целиком и решать, что из всего этого команда делает дальше?