Очень кратенько.
Если вы собираетесь делать корпоративный митинг, то говорите не только о том как хорошо движется фирма (так как, зачастую всем кроме владельца это в конечном счете все равно).
Говорите о том, что развитие может дать людям. Им будет гораздо интереснее.
Единственное замечание. Будьте аккуратны с называнием цифр. Так как нету ничего хуже, чем невыполнене обещания. А цифры очень легко запоминаются и потом хранятся в памяти подчиненных.
Что-то никак не хватает времени написать полноценную статью. Надеюсь, завтра этим займусь.
Так что, просто выкладываю совсем необработанные раздумия.
Я прошел через несколько мелких фирм, которые вырастали. Везде были одни и те же проблемы, как быстро сделать из группки молодых программистов, группу зубастых профов.
Как по мне, правильный ответ — никак. Быстро это сделать не удастся. Можно только, медленно и постепенно и то, не все станут профами.
Начнем с того, что вероятнее всего, в группе будут две подгруппы — те у кого нет опыта (то, что лечиться) и те у кого нет мозга (лечется только хирургическим путем).
Ладно, оставим вторых. Сконцентрируемся на первых.
Самый лучший метод, который я знаю на сейчас, просто сидеть с людьми (а-ля XP программирование) и вместе решать задачи/обсуждать, помогать править их код и объяснять, почему и что делается. Но, лучший не значит самый простой (честно говоря забирает кучу времени).
Второе, что приходит в голову — давать правильные книги. Занимает меньше времени, но гораздо менее эффективно.
Провождение семинаров. Как по мне, еще менее эффективно, чем книги. Скорее семинарами можно ликвидирывать дыру в знания какой-то темы, но невозможно заложить хорошую базу.
Кстати, одна из самых важных вещей база. Все знания хорошо ложаться, только на хорошую базу. В нее должна входить логика/абстрактное мышление и достаточно долгий опыт просто писания кода (чтобы не возникали проблемы в простейших языковых конструкциях).
Редкие налеты в виде просмотра код раз в месяц, как по мне не дают фактически ничего. Это может помочь уже толковому программисту, который и так растет каждый день, чуть ускорить рост. Но, это явно не столкнет с места новичка.
Вопрос полностью открытый. И очень хотелось бы услышать ваше мнение, как можно сделать это процесс быстрее/дешевле/в более короткие сроки. Принимаются оптимизации, по любой из этой величин.
P.S. Антон Наумов напомнил, один из достаточно эффективных, но жестоких методов. Новичка кидают на настоящий проект, с полной выкладкой и ответственностью. Собственно так я учился, когда после полтора года опыта оказался ведущим программистом, на достаточно крупном проекте (явно размером больше моих умений).
В статье предатель фирмы, я уж касался темы ухода людей.
Так вот, пока сидел на теплом диване, пришла одна мысль в голову, которую решил записать.
Абсолютное большинство работников которых вы наняли и наймете, в конце концов уйдут от вас (каким бы прекрасным работодателем вы не были).
Сейчас, стандартный по индустрии период работы в одном месте – это 2-3 года. Так то, лучше всего рассчитывать примерно на эти сроки.
Естественно, если вы распрекрасный работодатель (хорошая ЗП, интересная работа, хорошее отношение к людям, отличные перспективы), то средняя длительность работы сотрудников в вашей фирме будет больше, чем по индустрии. Ну и логична и обратная сторона — если вы плохой работодатель, то этот срок может быть меньше.
И естественно на длительность еще влияет рынок (спрос). Чем больше спрос, тем меньше длительность работы в одном месте.
Так что, не стоит себя баловать нежными детскими мечтами, что у вас кто-то собирается проработать все свою жизнь.
Исходя из этого, естественно нужно рассчитывать, чтобы человек принес прибыль за время работы (по этому, если его обучение займет само по себе 2 года, то вероятнее всего нанимать такого человека бесполезно), и важно иметь некое дублирование знаний/ответственности для критических должностей и людей.
P.S. Кстати, может мне кажется, но большинство уходов приходится на позднюю весну и раннюю осень. Вы не замечали такого феномена?
Вы заметили в крутых боевиках, не менее крутые, чем сам боевик герои, не просто мочат все направо и налево , но и просчитывают ситуацию на десять шагов вперед. Именно благодаря этому, ну и быстрой руке (которая как известно лучший друг индейца) они спасаю свою заднюю часть от разнообразных неприятностей.
Шахматисты, они тоже видно в прошлом супергерои, и тоже пытаются считать ситуацию наперед.
Так же наперед пытаются считать ситуацию инвесторы, банкиры.
Одни только программисты не нуждаются в этих всех бреднях. Они гордо выступают в неровный бой с багами, засучив руки и выключив мозг.
Шучу, конечно, не все программисты так делают, собственно, об этом и буду говорить.
Самый правильный метод разгребания багов, особенно , если они не слишком интуитивные, состоит в том, чтобы составить план. План должен состоять из списка идей, что может быть сломано такое, что приведет к такому багу и самый простой способ проверить свою теорию – из-за это происходит ошибка или нет.
Просто постоянно вижу картину, когда молодой (и горячий) разработчик бросается в бой с багом, по пути наталкиваясь на новый и бросаясь разбираться с ним и так обнаруживающий себя через неделю в глубине кода работающий неизвестно над чем. Причем, если его спросить, какой был изначальный баг, то где-то секунд десять в отражении его глаз можно расчесываться, после чего человек с напряжением выдает какую-то вразумительный ответ.
Так что, нужно всегда выстраивать дерево (сначала желательно на бумаге), потом можно и в голове. Дерево должно выглядеть так – идея N1 (что сломано) + как проверить, идея N2 + как проверить и т.п.. Почему я говорю дерево, да потому, что иногда в не слишком удачно написанных проекта, проверка теории не удается без того, чтобы, например, пофиксить другой баг (для которого тоже нужны записывать варианты). И чем глубже приходятся «копнуть» тем больше шансов потом забыть какой-то из кусочков этого дерева.
Кстати, еще забавность, в том, что зачастую некоторые идеи можно проверить и откинуть даже не садясь за комп. Просто потому, что думаешь, а вот если будет сломано это, то, хотя баг такой и будет наблюдаться, но вести оно должно себя по другому. Именно эта возможность, прокрутки ситуаций в голове отличает хорошего программиста с опытом работы на проекте от просто хорошего программиста или просто человека с опытом работы на проекте. Зачастую обнаружение багов и нахождение, откуда они пришли занимает таким методом в десятки раз меньше времени, чем тупое копание.
Ну и вернусь к тому, что я говорил, что метод проверки теории должен быть наибыстрейший. Как по мне, один из самых эффективных метод – комментировать большие куски кода. Это сразу позволяет выявить внутри этого ли модуля находиться баг. Хотя есть и другие не менее эффективные методы.
И еще одно мелкое замечание, что если возможно придумать тест, который опровергнет или подтвердит сразу несколько теорий, то это лучший метод сократить себе время пофикса.
