Классификация программистов по их ценности для бизнеса

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

  • junior — знает, что есть;
  • middle — знает, что можно;
  • senior — знает, что нужно.

Расшифровка на примере ситуации — когда вы сказали программисту что нужно сделать:

  • junior — возьмется делать, по ходу будет задавать вопросы, как это сделать, и если ему внятно объяснять как нужно — сделает;
  • middle — поисследует и предложит варианты, как это можно сделать, возможно порекомендует оптимальные, получив ваше одобрение — сделает;
  • senior — спросит — а зачем это делать, чего вы хотите добиться? Вы расскажете ему о своих целях. Он исследует вопрос, потом возможно поправит вас, скажет, что вот этого хотеть не надо, а вот другого — надо, приведет аргументы. Когда согласие насчет целей достигнуто, он найдет что и как для этих целей лучше сделать (вполне может оказаться, что это будет совсем не то, что вы предлагали изначально) и сделает в оптимальном виде.

По моим наблюдениям, помимо ценности для бизнеса эта классификация отражает естественный рост программиста в профессии. Junior начинает с изучения основ программирования — языки, фреймворки, алгоритмы, и т.д. Поэтому он в основном сфокусирован на уровне “как сделать”. Middle уже достаточно уверенно владеет языками и фреймворками, поэтому он переходит к следующему уровню — “что сделать”. Он расширяет свой кругозор, интересуется альтернативными вариантами решений, интересуется архитектурными подходами, начинает сравнивать разные подходы и формировать свои оценки для них. Senior уже обладает достаточно широким кругозором, и имеет за плечами серьезный опыт. Он чувствует в себе достаточно уверенности для того, чтобы самостоятельно найти подход практически к любой задаче. В то же время, он уже повидал в своей практике последствия плохих управленческих решений, когда люди выбирали неправильные пути для достижения своих целей, или вообще затруднялись четко сформулировать свои цели, из-за чего проекты терпели неудачу. Поэтому он начинает интересоваться уровнем “зачем” и выбором оптимального направления движения проекта. Таким людям часто доверяют быть тимлидами в командах, потому что они уже работают на том уровне, когда могут влиять на курс движения проекта в целом.

Чем эта классификация может быть полезна для программистов? Я думаю, из нее можно почерпнуть совет — как быстрее расти в профессии. В общем случае ответ на вопрос “как быстрее расти” конечно многогранен, и вряд-ли кто-то сможет претендовать что знает золотой универсальный способ. Поэтому этот совет я приведу с такой оговоркой — мы используем это в нашей компании (ivelum), и, мне кажется, это работает. Я не могу обещать что это подойдет всем, но по крайней мере вы можете принять это к сведению, и возможно попробовать.

Итак, как быстрее расти:

  • во-первых, старайтесь никогда не делать такой работы, смысла которой вы не понимаете. Если вам поставили очень конкретную задачу (типа, “добавить столбец в таблицу”) и не объяснили как это будет использоваться — постарайтесь это узнать. Где именно будет место этой работы в общей картине проекта, для чего это нужно делать, и почему выбрано именно такое решение;
  • во-вторых, привыкайте к работе с неопределенностью. Если вы попадаете в ситуацию, в которой вам непонятно что делать, то не спешите сразу идти к начальнику или к заказчику с вопросом “что делать”. Постарайтесь сначала найти варианты решений самостоятельно. Подумайте, в чем цели работы, какие есть варианты, какие у них плюсы и минусы. Вы все равно можете потом пойти к начальнику с вопросом “что делать”, но вы уже придете к нему с готовыми вариантами решений, с их анализом, и возможно с вашей рекомендацией — давайте сделаем вот это;
  • в-третьих, привыкайте брать на себя ответственность. Не во всех компаниях есть для этого подходящие условия (в нашей — есть :), но постарайтесь их найти. Постарайтесь добиться того, чтобы под вашу ответственность был выделен какой-то участок проекта, и вы могли в рамках него принимать решения сами. Пойти к начальнику спросить “что делать” — это проще, но это будет означать, что решение примет он. А вам надо учиться делать это самостоятельно.

На этом пока все :) Если у вас есть комментарии или вопросы к написанному — буду рад обсудить, здесь в комментариях или в чате Хекслета, можно в Твиттере.

Денис Стебунов

Originally published at ru.hexlet.io.

Show your support

Clapping shows how much you appreciated Hexlet.io’s story.