Здравствуйте, COFF, Вы писали:

COF>Здравствуйте, Gaperton, Вы писали:

G>>В чем проблема. Используйте советский подход.

COF>Просто интересно, почему Вы считаете советский подход плохим?

Я нигде не писал, что считаю советский подход плохим. Я привел для контраста трактовку приказа нашим уставом, сказал, что военные принципы им не исчерпываются, и описал немецкий принцип руководства auftragstaktik с конкретными выводами по управлению разработкой. Ну неужели Вы не заметили?

Здравствуйте, COFF, Вы писали:

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

COF>Кстати, зря смеетесь. То, что немецкие сапоги не были приспособлены для ведения боевых действий зимой, все прекрасно знают еще со школы. И неизвестно как бы обернулось дело, если бы не эти сапоги. А ведь это вопрос банального планирования и учета рисков, то есть непосредственно соприкасается с темой этой конференции

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

Здравствуйте, Gaperton, Вы писали:

G>Begreifen auftragstaktik!

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

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

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

Знать зачем делается проект и иметь представление о том,
что же реально хочет пользователь тоже очень и очень важно.
Мотивация реально повышается, если есть реальная связь с заказчиками/пользователями.

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

Точно так же авторитарный менеджер, контролирующий все и вся,
обречен на провал с командой самостоятельно действующих подчиненных.

Здравствуйте, Gaperton, Вы писали:

G>Я нигде не писал, что считаю советский подход плохим. Я привел для контраста трактовку приказа нашим уставом, сказал, что военные принципы им не исчерпываются, и описал немецкий принцип руководства auftragstaktik с конкретными выводами по управлению разработкой. Ну неужели Вы не заметили? :)

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

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

Здравствуйте, bkat, Вы писали:

B>Возможно этот подход считается "революционным" для армии, а для нормальной жизни
B>он мне кажется самым что ни на есть естественным.

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

B>Собственно нормальный менеджер для меня не приказывающий начальник, а координатор.
По auftragstaktik, да и вообще — он не только и не столько координатор, сколько "целеполагатель". Начальник дает не приказ в терминах действий, а некий фреймворк, в рамках которого подчиненный должен достичь четко поставленной цели, построив действия самостоятельно. Короче, вам дают не приказ, а некую "миссию", которую надо выполнить (в английском аналог — mission tactic). Не надо путать это с либерализмом .

B>Из проблем я вижу только одну.
B>Менеджер, работающий по "Auftragstaktik" ничего не достигнет,
B>если подчиненные привыкли только выполнять четко поставленные приказы.
Отчего же. Приказ-то не перестает быть четким. Сложнее приучить к самостоятельному мышлению в рамках заданных целей и ограничений. Собственно, особо не приучишь — либо есть, либо нет. Для этого требуется развитая логика и дисциплина мышления. Но людям, как показывает практика, это нравится. И то, что задача поставлена четко, и то, что при этом дается самостоятельность в ее решении.

B>Точно так же авторитарный менеджер, контролирующий все и вся,
B>обречен на провал с командой самостоятельно действующих подчиненных.
Такому менеджеру вообще нелегко. Во-первых, у такого менеджера по факту хуже контроль над ситуацией, во-вторых — он за деталями не видит леса, некогда ему, а в третьих — он лишен возможности гибко реагировать на ситуацию и лишает себя поддержки своих людей. Глупо.

Здравствуйте, COFF, Вы писали:
G>>"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 40 Устава внутренней службы Вооруженных Сил РФ)
COF>Ну, в конце-концов, Германия ведь проиграла. Так что практика не на стороне данного подхода =)
Так-то оно так, да только причём тут ваша сентенция: цитируется устав ВС Российской Федерации (которая типа как выиграла).

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, gandjustas, Вы писали:

G>>Вы упустили из виду три момента.

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

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

Здравствуйте, Gaperton, Вы писали:

G>По auftragstaktik, да и вообще — он не только и не столько координатор, сколько "целеполагатель". Начальник дает не приказ в терминах действий, а некий фреймворк, в рамках которого подчиненный должен достичь четко поставленной цели, построив действия самостоятельно. Короче, вам дают не приказ, а некую "миссию", которую надо выполнить (в английском аналог — mission tactic). Не надо путать это с либерализмом .

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

Здравствуйте, Аноним, Вы писали:

