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

Компанейская архитектура.

Четверг, Сентябрь 18th, 2008

Давно хотел написать о том, как по моему мнению должна быть построена иерархия в компания.
Но, как точно заметил СОТОНА, на идеальный пост времени нету.

Так что буду потихоньку эту тему раскапывать.

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

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

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

CompanyStructure

А теперь, о том, что я имел ею в виду

— Первое и самое основное (того, чего в схемке не указано). У каждой позиции должен быть четкий список обязанностей и ответственности. Директор по продажам не должен садиться подпедалить код,
а технический менеджер не должен мотаться по всему миру собирая у заказчиков требования.
Я кстати об этом писал в статье «О разделении обязанностей между технарями и продавцами.»

— Второе. Это размер фирмы. Естественно, нарисованная фирма скорее выглядит как что-то эдак размером человек 500. Скажем так, многие из этих должностей могут быть объедененны в одном человек для небольшой фирмы. Главное, что можно объеденять должности внутри одного подразделения, но не между ними.

То есть может быть и программист и главный программист в одном лице. И product manager с business director’ом в одном лице. Но уж никак не главный QA и sales director в одном флаконе.

Теперь можно уже и по структуре. Основное, с чего я вообще начал рисовать эту схему с Product Manager’а. Звучит конечно смешно, но это самый главный человек в компании. C одной стороны он находится достаточно низко в структуре, чтобы влиять на детали, с другой стороны достаточно высоко, чтобы выбирать направление. В этому его уникальность и ценность одновременно.

Итак, самая основная его идея в том, чтобы собирать все хотелки сверху (от CEO, от Sales (это скорее сбоку)), идеи о том куда двигаться в будущем (от маркетинка), крики и плевки от заказчиков (через отдел support’а) и пинки от engineering’а. После того, как все собрано — все приоритезируется и выдается вниз engineering’у на исполнение и вверх отчетность о приоритетах.

Замечу, дальше в зависимости от удачности или не удачности приоритезации именно product manager’ов (включая business development director) должны либо гладить по голове, либо гладить утюгом.

То есть к ним идут все ниточки входных сигналов и от них идут все ниточки выходных сигналов. Еще раз замечу, не к CEO, а к ним.

Теперь, расходимся от них концентрическими кругами.

В случае если product  manager’ов несколько — то Business Director как раз должен руководить, тем чтобы ниточки по нужным направлениями шли к нужному product manager’у и в ответ выходили нужные ответные сигналы.

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

Движемся дальше. Когда сигнал опускается до director’а engineering’а — то он обычно заключается в крупных проектах и это уже его дело разбить это напроекты поменьше, раздать менеджерам проектов х контролировать и т.п. В общем-то director engineering’а и project manager’ы это как раз те самые менеджеры среднего звена о которых я писал уже несколько раз.

Дальше движемся вверх по схеме. CEO по большему счету должен быть нужен в фирме для трех вещей

а) В случае наличия инвесторов — общение с ними

б) В случае если он основатель и задумщик идеи — он должен кормить этими идеям product manager’а. Хотя в идеале, тогда он должны перейти на должность Business Development Director и отдать руль CEO кому-то другому.

в) В случае если какая-то ветка работает плохо, разобраться в причине и уволить ее.

Ну и плюс сюда можно приписать воодушивительные выступления перед фирмой.

По большему счету это все, за что он должен отвечать

To be continued…

P.S. Круто… Первая картинка в блоге 🙂

Ракета с помощью молотка и зубила.

Воскресенье, Август 24th, 2008

Что вы скажете человеку, который сам будет строить космическую ракету только с помощью молотка и зубила?

Что вы скажете человеку, который будет хранить 10 гигабайт текстовой информации (по которой надо постоянно искать) в текстовом файле без индексации?

Что вы скажете человеку, который будет вскапывать огород размером в 500 гектар с помощью лопаты?

Давайте угадаю с трех раз… Вы скажете, что это…м…. не лучшая идея.

И что нужно:

а) Добавить новые и более мощные инструменты

б) Добавить новые и более мощные знания как управляться с инструментами

в) Добавить людей на тех задачах с которыми тяжко справиться самому

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

Начинающие менеджеры управляют чаще всего просто применяя здравый, некоторое количество интуиции и субъективную оценку. И на небольших объемах (эдак 5 подчиненных) даже неплохо работает. Потом, количество подчиненных в их иерархии (включая подчиненных подчиненных и т.д.) растет и вдруг все начинает валиться из рук и методы которые работали вчера на 5 людях работают плохо на 15 и не работают вообще на 50.

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

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

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

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

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

Так, что я за то, чтобы устанавливать разумные правило (особенно с ростом компании), я за то, чтобы пересматривать правила, если они не работают и я против того, когда говорят… Да не, мы лучше по старинке, дедовскими методами, лопатой и субъективным мнением будем менеджить компанию.

