Как создать крутую команду разработчиков Umbraco?

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

Подрядчики, аутсорсинговые команды разработчиков и встроенные команды

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

«Должны ли мы нанять больше сотрудников для работы с нашими текущими и/или предстоящими проектами или лучше использовать другой подход?»

Принятие правильного решения не всегда является наиболее практичным, так как могут быть задействованы самые разные факторы. Эти вопросы звучат знакомо?

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

Подрядчики №1

Вы «арендуете» разработчика (или двух, или трех) у компании, которая предоставляет им определенное количество времени и денег, и заставляете их работать над одним или несколькими проектами или поддерживать существующие проекты.

Вы управляете ими до тех пор, пока они «принадлежат» вам, и заставляете их выполнять любую работу, которая может вам понадобиться. Это способ искусственно увеличить вашу команду на короткий период времени без найма.

Предостережения:

Опять же, вам придется немного заняться HR — тот факт, что другая компания предложила конкретного человека, не означает, что он определенно подходит для этой работы. Интервью придется проводить, и новому разработчику придется очень быстро приспосабливаться к тому, что вы им должны дать — что бывает не всегда.

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

#2 Аутсорсинговые команды разработчиков

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

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

Предостережения:

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

И мы здесь вообще не говорим об agile-подходах — просто забудьте об этом, если только вы не работали с одними и теми же людьми снова и снова.

№3 Команда разработчиков встраиваемых систем

Это более гибридный подход, в том смысле, что вы получаете не одного разработчика, а группу людей, которые знают друг друга и имеют опыт совместной работы.

Затем эти люди «встраиваются» в вашу текущую внутреннюю команду, следуя вашим процедурам и методологиям и в конечном итоге повышая вашу общую производительность.

Предостережения:

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

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

Наше предложение: Команда разработчиков как услуга

(Или, как это называют другие, SDaaS — разработка программного обеспечения как услуга)

Это еще более гибридный подход, чем команда разработчиков встраиваемых систем, и (на наш взгляд) наиболее рентабельный и приносящий наилучшие результаты.

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

Вы назначаете работу этой команде и платите за часы, которые они тратят на работу.

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

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

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

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

Предостережения:

В отличие от использования облачных сервисов в ИТ-среде, это более постепенный процесс, требующий установления доверия с обеих сторон.

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