Сейчас во многих крупных компаниях берут даже стажОРов. Вместе они возможно и сила, но это только если сами по себе проекты не требующие особой компетенции. А Это ооооочень тонкий лед))) Со стороны, если позволите это выглядит как, страшное дело доверять свои инвестиции под аутсорс, в которой под капотом дети. Для MVP еще можно, чтобы к инвестору не с пустыми руками.В целом я думаю, что большинство небольших веб студий за счет этого и выживает, когда не может себе позволить хотябы одного более менее зрелого спеца в команду, потому что дорого. В любом случае, успехов вам и здорово, что делитесь такими откровениями.
Полностью согласен про оооочень тонкий лед. Но наша система подходит не всем. Более того, она видоизменяется в зависимости от условий и целей. Из статьи это не совсем понятно, но поскольку это вводная статья, я решил ее не перегружать. Ситуация следующая: в Zero 2 Hero есть своя специфика. Мы делаем прототип в максимально короткие сроки( максимум за 4 недели). И важно понимать, что прототип - это не MVP. Он не будет долго жить, но зато его можно сделать быстро и дешево. Прототип нужен только для того, чтобы проверить гипотезу, и если она верна, то можно отправляться к инвесторам и создавать полноценный и качественный продукт. Прототип прост в реализации: не нужно думать об архитектуре, отказоустойчивости, расширяемости и поддержке. Поэтому с данной задачей может справиться джуниор-команда (под руководством сеньор специалиста).
Подобную схему мы также запустили и в другой продуктовой компании (не аутсорс). Изначально у нас были только сеньор команды, но хороших сеньоров найти очень сложно. Поэтому мы решили параллельно растить своих сеньоров. Главная задача, которая стояла передо мной: как взять молодых специалистов и быстро дорастить их до сеньоров. При этом важно, чтобы junior команда как можно раньше начала приносить пользу бизнесу, чтобы этот "образовательный" проект не сильно тянул компанию вниз. Так и родилась данная методология. Именно junior разработчики непосредственно решают сложные задачи. А наши и без того занятые сеньор разработчики выступают в роли кураторов - посредников между бизнесом и разработкой. Не тратя много времени, сеньоры помогают командам доводить их решения до приемлемого качества. Таким образом, бизнес всегда получает результат приемлемого качества. Сеньоры не участвуют внутри процесса реализации фичи, экономя свое время, но контролируют качество фичей на выходе. Они дают полезный фидбек командам, который помогает ребятам расти. Получается, образование происходит на реальных задачах, продвигая бизнес вперед и позволяя дешево растить будущих спецов внутри.
Важно понимать, что это статья посвящена тому, как растить джуниоров внутри компании, а не про то, как выполнить бизнес-задачи с помощью дешевой рабочей силы.
Сейчас во многих крупных компаниях берут даже стажОРов. Вместе они возможно и сила, но это только если сами по себе проекты не требующие особой компетенции. А Это ооооочень тонкий лед))) Со стороны, если позволите это выглядит как, страшное дело доверять свои инвестиции под аутсорс, в которой под капотом дети. Для MVP еще можно, чтобы к инвестору не с пустыми руками.В целом я думаю, что большинство небольших веб студий за счет этого и выживает, когда не может себе позволить хотябы одного более менее зрелого спеца в команду, потому что дорого. В любом случае, успехов вам и здорово, что делитесь такими откровениями.
Полностью согласен про оооочень тонкий лед. Но наша система подходит не всем. Более того, она видоизменяется в зависимости от условий и целей. Из статьи это не совсем понятно, но поскольку это вводная статья, я решил ее не перегружать. Ситуация следующая: в Zero 2 Hero есть своя специфика. Мы делаем прототип в максимально короткие сроки( максимум за 4 недели). И важно понимать, что прототип - это не MVP. Он не будет долго жить, но зато его можно сделать быстро и дешево. Прототип нужен только для того, чтобы проверить гипотезу, и если она верна, то можно отправляться к инвесторам и создавать полноценный и качественный продукт. Прототип прост в реализации: не нужно думать об архитектуре, отказоустойчивости, расширяемости и поддержке. Поэтому с данной задачей может справиться джуниор-команда (под руководством сеньор специалиста).
Подобную схему мы также запустили и в другой продуктовой компании (не аутсорс). Изначально у нас были только сеньор команды, но хороших сеньоров найти очень сложно. Поэтому мы решили параллельно растить своих сеньоров. Главная задача, которая стояла передо мной: как взять молодых специалистов и быстро дорастить их до сеньоров. При этом важно, чтобы junior команда как можно раньше начала приносить пользу бизнесу, чтобы этот "образовательный" проект не сильно тянул компанию вниз. Так и родилась данная методология. Именно junior разработчики непосредственно решают сложные задачи. А наши и без того занятые сеньор разработчики выступают в роли кураторов - посредников между бизнесом и разработкой. Не тратя много времени, сеньоры помогают командам доводить их решения до приемлемого качества. Таким образом, бизнес всегда получает результат приемлемого качества. Сеньоры не участвуют внутри процесса реализации фичи, экономя свое время, но контролируют качество фичей на выходе. Они дают полезный фидбек командам, который помогает ребятам расти. Получается, образование происходит на реальных задачах, продвигая бизнес вперед и позволяя дешево растить будущих спецов внутри.
Важно понимать, что это статья посвящена тому, как растить джуниоров внутри компании, а не про то, как выполнить бизнес-задачи с помощью дешевой рабочей силы.