Инженер будущего
Последние 4 месяца активно работаем над формированием образа специалистов, которые должны работать в компании. Этот вопрос пересекается с производственным процессом, потому что именно он диктует формат команд и роли внутри них.
В этом посте позволю себе немного пофантазировать на тему будущего процесса разработки и места человека в нем.
Думаю, что уже сейчас человек является бутылочным горлышком в производственном цикле.
Представим роботизированную линию в каком-нибудь цеху. В нем есть участки, на которых стоят роботы с производительностью 100 изделий в час, но между участками есть этапы с людьми с производительностью 10 деталей. Общая производительность конвейера - 10 деталей.
Классический конвейер разработки выглядит так же: аналитика -> дизайн -> разработка -> кодревью -> тестирование -> релиз Между каждыми этапами есть много административных временных издержек, а какие-то из этапов могут полностью блокироваться человеком.
Стандартный пример — согласование требований. Аналитик написал ТЗ, ждёт согласования заказчика. Оно асинхронное и даже одна итерация правок может занимать от 1 дня до недели. Это не создавало проблем раньше, так как одно согласованное ТЗ, даже если на него уходила неделя, создавало большой объем работы на следующих этапах. Соответственно общая производительность зависела от производительности «участка» разработки.
Сейчас же скорость создания артефактов в каждом участке, включая разработку, выросла в разы. И узким местом стали согласования, проверки качества и так далее. То есть все, что делает человек между участками производства.
Какой смысл от того, что я могу написать ТЗ за 1 час вместо 6, если для согласования мне все равно придется подождать минимум день? Или какой смысл от быстрого написания кода, если мне нужно ждать кодревью от другого человека (при том, что его еще и завалило сверху бОльшим количеством ревью)?
Текущие инструменты в основном применяют для ускорения участков, но не пайплайна целиком. В такой конфигурации можно получить прирост общей производительности в единицы или в лучшем случае пару десятков процентов, если «был запас». Но кратный прирост не получится.
Это значит, что нужно изменять сам пайплайн. Минимизировать ручное администрирование и контроль, при этом обеспечив те же качество и предсказуемость, что и раньше.
Тогда целевая функция инженера — не просто выдать артефакт, а доработать систему выдачи этих артефактов, чтобы в будущем результат был более стабильный и предсказуемый. Дообучить систему, короче говоря.
Тогда роль «инженера будущего» в постоянном улучшении и ускорении пайплайна. Фактически как сейчас CI/CD, только в качестве шагов — агенты, которые делают те или иные проверки, вносят изменения в создаваемый продукт, а инженер отслеживает, в чем агенты ошибаются и изменяет самих агентов, или добавляет новых, чтобы в будущем система не допускала таких же ошибок.
Тогда разработка — это полностью продукт агентов. А продукт инженера будущего — это система по автономному предсказуемому произведению цифровых продуктов с заданным качеством.
В этом посте были ссылки, но мы их удалили по правилам Сетки
