Post #415

Кроме выступлений, на ЛАФ всегда интересны кулуары (и шашлыки!) В этот раз, например, поговорили с Денисом Бесковым про аналогию между аналитиками и инженерами. Системный аналитик — это какой инженер? В советском классификаторе были инженеры-исследователи, инженеры-проектировщики, инженеры-конструкторы, инженеры-технологи, инженеры по эксплуатации, инженеры по надзору. В западной практике есть ещё инженеры по качеству, инженеры по требованиям и системные инженеры (обычно вне ИТ). Так кто из них аналитик? Во-первых, кажется, системный аналитик до уровня -миддл — не вполне инженер, скорее младший инженер, чертежник, или в американской — drafter/engineering technician. Специалист, который фиксирует и детализирует требования и решения, а не принимает их. Или принимает самые минорные решения, согласуя их со старшим. Когда начинает сам принимать — уже инженер. Но какой? Инженер-конструктор принимает решение по созданию изделия с требуемыми функциями и характеристиками из готовых компонент. Это у нас обычно солюшн-архитектор или разработчик, техлид. То есть это про архитектуру и конструкцию. Инженер-технолог: либо бизнес-аналитик, проектирующий автоматизацию или методику выполнения деятельности, либо специалист по постановке процесса разработки — например, тот же agile-коуч или скрам-мастер, в идеале, должен быть технологом производства ПО. Инженер по качеству, очевидно, QA. Инженер-испытатель — тестировщик. По эксплуатации — SRE. Инженер-исследователь —продуктовый аналитик. Есть ещё инженеры по предмету: по безопасности, по данным, по ML, по эргономике/UX. Остается инженер-проектировщик. Кажется, многие системные аналитики сейчас как раз они: проектируют конкретные решения типовых задач (например, API). Цель понятна, интегрируемые системы в наличии, нужно спроектировать детали внутренних подсистем (конкретные форматы, эндпоинты, аутентификацию и полномочия, кэширование, мониторинг, журналирование, стратегию ретраев и гарантий, надежность и нагрузку). Конструировать тут особо нечего, т.к. решение не уникальное, а типовое. По идее, следующим шагом тут должны быть справочники решений, что мы уже видим как сборники лучших практик. Интересны роли инженеров по требованиям и системных инженеров. Это у нас редкость, а вот на проектах, где требований тысячи — без этого никак. Но столько требований в чисто софтверных проектах не бывает, у нас же agile. Прикольная роль "системный инженер", который видит систему в целом и во времени, на протяжении всего её жизненного цикла. Фактически, топовые аналитики этим занимаются, иногда это смесь аналитика и архитектора по набору скиллов и видов деятельности. Вот такая попытка классификации, что думаете? Ценно в ней то, что разных по контексту и содержанию деятельности инженеров нужно и учить разному, а у нас многие курсы дают смесь знаний, без четкого алгоритма применения (хотя бы даже улавливания различий между проектированием, конструированием и системной инженерией). И люди, попадая потом на производство, не понимают, чем занимаются, и что релевантно в этой работе.