Что-то никак не хватает времени написать полноценную статью. Надеюсь, завтра этим займусь.
Так что, просто выкладываю совсем необработанные раздумия.
Я прошел через несколько мелких фирм, которые вырастали. Везде были одни и те же проблемы, как быстро сделать из группки молодых программистов, группу зубастых профов.
Как по мне, правильный ответ — никак. Быстро это сделать не удастся. Можно только, медленно и постепенно и то, не все станут профами.
Начнем с того, что вероятнее всего, в группе будут две подгруппы — те у кого нет опыта (то, что лечиться) и те у кого нет мозга (лечется только хирургическим путем).
Ладно, оставим вторых. Сконцентрируемся на первых.
Самый лучший метод, который я знаю на сейчас, просто сидеть с людьми (а-ля XP программирование) и вместе решать задачи/обсуждать, помогать править их код и объяснять, почему и что делается. Но, лучший не значит самый простой (честно говоря забирает кучу времени).
Второе, что приходит в голову — давать правильные книги. Занимает меньше времени, но гораздо менее эффективно.
Провождение семинаров. Как по мне, еще менее эффективно, чем книги. Скорее семинарами можно ликвидирывать дыру в знания какой-то темы, но невозможно заложить хорошую базу.
Кстати, одна из самых важных вещей база. Все знания хорошо ложаться, только на хорошую базу. В нее должна входить логика/абстрактное мышление и достаточно долгий опыт просто писания кода (чтобы не возникали проблемы в простейших языковых конструкциях).
Редкие налеты в виде просмотра код раз в месяц, как по мне не дают фактически ничего. Это может помочь уже толковому программисту, который и так растет каждый день, чуть ускорить рост. Но, это явно не столкнет с места новичка.
Вопрос полностью открытый. И очень хотелось бы услышать ваше мнение, как можно сделать это процесс быстрее/дешевле/в более короткие сроки. Принимаются оптимизации, по любой из этой величин.
P.S. Антон Наумов напомнил, один из достаточно эффективных, но жестоких методов. Новичка кидают на настоящий проект, с полной выкладкой и ответственностью. Собственно так я учился, когда после полтора года опыта оказался ведущим программистом, на достаточно крупном проекте (явно размером больше моих умений).
Дело в мотивации разработчиков. Только в ней. Сидеть с людьми которые не хотят учиться/разбираться/понимать по причине лени/тупости/маленькой зарплаты/(тысяча других вариантов) бесполезно. Доказано Министерством образования и науки Украины.
Как мотивировать разработчиков развиваться? Это зависит только от самого работника, а работодатель этого сделать не может. Максимум на что он способен — создать условия для работы мотивированных работников и начать привлекать их в фирму любыми способами.
Я согласен, мотивация один из ключевых факторов.
И это пожалуй лежит за пределами статьи, как мотивировать людей.
Дальше вопрос следующий, пусть человек даже мотивирован. Как дальше, в кратчайшие сроки довести его до нужной кондиции.
согласен с Вами, Виктор, о мотивации. вообще еще я согласен с моим CTO — IT это сфера деятельности самомотивированных людей. им нужно просто не мешать. если это не работает — разработчик выбрал не правильную профессию.
Ну, как-то мотивировать надо. Но действительно 90% мотивации всегда идет изнутри.
Мне те же самые 10 лет назад никто не говорил: «Будешь писать хороший код и уметь строить архитектуру — будут золотые горы и кисельные берега». И ничего, сам разбирался без того, чтобы перед мной морковку вешали.
конечно, но только эта мотивация имеет форму «не мешай и будь честен». и опять-таки, есть порода людей, которой только дай компьютер и интересную задачу — они будут работать. поставь сроки, и они в них вложатся. и даже закончат раньше, потому что ловят кайф. есть люди, которым «жемчуг мелкий». вот например один из моих коллег уволился потому, что корпоративный новый год праздновался в офисе, а сам офис — open space. т.е. недостаточно пафосна внешняя аттрибутика. это крайности, но очень хорошо демострирующие полюса мотивации. остальное между ними, универсальный подход только один — не мешай и будь честен.
Я думаю, если положить руку на область желудка «уволился потому, что корпоративный новый год праздновался в офисе» — это просто был повод. Уверен, кроме повода, была еще и причина.
у нас решили почти как по первому пункту. Единственное просто пары были 1 толковый товарищ и 1 начинающий. Кроме этого сейчас проводятся level-up лекции которые тоже вроде худо бедно, но помогают, скорее направляют.
По поводу
>и те у кого нет мозга (лечется только хирургическим путем).
то таких просто увольняют и не парятся.
Но то, что парное программирование дает максимально ощутимый и хороший результат это факт. По крайней мере из того, что смогли опробывать
Согласен парное программирование, одна из самых лучших методик. Увы, очень трудоемкая и денежноемкая
А всегда приходится делать выбор между гибкостью, удобность и затратностью вложенных сил. Даже в самом программировании. Либо тяжелое решение, но надежное, либо легкое, но легко ломающеся..Среднее очень трудно найти, так и тут..
Согласен.
Но иногда бывают и не слишком сложные, но хорошие решения.
Их и ищем 🙂
Согласен с первым комментатором, только в мотивации разработчиков. Намного чаще возникает ситуация, когда потребности внутренней мотивации опережают возможности работадателя. У нас достаточно эффективно проводили семинары и закрпляли менее опытного программиста к более опытному, для решения одной задачи. Опытный программист учился делить задачу, контролировать ее выполнение, а менее опытный учился в первую очередь программировать.
У нас в свое время было так: ведущий программист, с ним заместитель (почти такой же по умениям программировать, но с меньшими организационными способностями), и с ними 3-4 программиста. Ведущий распределяет задачи, зная, кто на что способен и контролирует код. Вместе с замом решаются вопросы вида «как делать» и оказывается помощь в программировании. Ведущий просто катается на стуле от программиста к программисту почти все время.
Система довольно эффективна, правда, при наличии 4 программистов при плотной работе у ведущего практически времени на программирование не остается. Но уровень программистов подтягивается эффективно, разумеется, если мозги есть.
Если у программиста мозга нет — уровень не подтягивается, увольнение или сажается на вспомогательную работу, она всегда найдется. Отчет форматировать, за страховочными копиями следить…
Кстати, заместитель — это очень толково. Так как чаще всего, при том, что гравный программист должен и сам что-то делать и дизайн рисовать и следить за молодежью, то обычно слишком много работы на нем оказывается.
А на молодых полностью сгрузить нельзя, так как их и надо учить.
А, да. Если команда сравнительно молодая — пару раз в неделю последний час-полтора (ну или задержаться) — и всей командой Starcraft, CounterStrike и тд.
И пар выпустить, и весело, и программисты могут жестого измолотить ведущих 🙂
Команды распределяются чтобы примерное равновесие было или как попало. Заодно и многое выявляется в отношениях.
>>и всей командой Starcraft, CounterStrike и тд.
это напомнило как я за достаточно короткое время поднаторел в таких вот играх, чтобы выпускать пар на начальстве.
🙂
Когда игра начинается в рабочее время и правило «играй или работай» — все быстро обучаются 😉 Хотя ошибкой будет полагать, что все всегда играть будут — у нас часто кто-то и работал, когда остальные играли.
А вот выпустить пар на ведущих тяжко. На мой взгляд, ведущий программист просто обязан хорошо играть, навыки-то схожие: быстро оценить ситуацию и найти решение, помнить, кто на что способен и распределять функции, и так далее.
;)) Забавно, но к обучению в программирование имеет малое отношение
Скорее подымает настроение в коллективе
Как быстро подтянуть разработчиков? Очень просто!
Надо играть в скриптовую игру типа — Robot War, с обменом мнениями по результатам после игры. Тут и игровой процесс и напряжение мыслей для того, чтобы твой скрипт(танчик) победил и обмен алгоритмами после, и выявление лучших, и статистика роста. 🙂
Тоже забавно.
Увы скрипты к Robot Wars скорее должны быть умными в смысле алгоритма.
Хорошая расширяемая архитектура, чистый код и выполнения требований ТЗ в Robot Wars не обязательно.
Ну для начала надо разделить задачу. С помощью Robot Wars (RW), мы научили зеленых программеров писать алгоритмы. Далее, что у нас по плану? Выполнение требований ТЗ? Элементарно! Собираются ребята в пятницу в курилке и решают усложнить себе задачу по игре в RW, такими параметрами как — ограничение размера скрипта K-байтами, вот и оптимизация кода, если я правильно понял выражение чистый код. Дальше сроки — на оптимизацию старого или разработку нового скрипта — 5 дней, в пятницу вечером в 18-00 запускается игра. Не успел — не принимаешь участия. Для мотивации человека, кроме чувства победы, все скидываются по 200 р. и выигравший получает эти деньги или выигравший неделю всех остальных посылает за пивом за их счет. 😉 Придумать интересные варианты мотивации не составит труда группе из 3-5 человек.
Что остается? Расширяемая архитектура? Ну после пары месяцев игры в RW, им всяко придет на ум написать свою версию с возможностью расширения функций. А для этого надо разработать архитектуру и желательно расширяемую. 🙂 Вот вам и новый этап обучения. Программирование для себя, между программированием на дядю. Если не захотят, то программисты из них получаться не увлеченные программированием.
Забавная идея 🙂
Хотя подойдет явно не всем.
а можете подробнее рассказать про Robot War?
Robot War, на самом деле игра называется Robot Battle, их сайт — http://www.robotbattle.com/ игру привел как пример, где танчиками управляют не с помощью мыши, а с помощью скрипта. Если поискать, наберется с десяток аналогичных игр, где нужно играть с помощью скрипта.
Солласен с постами выше, но к сожалению жизнь оказывается гараздо сложнее…
Сегодня узнал что в британии молодежь в основном не интересуется hi-tech (больше идут в музыку, арт и тд) и найти специалиста по программированию очень сложно, этим занимаются в основном индусы так как они берутся за любую работу… Меня это слегка озадачило…
А что вас озадачило? Миром правит попса. А постоянное обучение которое необходимо в IT это ‘не круто’ и чтение документации по библиотеке — это ‘не гламурно’. Потому и выбирают этот путь либо те кто больше ничего не умеют но хотят хоть что-то зарабатывать, либо те кому эта профессия в кайф.
IT вообще популярно только в развивающихся странах по причине той, что за это платят больше, чем в других областях..
Аналогично в США.
Юр, представь себе, кто хочет в развитых странах конкурировать с миллиардом индусов и еще потенциально с миллиардом китайцев.
Программирование легко оффшориться. А скажем, выступление в Карнеги Холл, оффшорят редко 🙂
Еще интересно, что более популярные hi-tech компании, позиционируют себя как национальные, при этом втихаря (не любят это популяризировать) занимаются офшором, заводики на востоке строят, филиалы, офисы и тд. Так что по теме статьи они реально подтягивают (кормят) чужую армию 🙂
Думаю, оочень скоро все эти понятия чужая/своя армия исчезнут.
В любом пристойном киберпанковском рассказе — расписываеся, как корпорации становятся более сильными, чем страны. Соотвественно географические границы становятся не так критически.
Согласен, так как транснациональная корпорация открывающая филиал в какой-то там Украине, думаю может если не ложить на законы, но по крайней мере ложить на местную мафию, которая реально рулит! Так что глобализация однако! 🙂
э-ма, а Вы что работаете по украинским законам? мой договор заключен в штате Калифорния. и все вопросы регулируются законами этого штата. смешно, ей-Богу.
Ну, да я пока еще пока не дорос до Калифорнии 😀
При решении проблем с иностранными заказчиками, действительно будет решаться в штате Калифорния.
При решении проблем с украинскими представителями власти, я бы не сказал, что вопросы решаются на уровне, где заключен договор.
Зависит от размера корпорации и от того, сколько она делает денег на этом филиале.
Прямо сказать, что ложить на законы врядли можно. Но, конечно имея большие обороты, гораздо легче решать разнообразные проблемы.
Англия особенная старана, у них уклад общества и менталитет такой, что гуманитарное образование ценится намного выше чем техническое.
Жаль, что сейчас IT для многих это «не круто и не гламурно». ( Поэтому и вырастает такое поколение блондинок, тупых мажоров и еще кого то подобнго…(
Не надо жалеть, может это к лучшему.
Каждому свое. Почему все должны быть айтишниками? Вы же не хотите быть дворником? А где-то это очень даже популярная профессия.
Мне кажется, что XP — это оптимально в данной ситуации. Либо брать сразу опытных ребят..
по моему опыту знаю только два пути быстрого «подтягивания» ньюблов:
1) экстремальный. когда человека бросают в «боевой» проект и грузят отвественностью по полной. плюсом ялвяется создание спартанских условий в конторе. так начинал я и условия были не просто спартанскими, а практически фашистскими. там проходил естественный отбор, за 2 года я из Junior Developerа пришел к сеньйорской позиции и успел успешно порулить командой. сейчас этот способ практически не возможен — люди скорее всего уйдут. и он не очень хорош по сути. он дает только хороший технический результат и скорее всего кокурентам. но такой КМБ бесценен для разрботчика.
2) технологически-социальный. когда каждому разработчику дают в проекте, то что ему интересно, когда сеньйоры на своем примере показывают отвественность в отношении к работе, fun от процесса. когда тим лидер «горит» своим делом и «заражает» этим огнем подчиненных. довольно трудоемкий процесс, который требует расставления нужных людей на ключевые позиции, формирование команд с учетом психологических особенностей ее участников. это уже работа с людьми, а не ресурсами. построение механизмов взаимодейтсвий, где какждый не «винтик» в машине, а «незаменимая деталь». незаменимая не в плане уникальная, а в плане «нам тебя будет не хватать, мы надеемся на тебя и доверяем тебе». это сложно и имеет довольно высокую цену. но сейчас иначе не получается, и в конечном итоге не об этом ли мечтали все мы и каждый из нас, когда приходили в индустрию?
>за 2 года я из Junior Developerа пришел к сеньйорской
У меня еще такой вопрос возникает — а сколько вообще времени надо, чтобы придти к сеньору? 2 года — это много или мало? У меня стаж полтора, но сеньором и «не пахнет». Мне интересно — это политика нашей компании или мои недостаточные старания? Какова вообще «временная сетка» для становления разработчика?
Сериор — это не звание, это должность в фирме причем не задокументированная нигде. Если просто — то человек в опытом работы 🙂
т.е. на Juniour ты/вы тоже пришел с некоторым опытом?
сорри, флейм прекращаю.
если честно, то временных рамок нет. как все люди разные, так и сроки обретения заниний и опыта тоже индивидуальны. сейчас в объявлениях на сеньйорские должности пишут про 2-3+ года работы. т.е. это достаточно в среднем. по большому счету сеньйор от джуниора отличается только уровнем отвественности за сделанную работу и способностью разобраться с новой технологией за минимально короткое время. больше разницы нет. мои Juniorы знают порой такие детали фреймворков, которые я не узнал все 6 лет карьеры. но само по себе знание недостаточно, чтобы дать человеку сеньйорскую отвественность, полномочия и компенсацию.
ну и про опыт тоже хорошо сказано. умение находить ошибки, принимать решения, реально оценивать сроки, коачить людей, давать задания, контролировать выполнение заданий, прогнозировать риски — это все обязанности сеньйора. если Вы считаете, что справитесь, но Вам не дают попробовать и не дают без причин, то возможно дело в конторе. если по каким-то причинам, может быть дело в Вас. попробуйте сказать начальству, что Вы хотите. и посмотрите что выйдет. сеньйором Вас конечно не сделают, но могу дать вектор развития.
Ну, опять же что значит сделают сениором! Все это не больше чем игра слов!
Реально фирма дает обьявление на должность сениора и собеседуют людей по зад..ным вопросом, кого берут того и называют сениором 😀 Хотя реально опыт работы может любым, даже придуманным. Так что это настолько не официально, что даже трудно дать формулировку этому понятию. В любом случае сениор — это не юниор, то есть не тот что только закончил институт и пришел впервые на работу! 🙂
во-первых, не «делают сеньором», а дают сеньйорскую должность. если хотите, мы можем использовать термин «ведущий программист». если менеджер/тим лид берет на работу человека с придуманным опытом… то он берет не человека, а большие проблемы. это во-вторых. и в-третьих, формулировка понятию не нужна, есть скоуп обязанностей и эффективность. для джуниора хорошей является эффективность 30-50%. для мидлла — 50-95%. для сеньйора — 95-100%. и еще скоуп обязанностей включает все, перечисленное мною выше.
Да вы романтик 😉
Я согласен с GEF. Все эти Seniour или Junior. Это просто игра слов.
Я видел VP, которые никем не руководят, код не пишут, архитектуру не строят. Просто ходят и балаболят.
И я видел Team Lead’ов, которые тащили за собой добрый десяток людей и несколько проектов, при этом еще и занимаясь архитектурой.
Я бы сказал, что программист становится опытным минимально через 5 лет после начала трудовой деятельности. И то, эти пять лен он должен прыгать по проектам, делать разные вещи и смотреть с разных сторон на процесс работы.
Человек с двумя годами коммерческого опыта в IT скорее может быть просто нормальным программистом, за которым не нужно смотреть каждые 5 минут, чтобы он делал то, что надо.
Да кстати, я абсолютно забыл про метод, экстремальных условий. Сейчас допишу в P.S. статьи.
Мое ИМХО, обучать девелопера в короткий срок не только накладно, но и не выгодно, т.к. слишком велик риск, что он будет 2 месяца обучаться, станет крутым, и уйдет на третий месяц в другую контору. Особенно это относится к студентам и выпускникам, особенно к умным и амбициозным.
Потому тратить свое время и деньги на их скоростное обучение нет смысла. Снабжать документацией и материалами — да, ввести в команду из 4-5 девелоперов должность этакого архитектора, который обязан разбираться полностью в коде проекта, вохможно вести документацию и при этом просматривать весь код, который комитят остальные девелоперы, чтобы на раннем этапе пресекать самые грубые ошибки, которые допускают молодые девелы (копипастинг и написание своих собственных функций вместо того, чтобы поискать в коде или документации языка/фреймверка уже существующие, которые решают поставленную задачу), а так же давать советы по рационализации кода. Чтобы у него были полномочия откатывать изменения таких девелоперов, заставлять их комитится чаще, чтобы откат комита был бы еще возможен. Заставлять переписывать молодых девелоперов код. Вот собственно тогда я думаю можно быть уверенным, что и процесс будет идти и кодеры молодые постепенно будут обучаться. Правда есть один минус, на такой должности слишком долго работать не захочется, потому нужно чтобы в любой команде было два таких гуру кода проекта и чтобы они раз в месяц менялись обязанностями — один кодит, второй наблюдает за всеми и документирует фичи, чтобы потом при смене обязанностей тот кто месяц кодил, мог бы быстренько обозреть все ченжесы кода проекта за месяц (не только те которые он сам делал, а и ченжесы всех остальных девелоперов). Собственно наверное команды из 5-6 девелоперов 2 из которых такие вот гуру, это оптимальное решение , мне кажется.
Э… Вот тут я не согласен.
«обучать девелопера в короткий срок не только накладно, но и не выгодно»
Получается, что фирме выгоднее иметь неоптных людей, которые лажаются и за которыми надо следить, чем толковых людей, которые сами что-то могут делать.
«что он будет 2 месяца обучаться, станет крутым, и уйдет на третий месяц в другую контору.»
Если так происходит, то это в чистом виде проблема компании.
Это чаще всего значит, что оплата не поспевает за обучение и то, что люди просто мечтают свалить из компании и относятся к ней как к полегону тренировки.
ну в данном случае описывается сферическая модель некой конторы в ваууме, потому что люди все-равно научатся. и научатся быстро. а потом уйдут. потому что бОльшего хотят знать, а конторе это «не выгодно».
>Получается, что фирме выгоднее иметь неоптных людей, которые лажаются и за которыми >надо следить, чем толковых людей, которые сами что-то могут делать.
Нет. Компании выгоднее сразу брать людей под те задачи, которые они могут выполнять либо сразу, либо после не длительного инструктажа в течении 2-3 недель и еще 1-2 недели вливания в коллектив. А если ты берешь студента, который до этого делал лабы в институте и хочешь, чтобы он писал тебе дрова для новейшего плеера-Соньки для винды (всех саппортящихся версий), то тебе его прийдется 3 года этому обучать и ты потратишь деньги в пустую. Я утрировал конечно, но я имелл ввиду как раз то, что работник должен иметь возможность и рости профессионально на работе и при этом 50-90% рабочего времени каждый месяц работать на пользу компании. Вот это я и имел ввиду.
Ну, с этим я согласен, что брать людей и учить 3 года — это бессмысленно.
Но, вот, если бы тех же студентов, можно было научить за 3 недели, то на что сейчас уходит 3 года, я думаю ситуация резко поменялась бы.
Как ни странно, однако мой блог посвящён подобной тематике, и содержит публикации очень близкого смысла.
Давно опубликовал три статьи, являющиеся (как мне сейчас кажется) комментариями к сему посту:
1. Именование отделов (http://layer13th.last-step.ru/2008/02/22/imenovanie-otdelov/)
2. Именование серверов (http://layer13th.last-step.ru/2008/02/22/imenovanie-serverov/)
3. Количество программистов в команде (http://layer13th.last-step.ru/2008/02/06/kolichestvo-programmistov-v-komande/)
В эту субботу выйдет пост «Дисциплина Управление размышлениями». В следующее воскресение — «Дисциплина Управление энтузиазмом». Обе статьи в рамках темы Вашего поста и (что не маловажно) комментариев.
После того как обе дисциплины (точнее канвы) будут опбликованы, думаю дать моё видение методологи ведения разработок, ориентированной на русский (не просто российский) менталитет.
Спасибо за инфо!!:)Кул блог!
Да банально все 🙂 Нужно обучить — создаем план обучения, и выполняем его 🙂
Нужно обучить быстро — создаем маленький план обучения, но в нем собираем самое важное для нужд именно этого человека именно в этом проекте.
А как выбираем? Ну так аттестацией! Страшное слово? Ну, если такое уж страшное — заменяем на «опросник». Составляет тим-лид вместе с продактом, отвечает на вопросы
подопытныйобучаемый. В результате имеем почти полноценный план обучения. Добавляем немного подробностей (где копать и кто может помочь), оцениваем время.И не забываем включить в план и календарный график проекта 😉
По сути, это все то же самое, что и при приеме нового человека на работу. Только вместо резюме и собеседования — аттестация.
На самом деле, тогда мой вопрос можно переформулировать.
А что должно быть в этой аттестации?
Проблема в том, что если план обучения сделать коротким, то это не значит, что человек научится.
А что обычно включают в аттестацию? 🙂
1. Тема
2. Цели, которые обучаемый достиг.
3. Контрольные вопросы. (и ответы на них)
4. Упражнение для самостоятельного выполнения (лабораторный практикум? Ну или чуть более творческая задачка).
5. Итоговая оценка.
6. Выводы о достижении целей обучения.
Что касается пунктов 3 и 4 — можно привлечь разработчиков/архитекторов/тестировщиков с практическими навыками на данном проекте/продукте/направлении. И обязательно практические вопросы разбавить той теорией, на которой построена концепция продукта.
А по поводу «не значит, что научится» можно ответить просто — А риски никто и не отменял 🙂
P.S. «Опыт — он сын ошибок трудных» (с) кто-то из классиков.
Проблема в этом подходе, очень емкий процесс. Для того, чтобы разработать такую аттестацию (не дай бог еще слегка индивидуально, так как уровень может быть разный) займет много времени у подготавливающего.
А если делать по усредненному методу (как часто происходит в институте), то результат будет тоже очень усредненный.
А может давать разработчикам быть не только исполнителями, но и авторами проектов…
Давать им участвовать в написании ТЗ, тем самым самостоятельно придумывав себе задачи.
Я бы сказал, «не может». Если разработчик еще не дорос до определенной позиции, то толку от того, что он будет в том, что он будет писать ТЗ (он просто их еще мало видел).
Второе, бизнес все таки вещь созданная не для развлечения разработчиков, а для зарабатывания денег. Не уверен, что разработчики (младшего звена) придумал сами себе задачи от этого будут двигать бизнес вперед.