Archive for the ‘Менеджмент’ Category

Ужас-ужас и полная корпоративная амнезия.

Среда, Апрель 30th, 2008

Мне кажется в какой-то из статей я уже задевал эту тему. Меня немного, когда пишут – компания успешно выполнила скажем 500 проектов.

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

И что мы имеем? А имеем мы богача с полной амнезией. Так что же, надо писать, компания нарубила бабла за последние 500 проектов, увы мы плохо помним за какие?

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

Кстати, обычно переход уходом какого-то человека производят передачу дел и деление опыта. Это обычно полный ужас-ужас. Я видел единицы случаев, когда передача происходило нормально. Обычно, человеку который уходит уже все пофиг, человеку который принимает дела некогда, так как на нем и так лежат три проекта.

Я уже писал в статье, что накопление опыта, происходит только благодаря тому, что делаются ошибки, анализируются и потом делается правильно. Хитрость состоит, что если в компании спрашивают, почему был завален проект X, а люди отвечают, потому что Вася долб@еб его завалил (уже уволен). И при этом никто не может ответить конкретно, как его Вася завалил и почему так вышло и чем он собственно такой тупой это Вася, то вероятнее всего пришедший на его место Петя или Коля с таким же успехом завалит следующий проект.

http://victorronin.com/2008/04/14/opytnyj-znachit-oshibavshijsya/

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

Это и только это позволит компании иметь память вне людских голов.

Я опущу вопросы, какую информацию собирать и как анализировать. Для разных компаний – это будет по разному. Просто хочу сразу вскрыть основную проблему, почему фактически ни одна компания это не делает.

Сначала я опишу один пример из жизни, а потом уже вернусь, почему же никто толком не занимается корпоративной памятью.

Компания N1 (США) за свое деятельность поменяла 3 или 4 офшорных фирмы. С всеми фирмами были похожие (практически идентичные) проблемы (в большинстве своем инициированные компанией N1). Каждый переход на использование новой офшорной фирмы происходил с серьезными потерями финансов (ну скажем порядка $200-300K, при оборотах фирмы в несколько миллионов) и производительности (толком даже измерять не могу). Очередной менеджер, решил, что проблема в офшоре (и решил от него избавляться), хотя на самом деле, проблема в стратегии поведения Компании N1. Таким образом, из-за отсутствия данных, я думаю суммарно фирма прибила несколько миллионов на борьбу на самом деле с достаточно простой проблемой, то, что она толком не составляла контакт. Даже, если учесть, что достаточно сложно заставить выполнять контракт фирму находящуюся в другой стране, все равно, проблема остается в том, что нигде не были записаны/озвучены точные требования, ожидания и ограничения в работе.

Итак, возвращаясь к статье. Основная проблема с тем, почему информацию не хранят, заключается в следующем:

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

Тоже самое происходит и с менеджерами. Для них описания проблем, с которыми они столкнулись, как они их решали и что произошло — не имеет смысла. Так как они и так это уже знают, а то, что будет с менеджерами в фирме через 2-3 года опять же их не сильно волнует. Правда, ситуация похожа на программистов и документацию?

И точно также как с программистами – им надо объяснить и в приказном порядке заставить писать документацию, точно также надо поступать с менеджерами. Причем, точно также как кто-то должен проверять что документация написана у программистов, нужно проверять, что описаны проблемы и их решения у менеджеров.

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

Сделай сам.

Среда, Апрель 16th, 2008

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

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

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

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

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

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

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

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

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

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

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

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

Как быстро подтянуть разработчиков?

Среда, Апрель 9th, 2008

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

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

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

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

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

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

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

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

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

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

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

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

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

Сезонные миграции.

Воскресенье, Апрель 6th, 2008

В статье предатель фирмы, я уж касался темы ухода людей.

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

Абсолютное большинство работников которых вы наняли и наймете, в конце концов уйдут от вас (каким бы прекрасным работодателем вы не были).

Сейчас, стандартный по индустрии период работы в одном месте – это 2-3 года. Так то, лучше всего рассчитывать примерно на эти сроки.

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

И естественно на длительность еще влияет рынок (спрос). Чем больше спрос, тем меньше длительность работы в одном месте.

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

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

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