В супер маленьких компаниях (меньше 10 человек) обычно есть такая традиция, что люди активно вовлечены в жизнь фирмы. И когда появляется какая-то необходимость, люди не ждут милости от природы, а сами делают то что надо.

Когда размер фирмы увеличивается, количество инициативы и инициативных дико начинает падать. Вместо, того чтобы начать делать, люди начинают месяцам канючить - а кто мне купит мышку, а кто напишет документацию и т.п.

Ладно еще когда задача большая, то это и хорошо если человек не бросается ее делать, а пытается довести до менеджера, что задачу нужно на кого-то назначить. Но зачастую, начинается именно канюченье, переброс задачи от одного другому. И получается, что задачу на 5 часов, обсасывают десятки часов.

Ну как пример, мне нужна была одна программка, которая проверяет правильность работы сервера. В общем-то просто unitTest к серверу. Я в тот момент в .NET не особо рубил, ну и канючил у серверного разработчика, чтобы он написал такую программу. Но он все отмахивался-отмахивался, в результате когда меня достало его просить, я буквально за пару часов сам ее написал и стал ее наращивать добавляя разные тесты и возможности и через пол года (когда потратил на нее суммарно наверно часов 30) обнаружил, что вся компания у меня просит эту программку и активно ей пользуется.

Теперь, к выводами из этого всего

а) Если вы начальник и вы видите, что начинается канюченье, а еще хуже, отказывается от делания мелких задач - то давите это в зародыше. Это первые признаки разложения коллектива. Если люди не способны решать проблемы и упрощать себе работу, то чаще всего они и работу не будут особо хорошо делать (Кстати, тот самый серверный разработчик, которые отказывался мне помогать, делал сою работу таки откровенно похабно).

б) Начальник, должен озвучивать, что инициатива приветствуется. Но нужно установить пределы инициативы. Например, не больше чем, скажем 10-15 часов в месяц, инициативных задач, без одобрения.

в) Инициатива должна поощряться. Если кто-то сделал что-то действительно полезное, то нужно это упомянуть и премировать.

В общем, в результате получилась статья о поддержании инициативы.

И еще раз, как только начинается ситуация, когда одни люди гадят инициативу другим (путем безосновательного отказа в помощи, постоянных разговорах о том, что что-то нужно и ничего не делания и т.п. вещам) давите это в зародыше. Эта зараза легко заводится и очень плохо лечится.

И кстати, чем больше компания тем активнее нужно продвигать эту политику, так как нет ничего хуже, чем большая компания, в которой люди себя чувствуют мелкими шестеренками и поэтому поводу просто приходят отсидеть день на работе и сделать минимально работы, чтобы их не выгнали. Это угнетает и самих работающих людей и окружающих и компанию ни к чему хорошему не ведет.

P.S. Очень много людей сказали: начальству пофиг, начальство не дает. Идея инициативы в том, что делается она не спрашивая у начальства. Просто берется и делается. Поэтому важно начинать инициативу маленькой, чтобы она не мешала основной работе. И еще важно, чтобы она была действительно нужна фирме, тогда когда она уже станет заметной, то вас будут за нее хвалить, а не ругать. Есть такая фраза “победителей не судят”. Поэтому именно нужно быть победителем, чтобы инициативу постепенно подхватили многие и без нее уже не хотели работать.

По стопам прошлой статьи.

С Alexey мы углубились в дебри обсуждения и вышли на интересную тему – ошибок как двигателя обучения.

Чуть ли ключевым пунктом школьного и институтского образования проходит идея – «НЕ ОШИБАЙТЕСЬ». Вы ошиблись, вас наказали. Причем не просто нельзя ошибаться, а нельзя ошибаться даже первый раз. Но, ладно, тема пинания образования тут не ключевая.

Идея состоит в том, что я считаю, что обучиться можно ТОЛЬКО ошибаясь. Естественно, не имеет смысла делать ошибки специально, но только благодаря тому, что делается что-то много раз, каждый раз делаются ошибки и анализируются и есть движение вперед.

Многие скажут – только дураки учатся на своих ошибках. Опять же я не согласен.

Я бы сказал, что человек обучается не равномерно, а скачкообразно. То есть человек накапливает количественные знания, накапливает, до тех пор пока они скачком не переходят из количественных в качественные и человек переходит на новый уровень

