Последнее изменение: 13 мая 2008г.

О профессионализме и не только

У меня растут года,
Будет и семнадцать.
Где работать мне тогда?
Чем заниматься?

Владимир Маяковский

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

Итак. Предположим, герой – молодой человек, холостой кавалер... последнее, впрочем, неважно, это цитата. :) В общем, герой нашего романа решил стать программистом. Почему решил? Скорее всего потому, что интересно. Не суть. А решивши – берется герой за всё, до чего дотянется. И это нормально. Чтобы выбрать наиболее интересное (близкое, полезное – нужное подчеркнуть!), нужно попробовать как можно больше.

Долго ли, коротко ли – но набирает герой знаний в куче разных областей, технологий, языков. Visual Basic, Pascal, C/C++, Delphi, Perl, Java, PHP, SQL, HTML, JavaScript – список можно и продолжить. Обнаруживается при этом преинтереснейшая вещь – одни и те же задачи при использовании разных технологий решаются с сильно отличающейся степенью сложности. Говоря проще – одну задачу гораздо эффективнее решать на Perl, другую на Java, третью – на С++.

Это завораживает. Когда в три строчки решается задача, на которую ты недавно убил два дня – это производит впечатление. И постепенно формируется ощущение, что задачи нужно решать средствами, дающими максимальную эффективность. Т.е. – изучать одновременно множество технологий.

Быть. Широким. Специалистом.

Такая точка зрения очень распространена. Плюсы этого подхода известны, собственно от них-то и отталкиваются. Эффективность решения отдельно взятой задачи может быть гораздо выше, если использовать средство, заточенное под решение именно таких задач.

Ключевой момент – отдельно взятой задачи. В процессе обучения наш герой решает небольшие, можно сказать – учебные задачи. Однако жизнь – это не набор тестов, что бы ни воображали в министерстве образования. И учебных задач она не предлагает, в том числе и в разработке ПО. Все задачи учебного уровня уже давно решены, автоматизированы и не представляют интереса. Задачи сегодняшнего дня – они масштабны и нетривиальны.

– Не беда! – говорит наш герой. – Я разобью эту задачу на маленькие и решу каждую с помощью наиболее эффективного средства.

Ну... разбить можно. Решить каждую тоже можно. Однако решение множества мелких задач не является автоматически решением большой. Точно так же, как набор из микросхем, печатных плат и радиодеталей не является компьютером. Более того, даже набор из материнской платы, процессора, видеокарты, модулей памяти и жесткого диска не является априори компьютером. Не верите? Пожалуйста! Процессор AMD под гнездо Socket939, материнская плата на чипсете Intel с PCI-E и SATA, память RDRAM, видеокарта AGP, жесткий диск с интерфейсом IDE. Никакие два компонента1 этой системы нельзя заставить работать вместе. А каждый из них технологически почти что совершенен и являет собой пример эффективнейшего решения поставленной перед конструкторами задачи.

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

– Ерунда! – отвечает герой. – Я знаю множество технологий. Я смогу решить эти задачи в комплексе. Я. Смогу.

Сможет? Вот этому, собственно, и посвящена данная статья. Лирику и романтику в сторону, поговорим как взрослые люди.

* * *

Кем выгоднее быть – широким специалистом или узким? Однозначного ответа дать нельзя, все зависит от обстоятельств. Мне хочется поделиться своими мыслями по этому поводу.

Прежде всего, я бы хотел сделать несколько утверждений, очевидных на мой взгляд.

Утверждение первое. Скорость восприятия человека ограничена.

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

Из этого следует

Утверждение второе. Существует максимальный объем знаний, который можно получить за единицу времени.

Теперь я хочу ввести одно понятие, оно нужно для наглядности.

Пространство квалификации

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

Решающее значение для нашего обсуждения имеет площадь под графиком – объем знаний. Ибо есть "утверждение второе". Будем считать, что знания набираются максимально эффективно. Каким может быть график в момент времени t?

Возьмем двух сферических специалистов в вакууме – узкого и широкого. Пусть для определенности они оба пишут на Java и специализируются в web-разработке. Узкий специалист достаточно хорошо знает ядро Java, еще лучше знает веб-технологии, неплохо работает с базами данных. У широкого специалиста акценты те же, однако есть еще опыт в GUI, вебсервисах, EJB и OLTP. Графики их квалификаций – в таблице ниже:

