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

Март 19th, 2008

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Куча г. не станет золотом.

Март 17th, 2008

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

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

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

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

P.S. Кстати, это непосредственно связано со статьями:

Не позволяйте планке падать

Ремонт нельзя остановить, его можно только закончить.

Ford против BMW, плюс оптимизация.

Март 17th, 2008

В куче своих статей я говорю об оптимизации разнообразных процессов. Например, тут:

Директор, дай рублик на ремонт.

Стоимость бага.

Работать 8 часов вредно.

Программистский синхрофазотрон.

Обучение мыслить на шаг вперед.

Собственно, а зачем она нужна?

Начну, с одной недавно произошедшей со мной истории. Я езжу на Ford’е Focus, достаточно старого по США понятиям 2000 года. И вот, как-то я выезжаю из двора, и прямо за мной выезжает навороченный такой спортивный BMW (увы, я не рыбак, модель не скажу). Ну и этот BMW паля колеса с пробуксовкой уносится в сторону светофора. Через где-то пол минуты я подъезжаю и обнаруживаю его стоящим на перекрестке (красный свет) в полосе за пятью машинами, сам же пристраиваюсь в соседнюю полосе за двумя авто (то бишь в результате я нахожусь впереди него). Свет переключается на зеленый, опять у него горят колеса, он уносится за горизонт, только для того, чтобы через 30 секунд я обнаружил его стоящим на следующем перекрестке. На этот раз в поворотной полосе с десятью машинами, сам я предпочел стать в поворотную полосу с тремя машинами.

А теперь, к чему это я… Абсолютно понятно, что в большинстве случае лучше быть компанией эквивалентной спортивному BWM и рвать вперед. И понятно, что ему просто не повезло, что светофоры были красные, не было бы светофоров и ограничений, при всем желании за ним было бы сложно угнаться.
Вопрос состоит в том, что не все
IT компании являются эквивалентом спортивного BWM, а большинство как раз являются компаниями, эквивалентными хорошей рабочей лошадке а-ля средней давности Ford.

И соответственно, для того, чтобы не отставать от других нужно, что

А) Прокладка между сидением и рулем работала хорошо

Б) Автомобиль был на ходу, масла заправлены и шины лучше, чтобы были не лысые.

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

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

Директор, дай рублик на ремонт.

Март 12th, 2008

Представьте себе, идет серьезные переговоры в кабинете директора. Приехали большие потенциальные заказчики. Без стука, заходит завхоз в грязных сапожищах, ничего не спрашивая, подходит к директору и заявляет: “Э… тут ручка поломалась, нужна десятка, чтобы купить новую”, директор извиняется перед заказчиками, начинает рыться в портмоне, находит десятку, отдает завхозу. Через десять минут тоже самое повторяет с фразами «Закончилась туалетная бумага» или еще чего-нибудь. Ну, как вы догадываетесь переговоры проходят, ну очень успешно и больше о этих заказчиках никто ничего не слышал.

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

Как вы считаете, должен ли директор:

Тратить свое время на выдачу такой суммы лично

Контролировать траты таких размером

Прерываться, на решение вопросов данного уровня

Я искренне надеюсь, что вы ответили «нет».

Теперь другой вопрос, почему, собственно, он не должен этого делать? Да потом, что час работы директора, скажем условно стоит $60/ч (это не его ЗП, а скорее стоимость его воздействия на фирму). Так, вот для того, чтобы решить даже такую мелочь, он отвлечется скажем на 5 минут (это еще хороший случай, так как, если мысля думается и ее сбить, то она долго может не возвращаться). Как результат, он потратит $60/ч*5/60 = $5, для того, чтобы даже не сэкономить, а просто выдать $2. В результате туалетная бумага, купленная завхозом, по цене будет ближе к золотой парче 🙂

Соответственно напрашивается несколько выводов:

— Обычно у завхоза на руках должны быть какие-то деньги, чтобы он не бегал за каждым рублем.

— У него есть предел до который он имеет тратить не спрашивая (например, $30 в месяц).

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

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

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

Забавно выходит, то, что программист вам может напортачить в проекте на тысячи долларов и это нормально и такой риск мы можем принять, а вот позволить программисту купить переходник самому – это же блин опасно, а если все повадятся фигню покупать и обанкротят фирму?

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

Идем дальше, добираемся до менеджеров. И вот тут мысль спориться окончательно, почему-то, если программист имеет право тратить $5/месяц без запросов вперед, то менеджеру могут выделить ну дай бог $7/месяц, ну в самом крайнем случае $10.

Опять же, менеджер уже способен запороть не просто один проект на пару тысяч, а штучки три проекта, которые на нем висят, включая работу еще штук 5 программистов, которые ему подчинены. Но опять же выделить ему лимит в $50/месяц…. у… не, страшно и низзя.

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

Как мне кажется, примерная формула предела для большинства IT работников, что человек имеет тратить в месяц до 1% * количество людей в иерархии подчиненных ему (включая самого человека) * на свою ЗП. Для программиста — это 1% от его зарплаты, для менеджера младшего менеджера с 5 подчиненными получается 6% от его ЗП, для старшего менеджера – 5 прямых подчиненных у каждого из которых 5 своих – 26% от ЗП.

Замечу, это не ограничения сколько он вообще может потратить, это ограничения сколько он может тратить и оповещать об этом пост-фактум.

Завхоз в этом смысле исключение, так как заранее известно, что ему понадобиться больше, чем 1% от ЗП.По этому поводу ему можно/нужно выставить сумму прямым образом (без учета формулы). Кстати, он и не IT работник, так что формула к нему пожалуй еще и поэтому поводу не применима.

P.S. Пост основан на реальных событиях. Это просто меня убила сегодня ситуация, когда менеджер у которого суммарно в иерархии порядка 30 человек (с зарплатами от $4k до $8k в месяц) пошел к своему начальнику, чтобы тот одобрил трату в $1.2k.

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

P.P.P.S. После полторы недели, меня достало ожидание, пошел к фин. директору и вопрос был решен в течении 5 минут. Замечу, что на разные разговоры и обсуждения уже было потрачено часа полтора.