G>>>"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 40 Устава внутренней службы Вооруженных Сил РФ)
COF>>Ну, в конце-концов, Германия ведь проиграла. Так что практика не на стороне данного подхода =)
А>Так-то оно так, да только причём тут ваша сентенция: цитируется устав ВС Российской Федерации (которая типа как выиграла).
А>:)

Не, я просто понял исходное сообщение как противопоставление хорошего auftragstaktik подхода и плохого советского. Оказалось, что понял неправильно :)

Здравствуйте, Gaperton, Вы писали:

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

В сущности, это очевидно — исполнители должны этот "дух" как минимум понимать. Это означает, что они должны знать не только ЧТО надо делать, но и понимать, ЗАЧЕМ. А именно, исполнители нижнего уровня должны хорошо понимать логику принятия решений уровня выше.

Другими словами, программисты должны разбираться в продакт менеджменте и маркетинге. Не обязательно глубоко — им не обязательно уметь генерировать стратегии и знать нюансы ранка, но они ОБЯЗАНЫ ПОНИМАТЬ продуктовую стратегию, знать целевую аудиторию, ее потребности, и особенности позиционирования для того продукта, который разрабатывают.

То есть программисты ДЛОЖНЫ ПОНИМАТЬ маркетинговую стратегию, а менеджеры ДОЛЖНЫ ДОВЕСТИ эти вещи до программистов. И все будет зашибись.
Я долгое время пребывал в обеих ипостасях, я должен заметить, что этого категорически не достаточно. Менежемент очень туго воспринимает обратный поток информации, от исполнителей вверх, к управленцам.
Как человек, категорически не способный к механическому выполнению поставленных задач (из-за этого, кстати я расстался с карьерой кадрового офицера), я переодически сталкивался с подобными проблемами.
К примеру несколько лет назад, я участвовал в проекте разработки продукта из области BI в роли руководителя группы разработчиков и архитектора. Еще на стадии анализа мне стало понятно, что продукт позиционируется не правильно, упор делается не на те свойства, которые действительно могут быть востребованы. Но все попытки достучаться с до менеджеров отвечающих за выход продукта и продуктовых аналитиков ни к чему не привели. Все воспринималось как попытка влезть не в свою зону ответственности и даже как сабботаж. В результате продукт выл выпущен в срок и в соответствии с требованиями, но коммерческого успеха не имел. Во второй версии, насколько я знаю, они таки сделали изменения, которые я предлагал с самого начала, но я там уже не работал...
Этот пример характеризует общую проблему. Продуктовые менеджеры в большинстве своем не готовы воспринимать фидбек от разработчиков, направленный на улучшение маркетинговых свойств продукта. Разработчики часто сталкиваются с тем, что получают детальные требования, которые вызывают только улыбку. Но попытки объяснить, что все это можно сделать намного лучше, обычно наталкиваются на полное непонимание. Порой ни менеджер, ни заказчик ни пользователь не видит, что создаваемый продукт имеет скрытые потенциальные возможности (например, накопленные данные позволяют проводить корреляционный анализ, или облегчить ввод новой информации), но разработчику очень трудно продвинуть свои идеи "наверх". "Для этого у нас есть аналитики", "заказчику это не надо", "стратегия развития продукта это не предусматривает" — вот что слышит разработчик, и после этого стоит ли удивляться, что разработчики предпочитают "тупо кодировать по требованиям".
Требуя креатива в решении задач от подчиненных надо быть готовым делегировать им полномочия, и при этом не забывать что ответственность все равно остается на тебе. К этому большинство менеджеров категорически не готовы. И поэтому в управлении проектами царят действительно армейские методы, но описываются они не загадочным Auftragstaktik, а принципом, который у нас в армии назывался "принципом жолудя" — "Живешь среди дубов, и не знаешь какая свинья тебя съест"

Здравствуйте, bkat, Вы писали:

G>>По auftragstaktik, да и вообще — он не только и не столько координатор, сколько "целеполагатель". Начальник дает не приказ в терминах действий, а некий фреймворк, в рамках которого подчиненный должен достичь четко поставленной цели, построив действия самостоятельно. Короче, вам дают не приказ, а некую "миссию", которую надо выполнить (в английском аналог — mission tactic). Не надо путать это с либерализмом .

B>В общем я усматриваю некую аналогию с декларативным программированием,
B>которое в отличии от императивного, в основном оперирует целями.

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

Здравствуйте, stump, Вы писали:

