Комментарии 17
думал, что после такого заголовка под катом будет ответ "НИКАК" и конец статьи.
как мы за 5 месяцев набрали 28 начинающих специалистов, обучили и через 3 месяца получили миддлов.
Просто речь не про тех мидлов и джунов, которые работают. А про тех, что числятся в расчете бюджета перед инвестором (материнской компанией).
+1
В некоторых конторах считается, что "мидл - это разработчик, который может решить любую проблему/задачу".
В целом, соглашусь - крепкий мидл может решить любую проблему.
А сеньор делает так, чтобы проблемы не возникали (или не создавать проблем)
Следующий уровень - уметь делать так, чтобы другие не создавали проблем.
Вот еще классная табличка компетенций и я с ней согласен (правда применительно к iOS-разработке, но не сложно адаптировать под другие сферы) https://github.com/BohdanOrlov/ios-skills-matrix
Заголовок, конечно, можно трактовать по-всякому, но все же он не отражает сути статьи. Да, есть «часть 1», но масштабирование команды - это не просто объёмный найм. Тут нужно, чтобы эта конструкция заработала.
Вы предполагаете, что «Сеньор ведет тестовую документацию, передает ее в разработку. Это человек, который влияет на проект, может быть ментором для начинающих специалистов». Через что он влияет? В чем его «сеньорность»? Тут кроме менторства скорее некий аналитик вырисовывается, который в пару раз дешевле сеньора.
как мы за 5 месяцев набрали 28 начинающих специалистов, обучили и через 3 месяца получили миддлов.
Middle определяется опытом, а не объёмом умных фраз, вброшенных в голову джуна. За три месяца можно существенно продвинуться в сторону Middle-а, но на рынке это будет всё тот же джун. Да, он/она может научиться решать типовые задачи в рамках вверенной области кода. Но кто будет проверять качество, потенциал роста и тп? На 28 джунов нужно как минимум ещё 14 менторов, чтобы они могли направлять и растить, а ещё не давали превратить продукт в кодовую помойку. И получается, что масштабирование джунами - это не такой уж и дешёвый путь.
Круто разделять статьи на части, когда каждая часть несёт некую ценность. А тут пока outcome в том, что Вы быстро набрали толпу джунов, что влияет на продукт в основном тратой его бюджета.
Может быть, у Вас есть рабочая модель, которая подтверждена цифрами. Но стоит тогда её доносить более цельно.
Ага. Причем они более дорогие, и их дорогое время мы потратили на то чтобы менторить, а не разрабатывать. И нигде не показано, откуда тут взялся профит, потому что производительность одного синьора, который способен быть ментором, как правило выше чем у джуна, и возможно вовсе не вдвое, а больше.
компания хотела запустить много новых функциональностей
Видимо, функций. Не стоит переизобретать русский язык.
К сожалению, не заметил в статье ничего про "эффективно масштабировать команду". Вроде бы как найти хорошего джуна - это, конечно, отдельный подвиг.
Но статья, вероятно, должна называться: "Как после найма толпы джунов не перестать выдавать результат в продуктив".
Отделом QA мы оценили бэклог и поняли, что на это уйдет никак не меньше пары лет.
Может рассказать, как вы оценивали бэклог по функциям, которые еще только планируется сделать и выдать, для которых, наверняка, нет ни аналитики, ни проработанных сценариев использования и т.п?
Кажется, что в вашей топологии проектных команд масштабирование должно происходить среди проектных команд, а не функциональных отделов.
через 3 месяца получили миддлов
рано вы их из учебки выпустили. Через еще каких-нибудь 3 месяца - были бы уже готовые сеньоры!
Забегая вперед, нескромный вопрос... После волшебного превращения в middle-специалистов (в вашей нотации) изменилась ли заработная плата у избранных? Или хватит с них осознания того факта, что работодатель величает "миддлами"?
Очень понравилось как у вас оформлены профили специалистов. Подскажите, пожалуйста, есть ли инструмент для оформления таких же красивых матриц компетенций?
Как быстро и эффективно масштабировать команду в 2 раза с помощью джунов