Недавно вышла статья, мимо которой я сначала решил пройти, но потом решил написать развернутый комментарий в виде очередной статьи.
Программист должен решать проблемы бизнеса
Программист не должен решать задачи бизнеса
Я почти согласен с авторами обеих статей, однако есть несколько нюансов, о которых я хотел бы поделиться.
Уровни разработчиков
Начну я, пожалуй, с вопросов иерархии и уровней. Раньше я думал, что существует 3 уровня:
- Младший разработчик — когда выходишь из института и можно лепить, как пластилин. Некоторые могут сворачивать горы, некоторые тупят над простейшими задачами. Но самое главное — нужен строгий контроль того, что делают эти разработчики, по крайней мере на первое время. Часто нужно давать задачи и разжевывать каждый шаг.
- Разработчик — простой разработчик, который уже знает, что такое "продакшен код", релизы, дебаги, авралы, и прочие интересные штуки. Решает средней сложности задачи. может давать задание более младшим разработчикам.
- Старший разработчик — решает уже технически сложные задачи. Хорошо подкован в своей предметной области, а даже в некоторых смежных. Его кидают на амбразуру в случае непонятных или нетривиальных задач.
Впоследствии оказалось, что старший — это лишь начало реальной карьеры, а что было до этого — лишь разминка. Да, разминка, которая может затянуться на годы. Кто-то вообще застревает тут навсегда. Но тем не менее, именно старший разработчик наиболее ценен.
Почему? Потому что он обладает самостоятельностью и ответственностью. Ему можно дать задачу, и он ее сделает. Перелопатит весь интернет, спросит советов у "бывалых", но сделает. Именно такие кадры и нужны — когда даешь задачу и знаешь, что она будет сделана в соответствии с требованиями, вовремя и нужного качества. Старший разработчик умеет планировать, ставить и разбивать задачи. И еще некоторые умудряются руководить другими. Например, взращивать интернов или других разработчиков.
Дальше наступает практически потолок в технической части. Можно лишь свернуть в сторону руководства и управления. Так появляются технические руководители и менеджеры.
Так я раньше думал. Однако впоследствии оказалось, что старший разработчик может стать еще более старшим. И еще более. Как так? Есть несколько путей.
Разделение труда
Не секрет, что с ростом разделения труда растет и производительность. Начиная с определенного уровня технических знаний и компетенций возникает потребность более углубленного знания в определенной области. Каждое такое "углубление" дает еще бОльшую производительность труда. И, как нетрудно догадаться, повышается прибыльность бизнеса за счет той самой эффективности.
Прозорливые люди смекнули, что имеет смысл поддерживать таких разработчиков и не конвертировать их в менеджеры, т.к. они позволяют в достаточно узких областях создавать уникальные продукты, не под силам другим старшим разработчикам. Таких разработчиков, которые обладают уникальными компетенциями, полезными для бизнеса, стали называть по-особому. В основном я встречал это в англо-язычных публикациях, поэтому буду приводить без перевода:
- Senior engineer.
- Staff software engineer.
- Senior staff software engineer.
- Principal software engineer.
- Fellow engineer.
Понятно, что названия и уровни могут сильно разниться от компании к компании, но идею, я думаю, все поняли: существуют непустой достаточно глубокий уровень компетенций, в который можно развиваться и развиваться. Фактически, скорее ты упрешься в ограничения своего собственного мозга, нежели в предел инженерных уровней.
Большие и маленькие компании
Очевидно, что уровни разработчиков зависят от масштабов компании и сложности решаемых задач. Если надо написать сайт на известном фреймворке, который нужно просто адаптировать под определенные условия или требования, то с этой задачей вполне сможет справиться обычный разработчик, даже не старший. С ростом количества разработчиков как правило растет и сложность решаемых задач. А со сложностью решаемых задач растет и требуемый уровень компетенции.
Таким образом, масштабирование компании и бизнеса просто требует роста инженерных уровней и навыков. Каждый последующий уровень позволяет решать задачу еще более оптимально, сокращая издержки и повышая рентабельность бизнеса.
Бизнес
Ну и при чем тут бизнес, спросит внимательный читатель? Речь до этого шла про разработчиков, уровни, навыки. Как это связано с нашей темой и бизнесом?
Дело в том, что для понимания вопроса необходимо знать контекст. Именно контекст обсуждения и позволяет эффективно отвечать на вопросы и принимать решения.
Разделение труда действует не только на компетенции и уровни разработчиков, но и на типы самой деятельности. Т.е. разработка — это один тип деятельности, взаимодействия с партнерами — другой. Понимание работы бизнеса и формулировка требований — третий. Разделение труда и обязанностей позволяет более плотно сфокусироваться на проблеме и получить наибольший выхлоп.
Именно поэтому существуют менеджеры проектов, менеджеры продуктов, менеджеры менеджеров и проч. Каждый решает задачи в рамках своей зоны ответственности, и старается это делать максимально хорошо. По крайней мере, в теории.
В этом случае проблемы начинают возникать на стыке. Менеджер продукта должен сформулировать требования к продукту. Однако бывает так, что часть требований просто невозможно реализовать, или потребуются значительные усилия по реализации. А лучше вообще было бы сделать по-другому, т.к. так и проще, и более консистентно с существующим интерфейсом, например. Вот если бы разработчик мог бы сам это оценить и предложить — вот это было бы идеально. Таким образом, возникают гибриды на стыках разделения труда. Оказывается, что так некоторые вопросы решаются гораздо быстрее и с более высоким качеством. Так появляются гибриды, которые начинают пользоваться повышенным вниманием со стороны бизнеса.
Соответственно, если разработчик понимает, в каком направлении необходимо развивать продукт, то так экономятся значительные ресурсы компании. Такие разработчики начинают цениться, и такие разработчики также могут идти вверх по карьерной лестнице.
Тем не менее, существуют задачи, которые требуют высокой концентрации интеллектуальных усилий. Принятие во внимание нетехнических аспектов становится не только полезным, но и вредным, т.к. теряется фокус и без того ограниченной способности мыслить и работать в одном направлении, принимая сложные технические решения. Таких инженеров надо максимально изолировать от продуктовых требований и задач бизнеса, и предоставлять комфортные условия для создания продукта, обладающего высокой добавленной стоимостью. Зачем еще добавлять деньги в уравнение, когда уравнение уже содержит их в изрядном количестве?
Поэтому ответ на вопрос про то, что должны разработчики, а что не должны, лежит в плоскости понимания текущей ситуации с бизнесом, зависит от уровня задач, самого бизнеса, наличия кадров и т.д. и т.п. Нет универсального ответа, как нет и языка, на котором программируют все и радуются этому.
Все очень индивидуально и зависит от обстоятельств. Ну а тот, кто умен, найдет ключ в статье для своего собственного развития. Всем удачи!
