или «чем дальше в лес – тем толще партизаны»

Некогда, при подготовке лекций по предмету «Технологии разработки программного обеспечения», путём сведения воедино документации по RUP, MSSF, SWEBOK и бесценного личного опыта за 15 лет, я получил список из, если не ошибаюсь, 24 (двадцати четырёх) ролей в проекте по разработке программного обеспечения. Все они были понятны по набору компетенций, уровню квалификации, совмещаемости между собой в одном человеке, иерархии продвижения и, в общем, даже по специальностям, откуда таких выпускают, и текущему уровню зарплат. Вышедшие позже стандарты АП КИТ (известные в определённых кругах, как Оранжевая Книга), в принципе, всю эту конструкцию подкрепляли. Я даже удивлялся, что люди, составлявшие эту книгу, вслух не требовали немедленного повсеместного двухуровневого образования на всех IT-шных специальностях, как жизненно необходимого для функционирования данной отрасли – но речь сейчас не об этом.

А речь о том, что на двадцать третьем году работы в отрасли я вдруг обнаружил трещину в данной стройной конструкции. Точнее, трещина была заметна и ранее, но если раньше её можно было попытаться списать на «некомпетентность лиц, принимающих решения», то сейчас она, похоже, стала приобретать системный характер.

Речь идёт о том, что разработка под некоторыми распространёнными платформами с открытым кодом требует набора каких-то совершенно особых компетенций, и образует какую-то абсолютно свою профессиональную траекторию. Термин «платформа» я применяю здесь в широком смысле: к неким многофункциональным программным системам, разработка – или доработка – пользовательской функциональности к которым предполагает написание некоторых вспомогательных фрагментов, запускаемых полностью в контексте базовой системы. То есть, примеры таких платформ – Liferay, Pentaho, Bitrix, различные традиционные CMS, и тому подобные вещи. Общее свойство подобных платформ – в принципиальной недокументируемости. То есть, предполагается, что на то платформа и имеет открытый код, чтобы описать в документации только какие-то базовые интерфейсы, а в остальном разработчик должен сам разобраться, глядя в код. Не знаю, чем это вызвано, но документация к подобным «платформам», чаще всего, содержит огромное количество ошибок – но речь, опять же, не об этом. Кроме того, работа с подобными платформами всегда требует настройки взаимодействия ещё нескольких программных средств, как правило, очень чувствительного к версии каждого из компонентов.

И вот теперь – вопрос: кто он, тот человек, который должен заниматься такой разработкой?
Программист? Нет! Хотя бы потому, что в учебнике для первого класса по управлению софтверными проектами написано, что деятельность программиста должна быть отделена от деятельности системного администратора. Кроме того, если мы за такую работу, предполагающую максимум 40% деятельности в рамках его основных профессиональных компетенций, посадим человека с подготовкой программиста, то он либо деградирует, как программист, либо сбежит с такой работы, поскольку будет считать её грязной. И, что характерно, возразить ему будет нечего.

Системный администратор? Тоже нет, хотя бОльшую часть времени он занимается деятельностью, более свойственной системному администратору, чем программисту. Но системный администратор не ориентирован на разработку, у него другое профессиональное устройство компетенции.

А тогда кто? Не тестер же, в конце концов? Хотя, некоторая доля истины в том, чтобы считать такого специалиста продвинутым тестером тоже может быть.

Ещё бОльшие вопросы возникают с профессиональной траекторией такого разработчика. Во-первых, где его взять? Понятно, что таких людей никто не готовит – несмотря на то, что подготовить его достаточно просто. Но тут невозможно даже корректно подать объявление о том, что требуется человек на такую работу, поскольку непонятно, как его назвать «в общем». А искать, например, человека с опытом написания чего-то под Liferay – не то, чтобы безнадёжно, но узких специалистов действительно мало, а объяснить в объявлении «или что-нибудь похожее» - это уже, практически, бессмысленно.

Во-вторых, подобные «платформы» - слишком экзотические и короткоживущие системы (несмотря на относительную распространённость некоторых из них), чтобы человек хотел становиться по ним «узким» специалистом. То есть, работая в подобной роли, человек может набрать сколь угодно высокую, но крайне специфическую квалификацию, которая ему никогда не пригодится в дальнейшем.

Наконец, в-третьих, есть большие проблемы с тем, куда может расти подобный специалист – поскольку данная роль, несомненно, является «низовой». Подготовка программиста предполагает какие-то навыки проектирования систем. Эти навыки, если и требуются минимально на нижних должностных уровнях, но, по крайней мере, им не противопоказаны, и должны пригождаться в дальнейшем. Но при работе в роли, о которой идёт речь, любые навыки проектирования, наоборот, вредны. То есть, программист может вырасти в аналитика, тим-лида, системного архитектора. А вот в кого может вырасти специалист, о котором идёт речь, – ну, кроме такого же непонятного ведущего специалиста, – лично мне столь же непонятно, как и то, как назвать такую роль в проекте. Кроме того, непонятно, как оценивать рост такого специалиста, если называется он программистом, а характер деятельности его предполагает деградацию программистской компетенции.

Парадокс ситуации в том, что таких людей требуется всё больше и больше, а непонятно даже то, как отправить в мир запрос о том, что нужен человек на такую работу. Публикация объявления в виде «Требуется программист» уже настолько является надувательством, что через пару месяцев становится неудобно смотреть человеку в глаза: обещали же работу программиста! За что меня в это говно? А если сформулировать «специалист по допиливанию платформы» или «специалист по интеграции открытых программных систем» - так ведь никто не поймёт. И никто не придёт – несмотря на то, что для нормальной работы особо высокой квалификации не требуется, да и ответственность, в общем, минимальна.

Вот как решать проблему? Где искать недостающий термин? Какие рисовать перспективы молодым сотрудникам?

Не может же быть, чтобы эти проблемы были только у меня? Может, подскажет кто-нибудь что-нибудь?

31 января 2013 года

Пока нет комментариев