Что вы скажете человеку, который сам будет строить космическую ракету только с помощью молотка и зубила?
Что вы скажете человеку, который будет хранить 10 гигабайт текстовой информации (по которой надо постоянно искать) в текстовом файле без индексации?
Что вы скажете человеку, который будет вскапывать огород размером в 500 гектар с помощью лопаты?
Давайте угадаю с трех раз… Вы скажете, что это…м…. не лучшая идея.
И что нужно:
а) Добавить новые и более мощные инструменты
б) Добавить новые и более мощные знания как управляться с инструментами
в) Добавить людей на тех задачах с которыми тяжко справиться самому
Итак, теперь возвращаемся к IT. Я начинал эту тему уже в статье Менеджер с линейкой в голове и она снова всплыла в прошлой статье в комментариях.
Начинающие менеджеры управляют чаще всего просто применяя здравый, некоторое количество интуиции и субъективную оценку. И на небольших объемах (эдак 5 подчиненных) даже неплохо работает. Потом, количество подчиненных в их иерархии (включая подчиненных подчиненных и т.д.) растет и вдруг все начинает валиться из рук и методы которые работали вчера на 5 людях работают плохо на 15 и не работают вообще на 50.
Дело тут в том, что те молотоки, текстовые файлы, лопаты были хороши только для маленьких задач. Для больших задач, нужны другие методы.
Почему вы думаете столько говорят о построение разумных процессов в компании и постоянном их улучшение (а-ля CMMI, TQM и т.п.)? Именно потому, что они и есть этот более мощный инструмент.
Скажу сразу, опять же, мощный инструмент не всегда имеет смысл. И то, когда его пытаются переть куда не нужно, рождает легенды о том, что эта громоздкая никому ненужная фигня, которую придумали одни менеджеры, чтобы оправдать ничего не делание перед другими. Все должно применяться к месту.
Ситуация такова, что на больших размерах организации, все превращается в непрерывный испорченный телефон. И если ты сказал А, то большинство услышат Б, некоторые В, а будут и те кто ничего услышат . И единственный метод с этим бороться стандартизировать и закрепить то, что можно (и нужно) закрепить.
И если вчера вы лично хлопали Васю по плечу и говорили, Вася бросай играться, то завтра нужно принимать всеми ненавистные правила, чтобы играться в фирме с 9 до 5 запрещено.
Однако, есть еще одна не менее важная вещь. Важны не сами процессы и правила, а то, чтобы были люди, которые их имели право пересматривать и таки пересматривали их. Основная идея, не просто что-то водворить, а еще важно смотреть, какие результаты оно принесло. Например тоже правило не играться, может обернуться шквалом критики и тучей уходящий программистов, просто потому что это был устоявшийся в компании метод развлечения, а тот Вася, который упоминался раньше, просто игрался слишком много.
Так, что я за то, чтобы устанавливать разумные правило (особенно с ростом компании), я за то, чтобы пересматривать правила, если они не работают и я против того, когда говорят… Да не, мы лучше по старинке, дедовскими методами, лопатой и субъективным мнением будем менеджить компанию.
P.S. Кстати, небольшая рекламная пауза, про которую я забыл. Эти два сайта публикуют мои статьи, за что им большое человеческое спасибо.
Загляните на сайт KakRabota.com.ua. Он посвящен в первую очередь отзывам сотрудников и соискателей о различных компаниях Украины и России, сбору статистики зарплат в разрезе отделов. В разделе форума есть опубликованные вакансии и резюме с возможностью комментировать их или задавать вопросы а так же просто обсудить темы связанные с работой. А также на сайте есть блог разработчиков, на котором вы можете регулярно читать интересные статьи опять же на околорабочую тематику.
А второй сайт — это, сайт www.webdiktor.ru. Это забавный бесплатный сервис по озвучиванию статей. Они меня тоже посчитали и озвучили уже несколько статей вот тут. Так, что если есть люди, которые любят слушать статьи в стиле podcast’ов — заглядывайте туда почаще. Хотя, стиль начитывания статей слегка своеобразен. 😉
Какой-то не очень хороший показатель. У менеджера не должно быть больше 7 подчиненных (норма управления), а про подчиненных подчиненных он знать не должен — для этого подчиненные менеджеры есть.
Показатель, вполне себе. Мы же не говорим, о его прямым подчиненных. Их вполне может быть 5 человек. Но у тех подчиненных есть отже свои подчиненные.
Важно все таки считать, на какое количество людей влеяют его решения.
Нельзя же сказать, что у CEO всего 3 подчиненных — CFO, CTO и какой-нибудь VP Sales. Его иерархия подчинения — это вся фирма.
Нельзя сказать, что в подчинении трое, только потому, что это игра слов, которая придает CEO еще большую окраску власти. Ведь по сути СЕО не ходит по компании и не раздает указания каждому, а на прямую только трем людям, а они дальше раздают и т.д.
Да… Наученный своим опытом (не только горьким), на заявленный в начале вопрос я бы однозначного ответа не дал. Нужна дополнительная информация. Может быть, что обычный F3 в Notepad’е (сразу после того, как тот научился работать с более чем 64 килобайтами) будет вполне достаточно? Может быть, что вскапывание идет не ради вскапывания всех 500 гектар, а ради фитнеса? 😉
Точно также и управление людьми с помощью инструментов… работает далеко не всегда. Слишком много у меня было на глазах ситуаций, когда хороший человек превращался в отвратительного руководителя из-за увлечения инструментами. Да, его руководству все нравилось: у него всегда были на готове таблички с перформансом каждого из подчиненных сотрудников, состоянии всех вверенных ему проектов и т.п… Но… Круглые сутки сидел он за своим столом уткнувшись в монитор и пообщаться с ним возможность была пару раз в год — на годовом «ревью» и на презентации про нововведения в процессах…
Как я и писал — везде нужно не перегибать палку.
Между прочим, если у него есть постоянно было точное состояние дел на фирме — я бы сказал, уже пол дела сделано.
Что нехорошо (и что собственно надо было чинить), то что исчезли нормальные коммуникации с этим менеджером. Все таки менеджерство — это не только сбор данных и годовые ревью, но и решению текущих проблем.
А насчет 500 гектара для фитнеса. Опять же, есть более эффективные методы фитнеса, чем стояние раком по палящим солнцем по 8 часов подряд 🙂
Несколько удивил настолько плавный переход от инструментов к процессу. Для меня это вещи практически взаимоисключающие.
Вот есть инструменты. Молоток, пила, линейка. Они у меня висят на поясе. Я выполняю какую-то задачу и в процессе самостоятельно принимаю решения, какой инструмент когда использовать. Можно было бы обойтись кулаком, зубами и пальцами, но иструменты мощнее, проще, удобнее. Еще я люблю сравнивать инструменты со спеллами (а я маг, использующий то или иное заклинание) или со словами (а я писатель, способный заставить читателя плакать от тоски — или от смеха — путем правильной комбинации слов). Но я решаю, что я ими сделаю и зачем.
А вот есть процесс, воркфлоу, фреймворк. Это практически двоичное дополнение до инструментов. Т.е. все решения приняты (и навязаны), осталось их только выполнить. Если повезет и к процессу доложат инструментов — то выполнять буду инструментами. Если не повезет, то буду выполнять чьи-то решения кулаком, зубами и пальцами. Не важно, какие инструменты у меня есть в наличии, процесс я должен исполнить один и тот же. Не важно, что если бы я мог сам принимать решения, то я бы нашел другой, более гуманный путь к цели.
А с другой стороны, так если подумать, то процессы одного уровня управления вполне могут являться инструментами другого. Т.е. запуская процесс «Активация нового проекта», менеджер просто пользуется им как инструментом, чтобы достичь какой-то своей цели (например, выраженной в терминах доли рынка). То, что этот процесс может оказаться негуманным, если посмотреть на него снизу (например потому, что загоняют насильно работать в команде с неприятным человеком), так это менеджера, получается… не волнует?
Почему не волнует? И можно ли предоставить инструменты менеджеру, не загоняя подчиненных в чуждый им процесс? Я честно пытаюсь разобраться…
Так пытаюсь разделить на состовляющие
а) Насчет плавного перехода.
Когда пользуешься молотком — то чаще всего процесс находится в голове. Когда пользуешься строительным краном, то приходится чтобы процесс находился изначально вне головы, так как нужно тщательная согласованность этого инструмента с остальными.
Поэтому, все же стоит говорить о связи инструментов и процессов.
б) Насчет того, что процесс — является инструментом. Так оно и есть, процесс это всего лишь
определенный инструмент.
Насчет загоняния работаь в команде с неприятным человеком. Если вероятность вашего ухода умноженная на потенциальные потери от вашего ухода меньше, чем дополнительная полученная прибыль/часть рынка и т.п. То в общем-то менеджеру или владельцу в конечном счете может быть и все равно.
Вопрос можно ли было вас не загонять? Возможно и можно было, это надо в каждой ситуации смотреть. Хотя опять же, если не загоняние вас займет больше времени и ресурсов, чем дополнительная работоспособность от вас полученая, то опять же, смысла НЕ загонять — не будет.
«Когда пользуешься строительным краном, то приходится чтобы процесс находился изначально вне головы, так как нужно тщательная согласованность этого инструмента с остальными.»
Когда в Doom II в тимплее пользуешься BFG (извините, давно не играю, более свежего примера нет), то никакого внешнего процесса особо и не нужно. Напарники буквально за минуту научаются ховаться, услышав типичный посвист. Что лишний раз доказывает, что обучать людей можно и без прописывания должностных инструкций и многостраничных процессов 🙂
Проблема кранов заключается в том, что инструмент дорог и опасен в использовании по сравнению с BFG, и undo не сделаешь. В софтописательстве, по сравнению со стройками, таких инструментов сильно меньше. Должно и процессов быть поменьше, не так ли?
Что касается загонять или не загонять. По-моему, процесс, в который нужно загонять, просто не верен. Это такой верный признак, как синтаксическая ошибка в коде. Такой процесс и после успешного «загона» прибыли не принесет.
Причем у меня есть такое подозрение, что делают такие процессы в основном люди, которые свято уверены в том, что работа — не отдых, и просто должна приносить боль и страдания. Типа, если не страдаешь, значит не работаешь. Ну, есть такой комплекс у некоторых людей 🙂
Потому что есть более веселые процессы, тот же Scrum или MSF. Где каждое дисциплинарное ограничение тщательно обосновывается, а все, что можно, вынесено «на свое усмотрение».
>Когда в Doom II в тимплее пользуешься BFG (извините, давно не играю, более свежего >примера нет), то никакого внешнего процесса особо и не нужно.
Ничего, я тоже в более новое ничего не игрался. 🙂
Как вы точно заметили, с краном все поопаснее, поэтому тоже так не выйдет.
В софте, можно только в коде undo сделать. А вот в бизнесе undo не сделаешь, просранные деньги и заваленный проект не «откатишь» назад.
>Что касается загонять или не загонять. По-моему, процесс, в который нужно загонять, просто >не верен. Это такой верный признак, как синтаксическая ошибка в коде. Такой процесс и >после успешного “загона” прибыли не принесет.
Это _НЕ_ правильная идея.
Я писал вот тут: http://victorronin.com/2008/07/15/biznes-eto-vam-ne-xixanki-xaxanki/
Очень хочется, чтобы бизнес был белый и пушистый. Он на самом деле не такой.
Есть множество процессов, в которые по началу надо загонять.
Кстати напомню, не так давно программистов надо было загонять пользоваться системами контроля версий. Тогда плевались, сейчас без этого никто не работает.
>Причем у меня есть такое подозрение, что делают такие процессы в основном люди, >которые свято уверены в том, что работа — не отдых, и просто должна приносить боль и >страдания.
Работа может быть чем угодно.
Бизнес — это метод получения денег. Очень здорово, если это сопровождается весельем. Чаще это сопровождается рутиной.
>Потому что есть более веселые процессы, тот же Scrum или MSF.
Скрум тоже является процессом. Причем в нем тоже есть железные вещи и вещи, которые более мягкие.
Насчет «веселые процессы». Как я и писал, если не уменьшая веселость бизнес будет получать свою прибыль — такие процессы используют. Если веселость вдруг уменьшает прибыль, то веселость порубят.
В общем основная идея, на секунду вылезти из своей кожи и заглянуть в мозг всем остальным участникам — менеджерам, топ-менеджменту, владельцам, инвесторам и т.п.
Если Scrum весел для одних, это еще не значит, что он весел для других. Идеального для всех процесса не бывает.
Чаще всего владельцы (кроме lifestyle business) пытаются настроить так, чтобы оно максимизировало именно прибыль.
«Очень хочется, чтобы бизнес был белый и пушистый. Он на самом деле не такой.
Есть множество процессов, в которые по началу надо загонять.»
Какое-то слишком сильное обобщение, Вам не кажется? Я могу судить про бизнесы размером до 20 человек, порядка 5000 человек и в промежутке между ними. Так вот, именно те, что в промежутке, как раз могут похвастаться своей выдающейся негуманностью.
В мелком бизнесе все на виду, все отвечают за все, процессы нужны только самые общие, атмосфера семейная. Да Вы и сами много про это писали.
В крупном бизнесе не знаешь никого в лицо, процессы везде и всюду, но там нарабатывается достаточно прибыли, чтобы доходили руки внедрить процессы и для самого нижнего уровня иерархии, которые там, внизу, окончательно становятся инструментами. Например, инструмент «формуляр HW-08» можно применить, чтобы пришли, забрали старый и выдали новый компьютер. В итоге исполнители не только много работают НА процесс, но и могут сами воспользоваться процессами.
А в среднем бизнесе руки доходят только до высшего и среднего менеджмента (внедрение процесса начинается почему-то сверху). В результате исполнители с одной стороны уже работают на процессы, спускаемые сверху, а с другой стороны вынуждены бороться с окружающим их бардаком, оставшимся еще со времен мелкого бизнеса. Когда нет процессов для получения техники, мебели, рабочих инструментов, информации (банально, где какие серверы в локальной сети, и то приходится узнавать случайно по слухам, т.к. админы не ведут авторитативной директории). Нет процесса для годового разговора с менеджером и не понятно, что нужно сделать, чтобы продвинуться по карьере, так как нет формального процесса управления карьерой. И самое главное, цели и задачи фирмы не поставлены формально в виде общедоступного документа, поэтому нет понимания, на каком основании сверху спускаются именно такие процессы и какие проблемы они призваны решать. Впрочем, Вы про это тоже много и правильно писали.
А те процессы, которые в среднем бизнесе уже есть, они зачастую такого качества, что лучше бы их и не было. У нас, к примеру, с самого верха спустили Team Foundation Server. Те, кто спускал, ни секунды с этой системой не работали и не работают, и решение приняли из соображений, которые мне до сих пор не ясны. Как система контроля версий оно еще неплохо (хотя есть и сильно лучшие системы, но к сожалению не в мэйнстриме). А вот как баг трэкинговая система, это просто шняга. Любая, даже бесплатная веб-прилада типа багзиллы покроет в этом смысле TFS как бык овцу. Не говоря уже о Jira или Mantis. В результате могу наблюдать, что группы в фирме либо баги по нормальному не отслеживают, либо стабильно проваливают проект за проектом, работая строго «по процессу». Ну и кому такой «процесс» помог? Конкретно тому менеджеру, что ввел эту систему. Его повысили и сделали совладельцем фирмы. Впрочем, про карьеры плохих менеджеров Вы тоже уже написали 🙂 Мне бы и не жалко, если бы не приходилось сидеть по уши в отходах их жизнедеятельности.
Помоему два первых созданных процесса должны быть (прошу прощение за тавтологию):
1. Процесс анализа эффективности процесса («дебаг»)
2. Процесс изменения процесса
3. Процесс информирования о процессах
И ещё было бы неплохо постоянно уделять внимание оптимизации процессов.
Согласен на 100%.
Правда есть единственная заковыка. Чаще всего в самом начале еще не совсем понятно, нафига оно нужно и с чем его едят. И поэтому люди редко могут взглянуть на это сверху, чтобы сформулировать сначала эти три пункта, а потом уже делать все остальное.
Линк на «как-работа» битый.
спасибо, пофиксил.
озвучка статей отличная идея