Pull to refresh

Comments 25

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

Лечится пилюлей «Но мы же говорили!» :)
Никогда не работал в гос. структурах, но встречался с подобным поведением на всех управленческих уровнях в совершенно коммерческих конторах. Отсутствие лидерских качеств не является условием для этого. Руководитель, который не является «лидером», но при этом в состоянии банально сопоставить факты и причинно-следственные связи, вполне может к этому не скатиться.

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

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

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

Но я не уверен, что руководитель поймет, почему он остался без сотрудников…
А ему и не нужно понимать. Если у него не принципиально не получается руководить, пусть идет учиться, или обратно, погонять торговок овощами на рынке.
Пардон, одно «не» — лишнее, перед «принципиально».
Интересные примеры про язык.

Однако многие выдающиеся предприниматели считают, что оперировать финансами или вникать в ежедневную рутину зависит от собственного склада характера и стиля управления. Например, Евгений Чичваркин (Евросеть) постоянно ездил по своим магазинам, чтобы на месте разобраться, что происходит. А вот его коллега Максим Ноготков (Связной), насколько мне известно, предпочитал управлять из своего кабинета, так как получал информацию через ИТ систему. А исходя из Вашей статьи получается, что первый стиль управления в корне неправилен.
Да, неправилен. Вернее он присущ определенному типу людей, которые называются «Сделай сам». Он не может делегировать подчиненным ряд своих функций, или не доверяет исполнителям, предпочитая браться за все самому. Но это только усугубляет ситуацию с управлением. С ростом количества точек продаж, он перестанет управлять вообще, только и занимаясь мелкой рутиной.
Это точно, я думаю в любой организации есть такой менеджер, и не один. Но, на мой взгляд, вы забыли упомянуть ещё одну причину — ему просто тупо нравится ездить по своим магазинам. И он не может отказаться от этого.

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

А один знакомый руководитель целого подразделения мало того что детально разбирается в каждом своём проекте, так ещё и интервью по технологии проходит, и кодит. Стоит ли говорить об успешности того, ради чего он занимает эту должность?
«Добрый совет всем обездоленным и угнетенным работникам. Ваш менеджер — результат вашего труда над ним. Не бойтесь коллективно исправлять его недочеты.» — золотая фраза. При условии что менеджер адекватен конечно, готов учится и признавать свои ошибки (хотя бы для себя). Менеджеры тоже люди, они тоже ошибаются, и они не телепаты. Если работник считает что менеджер ошибся, или ошибается систематически, работник должен обьяснить ему это прямо, а не тихо злится.

Например типичная, и очень распространненая ошибка, добавлять фиксированный процент (очень любят цифру 25 или 30%) к любой оценке разработчика. Таким образом якобы получается реальная оценка, так как «разработчики всегда недооценивают задачу». В реальности разработчик лучше знает погрешность своей оценки, и менеджеру стоит спросить у него, сколько тут рисков. А потом уже, если есть возможность, добавить свои риски, связанные с качеством оценки для этого разработчика или с процессами о которых разработчик имеет мало информации. Но как же, во всех (ну многих) книжках пишут 30% добавляем и все, хотя на самом деле иногда достаточно 10% а иногда и 50%. В результате то работники без дела сидят, из-за зря добавленного риска, то (что хуже) срывают сроки так-как риски вот на эту задачу нужно было поставить больше, но этого менеджер позволить себе не мог, так как неоправданные риски на другие задачи сьели запас, или просто не стал этого делать. Злость и раздражение друг на друга и ничего хорошего.

