Archive for the ‘Инфраструктура’ Category

И еще раз о амнезии (часть вторая). Буква закона vs. Дух закона.

Воскресенье, Май 11th, 2008

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

В этой статье не буду писать никаких решений, а только буду бить по больным местам… э… пожалуй, только по больным местам этой темы.

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

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

б) Запись знаний, чаще всего низкий приоритет в системе ценностей человека. И поэтому, когда встает выбор – разгребать текущие проблемы или создавать «нетленку» 🙂, то чаще всего начинают разгребать именно текущее дела.

Дальше, перейдем к менеджеру того человека, который генерирует знания. Опять же у него возникает проблема очень похожая на б):

в) Нужно ли заставлять подчиненного писать свои знания или делать остальную часть работы. Опять же возникает конфликт приоритетов.

Потребитель знаний:

г) Почему собственно нужно читать чьи-то ошибки, сделанные непонятно когда и кем и пытаться понять какие-то решения, принятые людьми, которые уже не работают в фирме?

д) Как справляться с тем потоком информации, которые могут быть сгенерированными многими людьми. Как отбирать только нужное и важное и не тратить время на все остальное?

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

е) Что делать с людьми, которые не хотят сохранять знания, особенно если они ими обладают. Должно ли стать это требованиям к работе. Что делать с теми, кто не хочет изучать знания?

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

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

Д) Самое главное, как сделать весь этот проект прибыльным?

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

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

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

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

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

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

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

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

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

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

Очень хочется услышать ваше мнение о том, если я забыл указать какие-то проблемы и то, как вы считаете нужно решать самые серьезные их этих проблем.

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

Среда, Апрель 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 года опять же их не сильно волнует. Правда, ситуация похожа на программистов и документацию?

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

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

Должен или не должен, вот в чем вопрос?

Среда, Март 19th, 2008

В свое последней статье «Куча г. не станет золотом» по ходу обсуждения с ZaQ всплыла одна из больных тем – должности/роли/ответственности. Причем больная эта тема не только относительно IT, но и для любого молодого бизнеса.

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

Я уже задевал эту тему в статье «О разделении обязанностей между технарями и продавцами«, но тут копнуcь слегка глубже.

Проблема с должностями, собственно, состоит из нескольких частей

— люди делают не то, что они должны делать (и мешают этим жить другим)

— люди не делают то, что они должны делать (и из-за этого, что-то идет не гладко)

— люди неправильно распределяют время между несколькими вещами которые они должны делать.

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

Итак, с одной стороны проблема кажется надуманной (особенно для тех, кто с ней не сталкивался) и вроде решение лежит на поверхности «ну блин, сказать людям один раз, чем они должны занимать, а если они не вкуривают, то под зад их пинком». Но тут есть множество подводных камней:

Люди приходят и уходят из компании и то, что вы сказали кому-то год назад новые люди не знают.

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

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

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

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

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

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

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

— вторая вещь, которую нужно сделать, это для каждой должности буквально в пару строк расписать, что человек с этой должностью должен делать и за что отвечать. Например: “Менеджер по продажам отвечает за общение с заказчиками, заключение сделок, сбор пожеланий и проблем и коммуникацию с директором по продажам и техническим менеджером относительно технических вопросов». Это всего лишь пример, в вашей организации вы вполне можете сказать, что он должен отвечать за доставки пива в офис и за контроль наличия туалетной бумаги.

— третья вещь, которую нужно сделать – это написать для каждой должности, кто за нее отвечает. Не беспокойтесь, в начале это может выглядеть примерно так: “Директор – я, Менеджер – я, Программист – тоже я». Собственно, так реально дела и обстоят, когда вы один в фирме.

Что же теперь делать с этой все фигней, которую вы написали?

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

Вообще, не бойтесь менять эту схему, она не высечена в камне. Как раз основная идея, подстраивать ее под ситуацию.

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

Теперь следующий вопрос, зачем столько пурги, вокруг этого вопроса? Как обычно, можно сказать: «очередное бумагомарательство и так все умные люди и все знают, что делать».

Искренне надеюсь, что с вами работают только умные люди. Но, как я писал, проблема состоит в том, что все постоянно меняется и вы сам в том числе не всегда способны уследить, за продажу отвечает Вася (новый директор по финансам, который был директором по продажам) или Петя (новый менеджер по продажам)?

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

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

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

P.S. Особенно эта вся фигня помогает преодолеть проблемы 10-20 человековой компании, когда компания становится слишком большой, чтобы директор во всем участвовал, но еще достаточно маленькой для серьезного распределения по отделам, должностям и т.п.

В поисках нового дома.

Понедельник, Январь 7th, 2008

Уважаемые читатели я извиняюсь, если у вас возникают проблемы с блогом. Единственно, что по этому поводу хочется сказать это #!@$#@ насчет GoDaddy hosting’а.

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

Посему прошу помощи зала. Кто может подсказать, хороший (стабильный) и по возможности не слишком дорогой PHP + MySQL хостинг для переноса туда блога?

Ну и стандартные пару вещей…

Бизнес выводы 🙂

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

Ну и дабы ссылки на только что написанные статьи не уползли за горизонт:

Читайте про программистский синхрофазотрон и про тому кому выгодные плохие estimat’ы.