Недавно была опубликована статья, которую я сначала решил проигнорировать, но потом решил написать подробный комментарий в виде другой статьи.
Программист должен решать бизнес-задачи Программист не должен решать бизнес-задачи Во многом я согласен с авторами обеих статей, однако есть несколько нюансов, которыми хотелось бы поделиться.
Уровни разработчика
Начну, пожалуй, с вопросов иерархии и уровней.Раньше я думал, что есть 3 уровня:
- Младший разработчик - когда выходишь из института и умеешь лепить как пластилин.
Кто-то может свернуть горы, кто-то глуп в самых простых задачах.
Но самое главное — нам нужен жёсткий контроль за тем, что делают эти разработчики, хотя бы первое время.
Часто вам нужно распределить задачи и просмотреть каждый шаг.
- Разработчик — это простой разработчик, который уже знает, что такое «производственный код», релизы, отладка, авралы и прочие интересные вещи.
Решает задачи средней сложности.
может поручать задачи более младшим разработчикам.
- Старший разработчик – решает технически сложные задачи.
Хорошо разбирается в своей предметной области и даже в некоторых смежных.
Его бросают на амбразуру при выполнении непонятных или нетривиальных задач.
Да, разминка, которая может затянуться на годы.
Некоторые люди остаются здесь навсегда.
Но тем не менее, именно старший разработчик наиболее ценен.
Почему? Потому что у него есть независимость и ответственность.
Вы можете дать ему задание, и он его выполнит. Он обшарит весь Интернет, спросит совета у «бывалых» людей, но сделает это.
Это именно тот персонал, который нужен - когда даешь задание и знаешь, что оно будет выполнено в соответствии с требованиями, в срок и требуемого качества.
Старший разработчик знает, как планировать, назначать и разбивать задачи.
И некоторым все же удается руководить другими.
Например, обучение стажеров или других разработчиков.
Дальше по технической части почти потолок.
Вы можете обратиться только к лидерству и управлению.
Так появляются технические лидеры и менеджеры.
Так я думал раньше.
Однако позже выяснилось, что старший разработчик может стать еще старше.
И даже больше.
Как же так? Есть несколько способов.
Разделение труда
Ни для кого не секрет, что с ростом разделения труда растет и производительность.Начиная с определенного уровня технических знаний и компетенций, возникает потребность в более глубоких знаниях в определенной области.
Каждое такое «углубление» обеспечивает еще большую производительность труда.
И, как нетрудно догадаться, за счет этой самой эффективности увеличивается рентабельность бизнеса.
Дальновидные люди поняли, что имеет смысл поддерживать таких разработчиков, а не превращать их в менеджеров, потому что они позволяют создавать уникальные продукты в достаточно узких областях, которые не под силу другим старшим разработчикам.
Таких разработчиков, обладающих уникальными, полезными для бизнеса компетенциями, стали называть по-особому.
В основном я сталкивался с этим в англоязычных изданиях, поэтому процитирую без перевода:
- Старший инженер
- Штатный инженер-программист.
- Старший штатный инженер-программист.
- Главный инженер-программист.
- Товарищ инженер.
На самом деле, вы скорее столкнетесь с ограничениями собственного мозга, чем с пределом инженерного уровня.
Большие и маленькие компании
Очевидно, что уровни разработчиков зависят от размера компании и сложности решаемых задач.Если вам нужно написать сайт на известном фреймворке, который нужно просто адаптировать под определенные условия или требования, то с этой задачей справится обычный разработчик, даже не старший.
По мере увеличения количества разработчиков обычно возрастает сложность решаемых задач.
А с усложнением решаемых задач растет и требуемый уровень компетентности.
Таким образом, масштабирование компании и бизнеса просто требует повышения инженерного уровня и навыков.
Каждый последующий уровень позволяет решить задачу еще более оптимально, сокращая затраты и увеличивая прибыльность бизнеса.
Бизнес
Так причем здесь бизнес, может спросить внимательный читатель? До этого мы говорили о разработчиках, уровнях, навыках.Как это связано с нашей темой и бизнесом? Дело в том, что для понимания вопроса нужно знать контекст. Именно контекст обсуждения позволяет эффективно отвечать на вопросы и принимать решения.
Разделение труда влияет не только на компетенции и уровни разработчиков, но и на сами виды деятельности.
Те.
Разработка – один вид деятельности, взаимодействие с партнерами – другой.
Понимание бизнеса и формулирование требований — третье.
Разделение труда и ответственности позволяет более внимательно сосредоточиться на проблеме и получить наибольшую выгоду.
Для этого есть менеджеры проектов, менеджеры продуктов, менеджеры менеджеров и т. д. Каждый решает задачи в своей зоне ответственности, и старается сделать это как можно лучше.
По крайней мере в теории.
В этом случае начинают возникать проблемы на интерфейсе.
Менеджер продукта должен сформулировать требования к продукту.
Однако случается, что некоторые требования просто невозможно реализовать или потребуют значительных усилий по реализации.
Но лучше было бы сделать по-другому, потому что.
это проще и более соответствует существующему интерфейсу, например.
Если бы разработчик мог оценить и предложить это сам, это было бы идеально.
Таким образом, гибриды возникают на стыках разделения труда.
Оказывается, так некоторые вопросы решаются гораздо быстрее и качественнее.
Так появляются гибриды, которым начинают уделять повышенное внимание со стороны бизнеса.
Соответственно, если разработчик понимает, в каком направлении нужно развивать продукт, то экономятся значительные ресурсы компании.
Таких разработчиков начинают ценить и такие разработчики тоже могут продвигаться по карьерной лестнице.
Однако есть задачи, требующие высокой концентрации интеллектуальных усилий.
Учет нетехнических аспектов становится не только полезным, но и вредным, потому что.
Теряется направленность и без того ограниченной способности мыслить и работать в одном направлении, принимая сложные технические решения.
Таких инженеров необходимо максимально изолировать от требований к продукту и задач бизнеса, обеспечить им комфортные условия для создания продукта с высокой добавленной стоимостью.
Зачем добавлять в уравнение больше денег, если оно уже содержит их изрядное количество? Поэтому ответ на вопрос о том, что можно, а что нельзя разработчикам, лежит в плоскости понимания текущей ситуации с бизнесом, зависит от уровня задач, самого бизнеса, наличия кадров и т. д. и т. п.
Универсального ответа не существует, как нет и языка, на котором все программируют и этому рады.
Все очень индивидуально и зависит от обстоятельств.
Ну а умные найдут в статье ключик для собственного развития.
Всем удачи! Теги: #Карьера в IT-индустрии #программирование #разработка #решения #уровни
-
Как Починить Принтер Canon
19 Oct, 24 -
Простая Самодельная Видеокарта Vga.
19 Oct, 24 -
Конвертируйте Музыку В Flac С Помощью Cuda
19 Oct, 24 -
Использование Scala В Корпоративных Проектах
19 Oct, 24 -
Свобода Попугаям И... Женщинам
19 Oct, 24
