Дисклеймер: Данный пост может создать впечатление, что автор плохо относится к возрастным специалистам и пожилым людям вообще. Это впечатление обманчивое – адекватный возрастной специалист - это бесценный источник знаний и жизненного опыта. В своей трудовой деятельности автор старается дать подчиненным спокойно доработать до пенсии, определив им функционал и размер оплаты труда в соответствии с их компетенциями.
Критика же молодых специалистов и современной системы образования основана на личном опыте – автор активно работает со студентами и его печалит серьезное снижение уровня квалификации молодых специалистов.
Упоминание различных богов и конфессий оправдано литературным стилем, как и большинство людей с техническим складом ума - автор атеист.
В статье изложены заблуждения автора, основанные на его субъективном специфичном опыте, не претендующем на статистическую релевантность.
В последнее время меня часто привлекают в роли консультанта по цифровой трансформации бизнеса – руководство организаций приходит к осознанию того, что конкурентная среда диктует необходимость развития в области информационных технологий. Всем хочется не отставать от современных тенденций и создать IT ландшафт, соответствующий текущим стандартам, но на практике этот процесс сопровождается значительными трудностями и расходами. И хорошо если руководство это осознает – в моей практике были случаи, когда руководитель организации издавал приказ перевести весь парк (около 500 рабочих мест) на Astra Linux к началу следующего месяца, другой планировал внедрить ERP на крупном заводе за два месяца. Меня зачастую приглашают CIO организаций для обоснования руководству сроков и стоимости подобных проектов, так как руководитель не хочет слышать «отговорки» своих сотрудников и требуется квалифицированное мнение эксперта. Да – цифровая трансформация бизнеса дело не быстрое и дорогое, связано это не только с качеством подготовки персонала и устареванием используемого парка техники, но и с legacy ПО, используемом в организациях. По моему скромному мнению, для данного термина слово «наследие» надо было переводить не на английский, а на немецкий – слово ahnenerbe значительно лучше отражает весь тот кошмар современного программиста, который кроется в поделках его древних коллег. Давайте рассмотрим феномен legacy ПО подробнее…
Давным-давно, на заре компьютерной эры, заводы и крупные организации создавали IT (АСУ) отделы с огромным штатом разработчиков. Эти доблестные программисты самостоятельно автоматизировали специфическую деятельность своей организации в меру своих возможностей и способностей. Связано это было с тем, что в те времена не существовало то изобилие вендоров и готовых программных решений, которое присутствует сейчас, а формализовывать бизнес-процессы конкретных организаций и подгонять их под существующие программные пакеты было не целесообразно. Разработка в те времена велась системно, в современной терминологии предоставляя собой классическую методологию Waterfall. Древние артефакты тех времен можно и по сей день обнаружить в недрах IT подразделений – перфокарты и ТЗ, набранные на печатной машинке, вызывают ностальгию и умиление.
Чего умиления не вызывает – так это наследие той эпохи:
- Отсутствующая документация по проектам. В давние времена сотрудники отделов разработки старались следовать стандартам и, в большинстве случаев, составляли пакет программной и эксплуатационной документации – там были и Спецификация, и Техническое задание, и Программа и методика испытаний, и Пояснительная записка, и целая кипа Руководств – для администратора, программиста, оператора. Принято было даже программный код распечатывать и хранить на бумаге. Но время не щадит никого, а хранение документов в бумажном виде не самый надежный вариант. В годы перестройки, массовых сокращений и банкротств предприятий мало кто заморачивался сохранением архивов ИТ отделов. Сотрудники же вновь создаваемых отделов не рвались разбираться в горах бумажного мусора, оставленных предшественниками и, зачастую, их просто выбрасывали. В итоге получается так, что предприятие использует самописный старый софт с неизвестными современным сотрудникам алгоритмами и системной архитектурой. Чтобы разобраться как оно работает требуется проводить реверс-инжениринг, который по трудозатратам порой превосходит повторную разработку данного ПО.
- Некомментированный код. Обратная разработка штука трудоемкая, но ее значительно облегчает наличие хорошо откомментированного исходного кода. И тут мы опять сталкиваемся с мудростью предков – код в большинстве случаев комментариев не содержит. Ведь и верно – а зачем? Древние программисты честно разрабатывали полный пакет документации на проект – там были расписаны алгоритмы всех модулей, может где-то на бумаге существовал даже откомментированный вариант исходного кода. Ага – вот на той самой бумаге, которую мы сдали в макулатуру, прибираясь в кабинете предыдущего программиста.
- Отсутствие системы контроля версий. Итак, есть у нас ПО, допустим экономистов, и его исходный код, допустим идеально комментированный – берем мы его, радостно компилируем и… программа считает совсем не то, что ожидалось. А откуда современный программист знает в какой папке файловой помойки, оставшейся от его предшественников, лежит актуальная версия кода - Git систем-то в древности не было. Каждый программист творчески подходил к каталогизированию и ведению версий разрабатываемого ПО: у некоторых бунтарей все лежало в куче, кто-то раскладывал в папки по месяцам исходники разных проектов, у кого-то подкаталоги в папке проекта были названы не номером версии - кодовым названием сборки. Усугубляется это тем, что старые исходники могли быть миллион раз перенесены между различными файловыми системами и хранилищами, давным-давно утеряв атрибуты времени создания и изменения.
- Нестандартность творческих решений. В древности учили совсем не так – программиста не ставили на рельсы готовых конструкторов и фреймворков – им давали основы алгоритмизации, синтаксиса языка и позволяли творить. Структурировали их писанину не лучшие практики и методологии разработки, а технические ограничения железа. В древнем коде зачастую можно было обнаружить множественные запросы к базе в цикле – ну а что, базы были маленькие и если возможностей сервера хватало – почему бы и нет (базам же не свойственно расти да?). С другой стороны, для десктопных приложений этот же программист скрупулёзно вычищал память, чтоб не дай бог Pentium 166 с двумя мегабайтами оперативки не завалился на бок от его тяжеленной поделки. Короче сейчас, начитавшись умных книжек и наслушавшись модных коучей, анализировать древний код лучше и не пробовать – предыдущее поколение все делало не так, но ведь оно как-то работало.
- Древние программисты собственной персоной (назовем их красиво – legacy программистами, так как они тоже часть наследия древнейших времен). Да, большинство из первопроходцев в области программирования уже умерли от старости, унеся с собой секреты древних программных продуктов, но второе и третье поколение еще живы и продолжают нас радовать. Стереотипный legacy программист это человек 55-65 лет, поддерживающий старое ПО, со скепсисом смотрящий на современные IDEшки и фреймворки, мирно ждущий своей пенсии. Эти люди глубоко погружены в бизнес процессы своих организаций, знакомы со спецификой ПО и пользователями, но, зачастую, не могут передать знания новому поколению, а в большинстве случаев даже не хотят. В моей практике встречались носители древнего знания, которые, даже получая деньги за наставничество, отшивали учеников формулировками типа «тебе это не нужно» или «ты не готов» (ну прям пафосное «Ты не достоин!»). И дело тут не только в лени и нежелании учить. Люди предпенсионного возраста, не обладающие релевантными на текущий момент компетенциями и выполняющие минимальный функционал на праве держателя бизнес-процесса, прекрасно понимают шаткость своего положения. Зачем бизнесу старый программист, который не может написать ничего нового (банально по причине того, что конторе не нужен софт на Delphi, использующий BDE или не дай бог на FoxPro). Такой legacy программист сгодится только для поддержки legacy софта, в котором он единственный разбирается. Тогда зачем передавать знания новому программисту – он же поймет как софт устроен и станет его поддерживать – или, упаси Аллах, оптимизирует и перепишет в современной IDE – и тогда старый сотрудник станет не нужен. Боясь увольнения, такие деятели не только утаивают информацию, но порой даже идут на саботаж – доказывая свою незаменимость (ибо только носитель древнего знания в курсе, как работает программа, которой уже не один десяток лет). Есть и вторая, более адекватная, категория legacy программистов – эти готовы учить и передавать знания, но… не могут. И проблема не только в отсутствии преподавательских и наставнических компетенций – проблема тут уже в конфликте поколений, в разных понятийных аппаратах. Я здесь не говорю о конфликте не сильно адекватных наставника и ученика, которые пытаются друг другу «лицо сломать» - бывало и такое в моей практике, я говорю о том, что древних программистов учили по-другому: они строят абстракции иначе, подходят к алгоритмизации по-своему и вообще плохо понимают принцип современных методологий разработки. Современным же программистам хочется быстрее сдать MVP и выйти на следующий scrum цикл, а им тут наставник про waterfall втирает. Да – нас сейчас учат как можно быстрее удовлетворять потребности заказчика, в древности же программирование было ближе к науке, и разработчик стремился всесторонне рассмотреть предметную область и сделать программный продукт на века, решение, которое и в перспективе будет полезно заказчику. То есть в текущих реалиях программирование в большей мере тактическое, а в те времена было стратегическим. И этот конфликт поколений приводит к тому, что молодёжь рвется сломать все и сделать заново.
- Глубокая интеграция Legacy ПО в бизнес-процессы заказчика. Таки да, при первом приближении хочется просто грохнуть все древние наработки и сделать все по-новому и правильно, к тому же зачастую старый софт уже частично потерял актуальность ввиду изменения бизнес-процессов организации (были у меня случаи, когда экономист, проработавший в организации три года, честно сознавалась, что никогда не пользовалась «этой кнопочкой» в десятилетней программе). Но попытавшись поменять один модуль или программный продукт мы наталкиваемся на то, что разваливается вся инфраструктура. Например, для переноса данных из PDM системы в 1C используется Delphi костыль, который и поменять бы, но половина модулей этой программы отвечает не пойми за что и при остановке сервиса рушится вся MES система. Старое ПО тащит за собой старое ПО – например CAD система работает только на Windows 7, замена CAD системы на современную заставит менять PDM систему или переписывать механизмы взаимодействия с ней, если менять PDM придется менять ERP и MES системы. То есть отказ от legacy решений может привести к полной замене программной инфраструктуры – а это уже проект на несколько лет и десятки миллионов русских денег.
Что же делать организации, погрязшей во… в использовании самописного старого софта? Старые программисты постепенно сбегают на пенсию, при этом не стремясь как-то облегчить жизнь своим последователям. Молодежь же сейчас учат так, что, самостоятельно постигнуть таинство работы legacy кода им не по силам. Тут отдельная история – ну по крайней мере в провинции – у нас будущих программистов учат в техникумах и ВУЗах только на решетки… ну в крайнем случае на 1С и Java. В прогрессивных конторах сейчас требуется знание современных языков и фреймворков, организациям же, погрязшим в legacy нужны, спецы по FoxPro и Delphi. Ну и куда же выпускникам учебных заведений податься? Ну – это вопрос для другой статьи.
В контексте обсуждаемой проблемы важнее другой вопрос – что делать счастливым обладателям древнего программного наследия?
Учить молодого сотрудника старым методологиям и языкам не выход – скорее всего юный программист поймет бесперспективность такого пути и спрыгнет в другую контору. Удерживать старых программистов, уговаривая их работать на пенсии – решение, если быть честным… временное (лишиться, в самом печальном смысле этого слова, специалиста в неподходящий момент – так себе удовольствие).
Выход – искать что-то среднее, искать универсальных спецов возрастом 30-40 лет, тех самых людей, которых учила еще старая преподавательская школа, но которым приходилось адаптироваться к жизни в современных реалиях. Этот немногочисленный контингент изучал физику и математику в школе еще по советской программе, в ВУЗах же им давали алгоритмизацию углубленно, они начинали программировать на Assembler, Basic и Pascal, но сдавали дипломы уже написанные в Borland C Builder или Visual Studio. Эти дети 80х-90х еще помнят азы, но реализовывали себя уже в эпоху новых веяний. Они те самые - последние советские программисты, те, которых сейчас принято считать fullstack универсалами. Остается найти и как-то мотивировать их прийти работать к Вам, разбираться во всем этом старье. Но если раньше наличие в требованиях к вакансии знания FoxPro и Delphi вызывало улыбку, то сейчас это мотиватор развести работодателя на ЗП побольше, ибо люди знающие понимают, что организация, ищущая такого спеца, в заложниках у того самого махрового legacy.
Резюмируя, скажу, что в текущих реалиях использование legacy ПО крайне убыточно для бизнеса и является существенным риском для его развития. Возникновение такого феномена связано, в том числе, и с политической ситуацией в стране – перестроечный период существенно затормозил развитие ИТ ландшафта многих организаций. Но не надо сетовать на прошлое – надо двигаться в будущее - актуализировать свой софт, обновлять команды разработчиков, производить импортозамещение (это сейчас модно) и не жалеть на это времени и средств. Если этим не заниматься – то при текущей конъюнктуре Ваш бизнес долго не продержится.
