– ты здесь не для того, чтобы быть «аналитиком»,
– и не «руководителем проекта»,
– будь инженером.
Слабо я понимала смысл, хотя это одна из самых полезных профессиональных максим в моей жизни.
Меня учили способу мышления, ведь инженер – не обязательно человек, пищуший код. Он соединяет смысл, систему и последствия.
Последние пару лет узкие роли становятся сложно применимы:
🔹Аналитик, который «только пишет требования», слишком далек от решения
🔹Разработчик, который «только пишет код», слишком далек от пользователя
🔹Руководитель проекта, который «только двигает сроки», слишком далек от бизнес архитектуры.
🔹Архитектор, который «только рисует концепцию», слишком далек от реальной жизни системы
Это напомнило мне "пухососы", которые милые и важные, но буквально пару недель в году
Сейчас чтобы делать решения, а не просто закрывать задачи, нужны люди, которые на своём уровне держат целое.
🔹Аналитик становится инженером смысла. Он не просто фиксирует, что «заказчик попросил кнопку». Он понимает, какую боль эта кнопка должна закрыть, какие сценарии за ней стоят, какие данные нужны, какие исключения появятся, где пользователь может ошибиться, а где система начнёт врать.
🔹Разработчик становится архитектором поведения системы. Не в смысле «теперь все архитекторы», а в смысле — каждое техническое решение влияет на будущее: на скорость изменений, наблюдаемость, поддержку, безопасность, стоимость ошибки.
🔹PM или руководитель проекта перестаёт быть человеком, который просто носит задачи между людьми. Он становится инженером фокуса: удерживает гипотезу, приоритет, границы решения и обратную связь от реальности.
🔹Тестировщик перестаёт быть человеком, который «проверяет после всех». Он становится инженером качества: помогает команде заранее увидеть риски, слабые места, неочевидные сценарии и цену дефектов.
🔹Архитектура перестаёт быть отдельной комнатой, куда иногда уходят старшие люди подумать. Она проявляется по ежедневным решениям команды. В том, как мы называем сущности или как режем границы.
Это, конечно, не значит, что все должны уметь всё.
Сильная команда — не толпа универсальных солдат. Это люди с разной глубиной экспертизы, но с общей способностью видеть систему шире своей должностной инструкции.
А сейчас, с появлением и развитием ИИ, когда писать код становится быстрее, дороже становится другое: понять, что именно мы строим, где границы решения, какие сценарии мы забыли, чему можно доверять, как проверить результат и что будет с системой через полгода.
В DORA 2025 от Google Cloud ИИ описан как amplifier: он усиливает не только сильные стороны организации, но и её слабые места. Максимальная отдача появляется не от самого инструмента, а от зрелости процессов, культуры и инженерных практик команды.
С 2018 по 2024 команду можно было строить как конвейер: один понял, второй описал, третий сделал, четвёртый проверил, пятый выкатил, шестой поддерживает.
Сейчас такой конвейер слишком часто ломается на стыках, где живут самые важные решения:
– между пользователем и данными,
– между фичей и архитектурой,
– между скоростью и надёжностью,
– между «мы обещали» и «это вообще возможно поддерживать».
В 2026-27 вопрос при сборе команды звучит так:
какие уровни инженерного мышления у нас закрыты?
Есть ли в команде человек, который:
– понимает пользователя?
– кто понимает систему?
– кто видит данные?
– кто держит качество?
– кто умеет превращать неопределённость в решение?
– кто думает о жизни продукта после релиза?
И ещё важнее: умеют ли эти люди разговаривать друг с другом не как представители функций, а как соавторы одного решения?
⭐️ Наш продукт AI-оценка – взгляд на ИТ-разработку именно с такой позиции. Бесплатный тест по промокоду
JULY26