Все самое лучшее всегда должно быть простым и понятным. Это применимо ко всему. Если взять пример внедрение аналитических решений, взаимодействия с другими командами, то я ничего лучше не видел, чем framework DACI. Матрица DACI (да́си) — это таблица, в которой описывают роли членов команды на всех этапах проекта. Каждый участник может узнать, за что сейчас отвечает и что должен сделать. Всего существуют четыре роли: • Driver (организатор) — отвечает за процесс и результат. • Approver (заказчик) — принимает и оценивает итоги работы. • Contributor (исполнитель) — работает руками или консультирует. • Informed (информированный) — находится в курсе процесса. Для меня это простой инструмент экономии моего (и команды) времени. Нет смысла сидеть на встречах и слушать мнения некомпетентных коллег, особенно там, где у меня есть опыт. Один из недавних примеров - организация хочет строить аналитическое решение в AWS. У них сейчас on-premise SQL Server, SSIS, SSRS, и они уже месяцев 8 двигаются в эту сторону. Даже создали кластер Redshift, за который платят по $1000 в месяц, но только ничего на нём не сделали. Оно и понятно, ведь организация почти государственного масштаба, даже есть профсоюз, поэтому они не боятся увольнения, и AI им тоже не к чему. Что может быть проще, чем сделать хранилище на AWS и Redshift? Поэтому, чтобы ускорить процесс, мы создаём в Confluence Decision Log и список горячих вопросов. Для каждого вопроса у нас создаётся документ DACI, в моём случае список документов: 1. Количество AWS акаунтов - один общий для Dev/Prod или несколько, для каждой среды. Очевидно, чем больше акаунтов, тем дороже в линейной зависимости. 2. Каким образом мы накатываем изменения в AWS аккаунт? CloudFormation, Terraform, CDK - нужно выбрать один способ, и мне вообще всё равно, я больше сам код не пишу для инфраструктуры, хоть на Rust. Но важно, чтобы репозиторий был вне периметра IT, чтобы у нас были все козырные права. 3. Framework для трансформации данных - dbt, Glue, stored procedures. Они уже вовсю гоняют Glue Spark, чтобы данные внутри Redshift трансформировать. Про dbt не слышали. Хотя специально для таких консервативных пользователей лучше, чем dbt, нет. 4. Orchestration инструмент - AWS Batch, AWS Step Functions, on-premise Airflow (уже есть), Airflow on ECS, Managed Airflow. Так как я уже два раза внедрял Managed Airflow и остался очень доволен, то мой выбор очевиден. Но IT хотели бы свой Airflow on-premise. 5. Среда разработки - виртуальная рабочая станция (для работы с on-premise) или сам ноутбук. Даже без админского доступа я уже всё себе смог настроить через Python, VSCode. Но хотелось бы, чтобы они немного поменяли mindset и жили в современном мире. Написать эти 5 документов у меня заняло где-то час. И то пришлось копировать руками из Markdown в Confluence, потому что я не смог поставить Confluence MCP, так как нет прав на установку npm. А через Python не получилось. Без AI я мог бы писать по одному документу в день. А если взять их pace time, то можно писать один документ в неделю. В данном контексте AI лишь помог расширить мою мысль про правильное решение и подтянул дополнительные факты. Вообще через такие документы можно манипулировать мнением других. Дальше все желающие оставят комментарии, мы на них ответим, и, как говорится, полный газ. Менеджера я тоже очень воодушевил, рассказал ему, что он Leader (с большой буквы) и его задача убирать road blockers для команды и всех делать счастливыми (типа иди договаривайся с IT, как все доступы получить). У них ещё команда не обычная: главный ETL-разработчик уже не один десяток лет работает с ними, и, к сожалению, он практически ослеп на старость лет, но он всё ещё главный ETL-разработчик и делает мне демо, как у них там всё работает. А вы тут говорите, у вас времени нет учить AI и зарабатывать 😊