Auftragstaktik!
"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 40 Устава внутренней службы Вооруженных Сил РФ)
Однако, армейские принципы не исчерпываются мудростью советского устава и принципами дедовщины. Посмотрим, как они выглядели примерно с середины 19 века на просторах Германии, после реформы армейской системы. Это фундаментальный принцип, который лежал в основе работы как германского генерального штаба (вплоть до конца его существования в 1945 году :) ), так и всей германской армии.
"The concept of Auftragstaktik or "mission tactics" … made it the responsibility of each German officer and NCO … to do without question or doubt whatever the situation required, as he personally saw it. Omission and inactivity were considered worse than a wrong choice of expedient. Even disobedience of orders was not inconsistent with this philosophy."
Чему это может научить современного менеджера в разработки ПО? Многому, уважаемые коллеги. Мы раскроем суть этого принципа. Для начала, небольшое лирическое отступление.
Военная стратегия и тактика - огромный пласт опыта человеческой цивилизации, накопленный ажно со времен древнего рима. Сложно назвать другую область деятельности, в котором цивилизация обладает сравнимой практикой. Причем, уровень неопределенности, с которым работают военные, существенно выше такового в разработке ПО.
Более того, человеческий фактор там значит не меньше, а возможно и гораздо больше - значимость боевого духа войск по сравнению с другими факторами оценивают как 3 к одному, и большинство специалистов оценивают его как решающий. Ну и главное, армии нужны эффективные методы управления в условиях неопределенности, там результат на ладони, дикие риски, плюс огромная цена ошибки - там достаточно сложно выдать поражение за победу. Да и масштаб проектов там, согласитесь, достаточно большой. :)
Короче, ближе к делу, а именно - к aftragstaktik, Он заменяет приказ в обычном понимании этого слова "директивой". А именно - вы ставите подчиненному четкую цель, которой он должен достичь - по возможности математически точно описав критерии ее достижения, оставляя ему выбор способов ее достижения в соответствии с обстоятельствами, с которыми он столкнется при выполнении.
Более того. Он должен следовать не букве "приказа", а его духу. Если обстоятельства сильно изменились, принцип aftragstaktik предписывает ему нарушить приказ, чтобы соблюсти его дух, общий принцип. Следование приказу не является оправданием для поражения - это принцип aftragstaktik. "Его высочество сделал вас майором, потому что он был уверен, что вы достаточно умны, чтобы понять, когда НЕ надо следовать его приказам".
Звучит довольно странно, и требует пояснения. Перейдем к разработке софта, станет понятнее. Чтобы детально расписать требования к софту, и не дать возможности "неправильно выполнить приказ" - надо все очень подробно расписать, верно? При этом, по ходу проекта в требованиях будут выяснены противоречия, и они частично изменятся и потеряют актуальность? Знакомо, не так ли? Очевидно, более детальное расписывание требований не является выходом. "Мы сгенерировали тонну документации, и провалили проект. В следующем - мы сделаем две тонны."
Не являются выходом и декларации agile - фактический отказ от управления требованиями, и стратегия проигравшего на мизере - "забрать все свои", чтобы не схватить "паравоз". Нам бы помог принцип aftragstaktik - здорово было бы, если бы исполнители сами исправили неточность в требованиях, "выполнив не букву приказа, а дух", но как воплотить его в жизнь?
В сущности, это очевидно - исполнители должны этот "дух" как минимум понимать. Это означает, что они должны знать не только ЧТО надо делать, но и понимать, ЗАЧЕМ. А именно, исполнители нижнего уровня должны хорошо понимать логику принятия решений уровня выше.
Другими словами, программисты должны разбираться в продакт менеджменте и маркетинге. Не обязательно глубоко - им не обязательно уметь генерировать стратегии и знать нюансы ранка, но они ОБЯЗАНЫ ПОНИМАТЬ продуктовую стратегию, знать целевую аудиторию, ее потребности, и особенности позиционирования для того продукта, который разрабатывают.
То есть, они должны понимать, кто будет пользоваться их продуктом, и понимать, какую его потребность удовлетворяет их продукт. Не "находится в контакте с заказчиком" (это суть переваливание с больной головы на здоровую), а именно понимать - это самое главное.
Думаете, это сложно? В сущности - нет. К примеру, основная концепция iPhone очень проста - он делает настоящий интернет по настоящему мобильным. Именно поэтому там полноценный браузер - Safari, с полноценным JavaScript. Именно поэтому у него экран высокого разрешения. И именно поэтому он маленький и легкий, и там управление пальцами. И именно поэтому традиционные (и не нужные широкой аудитории) "смарфонные" функции там не реализованы, и Джобс рекомендовал писать для него приложения на вебе.
Потому, что это НЕ ОЧЕРЕДНОЙ СМАРТФОН с кульным дизайном. It makes internet mobile. С момента продаж iPhone мобильный интернет траффик вырос в 10 раз. iPhone НА САМОМ ДЕЛЕ смог сделать интернет мобильным.
Но я не рекламирую iPhone - я сам предпочел Нокую Е90. Я о другом. Обратите внимание - iPhone чрезвычайно точно реализует свою концепцию, задуманную Джобсом, не содержа при этом ничего лишнего и выходящего за ее рамки. :) Как так получилось? Неужто Джобс следовал принципам agile? :) Чушь - проект iPhone держался в секрете вплоть до его выхода, и никаким таким клиентам его не показывали. Может, Джобс сгенерировал тонну документации? Балшыт. Секрет успеха - в соблюдении принципа aftragstaktik. Разработчики знали, понимали, и разделяли концепцию, и им нравилось что они делают.
Вы замечали, что лучшие продукты делаются изначально для себя - для своих нужд? Скажем, возьмем C и UNIX. По ним видно. Они сделаны с душой, там все детали пригнаны так, что скальпель меж ними не вгонишь. Почему так? Потому, что люди знают, ЗАЧЕМ, а не следую приказам.
Итак, что же делать с документами требований? Очень просто. Они просто обязаны на половину состоять из маркетинговой части. Которая должна давать внятные ответы на вопросы, для кого делается продукт, и какую потребность мы удовлетворяем. Почему продукт крут. За что его будут покупать. Почему именно от него будут в восторге. Это - важнее деталей, это просто обязано не потеряться по дороге. Кроме того, надо внятно и точно обозначить критерий успеха проекта.
Вообще - самый близкий по духу к этому документ по классике имеет название Project Charter. Это ни разу не требования. Однако, он не содержит и маркетинговых материалов - очень в ограниченном виде. В ГОСТ-освких формах ТЗ наиболее близка по духу секция с мутным названием "характеристика области применения". Так как это ТЗ заполняется техническими специалистами и как попало, в данной секции обычно у нас оказывается балшыт. Поэтому, надо креативно подойти к формам документов, и что-нибудь придумать. Я, например, всегда стараюсь держать маркетинговую информацию близко к требованиям, чтобы облегчать кросс-проверки. Некий гибрид Project Charter и Requirements Spec выглядит практично и неплохо.
Ну, а если программист заметил ошибку в маркетинговой части, то он в соответствии с принципом aftragstaktik, обязан вынести это на обсуждение. А если менять требования уже поздно, или же там что-то не покрыто или конфликт - то выработать техническое решение, удовлетворяющее "духу" требований самостоятельно. Более того, если он что-то в ней не понял, то он должен поднять этот вопрос и понять. Ибо нам будет дешевле, чтобы он понял общую идею, и додумал детали сам, чем расписывать ему детально как он должен действовать. Да и самому программисту так гораздо интереснее.
Вообще же менеджерам следует взять за правило всегда объяснять причины своих заданий, и какую роль они играют в общем целом, и обязательно доносить "дух приказа". Концентрируясь на целях, и четко формулируя именно цели, а не способы их достижения.
Вооруженные силы построенные в соответствии с принципом aftragsataktik чрезвычайно мобильны и гибки, и состоят из большого количества небольших единиц, которые способны действовать самостоятельно, и периодически объединяться в более крупные единицы для достижения более крупных целей. Очень похоже на организацию разработки Google :).
Теперь об еще одном аспекте auftragstaktik. А именно - недопустимости микроменеджмента. В современные времена, с появлением информационных технологий и технологий анализа данных, желание у менеджмента запустить свои пальцы в детали и выдавать слишком детальные приказы, фактически относящиеся к уровню принятия решений на ступени ниже, стало настоящим бичом индустрии, блин. Дело в том, что современные технические средства управления поддерживают иллюзию, что менеджер лучше знает, КАК надо достигать приказ.
В такой ситуации, нижележащий командный уровень деградирует в "прозрачный прокси", который тупо транслирует чрезмерно детальные приказы вниз. Знакомо? Это является недопустимым. Я тут не буду раъяснять - я процитирую генерала Вернера Виддера, который просто великолепно высказался, тут добавить нечего.
It is unacceptable that subordinate levels are
disregarded and that higher command levels skip
intermediate command levels and interfere with
tactical decisions on the ground. In addition to
the implications for freedom of action and the
operations of soldiers, risks emerge for the tactical
and operational levels of military command.
- пишет он в своей статье, посвященной современным принципам немецкой армии от 2002 года, -
The commander who attempts to specify every-
thing is doomed to get lost in detail. He will lose track
of things and fail. What is more, the commander
who reaches down to exercise command and con-
trol at subordinate levels will lose the support of
his men and women and undermine their bases
of action.
http://usacac.army.mil/CAC/milreview/English/SepOct02/SepOct02/widder.pdf
Короче говоря. Очевидная вещь, которую нелишне повторить еще раз. Не надо лезть к подчиненным с указаниями, как им делать свою работу, вмешиваясь в их уровень принятия решений. Уровень менеджера - целеполагание, подбор людей, и организация работ. Все. Не надо пытаться делать не свою работу - даже если вам кажется, что вы лучше знаете, как ее делать. Вам только кажется.
Таков принцип auftragstaktik. Deutlich?
Ну, еще можете прочесть вот эту статью, которую я нашел по ключевому слову auftragstaktik и взял из нее цитату в начале поста. Статья неплоха, и сама содержит много замечательных цитат.
http://www.ducimus.com/Archive/auftrags-oleary.htm
Мне особенно понравилось вот эта цитата. Волшебно.
"Unobtrusive indicators of the "good [combat] officer"
Distrust any officer with a perfect or near perfect record of efficiency reports. He is conforming to the existing value system and will have no interest in changing it.
Look carefully at a man who gets low marks on "tact" and who "deviates from accepted doctrine." He may be creative.
An officer who gets low marks on loyalty is especially valuable, for he is unwilling to acquiesce to his superior's policies without debate. He is likely to have an independent mind.
Be suspicious of any officer who has accumulated awards for valour without having sustained physical injury. Trust a Purple Heart wearer.
Distrust any officer who has had "all his tickets punched" and who sports an array of staff awards on his chest. He is likely to be a manager playing the system.
Distrust all officers who use "buzz words" and have a poor vocabulary. They tend to be managers of the most obsequious type. True leadership is likely to be foreign to them.
Trust a man who heads for the sound of the guns and has repeated tours of combat and command duty at all unit levels; it is preferable that he have only minimal exposure to staff work.
Trust an officer who was seen by his men in combat and whose command performed well and showed low rates of drug use, fragging, body counting, etc.
Search for the officer whose readiness reports indicate a high percentage of equipment which is deficient. He is a man addicted to the truth." (12)
Однако, армейские принципы не исчерпываются мудростью советского устава и принципами дедовщины. Посмотрим, как они выглядели примерно с середины 19 века на просторах Германии, после реформы армейской системы. Это фундаментальный принцип, который лежал в основе работы как германского генерального штаба (вплоть до конца его существования в 1945 году :) ), так и всей германской армии.
"The concept of Auftragstaktik or "mission tactics" … made it the responsibility of each German officer and NCO … to do without question or doubt whatever the situation required, as he personally saw it. Omission and inactivity were considered worse than a wrong choice of expedient. Even disobedience of orders was not inconsistent with this philosophy."
Чему это может научить современного менеджера в разработки ПО? Многому, уважаемые коллеги. Мы раскроем суть этого принципа. Для начала, небольшое лирическое отступление.
Военная стратегия и тактика - огромный пласт опыта человеческой цивилизации, накопленный ажно со времен древнего рима. Сложно назвать другую область деятельности, в котором цивилизация обладает сравнимой практикой. Причем, уровень неопределенности, с которым работают военные, существенно выше такового в разработке ПО.
Более того, человеческий фактор там значит не меньше, а возможно и гораздо больше - значимость боевого духа войск по сравнению с другими факторами оценивают как 3 к одному, и большинство специалистов оценивают его как решающий. Ну и главное, армии нужны эффективные методы управления в условиях неопределенности, там результат на ладони, дикие риски, плюс огромная цена ошибки - там достаточно сложно выдать поражение за победу. Да и масштаб проектов там, согласитесь, достаточно большой. :)
Короче, ближе к делу, а именно - к aftragstaktik, Он заменяет приказ в обычном понимании этого слова "директивой". А именно - вы ставите подчиненному четкую цель, которой он должен достичь - по возможности математически точно описав критерии ее достижения, оставляя ему выбор способов ее достижения в соответствии с обстоятельствами, с которыми он столкнется при выполнении.
Более того. Он должен следовать не букве "приказа", а его духу. Если обстоятельства сильно изменились, принцип aftragstaktik предписывает ему нарушить приказ, чтобы соблюсти его дух, общий принцип. Следование приказу не является оправданием для поражения - это принцип aftragstaktik. "Его высочество сделал вас майором, потому что он был уверен, что вы достаточно умны, чтобы понять, когда НЕ надо следовать его приказам".
Звучит довольно странно, и требует пояснения. Перейдем к разработке софта, станет понятнее. Чтобы детально расписать требования к софту, и не дать возможности "неправильно выполнить приказ" - надо все очень подробно расписать, верно? При этом, по ходу проекта в требованиях будут выяснены противоречия, и они частично изменятся и потеряют актуальность? Знакомо, не так ли? Очевидно, более детальное расписывание требований не является выходом. "Мы сгенерировали тонну документации, и провалили проект. В следующем - мы сделаем две тонны."
Не являются выходом и декларации agile - фактический отказ от управления требованиями, и стратегия проигравшего на мизере - "забрать все свои", чтобы не схватить "паравоз". Нам бы помог принцип aftragstaktik - здорово было бы, если бы исполнители сами исправили неточность в требованиях, "выполнив не букву приказа, а дух", но как воплотить его в жизнь?
В сущности, это очевидно - исполнители должны этот "дух" как минимум понимать. Это означает, что они должны знать не только ЧТО надо делать, но и понимать, ЗАЧЕМ. А именно, исполнители нижнего уровня должны хорошо понимать логику принятия решений уровня выше.
Другими словами, программисты должны разбираться в продакт менеджменте и маркетинге. Не обязательно глубоко - им не обязательно уметь генерировать стратегии и знать нюансы ранка, но они ОБЯЗАНЫ ПОНИМАТЬ продуктовую стратегию, знать целевую аудиторию, ее потребности, и особенности позиционирования для того продукта, который разрабатывают.
То есть, они должны понимать, кто будет пользоваться их продуктом, и понимать, какую его потребность удовлетворяет их продукт. Не "находится в контакте с заказчиком" (это суть переваливание с больной головы на здоровую), а именно понимать - это самое главное.
Думаете, это сложно? В сущности - нет. К примеру, основная концепция iPhone очень проста - он делает настоящий интернет по настоящему мобильным. Именно поэтому там полноценный браузер - Safari, с полноценным JavaScript. Именно поэтому у него экран высокого разрешения. И именно поэтому он маленький и легкий, и там управление пальцами. И именно поэтому традиционные (и не нужные широкой аудитории) "смарфонные" функции там не реализованы, и Джобс рекомендовал писать для него приложения на вебе.
Потому, что это НЕ ОЧЕРЕДНОЙ СМАРТФОН с кульным дизайном. It makes internet mobile. С момента продаж iPhone мобильный интернет траффик вырос в 10 раз. iPhone НА САМОМ ДЕЛЕ смог сделать интернет мобильным.
Но я не рекламирую iPhone - я сам предпочел Нокую Е90. Я о другом. Обратите внимание - iPhone чрезвычайно точно реализует свою концепцию, задуманную Джобсом, не содержа при этом ничего лишнего и выходящего за ее рамки. :) Как так получилось? Неужто Джобс следовал принципам agile? :) Чушь - проект iPhone держался в секрете вплоть до его выхода, и никаким таким клиентам его не показывали. Может, Джобс сгенерировал тонну документации? Балшыт. Секрет успеха - в соблюдении принципа aftragstaktik. Разработчики знали, понимали, и разделяли концепцию, и им нравилось что они делают.
Вы замечали, что лучшие продукты делаются изначально для себя - для своих нужд? Скажем, возьмем C и UNIX. По ним видно. Они сделаны с душой, там все детали пригнаны так, что скальпель меж ними не вгонишь. Почему так? Потому, что люди знают, ЗАЧЕМ, а не следую приказам.
Итак, что же делать с документами требований? Очень просто. Они просто обязаны на половину состоять из маркетинговой части. Которая должна давать внятные ответы на вопросы, для кого делается продукт, и какую потребность мы удовлетворяем. Почему продукт крут. За что его будут покупать. Почему именно от него будут в восторге. Это - важнее деталей, это просто обязано не потеряться по дороге. Кроме того, надо внятно и точно обозначить критерий успеха проекта.
Вообще - самый близкий по духу к этому документ по классике имеет название Project Charter. Это ни разу не требования. Однако, он не содержит и маркетинговых материалов - очень в ограниченном виде. В ГОСТ-освких формах ТЗ наиболее близка по духу секция с мутным названием "характеристика области применения". Так как это ТЗ заполняется техническими специалистами и как попало, в данной секции обычно у нас оказывается балшыт. Поэтому, надо креативно подойти к формам документов, и что-нибудь придумать. Я, например, всегда стараюсь держать маркетинговую информацию близко к требованиям, чтобы облегчать кросс-проверки. Некий гибрид Project Charter и Requirements Spec выглядит практично и неплохо.
Ну, а если программист заметил ошибку в маркетинговой части, то он в соответствии с принципом aftragstaktik, обязан вынести это на обсуждение. А если менять требования уже поздно, или же там что-то не покрыто или конфликт - то выработать техническое решение, удовлетворяющее "духу" требований самостоятельно. Более того, если он что-то в ней не понял, то он должен поднять этот вопрос и понять. Ибо нам будет дешевле, чтобы он понял общую идею, и додумал детали сам, чем расписывать ему детально как он должен действовать. Да и самому программисту так гораздо интереснее.
Вообще же менеджерам следует взять за правило всегда объяснять причины своих заданий, и какую роль они играют в общем целом, и обязательно доносить "дух приказа". Концентрируясь на целях, и четко формулируя именно цели, а не способы их достижения.
Вооруженные силы построенные в соответствии с принципом aftragsataktik чрезвычайно мобильны и гибки, и состоят из большого количества небольших единиц, которые способны действовать самостоятельно, и периодически объединяться в более крупные единицы для достижения более крупных целей. Очень похоже на организацию разработки Google :).
Теперь об еще одном аспекте auftragstaktik. А именно - недопустимости микроменеджмента. В современные времена, с появлением информационных технологий и технологий анализа данных, желание у менеджмента запустить свои пальцы в детали и выдавать слишком детальные приказы, фактически относящиеся к уровню принятия решений на ступени ниже, стало настоящим бичом индустрии, блин. Дело в том, что современные технические средства управления поддерживают иллюзию, что менеджер лучше знает, КАК надо достигать приказ.
В такой ситуации, нижележащий командный уровень деградирует в "прозрачный прокси", который тупо транслирует чрезмерно детальные приказы вниз. Знакомо? Это является недопустимым. Я тут не буду раъяснять - я процитирую генерала Вернера Виддера, который просто великолепно высказался, тут добавить нечего.
It is unacceptable that subordinate levels are
disregarded and that higher command levels skip
intermediate command levels and interfere with
tactical decisions on the ground. In addition to
the implications for freedom of action and the
operations of soldiers, risks emerge for the tactical
and operational levels of military command.
- пишет он в своей статье, посвященной современным принципам немецкой армии от 2002 года, -
The commander who attempts to specify every-
thing is doomed to get lost in detail. He will lose track
of things and fail. What is more, the commander
who reaches down to exercise command and con-
trol at subordinate levels will lose the support of
his men and women and undermine their bases
of action.
http://usacac.army.mil/CAC/milreview/English/SepOct02/SepOct02/widder.pdf
Короче говоря. Очевидная вещь, которую нелишне повторить еще раз. Не надо лезть к подчиненным с указаниями, как им делать свою работу, вмешиваясь в их уровень принятия решений. Уровень менеджера - целеполагание, подбор людей, и организация работ. Все. Не надо пытаться делать не свою работу - даже если вам кажется, что вы лучше знаете, как ее делать. Вам только кажется.
Таков принцип auftragstaktik. Deutlich?
Ну, еще можете прочесть вот эту статью, которую я нашел по ключевому слову auftragstaktik и взял из нее цитату в начале поста. Статья неплоха, и сама содержит много замечательных цитат.
http://www.ducimus.com/Archive/auftrags-oleary.htm
Мне особенно понравилось вот эта цитата. Волшебно.
"Unobtrusive indicators of the "good [combat] officer"
Distrust any officer with a perfect or near perfect record of efficiency reports. He is conforming to the existing value system and will have no interest in changing it.
Look carefully at a man who gets low marks on "tact" and who "deviates from accepted doctrine." He may be creative.
An officer who gets low marks on loyalty is especially valuable, for he is unwilling to acquiesce to his superior's policies without debate. He is likely to have an independent mind.
Be suspicious of any officer who has accumulated awards for valour without having sustained physical injury. Trust a Purple Heart wearer.
Distrust any officer who has had "all his tickets punched" and who sports an array of staff awards on his chest. He is likely to be a manager playing the system.
Distrust all officers who use "buzz words" and have a poor vocabulary. They tend to be managers of the most obsequious type. True leadership is likely to be foreign to them.
Trust a man who heads for the sound of the guns and has repeated tours of combat and command duty at all unit levels; it is preferable that he have only minimal exposure to staff work.
Trust an officer who was seen by his men in combat and whose command performed well and showed low rates of drug use, fragging, body counting, etc.
Search for the officer whose readiness reports indicate a high percentage of equipment which is deficient. He is a man addicted to the truth." (12)