P.S. Кстати, небольшая рекламная пауза, про которую я забыл. Эти два сайта публикуют мои статьи, за что им большое человеческое спасибо.

Загляните на сайт KakRabota.com.ua. Он посвящен в первую очередь отзывам сотрудников и соискателей о различных компаниях Украины и России, сбору статистики зарплат в разрезе отделов. В разделе форума есть опубликованные вакансии и резюме с возможностью комментировать их или задавать вопросы а так же просто обсудить темы связанные с работой. А также на сайте есть блог разработчиков, на котором вы можете регулярно читать интересные статьи опять же на околорабочую тематику.

А второй сайт — это, сайт www.webdiktor.ru. Это забавный бесплатный сервис по озвучиванию статей. Они меня тоже посчитали и озвучили уже несколько статей вот тут. Так, что если есть люди, которые любят слушать статьи в стиле podcast’ов — заглядывайте туда почаще. Хотя, стиль начитывания статей слегка своеобразен. 😉

Мифология (Наемный рабочий vs Консультант).

Вторник, Август 19th, 2008

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

Итак, капнемся откуда растут ноги (как будто у них есть шанс расти из другого места).

Миф N1: «Наемный рабочий лояльнее».

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

Как по мне, второй тип ухода более лоялен, чем первый. А в остальном, лояльность — это просто  броское слово.

Миф N2: «Наемный рабочий дешевле чем консультант».

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

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

Миф N3: Консультант украдет все ваши знания и продаст их конкурентом.

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

А если смотреть на это чуть с другой стороны. Что мешает сделать это же наемного рабочему? У него что чип в мозг встроен, который запрещает работать с вашими конкурентами?

Миф N4: Консультант всегда ищет дополнительные заказы и работает еще с кем-то.

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

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

Миф N5: Консультанта нужно постоянно тщательно менеджирить, чтобы он делал, то что надо.

Опять же — это не миф. А вот, то что наемного сотрудника можно  оставлять на самотек — это миф. Управлять надо и теме и другими. Если ими не управлять, то вероятнее всего результат будет совсем не то, что ожидался.

Миф N6:  Консультант никогда ни будет что-то улучшать просто так.

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

Хе-хе… Мощно вышло. Чувствую, завтра все кто на найме, придут меня бить 😉

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

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

С удовольствием приму (и допишу) предложенные вами Мифы на эту тему.

P.S. Ссылочка на блог Константина Галайко. Блоггер, программист, да еще и ронин (не смог я обойти последний пункт, не дав ссылку 🙂

P.P.S Миф N7 от Артура Ракицкого. Консультанты не фига не хотят делиться знаниями, в то время как наемный рабочие с удовольствием делятся информацией.

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

Проблема тут не в деньгах, а в головах. Если человеку хочется кого-то обучать, то он это будет делать, если не хочется — не будет.

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

Миф N8 (от technoman): Консультант это бизнесмен и человек который хочет заниматься бизнесом. поэтому он редко рассматривает возможность долгосрочной работы на одном месте

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

То есть получается, что для наемных работников мы говорим: «да мы им можем даже на головы нагадить, а они останутся», а для консультанта почему-то так делать боимся.

Как я писал уже в мифе N4. И те и другие ищут. Одни просто ищут более активно. Ну блин, так на то работодатель должен быть с головой, чтобы расчитывать, что средняя длина сотрудничества с наемным — 2-3 года, с консультантом 1-1.5 года.

Миф N9 (от Анонима 🙂 Наёмный работник более лоялен к смене проекта, в котором учавствует. Например, если работодатель считает что один проект у него важнее остальных, то начинается перемещение людей. И аргумент, что КПД упадёт в разы его (работодателя) не вдохновляет :(((.

Не совсем понял к чему тут КПД относительно лояльности.  И это вообще сказочно развенчивается. Консультанты чаще всего сильно ориентированны на деньги и готовы делать даже не самые интересные проекты (особенно учитывая, что оплата у них вполне таки хорошая). Поэтому он особо не кислится, если его переместили на неинтересный проект. А вот как раз наемный работник, сразу впадает в хандру на «плохом» проекте и начинает оглядываться куда-бы свалить от этого плохого проекта.

Заставь работника трудиться на тебя всю жизнь.

Пятница, Август 8th, 2008

Сегодня имел длинную и продолжительную беседу с нашим VP Engineering’а о том как сделать так, чтобы люди в фирме оставались дольше.

Интересно, что лет 7 назад у меня была похожая беседа с владельцем той фирмы в которой я работал.

Ну и в своей фирме тоже об этом постоянно приходилось беспокоиться.

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

В общем, по ходу обсуждения пришли к нескольким выводам

— Рост.

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

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

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

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

—  Отсутствие фигни

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

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

— Эффект звездного коллектива

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

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

Хм… Вроде, описал все, что мы говорили.

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

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

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

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