«Воспитывайте» своих менеджеров (если они адекватны конечно) и всем будет хорошо. Хотя не стоит забывать что решение, в тех вопросах которыми занимается менеджер, все-же за ним, так как он отвечает, без крайностей. Ну и менеджеры должны обучатся без крайностей, понимать что разобраться в вопросах программирования на уровне разработчика они все равно не смогут, банально времени на это не хватит, так что вопросы типа: «а как это сделано (или будет сделано)?», «а почему такая оценка?» должны появляться в крайних случаях (если менеждер конечно уже не разбирается в этих вопросах не хуже разработчиков, т.е. фактически недавно сам занимался разработкой).
    Однажды, в одной компании я работал ПМ-ом. Причем устраивался я на должность ПМ-а, а руководство компании сказало, что нам нужен еще и программист, поэтому будешь либо совмещать и работать, либо давай до свидания! Был кризис, работы не было и выбирать не приходилось (к тому же речь идет про регион). Руководство, в лице генерального директора, который до этого занимался совсем другой деятельностью, что то в сфере строительства, контролировало все. Мало того, генеральный еще и давал временные оценки. К примеру, необходимо создать модуль, который будет производить некие операции с базой и красиво с графиками выдавать результат. Я опрашиваю людей, никакого SCRUM-а и Planning Poker -а не было, просто каждый разработчик говорил, что и как долго он будет делать. Я умножал эту оценку на некий коэффициент (не 30%, этот коэффициент основывался на отклонении в прошлых оценках разработчика, от реальных данных, и со временем я стал попадать «точь в точь»...) и передавал эти данные генеральному. Они ему не нравились, и он говорил, что нужно сделать к примеру за 10 дней, а не за 20 и никакие объяснения не помогали. Мало того, он также влиял на стоимость контрактов. К примеру заказчик формирует задачу, я делаю предварительную оценку времени, и следовательно бюджет на проект, говорю мол, так и так, это будет Х дней и Y денег, на что мне руководство говорит, что за Y денег заказчик не будет заказывать у нас, так что я запрошу у него Y/3, а ты уж сделай так чтобы мы успели… И мы соответственно не успевали, как бы я не старался. Руководство негодовало, лишало премий, делала выговоры, но как говориться, если беременная женщина должна родить спустя 9 месяцев, то что бы ты не делай, как не старайся, раньше она не родит, а если и родит, то дитя будет с серьезными проблемами или мертворожденным.

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

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

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

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

Над проблемой я задумался тогда, когда не прошел собеседование. От меня хотели, чтобы я был «руками», а я показал, что готов общаться только на языке «финансов». Уверен, что именно это и испугало потенциальных работодателей, потому что я был в их глазах конкурентом, а не профессионалом, которому можно доверить производство.
Воспитывать менеджеров — это сильно сказано. Обычно менеджеры сами часто «от сохи», и сами немало знают о том, что и как надо. Я бы сказал не воспитывать, ибо это чревато конфликтами (каждый должен делать свою работу), а помогать им. Вот это вот «выдавать оценки периодами» — очень расслабляет исполнителей. Менеджер поставит максимальную, допустим, оценку времени, а если разработчик её превысит? А он скорее всего её превысит, есть такая штуковина как «Студенческий синдром», тем более что и мотивации сделать быстрее при таких оценках нет. А в результате по шапке прилетает менеджеру.

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

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

Я когда-то тоже пытался указывать своим менеджерам на ошибки, ни к чему хорошему это не приводило. А когда стал помогать им (искренне) делать их работу, и сделал всё, чтобы быть «без сюрпризов» (а это руководство меньше всего любит, и чаще всего за это увольняет) — отношения улучшились в разы.

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

Если менеджера воспитывают, то ему стоит задуматься, что он делает не так. Если он не хочет задумываться, его не стоит держать в компании.
Я вот много слышал и читал о Менеджере, который ведет вперед, и «управляет людьми», и вообще просто царь Леонид с тремя сотнями спартанцев (что самое забавное, много компаний себе такого кудесника-пассионария хотят, но вот видели ли?). Но сколько ни сам не работал, ни сколько видел менеджеров — все как-то более прозаично. А именно — «подопечные» либо хотят сделать чересчур хорошо, но долго, либо хотят сделать быстро, и как получится (и всегда с доплатой за переработки). Руководство же продает уже посреди срока еще не сделанный продукт.

А куда деваться менеджеру? С него сверху трясут «побыстрее!», снизу трясут «помедленнее!», как-будто от него зависит скорость. Содержание проекта, иногда (конечного) продукта — да, зависит, а скорость — нет. Скорость зависит от мотивации команды, и если быть точнее, от её ключевых фигур — которые определяют скорость. А вот поскольку проект — система не замкнутая, и у этих самых «ключевых фигур» (чаще всего тимлидов) есть какой-то свой корпоративный бэкграунд и текущие отношения с другими руководителями — то всё часто снизу переводится в плоскость личную («ты — такой» или «ты — не такой», «а вот был такой»). Это как раз и разрушает команду — личные оценки чужого профессионализма. Особенно при разговорах в курилках и на кухнях.

Я же сторонник подхода профессионального — когда nothing personal, и каждый отвечает за свою зону, а непокрытые кусочки — закрываются денежной мотивацией за достижение целей проекта. Менеджер отвечает за достижение конечного результата, но в рамках тех ресурсов, инструментов и полномочий, что ему доступны. Если например заменить медленного исполнителя некем (бывает и такое, и нередко), а он срывает сроки, то в данном случае перенос ответственности — вполне законное дело (если конечно не менеджер его принимал). Нельзя говорить, что менеджер отвечает «за всё» — людей готовых к подобному не хватает надолго, им ведь тоже нужна предсказуемость, или же они не могут охватить все риски — им просто не дают столько денег и времени.