S>Сложно не соглашаться с озвученными вами идеями, однако вы рассмотрели проблему лишь с одной стороны.
S>Хорошо менеджеру иметь умных и мотивированных подчиненных:

Неправильно, посылка совершенно не та. Auftragstaktik предъявляет больше требований к менеджерам, чем к подчиненным. А вовсе не сводится к тому, "как хороше если бы подчиненные были бы такими умными, что делали б все сами".

Раз. Который мало кто делает, лишая подчиненных возможности исправлять свои ошибки.

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

Два. Который большинство менеджеров нарушают, много думая о том "как", и почти не думая о том "что" и "зачем" — а именно в последнем их работа и состоит.

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

S>Требуя креатива в решении задач от подчиненных надо быть готовым делегировать им полномочия, и при этом не забывать что ответственность все равно остается на тебе.

Да, собственно именно этого auftragstaktik и добивается. Делегируется ответственность при сохранении полноты контроля и точности указания. Почитай вот эту статью — тебе интересно будет.
http://usacac.army.mil/CAC/milreview/English/SepOct02/SepOct02/widder.pdf

S>К этому большинство менеджеров категорически не готовы. И поэтому в управлении проектами царят действительно армейские методы, но описываются они не загадочным Auftragstaktik, а принципом, который у нас в армии назывался "принципом жолудя" — "Живешь среди дубов, и не знаешь какая свинья тебя съест"

Ну да. Я об этом и писал в начале поста.

Постоянно нарушаемая на местах многими "гражданскими" людьми, очень умными, с высшим образованием полученном в неплохих ВУЗах, и, когда доходит до реального руководства людьми — являющихся почему-то классическими образчиками ментальности "сапогов" из начала 19 века.

Здравствуйте, gandjustas, Вы писали:

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

G>Любые тактические принципы являютя отражением состояния вооружения и боевой подготовки. Любой военный принцип, оторванный от контекста ничего не стоит. Какими бы правильными принципы не были начать применять их на ровном месте мало кто соберется.

Угу. До чего верно подмечено. Вот ваши слова, взять, например — ведь совершенно оторваны от какого-либо контекста. "любые", "любой", "какими бы", "на ровном месте", "мало кто".

Здравствуйте, COFF, Вы писали:

G>>Я нигде не писал, что считаю советский подход плохим. Я привел для контраста трактовку приказа нашим уставом, сказал, что военные принципы им не исчерпываются, и описал немецкий принцип руководства auftragstaktik с конкретными выводами по управлению разработкой. Ну неужели Вы не заметили?

COF>Не знаю, выводы вроде хорошие и правильные, но такое впечатление, что именно auftragstaktik тут притянуто за уши. С таким же успехом их можно делать из фильма "Москва слезам не верит", где директор говорит, что мне не важно почему это не сделано, мне важно, что ты сделал, чтобы эту проблему решить...

Ну, значит вам понятны некоторые частности, но общий принцип, который за ними стоит и из которому они подчинены, вам не понятен. Ну, бывает. Я что-то должен с этим делать? Зачем? Если вам интересно, то вы можете пойти по ссылкам в статье, напрячься, и попробовать понять. А можете расслабится, и не пытаться — но тогда вы не можете рассчитывать и на мое внимание, с какой стати мне время-то на вас тратить? Еще опции?

Ну, можно конечно попробовать мне доказать, что никакого общего принципа нет — но это довольно глупо. Я-то его понимаю . Ну, какие еще опции остаются? А, можно что-нибудь умное не по теме сказать, и попытаться втянуть меня в дискуссию про дорожные правила, материал портянок немецких солдат, Россия vs Германия в ВОВ, и т.д. Это меня от души веселит . Если будете упорствовать, то я попрошу модераторов выделить это в отдельную ветку и перенести с глаз долой — в священные войны.

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

Здравствуйте, Gaperton, Вы писали:

G>А еще можно задать мне конкретный вопрос или высказаться по теме. Тут конечно так не принято, если судить по большинству ответов, но можно попробовать. Тогда я с вами побеседую.

