• Не давайте задания. Ставьте проблемы!

    Posted on August 17th, 2009 Александр Орлов 25 comments

    Три недели назад в одном московском пивном заведении собралась небольшая компания докладчиков конференции Software People. И там Влад Балин (известный в ПМских кругах под ником Gaperton) вкратце рассказал про Auftragstaktik. Я еще, помню, тогда себе в напоминалку поставил “почитать у Влада про это дело”. И почитал вот только недавно. Очень редко у меня возникает такая реакция: елки-палки, что ж я раньше-то это не прочел?!

    Потрясающая статья про то, почему подчиненным нужно ставить не задачи, а  проблемы. Как это делать и что из этого получается. (Те, кто были на наших со Славой тренингах наверняка вспомнят знаменитое панкратовское “ииииии?!” :) ).

    Практическое peopleware

    Сейчас мы сознательно его применяем и соблюдаем. Что я могу сказать. Цитируя генерала Виддера, “переход к Auftragstaktik не был простым и легким”.

    Суть Auftragstaktik в нашем случае в том, что все управление ведется от проблем. Проблема – единица планирования. Из них состоит весь план. Вы не ставите человеку задачу сделать что-то. Вы поручаете ему решить проблему.

    И этот принцип соблюдается до конца – до конечных исполнителей. Собственно, при такой схеме нет “исполнителей” в традиционном понимании этого слова.

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

    Во-вторых, существенно повышается эффективность работы. Менеджер не декомпозирует проблему на решение, которое состоит из действий, которые он поручает исполнителям. Он разваливает проблему на набор частных проблем. Это приводит к радикальному повышению КПД. Пример.
    1-й вариант, Befehlstaktik. Так практически все дают задания.
    - Надо вычленить драйвер USB из загрузчика uBoot, чтобы его можно было запустить отдельно, без ОС.

    2-й вариант того же задания. Auftragstaktik.
    - У нас есть контроллер USB. Он DMA-мастер. Надо заставить его мастера сгенерировать любую транзакцию. Требуется это для проверки, сможет ли он добраться до памяти, читать и писать в нее. Результат должен быть оформлен в виде программы, не требующей ОС. Вот мануал к контроллеру.

    Это реальный пример. Получив первое задание, человек потратил день на разбирательство, и сказал – вот, готово. Что дальше-то?

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

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

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

    Вы знаете, что такое микроменеджмент? Не факт, что знаете. С точки зрения Auftragstaktik микроменеджментом является первое задание. А именно такие указания и выдает большинство руководителей. Это интуитивная реакция. Надо за собой следить. Это указание выдавал не я, однако, и я иногда ловлю себя на Befehlstaktik.

    Второй пример. Проблема – надо обеспечить удаленный доступ к стенду через веб-камеру. Я могу сказать так:
    - Подключи камеру к этому компу.
    Через некоторое время мне скажут – готово. И я буду думать, как мне говорить с админами, чтобы обеспечить удаленный доступ к камере снаружи локальнй сети.

    Но я могу сказать:
    - Надо решить проблему удаленного доступа к стенду через веб-камеру. Вот камера. Вот компьютеры. Проблема решена, когда наш субподрядчик сможет видеть изображение с нее. Да, вот телефон админов – надо будет решить вопрос с нашими файрволлами.

    Вот здесь мы приходим к “минусам”. Вернее, к тому, в чем внедрение Auftragstaktik встречает сопротивление. Причина в том, что “исполнители”, привыкшие к тому, что они “исполнители”, не всегда готовы к тому, что им надо решать проблемы. Первое задание принимается легко. Второе задание – может встретить сопротивление.

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

    Общая причина сопротивления шире. Получая проблемы вместо работ, люди становятся отчасти менеджерами. Их работа перестает быть спокойной и размеренной. Они вступают в непосредственное соприкосновение с проблемами, получают больше отвественности, и вынуждены активно принимать решения – а следовательно – брать на себя риски и проявлять инициативу. Это людей беспокоит. Некоторых это начинает нервировать. Поскольку, при Auftragstaktik действительно менеджерские функции равномерно распределяются по всей команде до последнего исполнителя. А менеджером быть на самом деле очень непросто.

    В этом состоит суть принципа Innere F?hrung. “Внутреннее руководство”. Оно, руководство, должно теперь исходить не извне. Оно должно идти изнутри. Да, основа Innare F?hrung в том, что подчиненный – свободный человек, и его права и свободы уважаются. Никаких “я начальник ты дурак”. Однако, взамен требуется оно-же, неудобоваримое немецкое Innere F?hrung – “внутреннее руководство”. И в этом – суть Auftragstaktik. “Тактики поручений”.

    Мой зам на пред-предыдущей работе, Виктор Александрович Александров, рассказал мне занимательную историю про своего знакомого, который устроился разнорабочим на стройку в Германии. Его знакомый, заступив первый свой рабочий день на стройку, поразился тому, что половину дня ему никто не выдавал заданий. Он сидел, и курил, и занимался тем, что смотрел на работающих людей. Радовался. “Отличная работа”, думал.

    Ближе к обеду к нему подошел прораб, и сказал: “Вторую половину дня так просидишь – и я тебя уволю”.
    - Так что делать-то?!
    - Помогать. Тебя для этого наняли.
    - Кому?! Как?!
    - Оглядись вокруг, животное! Вон, смотри – людям цемент нужен, видишь! А вон там – люди грузят кирпич! На стройке все заняты. Думаешь, у кого-то есть время говорить разнорабочему, что делать?

    В некоторых местах нашей планеты, Innere F?hrung, как вы видите, касается даже разнорабочих. :)

    Да. И последнее. Принцип Auftragstaktik основан на взаимном доверии. Это не пустые слова. Речь идет о взаимном доверии начальства и подчненных, именуемыми “нижележащими командными уровнями”. Ведь “исполнителей” при таком подходе у нас нет, и это слово должно быть исключено из обихода, не так ли?

    Руководитель, поручая решение проблемы подчиненному, оставляет ему свободу в выборе решения, сообщая детали относительно решения только в случае, если меры по достижению разных целей должны быть согласованы, или если наличествуют некоторые “военные или политические ограничения” (я сейчас по сути цитирую немецкий устав). Заменим последнее “техническими или организационными ограничениями”, и получим вполне гражданский контекст.

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

    Однако, подчиненный также должен доверять руководителю. Ибо принцип построен на ВЗАИМНОМ доверии. Подчиненный должен доверять руководителю в том, что он адекватно ставит цели, и в том, что он адекватно расставляет приоритеты. Точно также, даже в том случае, если он не понимает, почему приоритеты стоят именно так, а не иначе.

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

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

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

    Однако, проблема ли это Auftragstaktik? Или же Auiftragstaktik просто делает проблему взаимного недоверия более заметной, “высвечивая ее”? Вообще-то, верно второе. Организация не сможет работать эффективно без взаимного доверия в любом случае – просто эта проблема маскируется при Befehlstaktik, так, что до нее трудно докопаться. И Auftragstaktik является практичным способом выявлять и решать данную проблему.

    Помните Peopleware Тома ДеМарко? Отличная книга. Так вот, я предлагаю вам выбросить ее в топку, и заняться практикой peopleware, о которой я вам сейчас рассказываю, вместо того, чтобы с умным видом рассуждать о нем. Займитесь этим прямо завтра. Ибо – понимание требуется для действия. Ни для чего другого.

    (Оригинал – здесь.)

     

    25 responses to “Не давайте задания. Ставьте проблемы!”

    1. Моя практика показывает, что решение проблемы “нижележащими командными уровнями” сводиться к минимальной активности направленной на ее решение. Оправданием некачественного решения станет нечеткие формулировки задач и т.п…

    2. Увы, ауфтраг тактик я не читал. Возможно, там все как-то по другому. В статье же – это мое личное мнение – переиначен метод управления проектом как управление рисками. Он описан у того же Демарко в “Роман об управлении проектами”.
      Есть проблема – это идентифицированный риск. Мы назначаем этому риску владельца и “забываем про него”. Решая проблемы, мы постоянно уменьшаем общий риск провала проекта. Так?
      Однако подход постановки проблем представляет собой не более чем укрупненную задачу разработки, декомпозицию которой мы перегружаем с плеч менеджера на плечи исполнителя. С теми же самыми проблемами, что и в стандартном процессе. Если исполнитель опытный, он прекрасно справится с данной проблемой. Равно как и задачей из план-графика. Если же исполнитель – джуниор, он будет постоянно бегать за советами к старшим товарищам или к ПМу. Нет отличий.
      Теперь по поводу взаимного доверия и взращивания менеджеров. С моей точки зрения – идеальная питательная среда для взращивания. Но я – менеджер. У программиста – подход другой. Ему не хочется решать кучу мелких неинтересных задач, типа пробивать в ИТ-департаменте разрешение на прямой выход в Инет с тестового сервера и носить на подпись согласующие бумажки. Накладные расходы на управление сильно раздражают программиста. С его точки зрения, это – зря потраченное время, потому что ему нравится программить, а не изучать инструкции. Доверять человеку делать неинтересные ему вещи – это ведет не к снижению, а к повышению рисков. Понятно как – человек откладывает неприятные задачи на потом, потом, потом. EQ никто не отменял :) После трех провалов возникнет вопрос об отчетности и контроле в процессе, и все вернется на круги своя.

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

    3. В каком-то моменте склоняюсь к +1 для “Применять его к новичкам или к архитекторам – можно, но на мой взгляд, не стоит”, но колеблюсь, поэтому хочу рассказать о тонкостях этого дела.

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

      Было реально нервозно. Я пришпилился к лагерю тех, кто “не успевает”, и тал там жить. Все это прошло со временем, когда я тоже начал понимать все то, что и как они делают, и сделал свое первое самостоятельное решение проблемы. Тогда меня начали понемногу принимать в компанию “крутых”, и мое самомнение взлетело до бровей :)

      Потом я уже был менеджером проектов в мелкой компании, которая “профессионально сделает вам веб-сайт, и даже объяснит, нафига он вам нужен”, и тоже в какой-то момент прибег к описанной нахфрагтактик (блин, как это запомнить?). Но в крохотной компании поле для действий было узким и последствия были болезненными. Создание группировки “проблеморешальщиков” привело к тому, что один дизайнер почти перестал получать задания. Тоже было сложно это пережить.

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

      Отсюда выводы:

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

      - риск “После трех провалов возникнет вопрос об отчетности и контроле в процессе, и все вернется на круги своя” неимоверно высок.

      - нахфраг находится в головах, а не в корпоративных документах о рабочих процессах.

    4. Саша, мне кажется, что надо было бы назвать твой пост не “Не давайте задания. Ставьте проблемы”, а “…Ставьте Цели” – это больше соответствует посту Гапертона. Посмотри первый же коммент -” Моя практика показывает, что решение проблемы “нижележащими командными уровнями” сводиться к минимальной активности направленной на ее решение. Оправданием некачественного решения станет нечеткие формулировки задач…”

      Вот оно – “нечеткие формулировки задач…” А надо не задачи выполнять путем минимизации усилий и получения галочеки за выполнение – а достигать цели. Вот тут уж минимизация усилий будет плюсом, а не минусом, и не потребует микроменеджмента от руководства.

    5. 2 elena. Лен, наверное, ты отчасти права. ставить надо то :) , про что можно сказать: решено/не решено. А там обзывай хоть проблемой, хоть целью, имхо. :)

    6. 2 sournk, nvbodunov и Алексей Лупан. Коллеги, никто жеж разные уровни готовности сотрудников при делегировании им задач не отменял. Конечно. соглашусь с вами.

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

      P.S. Леша, за термин “нахфрагтактик” отдельное спасибо. Я сполз под стол. :)

    7. Александр, что значит “выше”?

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

      Недавно купил новую книжку “Разработка программных проектов на основе RUP”. Там есть очень интересная мысль – программисты с раздражением относятся к рулежке извне в технической области, но требуют подробнейших инструкций для процессов организационных, вроде приобретения чего-то материального для проекта (кто работал в крупных организациях – знает, какой это геморрой).

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

    8. 2 nvbobunov. “Выше” – я имел в виду, что человеку интересно решать и организационные проблемы, в том числе.

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

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

    9. Программистов, которым интересно решать организационные проблемы, раз в 10 меньше, чем тех, которым решать эти проблемы совершенно неинтересно. То, что для первых будет мотивацией (?), вторых точно демотивирует. Соответственно, усредненный эффект – отрицательный.
      Давайте сойдемся вот на чем: метод ауфтраг тактик – действительно хорош. Но подходит, как и все остальные методы, для узкой группы людей. В данном случае – для тех, кто стоит на границе перехода от программиста к менеджеру. Собственно, он может использоваться как тест для выяснения, кто может стать менеджером, а кто нет. Но объявить на очередном проектном совещании “Отныне ВСЕ задачи будут ставиться по ауфтраг тактик” и начать претворять этот принцип в жизнь – не стоит.

    10. Вот, спасибо за формулировку. :) Согласен.

    11. Ничего нового. Во всех теориях мотивации персонала этот вариант постановки задачи рассматривается как один из краем континуума принятия решений. На одном конце принимает решения только руководитель, на другом – только подчиненные. Нельзя всегда во всех ситуациях находиться только в одной точке континуума.

    12. 2 covrom. Отлично. Коллега, скажите, правильно ли я понимаю, что если для Вас в чем-то нет ничего нового, то про это писать не надо? Ничего личного, просто интересуюсь.

    13. Николай Смирнов

      Каждый должен заниматься своим делом, желательно, любимым – вот такая простая мысль ограничивает применение данной техники до весьма скромных масштабов в условия реального IT производства реальными IT специалистами …

      Господин nvbodunov, на мой взгляд, во втором комментарии исчерпывающе это зафиксировал.

      В моей команде 3 человека, которые охотно решают проблемы на пути к цели и ~40, который подобный подход “убивает” – люди упираются в проблемы коммуникаций, бюджетирования и сроков и начинают “такую жгучую неприязнь испитывать” в мой адрес, если вдруг по стечению обстоятельств я им доверил разруливать поставленную и не отрезолвленную до деталей ( а даже и отрезолвленную) проблему …

      На самом деле, обсуждаемая практика – частный случай традиционной событийной модели, в которой ставится частная цель некоторому подколлективу (в данном, частном случае, состоящему из одного человека), способному ее решить, озвучиваются коммуникационные связи, сроки, видимые подводные камни и примерная реакция на их “всплытие” и тд и тп …

    14. 2 Николай Смирнов. Я, извините, немного ошарашен статистикой “3 против 40″. Можно задам несколько вопросов, которые прямо бьют в голову и не дают больше ни о чем думать? :)

      Если не секрет, почему таких людей только 3? Я понимаю, что там должна быть куча исторических причин, но тем не менее.

      Эти трое – наверное, еще и менеджеры? Иначе кто руководит этими 40 людьми на первом уровне? А где у них заместители – среди оставшихся 40? Как эти трое героев ходят в отпуск? Что будет делать руководитель команды, когда один из трех людей решит уволиться?

      Буду очень благодарен за ответ.

    15. Николай Смирнов

      Александр,
      ответил по почте.

    16. 2 Александр:

      Это Вы-то ошарашены статистикой? Не верю. Нет, я понимаю, Вы долго работали в Интеле, но не всю же свою жизнь Вы там работали.

      У меня, по трем последним работам, статистика примерно такая же. Вот реальный случай, произошедший год назад – тогда я некоторое время работал функциональным руководителем:
      Приходит ко мне руководитель проекта – далеко не худший в компании, так, серединка.
      -Николай, мы тут подписали контракт, вот ТЗ. Бюджет позволяет выделить 120 часов работы технического писателя, 160 часов программиста и 80 часов инженера-электронщика. И мои 80 часов как ПМа тоже туда включены. Ну или сам переставь часы, с техписателя на программиста, или еще как, только помни, что у них рейты разные.
      Ну, я немного выпадаю в осадок, но всякое приходилось слышать, поэтому зову своих ребят, чтобы дали грубую оценку, за сколько они смогут сделать данную работу. Риски и тестирование – пока лежат в сторонке, до них доберемся позже. Ребята выдают оценку, прошу их по возможности расписать детали, уточняю спорные моменты – получается в 3 раза больше времени, чем позволяет бюджет. Это без рисков и тестирования. Посылаю все это ПМу. Он ко мне приходит и заявляет:
      - Николай, у нас по новым правилам маржинальность проектов должна быть не менее 40%, поэтому, если я выделю дополнительное время, уменьшится маржинальность и мне попадет.
      - А если проект реально будет стоить в 5 раз дороже, что обязательно случится, тебе не попадет?
      - Николай, это тогда ты виноват будешь, потому что получается, что твои люди медленно работают. Набрал дураков, вот отсюда и все проблемы
      - Так найди умных оутсорсеров, они тебе за 3 рубля и 2 часа сделают, в чем проблема-то?
      - Николай, нет у меня знакомых оутсорсеров, увы…
      - А перед подписанием контракта дать мне ТЗ на оценку можно было?
      - Николай, извини, я был сильно занят, на мне еще 2 проекта висит, закрутился и забыл как-то.

      Ну и так далее. Как Вы думаете, можно такого человека назвать ПМом? А ведь это, повторяю, не худший. И в трудовой книжке у него записано – руководитель проекта. И структура формально соблюдена – 1 ПМ на 5 человек. Хотя по сути он – не ПМ, а программер, и довольно неплохой – в своей области.
      Разруливается такая ситуация сложно. У этого ПМа был вменяемый руководитель, вот ему я и объяснил проблему. Но, как Вы понимаете, на всех его не хватает, поэтому наступают факапы. И при уходе его в отпуск – тоже. А что еще может быть? Чудес не бывает.

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

      Со Славой мы вон даже проект “Игры в ИТ” сделали, где ситуацию, которую вы описали, назвали “Маржа”.

      Но каждая такая история меня все-таки все еще удивляет и ошарашивает. Похоже, поле для работы еще долго будет непаханным.

      P.S. Спасибо за историю, очень живо описано. Человек прямо нарисовался перед глазами. :)

    18. “Каждый должен заниматься своим делом, желательно, любимым – вот такая простая мысль ограничивает применение данной техники до весьма скромных масштабов в условия реального IT производства реальными IT специалистами”

      Кому-то могло показаться, что суть состоит в сваливании на конечного исполнителя всей деятельности по организации работ. Это не так.

      Вы ставите цель в соответствии с “данной техникой” каждый раз, когда акцентируетесь при выдаче задания на критерии приемки работы, и объяснении проблемы, которую должен решить результат работы. Вместо объяснения, _как_ надо выполнять эту работу. Это в равной степени касается в том числе и сугубо технических заданий.

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

      Понимание данного подхода требует изменения ментальности менеджера в первую очередь. Ему надо начать наконец думать не о том, _как_ делаются задания, не о “загрузке подчиненных” (не токарные станки это, знаете-ли), а о том, _зачем_ делается каждая работа. Выполняя декомпозицию работ не по активностям, а по решаемым проблемам. Техническим проблемам, техническим, не организационным.

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

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

    19. “На самом деле, обсуждаемая практика – частный случай традиционной событийной модели, в которой ставится частная цель некоторому подколлективу (в данном, частном случае, состоящему из одного человека),”

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

      http://en.wikipedia.org/wiki/Mission-type_tactics

    20. “Во всех теориях мотивации персонала этот вариант постановки задачи рассматривается как один из краем континуума принятия решений. На одном конце принимает решения только руководитель, на другом – только подчиненные. Нельзя всегда во всех ситуациях находиться только в одной точке континуума.”

      Континуум с концами – во всех теориях мотивации? Ну теоретики мотивации и задают жару :) .

    21. Николай Смирнов

      2gaperton
      Я не верю, что PM может быть эффективен без серьезных знаний предметной области проектов, которые он взращивает.
      Цитату же из моего поста надо как раз воспринимать с точностью наоборот. Именно зная до винтика кухню, понимаешь, что некоторые подзадачи (или точнее работы) проблемы можно и нужно поручать или менее квалифицированному исполнителю или узкому специалисту с целью распараллеливания и снижения временных затрат.
      А это приводит нас к обычной мотивации команды, что есть песнь не менее важная, но другая – называемая вовлечением и сопричастностью – сиречь все той же ответственностью за результат, о которой нам тут рассказывали …

    22. 2 gaperton

      Вот, теперь мы сузили предметную область – до технических заданий.

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

      У меня в памяти всплывает история, которую я читал в какой-то книге по управлению:
      На железнодорожном переезде уволился оператор шлагбаума, и повесили объявление “Требуется оператор шлагбаума”. Висит объявление неделю, другую – нет желающих.
      Тогда повесили другое “Требуется начальник переезда” и на следующее утро у дверей конторы стояла очередь из кандидатов.

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

      А более опытные менеджеры, обжигая руки, достают Peopleware из топки, и читают ее в очередной раз :)

    23. Николай Смирнов

      “[...]С тех пор и по сей день она является основным руководящим принципом в немецкой армии,[...]”
      Как я уже приватно отвечал Александру, в нашей армии – тоже самое за исключением малости – материально-технического обеспечения решения проблемы … Думаю иллюстрировать ситуацию не нужно.
      Вот только первый маленький нюанс – военнослужащий – не сотрудник, он не может сказать “я не буду этого делать” (какой аргументацией будет оперировать человек – не важно). И второй маленький нюанс – если критерием качества решения проблемы является любая попытка решения или вовсе лишь обозначение решения проблемы – не вижу смысла обсуждать методы мотивации в таких ситуациях ;)

    24. gaperton, метафора армии хороша, и у неё есть хорошие границы применения… армия :) знаешь в чем различие в управлении между армией и разработкой ПО?

      в армии когда ты попадаешь под обстрел, то что нужно делать? правильно, бежать вперёд и стрелять.

      в армии когда попадаешь на минное поле. что делать? правильно, стоять.

      а что делать когда на минном поле попал под обстрел? правильно :) бежать вперёд и стрелять.

      так вот цель руководителя в армии – заставить народ ломиться вперёд и стрелять когда они на минном поле и попали под обстрел.

      секрет управления в ИТ, в ИТ – это про другое :)

      ответ: пиплваре для начала.

    25. 2 denis_miller

      Приведенный пример из Спольски не совсем корректен, поскольку тот расказывает фактически о действиях пехоты, при этом сам будучи десантником. Впрочем, он сам заметил, что был худшим в подразделении, так что ему простительно :) Надо же было додуматься до такого примера – десант на штурм через минное поле погнать! Это как анекдот “Нужно трое сильных программистов – на пятый этаж пианино занести”.

      Действия более элитных (по сравнению с пехотой) вооруженных подразделений, где ценятся в первую очередь мозги, а уже потом – умение стрелять, достаточно сильно отличаются от вышеописанного. И там вполне применим auftragtaktik. Как и в ИТ. Просто в этом нового ничего нет, но как метод управления – он очень неплох.

    Leave a reply

    You must be logged in to post a comment.