Заказчики, которые сами пишут себе фичи
За несколько месяцев в один из внутренних продуктов, который я веду, влилось 1292+ коммита от 29 людей. И здесь важно не количество коммитов, а форма графика. Коммиты идут почти каждый рабочий день, без больших провалов, это устоявшийся рабочий ритм. В составе авторов за этот период разработчиков всего 9)). Остальные 20 в жизни не открывали терминал и вряд ли откроют, но это не мешает им доставлять фичи в прод и получать от этого порцию дофамина.
В эти двадцать входят аналитики, менеджеры, люди, которые ведут переговоры с клиентами и готовят КПшки. Сейчас они коммитят в репозиторий не только текст, черновики и спеки, а целые фичи, да блин, целые страницы фичей.
Причины, по которым каждый из них здесь оказался, разные. Чаще всего у каждого есть потребность в конкретном куске функциональности системы и есть интерес сделать это самому, не дожидаясь очереди к разработке.
Раньше человек без бэкграунда не мог сам довести изменение до финала. Не знал команд и ждал, пока это сделает кто-то из разработки. ИИ-агент сдвинул этот барьер входа ближе к проду. Он помогает на каждом этапе, подсказывает команды, объясняет причину конфликта и сам пишет коммит по формату.
Конвейер, где агент доводит изменение до прода, выглядит хорошо-прекрасно, и многие такой флоу уже строят, мы в том числе. Но ревью нельзя перекладывать на агента, а финальный шаг, доставку в прод, должен делать человек, с ответственностью за то, что туда уехало.
В классической парадигме единица планирования это задача со сроком, и роль решает, кто её берёт. Аналитик собирает требования, разработчик пишет код. Теперь единицей часто становится целое направление, доведённое до результата за один подход, и опыт всё меньше решает, сколько работы человек возьмёт. Путь состоит из идеи, которая оформляется чейнджом, что и зачем меняется, и уходит на ревью к разработчику. После апрува агент берёт задачу и ведёт её от кода до проверок, а на выходе сам готовит черновик MR по шаблону. В нём есть разделы "что сделано", "как проверить", "риски и ограничения" и блок для ревьюера. После ревью реализации фича попадает в прод.
Есть и потолок, но не в инструменте, а в голове человека. Четыре параллельных направления в фокусе не удержит даже сильный спец. Мозг не умеет работать параллельно, он умеет только быстро переключаться. Переключиться на другую задачу, пока предыдущая ждёт ревью, вполне ок. Но чем больше треков в активной работе одновременно, тем быстрее в каждом из них падает качество, поэтому держать их стоит не больше двух, а остальные держать в очереди.
Остаётся вопрос, когда это всё успевать ревьюить.
За несколько месяцев в один из внутренних продуктов, который я веду, влилось 1292+ коммита от 29 людей. И здесь важно не количество коммитов, а форма графика. Коммиты идут почти каждый рабочий день, без больших провалов, это устоявшийся рабочий ритм. В составе авторов за этот период разработчиков всего 9)). Остальные 20 в жизни не открывали терминал и вряд ли откроют, но это не мешает им доставлять фичи в прод и получать от этого порцию дофамина.
В эти двадцать входят аналитики, менеджеры, люди, которые ведут переговоры с клиентами и готовят КПшки. Сейчас они коммитят в репозиторий не только текст, черновики и спеки, а целые фичи, да блин, целые страницы фичей.
Причины, по которым каждый из них здесь оказался, разные. Чаще всего у каждого есть потребность в конкретном куске функциональности системы и есть интерес сделать это самому, не дожидаясь очереди к разработке.
Раньше человек без бэкграунда не мог сам довести изменение до финала. Не знал команд и ждал, пока это сделает кто-то из разработки. ИИ-агент сдвинул этот барьер входа ближе к проду. Он помогает на каждом этапе, подсказывает команды, объясняет причину конфликта и сам пишет коммит по формату.
Конвейер, где агент доводит изменение до прода, выглядит хорошо-прекрасно, и многие такой флоу уже строят, мы в том числе. Но ревью нельзя перекладывать на агента, а финальный шаг, доставку в прод, должен делать человек, с ответственностью за то, что туда уехало.
В классической парадигме единица планирования это задача со сроком, и роль решает, кто её берёт. Аналитик собирает требования, разработчик пишет код. Теперь единицей часто становится целое направление, доведённое до результата за один подход, и опыт всё меньше решает, сколько работы человек возьмёт. Путь состоит из идеи, которая оформляется чейнджом, что и зачем меняется, и уходит на ревью к разработчику. После апрува агент берёт задачу и ведёт её от кода до проверок, а на выходе сам готовит черновик MR по шаблону. В нём есть разделы "что сделано", "как проверить", "риски и ограничения" и блок для ревьюера. После ревью реализации фича попадает в прод.
Есть и потолок, но не в инструменте, а в голове человека. Четыре параллельных направления в фокусе не удержит даже сильный спец. Мозг не умеет работать параллельно, он умеет только быстро переключаться. Переключиться на другую задачу, пока предыдущая ждёт ревью, вполне ок. Но чем больше треков в активной работе одновременно, тем быстрее в каждом из них падает качество, поэтому держать их стоит не больше двух, а остальные держать в очереди.
Остаётся вопрос, когда это всё успевать ревьюить.