?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Еще один открытый тренинг, 21-22 ноября, Москва

Posted on 2009.11.08 at 03:30
Tags:
Как и в прошлый раз в сентябре, 21-22 ноября я выступаю приглашенным гостем на тренинге Саши Орлова, Москва. “Управление командой” и “Карьера менеджера”.

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

http://gaperton.livejournal.com/38349.html
"Есть две интуитивных человеческих реакции, которые приводят к провалу проектов. Одна из них касается управления приоритетами - люди интуитивно пускают работы, по которым понятно, что делать надо, вперед, а те, в которых непонятно что делать для решения - откладывают. Второе - при выдаче задания подчиненным люди пытаются решить проблему самостоятельно, и выдать указания в терминах решения, но не проблемы, которую озвучить "забывают".

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

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

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

Пример.
"У тебя программист Вася сейчас чем занят?"
"Он отлаживает вот эту софтину, на которой глючит оборудование, помогая найти баги в оборудовании".
"Но ведь когда аппаратчики исправляют оборудование, он ничего не делает?"
"Когда аппаратчики исправляют оборудование, он думает на своей следующей задачей. Проектирует."
"Это плохо. Программисты у тебя недогружены. Надо нагрузить".

Осталось 5 мест. Регистрируйтесь на сайте.
http://www.happy-pm.com/blog/?p=3116

Comments:


elennaa at 2009-11-08 18:18 (UTC) (Link)

"Осталось 5 мест"

Говорят осталось уже 4. Пошел обратный отсчет
the_realistic at 2009-12-04 01:35 (UTC) (Link)
А это не обязательно пример дурного менеджмента.

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

Думает? над чем? где результат? в виде дизайн-документа, в виде объявления интерфейсов или чего-то вроде?
Gaperton
gaperton at 2009-12-04 09:39 (UTC) (Link)
> Склонность программистов строить башни из слоновой кости всем известна, и "думание" часто сводится к такому.

Нет такой склонности у программистов. Это симптом неумения менеджмента управлять исследовательской фазой разработки.

> Думает? над чем? где результат? в виде дизайн-документа, в виде объявления интерфейсов или чего-то вроде?

А вот это - наглядный пример такого менеджмента. В хай-теке такому менеджменту делать нечего.
the_realistic at 2009-12-04 12:25 (UTC) (Link)
Процесс должен идти, и иметь результат.

Абстрактное "думание" есть трата времени. Думать надо _над конкретной задачей_, и получать _результат_, т.е. что-то придумывать в итоге.

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

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

Менеджменту вообще не стоит в это вмешиваться, кроме как а) раздать роадмапы и б) следить, чтобы не было недогруженности. "Продумывай следующую задачу из роадмапа, или следующую+1, или следующую+2" - такая позиция.

Сотрудники вообще скорее не думают, а задачи решают.

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

Исследовательская фаза вообще есть не у всех задач. У 1 из 10 примерно. Так, например, "исследовательская фаза" часто есть "дать девелоперу время почитать документацию", что в случае опытного именно в этой технологии девелопера не нужно. Главная цель предварительного чтения документации - выяснить ограничения той технологии, которая будет задействована. Что она может, что нет, что в ней делается легко, а что сложным анальным путем. Да вплоть до версий платформы, на которых технология поддержана. :)

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

В значительной степени менеджер и есть переводчик с одного языка на другой.

Психологически-закомплексотские заморочки типа боязни биг-босса, что его подсидят, и прочих всякоразных интриг - тоже играют роль.
Gaperton
gaperton at 2009-12-04 17:55 (UTC) (Link)
> Исследовательская фаза вообще есть не у всех задач. У 1 из 10 примерно.

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

У вас это может быть одна из десяти задач, у меня - 9 из 10. Я не занимаюсь проектами, в которых можно тупо "копать", и им от этого не станет плохо. Не интересно это мне - слишком легко. Это вообще не менеджмент. Говорить даже не о чем.

Вообще, для выражения своих мыслей о менеджменте вы можете писать в своем блоге. Он для этого подходит больше, чем чужой.
the_realistic at 2009-12-04 01:37 (UTC) (Link)
И еще. Тот, кто сказал о "недогруженности", бывает прав еще вот в чем - роадмапы есть добро. Если программист простаивает потому, что _не знает_, в чем следующая задача - то это минус менеджеру.

Я вот свой роадмап на месяцы вперед знаю. Он корректируется, конечно, но таки у меня не бывает, чтобы я не знал следующую задачу.
Gaperton
gaperton at 2009-12-04 09:28 (UTC) (Link)
Тот, кто сказал о "недогруженности", _ничего_ не сказал "о роадмапах". :) И поэтому, не может быть в этом прав. Ему, собственно, плевать на роадмапы. Ему нужно, чтобы вы постоянно были чем-то заняты. Почувствуйте тонкую разницу.
the_realistic at 2009-12-04 12:30 (UTC) (Link)

"Копать от забора и до обеда"

Менеджмент по-прапорщицки совсем не на 100% плох.

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

"Плохо, когда люди недогружены" - именно из оной мифологии.

Еще раз - это не _зло_. Это _база_. Если на ней все и останавливается - то это унтер Пришибеев, но и не-Пришибеевы не должны такие моменты упускать из виду.

Это нормально, когда менеджер каждый день знает, какая задача на данный момент у каждого, а не просто "он думает".

Соответственно, нормальный сотрудник - это тот, что, закончив одну задачу и не имея роадмапа, начнет "доставать" начальство с требованиями оный роадмап ему выдать, хоть в каком-то виде.
Gaperton
gaperton at 2009-12-04 17:44 (UTC) (Link)

Re: "Копать от забора и до обеда"

> Менеджмент по-прапорщицки совсем не на 100% плох.

Когда работаешь с идиотами - то да. Это не случай хайтека. По крайней мере я с идиотами предпочитаю не работать.

> Еще раз - это не _зло_. Это _база_.

Я прекрасно понял, что вы сказали, и какая у вас база. Повторять "еще раз" нет никакой необходимости.
Previous Entry  Next Entry