Собственная рефлексия по мотивам [СММ-2024] Вскрытие аналитиков
Всегда, когда сталкиваюсь с ситуацией, которая вызывает вопрос “да как так можно то?”, пытаюсь не научить как надо сходу, а разобрать историю, причины такого поведения.
Так что для разбора про аналитиков обратимся в надсистему, вернее даже в её постепенную эволюцию, пытаясь ответить на вопрос “как мы дошли до жизни такой?”.
Работаю уже множество лет в компании, где и сейчас есть немало тех самых системных аналитиков. Компания занимается заказной разработкой ПО.
Как появились в моих глазах системные ананлитики и почему (в каком смысле) они “системные”?
Появились они на проектах внедрения больших “систем”, типа внедрения (зарубежной) автоматизированной банковской системы в отечественный банк. По сути задача ближе к кастомизации продукта, просто продукт очень крупный и объем кастомизациии очень немаленький. Но этом это большие разработка поверх платформы, где все базовые механизмы технически уже реализованы и остается задавать логику работы системы. Т.е. набор аффордансов сведен к вполне конкретному и конечному списку и для многих задач есть единственный способ её сделать. Притащить туда новую модную библиотеку/новый язык программирования/другой архитектурный стиль не возможно чисто технически. Таким образом, получается системный аналитик = аналитик в рамках какой-то ИТ-системы.
Почему отдельно аналитик, а не разработчик? Да просто людей не хватает, надо хоть кем-то закрывать дыру. В таких проектах было задействовано немало людей в нулевые. “Войти в IT” еще не звучит из каждого сапога, огромной кучи опытных инженеров не стоит на пороге. Зато есть модное слово аутсорс. Ну и помним, что в те времена RUP еще вполне себе жил, может и не был SoTA уже, но книжек навалом.
И вот в такой ситуации экономически выгодно становится иметь “недопрограммистов” (да простят меня аналитики), когда есть большое количество достаточно однотипных задач, по которым тем не менее надо узнать и догориться о несуперважных для системы в целом вещах. Ключевые же берут на себя инженеры/программисты.
А дальше на эту же аутсорсную компанию приходят новые контракты, на создание различных интеграций между системам на базе большой умной платформы для разработки интеграций. Опять получаем тепличные условия - есть платформа с конечным набором качественных строительных блоков, из которых надо клепать много и зачастую однотипных решений. И зачем нам иметь 10 (интровертов) программистов, когда можно половину заменить на (девочек)аналитиков, которые будут за меньшую зарплату ходить узнавать, чего же тут надо сынтегрировать и даже писать какие-то ТЗ. Качество страдает? Да в общем-то сойдет, что-то при внедрении поправим, да и заказчик не горит желанием платить больше. На серьезных программистов всё равно не хватает да и не будут они такими скучными задачами заниматься.
Постепенно добирается компания и до нормальных заказов на разработку ПО, ну и тут по традиции “мы же всегда так работаем” идут рука-об-руку программисты, которые привыкли “дайте нам ТЗ” и аналитики, которые не готовы проектировать “в боевых условиях”.
Несколько таких проектов потянуть кое-как можно, на запасе прочности. Но в какой-то моммент назревает кризис и становится понятно, что дальше так и с такими проектами жить не получается, но наступает 2022 год и других проектов больше не предвидится.
И получается вроде и реформироваться надо, но для этого надо выграть минимум половину людей? Нежизнеспособный вариант.
Пока единственный реалистичный вариант реформрования я вижу в выращивании новой структуры, работающей по другим правилам “рядом” со старой структурой, с предоставлением очень значительной степени свободы, чтобы не скатиться в те же ограничения, которые породили существующую структуру. Постепенно некоторые “достойные”, могут переходить в новую структуру, но явно не все. Только так можно сделать переход относительно плавным. Попытки же плавно менять снизу в итоге упираются в существенные ограничения сверху.