Узкий специалист Широкий специалист Сводный график
Web narrow Web wide Web summary

Сразу поясняю. Везде, где я сравниваю графики, выполняются два условия. Графики выполнены в одном масштабе и площади под ними равны. Тем самым я облегчаю визуальное сравнение, во-первых, и ставлю сравниваемых специалистов в одни условия, во-вторых, – общий объем знаний у них одинаков.

Для удобства сведем графики в один. Результат, собственно говоря, предсказуем. Узкий специалист (синий график) концентрируется всего в нескольких областях. Соответственно, его знания в них высоки, но зато наблюдаются провалы в других областях. И наоборот – у широкого специалиста (красный график) есть знания в тех областях, где они отсутствуют у узкого – GUI, EJB и т.п., – но это компенсируется меньшей высотой пиков в областях специализации. А площади под графиками – то есть общие знания – одинаковы.

* * *

Оставим наших мифических специалистов в их вакууме и поговорим немного о другой стороне медали. А именно – о задачах, которые ставятся перед этими самыми специалистами.

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

Как я уже упоминал, задачи в современном мире становятся все более и более сложными. Требуя при этом знаний как более широких, так и более глубоких. Возникает вопрос. Как понять, может ли специалист решить задачу? Фактически – хватит ли у него на это квалификации?

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

И вот тут кроется серьезная проблема: объем требуемых знаний непрерывно повышается (ибо задачи усложняются), а объем имеющихся – ограничен. Вопрос. Что делать? Или, переформулируя – можно ли каким-то образом обойти ограничение по максимальному объему знаний?

Разумеется, можно. И довольно просто. Нужно всего лишь собрать команду.

* * *

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

Задача

Итак, поговорим о команде. Есть два варианта – собрать ее из широких специалистов и из узких. Какой вариант эффективнее? Вот это мы и будем выяснять.

Для начала определимся с задачей. Пусть это будет банковская система. С доступом как через толстого клиента, так и через web-интерфейс. С хранилищем данных, с online-обработкой транзакций. В общем, совершенно реальная задача. Жизненная. График квалификации, требуемой для ее решения, приведен слева.

Возьмем четырех специалистов. Один специализируется на создании толстого клиента, другой – на создании веб-клиентов, третий отвечает за работу с базой данных и backend, четвертый занимается в основном обработкой транзакций. Такая вполне сбалансированная команда.

Зададимся вопросом – в каком отношении находятся знания членов команды и общий объем знаний команды? В очень простом – суммарный объем знаний в команде не превышает объема знаний любого из ее членов. Логика тут простая – если в какой-то области один специалист знает X, а другой – Y, то вместе они будут знать не X+Y, а max(X,Y). Ибо знания, к сожалению, не аддитивны. Если каждый из 10 первокласников умеет считать до 10, то вместе до 100 они считать не смогут.

Таким образом, на графике квалификации знания команды – это огибающая всех графиков членов команды.

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

Специалист Client Web Enterprise OLTP Team Both teams
Узкий Client narrow Web narrow Enterprise narrow OLTP narrow Team narrow Both teams
Широкий Client wide Web wide Enterprise wide OLTP wide Team wide

Посмотрите на сводный график. Очевидно, что в случае узких специалистов площадь под огибающей больше. Причины понятны: меньше пересечений – областей, в которых знаниями обладают несколько членов команд.

Summary

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

Что мы видим? Поставленная задача (зеленая огибающая, штриховка) полностью покрыта суммарной квалификацией команды узких специалистов (синяя огибающая, желтая заливка), но выходит за рамки возможностей команды широких специалистов (красная огибающая, зеленая заливка). Иначе говоря, команда, составленная из узких специалистов, может решить поставленную задачу, в то время как команда, составленная из широких специалистов, – нет.

Не знаю, для кого как, а для меня этот результат постоянно подтверждается практикой.

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

* * *

Начнем, пожалуй, подводить итоги.

Основное, что можно вывести из всего сказанного:

Возможности команды, составленной из узких специалистов, выше, чем возможности команды, составленной из широких специалистов.

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

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

