Приветствую вас, коллеги.

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

В средние века ученые изучали одновременно большое количество областей знаний — то, что впоследствии назовут физикой, химией, биологией, математикой, астрономией и положат в основу школьного образования. Но после того, как объем знаний лавинообразно увеличился, люди уже не могли специализироваться на всем сразу и произошло разделение областей знаний. Похожий процесс можно наблюдать и в разработке. Я помню, как еще двадцать лет назад один и тот же разработчик мог разрабатывать офисные приложения, игры и первые веб-сайты. Сейчас два лучших специалиста в разных областях могут иметь не более 20% пересекающихся знаний — им даже поговорить будет не о чем. Последние десять лет я наблюдаю стремительное разделение разработки на все большее количество узких областей, каждая из которых обрастает своей спецификой, наборами инструментов и подходов к разработке.

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

Опытные разработчики следуют за стремительно сменяющими друг друга технологиями, языками программирования и платформами, выполняя задачи, актуальные в данный момент для бизнеса. Конечно, многие сохраняют узкую специализацию и предпочитают работать только в «своей» области — но, на мой взгляд, таких разработчиков пока меньшинство. Все это накладывает свой отпечаток на управление разработкой, и, в особенности, на найм.

Как мы обычно смотрим на резюме разработчика

Знание основных особенностей разработки — медленное накопление знаний, постоянные новые задачи, отсутствие глубокой специализации и хорошего теоретического фундамента — позволяет по новому смотреть на резюме разработчиков. Как традиционно выглядит найм в IT? Руководитель смотрит на текущий проект, применяемые в нем технологии, и составляет вакансию — «веб разработка, бэкенд, ruby on rails». При этом в большинстве случаев игнорируются резюме, в которых не содержатся указанные технологии, значительно ограничивая список кандидатов. При этом на практике я неприятно часто видел ситуацию, когда через год проект уже использовал single page frontend с django-based rest api, не оставляя почти ничего от «начального» списка технологий и заставляя разработчиков либо менять работодателя, либо переучиваться. Бывают проекты с замороженными на годы технологиями — к примеру, поддержка бизнес-автоматизации крупного корпоративного заказчика, имеющего парк в десятки тысяч компьютеров под управлением Windows 2000 и централизованно использующего 6-ую версию Java. Или доработка монопродукта, написанного 15 лет назад на С++ под Windows, и с тех пор развивающегося исключительно количественно. Но такие случаи не то чтобы повсеместны. Гораздо чаще я вижу что уже за несколько лет работы в одной компании разработчик успевает сменить две-три технологии и основной язык программирования.

Как смотреть необычно

Мой опыт показывает, что гораздо удобнее смотреть не на «текущий» список используемых разработчиком технологий, а на его умение разрабатывать вообще и изучать новое. Много лет разработки веб-приложений на PHP и Python позволяют разработчику очень быстро перейти на Rails и усилить команду его знаниями в смежных областях. И уже через пару месяцев такой разработчик может быть эффективнее, чем разработчик с меньшим суммарным опытом только Rails.

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

Даже если вы берете человека на поддержку существующего продукта и уверены, что и через пару лет не будете его переписывать — все равно полезно искать легко адаптирующихся специалистов. Хотя бы потому, что при низкой загрузке по основному проекту вы сможете легко давать такому специалисту задачи в смежных областях, адекватно используя его возможности и умения.

Компания Valve, много лет разрабатывающая успешные компьютерные игры, даже придумала название для таких сотрудников: «T-Shaped People». Они говорят, что оптимальная для работы в команде квалификация имеет форму буквы «Т» — глубокие знания одной области, образующие «ножку» буквы, и неглубокие, но широкие знания в разных областях, образующие «перекладину». Именно такие бойцы лучше всего подходят для командной борьбы с проблемой сложности. О которой мы поговорим в следующей статье.