Спасибо за столь лестное мнение о моих умственных способностях и рад, что Вас повеселил :) А конкретный вопрос у меня один и задал я его с самого начала, только Вы никак не хотите его понять. Вот Вы проводите аналогию между специфичным методом руководства войсками и процессом разработки, при этом утверждаете, что этот метод хорош. Я и хочу понять почему? Потому что Вам так кажется или потому что этот метод доказал эффективность на практике? Если последнее, то почему при всей этой прекрасной организации немцы проиграли почти все войны, что вели? Наверняка ведь такой вопрос ставился сторонниками auftragstaktik. Где положительные результаты? По крайней мере, ответив на этот вопрос, можно будет понять ограничения и пределы применимости данного метода. А сейчас получается типа — давайте рассмотрим прекрасный процесс, которым пользовалась IBM при разработке OS/2. Может там и в самом деле был прекрасный процесс и IBM проиграла рынок по совсем другим причинам, но OS/2 сейчас может изучаться только в качестве отрицательного примера. Вот как-то так.

Здравствуйте, Gaperton, Вы писали:

G>Помните здесь были дискуссии про военные методы в разработке ПО? Последнее время я очень плотно интересуюсь военными методами управления. И обнаружил массу интересного. У меня для вас есть кое-что — я написал небольшую заметку про немецкий принцип Auftragstaktik.

Для данного принципа имеется и русский термин, который с успехом применяется конструкторами, инженерами при проектировании сложной техники, например, самолётов. Термин этот — "функциональный подход" или "функциональное описание задачи". В Вашем примере — это когда менеджер описывает задачу и критерии её успешного решения. В случае с проектированием самолёта КБ получает на вход документ, называющийся "тактико-технические характеристики". Это своего рода тоже функциональное описание задачи, т.к. в этом документе содержатся требования к скорости, высоте полёта, грузоподъёмности самолёта и не содержатся указания о форме фюзеляжа или крыла. Т.е. вместо "самолёт должен иметь не шасси, а лыжи" пишут "самолёт должен приземляться на льдины и ледяные лётные поля".

К сожалению, как я заметил, большинство (и менеджеров, и программистов) избегают функциональной постановки задачи и тяготеют к объектной. Т.е. вместо "функции" описывают первое попавшееся (и поэтому неоптимальное) решение. Моя гипотеза — делают они это так, потому что так проще. Чтобы описать функцию и, тем более, критерии качества решения, нужно думать. А вот, к сожалению, большинство думать не любят. В этом легко убедиться, посмотрев, например, обсуждения на форуме "Архитектура". Львиная доля вопросов начинается с описания объекта: "У меня есть класс..." или "Решил использовать паттерн..." А о том, что требуется сделать — ни слова. В лучшем случае опишут какую-нибудь проблему, которая, как правило, порождена неправильным подходом к проектированию. А вот задачу — что программа должна делать — ни-ни.

Полагаю, это общая проблема... Возможно, на собеседовании (особенно, на должность проектировщика) полезно задавать связку из двух вопросов:

1) Сформулируйте критерии качественного решения для данной задачи. (При этом, при бездумном перечислении шаблонов "модульность", "расширяемость", "объектная ориентированность" посылать на хрен.)
2) Спроектируйте конструкцию (думаю, этот термин лучше подходит, чем термин "архитектура"), которая удовлетворяет сформулированным критериям.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>К сожалению, как я заметил, большинство (и менеджеров, и программистов) избегают функциональной постановки задачи и тяготеют к объектной. Т.е. вместо "функции" описывают первое попавшееся (и поэтому неоптимальное) решение. Моя гипотеза — делают они это так, потому что так проще. Чтобы описать функцию и, тем более, критерии качества решения, нужно думать.

Совершенно верно. Чтобы формулировать задачу декларативно — надо уметь думать. В действительности, auftragstaktik предъявляет высочайшие требования в первую очередь к менеджменту.

Пример с ТТХ и ТЗ вообще, который вы привели, с декларативной постановкой целей и ограничений — неплох. Но иллюстрирует только половину принципа. Вторая половина содержится в понимании, ЗАЧЕМ нужен этот самолет, почему мы пришли к необходимости его создания, какую проблему он решает. В ГОСТ-овском ТЗ на этот вопрос отвечает секция "характеристика области применения" (24-й ГОСТ).

Однако, наиболее полно этой концепции соответствует шаблон Vison & Scope Document за авторством Вигерса (это прокомментировал t_gra в ЖЖ). Его можно найти в сети.

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

http://usacac.army.mil/CAC/milreview/English/SepOct02/SepOct02/widder.pdf

Здравствуйте, COFF, Вы писали:

G>>А еще можно задать мне конкретный вопрос или высказаться по теме. Тут конечно так не принято, если судить по большинству ответов, но можно попробовать. Тогда я с вами побеседую.

COF>Спасибо за столь лестное мнение о моих умственных способностях и рад, что Вас повеселил
А причем тут Ваши умственные способности? Если вы что-то не понимаете — это что, обязательно означает, что у вас с умственными способностями что-то не так? Я вот не стесняюсь признаваться в том, что я чего-то не понимаю . Прям так и говорю — не понимаю, объясните. Что в этом такого-то?

COF>А конкретный вопрос у меня один и задал я его с самого начала, только Вы никак не хотите его понять.
Да, признаться вопрос Ваш я пока не понял.

COF>Вот Вы проводите аналогию между специфичным методом руководства войсками и процессом разработки, при этом утверждаете, что этот метод хорош. Я и хочу понять почему? Потому что Вам так кажется или потому что этот метод доказал эффективность на практике?

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

COF>Если последнее, то почему при всей этой прекрасной организации немцы проиграли почти все войны, что вели?

Потому что не надо путать выигрышь войны и тактику отдельных операций. Война — это гораздо больше чем сражение. Потому что одним только методом принятия решений войну выиграть нельзя. Это одно из ваших преимуществ, но только одно из. Помимо метода у вас есть материальные и человеческие ресурсы, качество и количество боевой техники, качество генерального штаба, боевая подготовка войск, боевой дух войск (чрезвычайно важный фактор, основной, в числе ведущих), политические ресурсы и внешняя ситуация, внешние и внутренние риски, положение на фронтах и стратегический расклад сил, географическое положение вас и противника, информированность вас и противника, а также ПРОТИВНИК, который вовсе не представляет собой статичную мишень, а активно вам противодействует на пределе сил, и у него есть свои сильные стороны — обычно не такие, как у вас, и он на них также вовсю полагается. И кроме того, при самой совершенной системе управления, вы все еще можете и будете ошибаться, и успех войны зависит от вашего чутья, умения предвидеть, умения адаптироваться к меняющейся ситуации, и везенья. А ошибки главкома обходятся дороже всего. Computers are so unreliable... just like people.

Помимо прочего, вам должно ВЕЗТИ, потому что все предусмотреть невозможно. Я всегда чувствую себя неловко, когда приходится объяснять такие элементарные вещи. Вы могли бы и сами догадаться. Подобные вопросы я объясняю исключительно нежеланием думать. В ответ на Ваше нежелание думать — у меня пропадает желание тратить на вас время, поскольку мне лично такая беседа пользы никакой не приносит.

COF>Наверняка ведь такой вопрос ставился сторонниками auftragstaktik. Где положительные результаты?
COF> По крайней мере, ответив на этот вопрос, можно будет понять ограничения и пределы применимости данного метода.

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

Но если Вам так интересно — почитайте про кампании Бисмарка 19 века, например. Или про то, как была захвачена Европа Гитлеров в начале второй мировой.

COF> А сейчас получается типа — давайте рассмотрим прекрасный процесс, которым пользовалась IBM при разработке OS/2. Может там и в самом деле был прекрасный процесс и IBM проиграла рынок по совсем другим причинам, но OS/2 сейчас может изучаться только в качестве отрицательного примера. Вот как-то так.

Сейчас получается типа, что вы не хотите думать, вяло так сидите и хотите чтобы вам все разжевали да в рот положили. Да еще при этом кривитесь, это мол не так, да тарелки не те. Вопрос — хотя бы по одной ссылке из статьи сходили? Нет? Так вот, ничего рассматривать я вас не заставляю — не переживайте. Мне от вас ничего не надо, понимаете?

Здравствуйте, Gaperton, Вы писали:

G>Совершенно верно. Чтобы формулировать задачу декларативно — надо уметь думать. В действительности, auftragstaktik предъявляет высочайшие требования в первую очередь к менеджменту.

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

Как правило, такой эффект характерен для аутсорсинговых компаний.

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

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

Поэтому я выбираю другой путь. Обычно я прошу сформулировать задачу в привычном для них виде, т.е. в терминах объектов. Если менеджер хочет, чтобы какой-нибудь программный модуль работал так, как в программе конкурентов, я прошу его показать программу конкурентов. Если менеджер хочет какой-то свой особый GUI и, главное, стремится сам нарисовать этот GUI, я прошу его нарисовать этот GUI. А дальше я уже сам эту поставленную в терминах объектов задачу перевожу в постановку в виде функций и критериев. При этом, от первоначально нарисованного GUI'я может и ничего не остаться. Но важно то, что я получаю ответ на вопрос "Зачем?", т.е. понимаю конечную задачу.