Так вот, учиться на чужих ошибках можно только тогда, кода ошибки которые вы разбираете находятся на том же уровне, что и вы.

Как вы считаете, может человек только что начавший играть в шахматы учиться на ошибках чемпиона мира? Гроссмейстера? Перворазрядника?

А наоборот, может ли гроссмейстер обучаться на ошибках человека, который только научился играть?

То есть, да действительно можно учиться на чужих ошибках, но среди моря чужих ошибок вам подойдут, только ошибки вашего уровня. Мы же сами является постоянными генераторами ошибок именно нашего уровня, так что учиться легче всего на своих ошибках (и ничего в этом жуткого нет).

В какой-то момент, когда я нанимал студентов (еще не в свою компанию), то основное, что я хотел узнать у них – выписались ли они. То есть написали ли они уже скажем 10000 строк. Если человек их написал, то он уже совершил все ошибки на уровне непонимания языка программирования и его уже можно было брать (не беспокоясь об этом уровне понимания).

То же самое, первые несколько проектов у менеджера обычно завалены. По этому поводу, начинающему менеджеру лучше всего давать не слишком важные проекты с не слишком давящими заказчиками.

Не знаю, какие выводы из этого всего делать. Мне просто кажется, нужно не отмахиваться от того, что опыт приходи через ошибки и их решение, а принять это и исходить из этого.

Так, что спросите на следующем собеседование, не только о успешных, но и о заваленных проектах.

P.S. Загляните на этот блог

И если вы LJ пользователь, то можете меня зафрендить. Мой профайл: vronin.

Очень кратенько.

Если вы собираетесь делать корпоративный митинг, то говорите не только о том как хорошо движется фирма (так как, зачастую всем кроме владельца это в конечном счете все равно).

Говорите о том, что развитие может дать людям. Им будет гораздо интереснее.

Единственное замечание. Будьте аккуратны с называнием цифр. Так как нету ничего хуже, чем невыполнене обещания. А цифры очень легко запоминаются и потом хранятся в памяти подчиненных.

Что-то никак не хватает времени написать полноценную статью. Надеюсь, завтра этим займусь.

Так что, просто выкладываю совсем необработанные раздумия.

Я прошел через несколько мелких фирм, которые вырастали. Везде были одни и те же проблемы, как быстро сделать из группки молодых программистов, группу зубастых профов.

Как по мне, правильный ответ - никак. Быстро это сделать не удастся. Можно только, медленно и постепенно и то, не все станут профами.

Начнем с того, что вероятнее всего, в группе будут две подгруппы - те у кого нет опыта (то, что лечиться) и те у кого нет мозга (лечется только хирургическим путем).

Ладно, оставим вторых. Сконцентрируемся на первых.

Самый лучший метод, который я знаю на сейчас, просто сидеть с людьми (а-ля XP программирование) и вместе решать задачи/обсуждать, помогать править их код и объяснять, почему и что делается. Но, лучший не значит самый простой (честно говоря забирает кучу времени).

Второе, что приходит в голову - давать правильные книги. Занимает меньше времени, но гораздо менее эффективно.

Провождение семинаров. Как по мне, еще менее эффективно, чем книги. Скорее семинарами можно ликвидирывать дыру в знания какой-то темы, но невозможно заложить хорошую базу.

Кстати, одна из самых важных вещей база. Все знания хорошо ложаться, только на хорошую базу. В нее должна входить логика/абстрактное мышление и достаточно долгий опыт просто писания кода (чтобы не возникали проблемы в простейших языковых конструкциях).

Редкие налеты в виде просмотра код раз в месяц, как по мне не дают фактически ничего. Это может помочь уже толковому программисту, который и так растет каждый день, чуть ускорить рост. Но, это явно не столкнет с места новичка.

Вопрос полностью открытый. И очень хотелось бы услышать ваше мнение, как можно сделать это процесс быстрее/дешевле/в более короткие сроки. Принимаются оптимизации, по любой из этой величин.

P.S. Антон Наумов напомнил, один из достаточно эффективных, но жестоких методов. Новичка кидают на настоящий проект, с полной выкладкой и ответственностью. Собственно так я учился, когда после полтора года опыта оказался ведущим программистом, на достаточно крупном проекте (явно размером больше моих умений).