Почему не нанять сразу крутых разработчиков:
- Дорого, сложно найти.
- Держать компетенцию желательно распределенно.
- Не всегда уживаются вместе в силу конкуренции, бывает.
- Завышенные требования
Junior-разработчик — минусы:
- Нет фундамента и знаний правильной разработки.
- Не проверяет за собой, спешат быстрее сказать “Я сделал”.
- Не знают маломальских регламентов.
- Тесты — знают что полезно, но никогда их не писали.
- Метрики — что черт возьми это такое.
- Легко хантятся на сторону.
Junior-разработчики — плюсы:
- Стоят копейки, легче найти
- Можно состряпать человека под команду.
Из сего видно что минусов у них гораздо больше чем плюсов, так как же минусы превращаются в плюсы? Для начала предстоит немного попотеть самому и создать фундамент для этого:
- Микросервисная среда, причем микросервисы должны быть максимально стандартизированы. О микросервисной архитектуры можно тут — и на русском. Микросервис должен быть понятен даже маме разработчика, которая работает в библиотеке.
- Документирование всей системы (нет-нет это не та глупая бездумная документация которую никто не читает) это понятная схема причем если она будут интерактивной еще лучше. Если разработчик за 1 день не разобрался с вашим микросервисом, то у вас проблемы с документацией.
- Тесты-тесты-тесты. По моему мнению самый эффективный результат дают функциональные приемочные автотесты, а также тесты real-time по боевому окружению. Тесты должны писать совсем не разработчики софта — разработчики пишут тесты получаются де… мо.
- РЕГЛАМЕНТЫ — вот над чем стоит действительно поработать и следить за этим. Я считаю это наиболее весомым делом. Старт разработки, описание стандарта кодирования, описание для тестирования, тесты, сдача метрик и алертов, культура деплоймента, да даже регламент на попить чаю — все это должно занимать около 50% всего времени.
- Разработка с Junior-разработчиком строится исключительно по принципу — разработал, сдал тесты, метрики, алерты, документацию = сдал задачу.
Что в итоге это дает:
- В первую очередь ты всегда контролируешь процесс и никогда не отдаешь работу в которой плохо понимаешь.
- Если что-то сломалось ты всегда знаешь что, где и как это починить.
- У тебя в 2 раза больше людей (твоя гарантия MVP команды) за меньшие деньги.
- Бонусом ты получаешь самое ценное в разработки — актуальные метрики, алерты и тесты — ради этого все делалось.
Главная идея данного поста, что при таком подходе ты вынужден строить фундамент для качественной работы сервисов.
Комментарии (14)
Tyiler
05.08.2019 21:03делают мой проект
Ваш проект что/где? ссылку не вижу.
Напишите потом еще о результате, когда сделают наконец.
argamidon
05.08.2019 21:37+2Топик стартер тут пишет — "мой проект".
А в команде, наверное, по-другому поёт — «это наш проект, он очень важен для всех нас, великая идея… бла бла бла»
ZXZs
05.08.2019 21:45+1В плане управления, если он занимается этим один, то он имеет право говорить «мой». А если в общем плане, то естественно он «наш» :)
dom1n1k
05.08.2019 22:15А почему нужно выбирать из крайностей «крутой» vs junior? По-моему, вполне очевидно, что звезды — штучный товар, их много и не нужно. Но нужны мидлы — это фундамент, основная движущая сила, их в идеале должно быть большинство.
nshipyakov
04.08.2019 23:18На первых порах в джуниора больше вкладываешься нежели получаешь профит, поэтому описанные плюсы и достоинства сомнительны имхо
В первую очередь ты всегда контролируешь процесс и никогда не отдаешь работу в которой плохо понимаешь.
тоже самое можно сказать про то, что круто быть одному на проекте, потому что ты там все знаешь и контроллируешь
У тебя в 2 раза больше людей (твоя гарантия MVP команды) за меньшие деньги.
В два раза больше работы, так как за джуниорами глаз да глазcodecity
05.08.2019 02:20В два раза больше работы, так как за джуниорами глаз да глаз
По началу в несколько раз больше работы и практически нулевая полезность (легче было бы за 8 мин. сделать самому, с чем он там пол дня ковыряется). Однако кто-то же должен этим заниматься? Редкие преподы могут достойно подготовить в наших реалиях.nshipyakov
05.08.2019 10:10Ну так то да, но в статье преподносится вытягивание проекта джунами. т.е. понятное дело что без джунов никуда, но все же в реале проект тащат мидлы по большей части и сеньеры.
Хотя возможно я не правильно понял посыл статьи
vmoskalev
05.08.2019 13:08ancleOtto из материала создаётся впечатление, что существует средний, или, возможно, крупный проект построенный на базе микросервисной архитектуры. Было бы любопытно глянуть на статистику трудозатрат на разработку и дальнейшее сопровождение элементов системы, выполненные разработчиками различной квалификации. Тезисная подача материала не раскрывает предмета обсуждения и несёт односторонний характер.
з.ы. согласен, ресурс большей частью технический, но всё-таки минимальную вычитку для правок опечаток, орфографии и пунктуации перед публикацией в песочницу стоило провести.
el_kex
05.08.2019 13:08Джуниоры в команде — это как кредит. Доступный практически всем инструмент. Но если им не уметь пользоваться и набирать один за другим бездумно, можно залезть в яму.
Без ментора, планируемого роста, программы обучения, документации внутри команды это будет просто генератор говнокода. Надо понимать, что джуны нанимаются не потому, что дёшево и быстро, а потому, что получившийся миддл (при правильном приготовлении) вырос внутри системы и знает, как с ней обращаться. А также его не надо искать.
Другое дело, что я встречал множество примеров, когда джун вырастал, и его начинали кормить завтраками с повышением в зп, должности и так далее. Неудивительно, что потом такие компании пишут: «Джуны уходят». Хочется добавить: «Только джуны?».
Возвращаясь к финансовым аллегориям, джуны являются долгосрочными инвестициями на случай, если Вы понимаете, что поиск одного миддла и выше занимает много времени/стоит дорого/свой вариант (нужное подчеркнуть).
Джуны также часто плохо переваривают критику, графики работы (хотя их необходимость вообще под вопросом) и прочие строгие процессы. Они зачастую только что из института, не привыкли к таким вещам. И без правил игры начинаются истории с пустым рабочим местом и фразой: «Я что-то вчера устал».
Резюмируя: если не знаете, зачем Вам джуны, или думаете, что это просто дешёвые программисты, то лучше не нанимать их.
ancleOtto Автор
05.08.2019 13:16vmoskalev el_kex проект средний узнаваемый, не хочу упоминать его имя, потому-что он имеет историю бизнес-страданий, а мы тут вроде как про управление разработкой говорим.
Идея статьи — я тут поделился успешной историей, когда смог организовать процесс, достаточно дешевый для компании и хорошо управляемый, стабильный. Не факт что он подойдет кому-то еще, т.к. требует достаточно усилий на соблюдение регламентов — эта идея из авиастроения, там даблчек — делают везде и на каждом этапе вертикали производства.
Возможно данная статья кого-то заставит задуматься и пойти данным путем.vmoskalev
05.08.2019 13:50Для многих провинциальных компаний актуальна проблема оттока сильных специалистов в город крупнее или за рубеж. Развёрнутый анализ работы с джунами мог бы стать действительно полезным материалом. Для меня вопрос сложности поиска толковых опытных разработчиков стоит остро и при этом есть выбор талантливых студентов, инвестиция в которых может быть прибыльной. Успешная история просто сама по себе, к сожалению, имеет небольшую ценность, тк порождает ошибку выжившего. Поэтому я спрашивал про анализ некоторой «усреднённой полезности в вакууме» на примере сравнения историй разработки и сопровождения нескольких отдельных микромодулей. Есть такая? Или есть просто история «а вот так у нас получилось хорошо»?
el_kex
05.08.2019 18:12Да я же не против :) Более того, я за развитие людей в команде.
Но ведь читатели могут начать применять Ваши рек. И я не могу не отметить, что в истории не хватает слов о ресурсах, уходящих на контроль джуниоров, о чем написали в параллельных комментариях. А это довольно ощутимый ресурс: ментор должен учить, тщательно просматривать код, давать рекомендации — ментором работать.
А ещё не каждый разработчик согласиться брать на себя эту ответственность просто так. Да, «во имя команды» и все такое. Но так из-за джуна можно и мидлов и выше потерять.
brrr
Плати меньше, греби дальше