Резюмирую: хорош тот менеджер, который вовремя правильно осветит руководству ситуацию на проекте, найдет ошибку в плане (заранее или как минимум постфактум), и предложит некоторые решения — на «сейчас» и на «вообще».
Перенос ответственности — путь к разрушению. Если вы не в состоянии, как менеджер, найти подходы к своим подчиненным, то зачем свои проблемы перекладывать на работника? Он не виноват, что менеджер не учел скорость работы данного человека, что вовремя не перераспределил его задачи между теми, кто может спасти ситуацию, что не пошел к руководству обсуждать превышение бюджета. Пять лет назад я тоже думал, что виноваты все вокруг, кроме меня самого. Теперь я считаю, что рабоников вообще нельзя упрекать в отсутствии результатов, и тем более, перекладывать на них ответственность.
Я говорю не о переносе скорее, а о изначальном разделении, и том, что следует ждать от менеджера. Пять лет назад я тоже думал, что я менеджер, и ответственнен за всё в проекте.
Теперь я думаю что есть такая штука, как корпоративные «активы», которые не в меньшей степени определяют успех проекта, и поэтому ждать чудес от менеджера не стоит, выше компании не прыгнет.

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

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

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

Ну и заодно, если вас коробит слово «воспитывать», замените его на «обучать». Я не хотел никого обидеть этим словом, мысь была совершенно в другом.
Вы (и s0rr0w) поймите меня правильно.

Я не говорил, что менеджер должен там все пробрасывать, хотя и не исключаю таких случаев — они происходят когда менеджер только въезжает в вопрос обычно. Точно также я и не говорю, что менеджер — отвечает за абсолютно всё в проекте. Если бы за все факапы команд наказывали бы только менеджеров — никто бы не работал менеджером.

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

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

Еще рекомендую ознакомиться со стандартом в области оценки менеджеров проектов, основанных на их практике (измеряемых практикой компетенциях). Он вроде и не стал глобальным, как задумывалось, но тем не менее попытку засчитать можно.
www.build-project-management-competency.com/wp-content/uploads/2009/12/GAPPS-PM-Competency-Standards.pdf
Вы абсолютно верно говорите, особенно про золотую середину.

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

Если менеджер боится ответственности, то он будет строить процессы, которые как можно больше будут снимать с него проблемы. А кто будет получать шишки? Работники. Но в чем они виноваты? Что менеджер не подносил патроны, и из-за этого никто не стрелял? Или в том, что он не смог вовремя сориентироваться в проблемах?

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

Под моим «не ждать чудес», конкретизирую, имеется ввиду что если руководитель менеджера сам не видит возможности вытянуть проект, то и от менеджера ждать этого — как ждать чуда. А чудеса случаются раз, может два, но не могут случаться постоянно.

Конечно, в случае работы с командой — менеджер должен подносить патроны, обеспечивать подчиненных всем для продуктивной работы (если правильнее говорить — проект ресурсами). С этим я не спорил. Но насчет менеджмента скажу так — почему компании тогда так не живут, без менеджеров? Потому что конкурентоспособной она будет недолго. Все дело как раз в предсказуемости, которую они должны обеспечить, однако всякая среда или задача являются рискованными, и моя мысль в том, что некоторому уровню ответственности (и вознаграждения) должен соответствовать некоторый уровень риска. Если компания не предпринимает усилия по снижению этого риска, то в чем выгода PM'у брать на себя лично ВЕСЬ риск проекта? В последнее время, тенденции в отрасли таковы, что PM'ы получают за свою ответственность и за риск, который принимают на себя, деньги не большие, а то и меньшие, чем разработчики. Но даже не в деньгах дело, дело в том, что на мой взгляд, работа должна быть понятной не только программисту, но также и менеджеру, а иначе не стать ИТ промышленностью — если от проектного менеджера ждут всего-всего-всего — то удовлетворительный результат недостижим. Компания должна управлять рисками не меньше, а то и больше, чем проект (потому что проект — всего лишь часть компании, и то временная).

Вобщем не знаю кто как, а я сталкивался с завышенными ожиданиями относительно проектного менеджмента. Вот «он придет и молча поправит всё» ((с) Гребенщиков), а то что завели проект или команду в глухую жопу, так это теперь чужие проблемы. Всё о чем я говорю — решается, решается Офисами Управления Проектами, оценкой рисков, планированием портфелей (проектов, ресурсов, активов, целей). Но это тема для отдельного разговора.
Риск проекта никогда не перекладывается полностью на ПМа. Это не его зона ответственности, а руководителя.

Sign up to leave a comment.

Articles