С другой стороны, есть профессии, в которых общение не кажется главной составляющей работы. Например, разработчики большую часть времени посвящают написанию кода.
Согласно исследованиям, некоторые из них так погружены в работу с компьютером, что теряют навык эмпатии.
Однако для отличного результата разработчику нужно не писать больше кода, а лучше понимать цели заказчика. Программист
Андрей привык получать декомпозированные задачи и четкие инструкции от проектного менеджера.
Он не пытался погружаться в детали фичи: зачем она нужна, какие цели заказчик хочет «закрыть» с ее помощью? Из-за этого
Андрей работал механически, то есть писал код под отдельные задачи в таск-трекере, не воспринимал трек развития продукта целиком и не понимал, как конкретная фича его должна усилить.
Но часто результат не соответствовал ожиданиям заказчика в полной мере, и
Андрею приходилось по несколько раз переделывать одно и то же. Почему так происходило?
Менеджер мог не так декомпозировать задачу.
Или декомпозировать настолько мелко, что смысл терялся.
Или при декомпозиции терялась часть требований, важных для заказчика. Причин множество. Не так давно
Андрей начал использовать ИИ в написании кода
В конце концов, в гите есть миллионы строк кода по тому, как решить задачи на распространенных языках. А код - это тот же датасет, то есть источник знаний для ИИ. Использование ИИ позволяет
Андрею меньше тратить времени на работу «машинистки».
Теперь у него освободилось время для того, чтобы погружаться в детали проекта и понимать потребности заказчика.
Теперь большая часть рабочего времени Андрея уходит не на кодинг.
Он встречается с заказчиком, чтобы лучше понимать цели и ценность каждой новой функции в приложении.
Он знает, какие метрики должна улучшить фича, как она должна интегрироваться в текущую систему и как будет развиваться в будущем.
Он продумывает логику фичи глубже и внимательнее
…А затем пишет подробный промпт, на основе которого ИИ генерирует практически готовый код.
Андрею останется лишь протестировать и отрефакторить его.
Как результат, заказчик принимает 90% фич с первого раза, ведь они полностью соответствуют требованиям и целям проекта, а остальные принимаются с минорными правками.
Компания заказчика благодаря этому быстрее выводит продукт на рынок и экономит ресурсы. А ИТ-команда получает более высокие оценки по удовлетворенности заказчика и стала более маржинальной - ведь по гарантии почти не работает, то есть не тратит время на переписывание или переработку. Выглядит как котоламповая история?
Но мы в KT.Team уже начали внедрение такого подхода. И опыт показал, что он работает.