* * *

Вот и пришло время вернуться к нашему герою. И к изначальному вопросу – кем быть? Узким специалистом или широким?

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

Узкий же специалист может решить достаточно ограниченное количество задач. Но эти задачи могут быть гораздо более сложными, чем в случае широкого специалиста. И, что немаловажно, – команда из узких специалистов имеет куда большие возможности, чем каждый из них по отдельности.

На что ориентироваться – каждый решает для себя. Как я уже говорил – задачи становятся все сложнее. И широкие специалисты с каждым днем имеют все меньше шансов на успех.

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

  • Ядро Java – язык, threads, I/O, Collections API, Reflection – на очень хорошем уровне
  • Сервлеты/JSP, JSTL, фильтры
  • Работа с базой – JDBC, по меньшей мере один из ORM – какая-нибудь реализация JPA, Hibernate, Cayenne.
  • Фреймворки MVC – общие принципы, устройства; Struts, Spring WebMVC, JSF, WebWorks, один из них – на уровне каждодневого использования
  • XML – фундаментальные принципы, методы описания (DTD, Schema); XSLT
  • (x)HTML, CSS, JavaScript, DOM
  • Принципы функционирования сети – unicast, broadcast, multicast; TCP/IP, UDP/IP, ICMP
  • Сетевые протоколы верхнего уровня – HTTP, FTP, SMTP, POP
  • Принципы работы сервлет-контейнеров, жизненные циклы, диаграммы обработки запросов
  • Общие принципы обработки HTTP-запросов, защита от повторных посылок данных и т.п.
  • Общие принципы защиты от взломов (SQL injections и т.п.)

Всё это – не из разряда "слышал, что такое есть", а на уровне "понимаю как работает и могу использовать".

Почему я называю этого специалиста узким? Потому что он не лезет, например, в тонкую оптимизацию базы данных. Этим должен заниматься специалист по базам.

Вот тут был у меня показательный опыт. Работали мы над повышением производительности нескольких запросов. Наших знаний хватило на улучшение процентов на пять. После чего с базой и нашими запросами поработал профессионал – и скорость возросла в три (!) раза. Просто потому, что он этим занимался всю жизнь.

* * *

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

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

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

* * *

Ну вот, пожалуй, и всё. Что можно посоветовать нашему герою? Советовать вообще-то занятие неблагодарное, но тем не менее. О чем ему стоит задуматься при выборе пути?

На мой взгляд, надо ответить себе на следующие вопросы:

  • Какова ширина ниши, в которую я хочу влезть? Каков риск ее исчезновения?
  • Какова востребованность специалистов того профиля, к которому я стремлюсь?
  • Какие задачи ставятся в той области, куда я собрался? Остались ли там задачи широкого профиля, или же они все уже решены? Насколько эта область покрыта решениями на текущий момент? Какова тенденция?
  • Что мне ближе – универсальность или уникальность? Стоит ли выбирать специализацию прямо сейчас или же лучше отложить выбор, а пока просто двигаться в одном глобальном направлении?
  • Что мне ближе – самостоятельная работа или тесная работа в команде?
  • Кем я хочу быть через год? Через пять лет? Через 10? (На эти вопросы стоит отвечать регулярно, не реже раза в год.)

Скорее всего вопросы этими не исчерпываются. Это лишь приблизительный список. И в зависимости от ответов необходимо корректировать свои действия и искать оптимальный баланс между универсальностью и уникальностью.

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

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

* * *

P.S. Касательно узких и широких специалистов. Хочется привести пример, позволяющий, так сказать, пощупать эти понятия.

Итак, представьте себе команду в игровом виде спорта. Такую, где четко распределены амплуа. Футбол, хоккей. Представьте себе, что все игроки одинаково могут играть в нападении, в обороне, защищать ворота. И развитию всех этих умений они уделяют одинаковое количество времени.

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

Мне кажется – всё, что захотят.


1. Имеются в виду компоненты, которые соединятся вместе – процессор и материнская плата, материнская плата и память, материнская плата и жесткий диск и т.п. Очевидно, что жесткий диск в видеокартой никак не пересекаются и при желании (и наличии соответствующей материнской платы!) могут прекрасно работать вместе.


В начало