G>Вторая половина содержится в понимании, ЗАЧЕМ нужен этот самолет, почему мы пришли к необходимости его создания, какую проблему он решает. В ГОСТ-овском ТЗ на этот вопрос отвечает секция "характеристика области применения" (24-й ГОСТ).
Конечно. Но именно в ответе на вопрос "Зачем?" и заключается функциональная постановка задачи. Ибо конечному пользователю нужна не сама вещь (т.е. объект), а её функция.

К сожалению, большинство программистов (да и менеджеров) не понимают этой простой истины. Плюс присутствует большая инерция мышления, вызванная пропагандой объектного подхода. В качестве примера опять-таки сошлюсь на форум Архитектура. Большинство задач, разбираемых там, начинается со стандартной фразы: "Дан объект...". На самом деле, ни один другой инженер (не программист) не начинает проектирование с объекта. А начинает он именно с функции, т.е. с понимания того, зачем и в каких условиях эта проектируемая система будет использоваться.

На самом деле, именно функциональное и критериальное (а не объектное) мышление является сильным. В ряде технических дисциплин существуют специальные методы, которые подталкивают именно к функциональному мышлению. Например в ТРИЗ существует понятие "идеальная техническая система" — это когда системы нет, а её функция выполняется. Смысл понятия идеальность — подтолкнуть инженера к тому, чтобы он мыслил функциями (задачами), а не объектами.

В ФСА (функционально-стоимостном анализе), вернее в смеси ТРИЗ + ФСА существует метод "функционально-идеальное моделирование", суть которого заключается в том, что сначала создаётся функциональная модель улучшаемой системы, а затем — создаётся её конструкция. (Но это объяснение на пальцах. Чтобы получить подробную информацию, лучше почитать книжки по ТРИЗ + ФСА.)

G>На самом деле речь идет о большем — это leadership principle, которому подчинена вся система управления. Документ — это частность.
Понятно. Если команда состоит из слабых специалистов, то к любому документу будут относиться достаточно формально: соблюдать лишь внешние требования, а на самом деле проектировать систему, как привыкли, а не так, как нужно. Чтобы документы, правила, методики не превратились в пустую формальность, нужно ещё создать команду — команду грамотных специалистов. Но вот создание такой команды, к сожалению, пока ещё является серьёзной архи-задачей. Очень уж мало видел я успешных примеров.

G>http://usacac.army.mil/CAC/milreview/English/SepOct02/SepOct02/widder.pdf
Спасибо, посмотрю. К сожалению, мой английский не позволяет мне прочесть её быстро.

Здравствуйте, Gaperton, Вы писали:

G>Сейчас получается типа, что вы не хотите думать, вяло так сидите и хотите чтобы вам все разжевали да в рот положили. Да еще при этом кривитесь, это мол не так, да тарелки не те. Вопрос — хотя бы по одной ссылке из статьи сходили? Нет? Так вот, ничего рассматривать я вас не заставляю — не переживайте. Мне от вас ничего не надо, понимаете? :)

Но Вы же анонсировали, что изучили вопрос досконально, а в это понятие, по моему, входит и изучение конкурирующих подходов, нет?

Знаете, Ваша заметка делится на две части: первая — это краткое описание Auftragstaktik, вторая — конкретные рекомендации по разработке ПО, которые якобы следуют из нее. Со второй частью спорить затруднительно, так как она описывает широкораспространенные практики, которые являются общим местом. Тем более, что Вы отрицаете конкретную связь, которая может существовать между разработкой ПО и военным делом. В этих условиях Auftragstaktik — это не более чем buzzword.

С моей точки зрения, было бы куда интереснее найти информацию по противостоящей доктрине, понять, чем они отличаются, и почему все-таки, несмотря на применение Auftragstaktik на всех уровнях немецкой армии вплоть до генерального штаба, она уступила менее продвинутой (по Вашему утверждению) советской доктрине. Только-ли по воле случая? Я не поленился и нашел вот такой документ: http://stinet.dtic.mil/cgi-bin/GetTRDoc?AD=ADA262662&Location=U2&doc=GetTRDoc.pdf

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