Помните здесь были дискуссии про военные методы в разработке ПО? Последнее время я очень плотно интересуюсь военными методами управления. И обнаружил массу интересного. У меня для вас есть кое-что — я написал небольшую заметку про немецкий принцип Auftragstaktik. Совершенно великолепный принцип. ЭТО и есть квинтэссенция управления. Постоянно нарушаемая на местах многими "гражданскими" людьми, очень умными, с высшим образованием полученном в неплохих ВУЗах, и, когда доходит до реального руководства людьми — являющихся почему-то классическими образчиками ментальности "сапогов" из начала 19 века.

"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 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."

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

Begreifen auftragstaktik!

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

G>Begreifen auftragstaktik!

Есть определённые сомнения. Для того, чтобы это всё работало у исполнителей должен быть высокий уровень вменяемости. А такие вещи нужно воспитывать с детства всем обществом.

Например, в штатах довольно распространены all-way stop перекрёстки, где водители сами решают кому двигаться первым. В России такие решения не будут работать в принципе. Так и с auftragstaktik, идея правильная, но для того, чтобы она работала людей нужно серьёзно готовить. Причём то, чему нужно готовить находится вне области технологий.

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

IT>Например, в штатах довольно распространены all-way stop перекрёстки, где водители сами решают кому двигаться первым. В России такие решения не будут работать в принципе.
Мой отец говорит что в Уфе очень долго был "нахальный перекресток" без сфетофоров.
И не смотря на весьма оживленное движение аварийность там была очень низкая.

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

WH>Мой отец говорит что в Уфе очень долго был "нахальный перекресток" без сфетофоров.
WH>И не смотря на весьма оживленное движение аварийность там была очень низкая.

Для без светофоров есть очень чёткое правило, называется главная дорога и помеха справа. Поэтому, определить виновного элементарно, и это понимают прежде всего сами водители. В штатах такого правила нет и для all-way stops всё разруливается самими водителями.

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

IT>Для без светофоров есть очень чёткое правило, называется главная дорога и помеха справа. Поэтому, определить виновного элементарно, и это понимают прежде всего сами водители. В штатах такого правила нет и для all-way stops всё разруливается самими водителями.
Я не буду спорить ибо не знаю что именно там были за знаки и были ли вобще.
Но я думаю его не зря называли нахальным.

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

IT>Для без светофоров есть очень чёткое правило, называется главная дорога и помеха справа. Поэтому, определить виновного элементарно, и это понимают прежде всего сами водители. В штатах такого правила нет и для all-way stops всё разруливается самими водителями.
Правило "помехи справа" может дедлочиться, если одновременно подъедут четыре водителя с разных сторон. Что на оживлённом перекрёстке вполне реально.

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

G>"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 40 Устава внутренней службы Вооруженных Сил РФ)

Ну, в конце-концов, Германия ведь проиграла. Так что практика не на стороне данного подхода =)

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

IT>>Для без светофоров есть очень чёткое правило, называется главная дорога и помеха справа. Поэтому, определить виновного элементарно, и это понимают прежде всего сами водители. В штатах такого правила нет и для all-way stops всё разруливается самими водителями.
C>Правило "помехи справа" может дедлочиться, если одновременно подъедут четыре водителя с разных сторон. Что на оживлённом перекрёстке вполне реально.

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

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

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

G>>"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 40 Устава внутренней службы Вооруженных Сил РФ)

COF>Ну, в конце-концов, Германия ведь проиграла. Так что практика не на стороне данного подхода =)

Думаю, не Германия проигралла, а выиграл СССР. Вопрос в цене выигрыша.

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

IT>В штатах такого правила нет и для all-way stops всё разруливается самими водителями.
Такое правило есть, как минимум в NJ

As a general rule, the vehicle on the left should yield to the vehicle on the right

http://www.state.nj.us/mvc/manuals/chap_04_06.html

Другое дело, что перекрестки без знаков вообще еще поискать надо.

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

COF>Ну, в конце-концов, Германия ведь проиграла. Так что практика не на стороне данного подхода =)

Германия в итоге всегда проигрывала.
Благодаря Auftragstaktik(?) очень резво начинали и потом всегда получали по шапке

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

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

G>>"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 40 Устава внутренней службы Вооруженных Сил РФ)

COF>Ну, в конце-концов, Германия ведь проиграла. Так что практика не на стороне данного подхода =)

Так я и думал, что будут подобные комментарии . Их очень легко давать, не вникая в суть. И думать не надо, и мнение свое есть — удобно .

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

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

IT>>В штатах такого правила нет и для all-way stops всё разруливается самими водителями.
O>Такое правило есть, как минимум в NJ
O>

As a general rule, the vehicle on the left should yield to the vehicle on the right

O>http://www.state.nj.us/mvc/manuals/chap_04_06.html

Should — это, конечо, правило ... для американца. А для русского?

O>Другое дело, что перекрестки без знаков вообще еще поискать надо.

Я правила изучал в Атланте много лет назад и специально искал тогда упоминание о помехе справа. Не нашёл

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

G>Помните здесь были дискуссии про военные методы в разработке ПО? Последнее время я очень плотно интересуюсь военными методами управления. И обнаружил массу интересного. У меня для вас есть кое-что — я написал небольшую заметку про немецкий принцип Auftragstaktik. Совершенно великолепный принцип. ЭТО и есть квинтэссенция управления. Постоянно нарушаемая на местах многими "гражданскими" людьми, очень умными, с высшим образованием полученном в неплохих ВУЗах, и, когда доходит до реального руководства людьми — являющихся почему-то классическими образчиками ментальности "сапогов" из начала 19 века.

G>

G>"Приказ командира должен быть выполнен беспрекословно, точно и в срок". (Статья 40 Устава внутренней службы Вооруженных Сил РФ)

G>Однако, армейские принципы не исчерпываются мудростью советского устава и принципами дедовщины. Посмотрим, как они выглядели примерно с середины 19 века на просторах Германии, после реформы армейской системы. Это фундаментальный принцип, который лежал в основе работы как германского генерального штаба (вплоть до конца его существования в 1945 году ), так и всей германской армии.

G>"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."

G>Чему это может научить современного менеджера в разработки ПО? Многому, уважаемые коллеги. Мы раскроем суть этого принципа. Для начала, небольшое лирическое отступление.

G>Begreifen auftragstaktik!

Вы упустили из виду три момента.
1)Неправильные действия и руководство на поле боя может стоить жизни самому командиру
2)В армии порядки гораздо более жесткие, чем на гражданке, за нарушение устава (или какого-либо другого предписания) в военное время и расстрелять могут
3)Почитайте как готовили германских офицеров в то время. Курсанты проходили все супени воинской службы за время обучения (солдат-сержант-прапорщик-офицер), причем в боевых частях. Далеко не все зачисленные курсанты становились в итоге офицерами, была серьезная система отбора. Ничего аналогично на гражданке нет ни в одной стране мира.

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

G>Так я и думал, что будут подобные комментарии . Их очень легко давать, не вникая в суть. И думать не надо, и мнение свое есть — удобно .

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

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

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

G>>Так я и думал, что будут подобные комментарии . Их очень легко давать, не вникая в суть. И думать не надо, и мнение свое есть — удобно .

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

Ну вы зря тактику стратегию валите вместе.

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

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

G>>Так я и думал, что будут подобные комментарии . Их очень легко давать, не вникая в суть. И думать не надо, и мнение свое есть — удобно .

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

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

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

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

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

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

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

Просто интересно, почему Вы считаете советский подход плохим? Чем плох принцип, что "приказ командира должен быть выполнен беспрекословно, точно и в срок"? Приказы ведь тоже разными бывают. Можно приказать — выкопай яму отсюда и до обеда, а можно поставить проблему и приказать (попросить на гражданке) решить ее доступными средствами. Потом в армии, в отличии от типичной софтверной конторы (где по идее все инженеры — то есть офицеры по военному), не все солдаты достаточно адекватны для проявления инициативы, соответственно для некоторой категории именно четкий и недвусмысленный приказ является оптимальным. Вот у Вас в конторе наверняка есть повар или уборщица — Вы их тоже в маркетинговые подробности посвящать собираетесь?

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

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

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

Здравствуйте, 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) как раз была нацелена на то, чтобы недостатка информации не возникало. И она предполагает возможно более полное обеспечение свободной циркуляции информации в обоих направлениях и принятие решения на адекватном этому решению уровне, а вовсе не прямое руководство каждым солдатом со стороны генерала :)

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

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

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

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

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

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

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

У меня нет для вас времени. Всего доброго. Спорьте без меня.

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

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

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


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

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

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

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

Интересная мысль. Я тоже что-то подобное всегда чувствовал. Буду ее думать.

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

Не совсем. Даже если команда будет состоять из сильных специалистов, результат всегда можно свести на дерьмо директивным стилем руководства в сочетании с микроменеджментом. Я вам скажу — делайте вот это и вот это вот так, а зачем — вас не касается. Выполнить любой ценой. Незаменимых людей нет. Вот сделаете — будете жаловаться. И все. Этот стиль, называется Befehlstaktik или Normaltaktik, "императивная" тактика детальных приказов, который в особом представлении не нуждается, потому что его интуитивно применяет буквально каждый идиот, ставший начальником. Его тут COFF обнаружил в сети, и думает в соседней ветке, что это крутой эксклюзивный мега-метод, боагодаря которому СССР добилась победы во второй мировой .

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

Так и в команде — вы должны аккуратно подбирать людей, избегать командоразрушающих факторов, и применять дружественные команде leadership principle и схемы организации работ. Тогда, возможно, пройдя серию проектов и добившись вместе успеха (это очень сильно сплачивает, и необходимо для командообразования), ваши люди превратятся в слаженную команду. Первое — зависит от вашего чутья и личных качеств, второе — в принципе что делать не надо (worst practices) — известно, а насчет третьего — вот auftragstaktik как раз об этом. Это один из таких принципов, который помимо прочего явно стимулирует командообразование. Но цель данного принципа не создание команды, он из серии "дружественных" для команды, не более того.

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

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

sc>А я вообще не понял разницы между нашим и немецким подходом. Наверное потому что в армии служил
sc>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.
sc>Например в приказе "копать канаву от забора до обеда" понятно только что нужно делать, но не как. Как — это уже твои проблемы. Для чего, всегда объясняли, например, для нового кабеля, старый уже в десяти местах рвался, весь в скрутках. И творческий, нестандартный подход к делу всегда только приветствовался. Например, собрать деньги (спирт) и нанять тракториста с соседней деревни.
sc>Ну и в кино "про войну" это можно видеть повсеместно.

+3
ЗЫ: Еще есть со старых времен на флоте "... куда матроса не целуй, все равно жопа..." (в армии мотивация другая )

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

IT>Я правила изучал в Атланте много лет назад и специально искал тогда упоминание о помехе справа. Не нашёл

Может быть, конечно, позже добавили, но — открыв правила штата Georgia (если речь про Atlanta, GA, а не про другую Атланту), видим:

Yielding Right-of-Way: Always yield right-of-way to pedestrians, vehicle
operators, and bicyclists who move into the intersection before you by stopping
and remaining stopped until they have cleared the intersection.

At a four-way intersection where all drivers are faced with stop signs, all drivers
must yield to pedestrians; otherwise the vehicles should proceed through the
intersection in a “first to arrive, first to proceed order.” If two vehicles reach the
intersection at approximately the same time, yield to any vehicles on your right.

http://www.dds.ga.gov/docs/forms/FullDriversManual.pdf

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

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

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

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

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

Между тем, чем выше занимаемая разработчиком позиция, тем меньше необходимость в т.н. "хакерских навыках" (== в знании вещей низкого уровня). На передний план выходят конструкторские навыки, умение проектировать (конструировать) сложные технические системы.

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

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

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

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

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

Я с этим согласен. Дело не в том, что эти менеджеры — плохие программисты. Проблема в том, что у них отсутствуют конструкторские навыки.

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

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

1. Выбор типов данных под переменные. Если выбран не тот тип, может произойти переполнение, потеря точности вычислений или перерасход памяти.
   
2. Выбор названий для переменных и подфункций. Если названия даны произвольно, то в написанном коде будет потом трудно разобраться.
   
3. Выбор мест (фрагментов кода), которые нужно откомментировать.
   
4. И т.д. и т.п.

Если программист не умеет решать самостоятельно такие микро-задачи, то детализация приказа не спасёт.

G>О команде. Ну, "создать команду" звучит как заклинание — и действительно никаких методик создания команд нет. Если ставить задачу так — она заведомо невыполнима — не можете вы ее создать, она может у вас сложиться. Здесь более уместна аналогия с выращиванием растения (автор аналогии — Том ДеМарко). А именно — вы посадили растение, поливаете его, удобряете удобрениями, и вы можете надеятся, что оно может быть вырастет и принесет хорошие большие плоды, если вы конечно при этом не будете ломать ему стебель и подкапывать корни.

Опять-таки согласен с Вашей метафорой про выращивание. Это очень напоминает то, как формируется отдельно взятый специалист. Квалификация растёт на задачах. Чем больше сложных и нетривиальных задач решил человек, тем больше его практический опыт, тем выше его квалификация. К сожалению, достойных публикаций на обе темы (формирование команды и формирование грамотного специалиста) не так уж много. Автором ТРИЗ Г.С. Альтшуллером на базе анализа порядка 1000 биографий творческих людей была создана ТРТЛ (теория развития творческой личности). Какую-то информацию о ней можно посмотреть здесь.

Ещё в советские времена была публикация Б.Л. Злотина по теории развития творческих коллективов. Но, к сожалению, в интернете её нет.

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

КЛ>До недавнего времени мне казалось, что в продуктовых компаниях дела с разработкой должны обстоять лучше, т.к. задача компании — продать продукт. А если он не будет качественным, то и покупать его никто не будет. Но столкнувшись с одной брендованной компанией и узнав на практике, как там поставлена разработка, я понял, что и продуктовые компании от бардака не застрахованы.
Самое время вспомнить книгу Алана Купера "Психбольница в руках пациентов: Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие"

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

sc>А я вообще не понял разницы между нашим и немецким подходом.

Поскольку в заметке, помимо статьи 40, не приводятся статьи 38 и 42 Устава внутренней службы ВС РФ, может сложиться впечатление о противопоставлении автором двух систем. Не думаю, что это так.

38. Командир (начальник) перед отдачей приказа обязан всесторонне оценить обстановку и предусмотреть меры по обеспечению его выполнения.
...
Приказ должен быть сформулирован ясно, не допускать двоякого толкования и не вызывать сомнения у подчиненного.

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

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

Процитированные статьи УВС ВС РФ в совокупности определяют принцип успешного выполнения боевых задач в ВС РФ. И, полагаю, что он никак не противоречит aftragstaktik. Более того, на мой взгляд, aftragstaktik может являться рекомендацией или частью наставления по обеспечению выполнения боевых задач.

sc>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.

к сожалению, не всегда бывает так...

sc>"копать канаву от забора до обеда"

На мой взгляд, не совсем удачный пример...
Такая постановка задачи говорит о том, что начальнику важен не столько результат, сколько сам процесс, точнее длительность процесса. При такой постановке задачи, начальник занимает подчиненных делом, чтобы не сработало правило: «если солдат ничем не занят, ему в голову лезут дурные мысли».

Думаю, что более удачен следующий пример (Н — начальник, П- подчиненный):
Н: Есть ли связь со штабом?
П: Есть, но не работает...
Н: Что б через полчаса заработала!
П: Есть!

Классная статья. Очень понравилась!

Более того, человеческий фактор там значит не меньше, а возможно и гораздо больше — значимость боевого духа войск по сравнению с другими факторами оценивают как 3 к одному, и большинство специалистов оценивают его как решающий.

Это scrum и agile вообще. "Люди важнее процессов". Самомотивация и стремление к цели.

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

Это в точности scrum. Sprint goal, backlog item с информацией о том, как это показать на демо.

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

И это тоже scrum и agile. Нет смысла упираться рогом.

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

Непременно надо включить вашу замечательную статью в семинар по scrum! Все как на подбор!
Например, это — про то, как проводится planning day. Product owner рассказывает, что нужно получить и зачем это нужно в продукте.

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

Ну конечно же scrum!
Каждый backlog item имеет четкий buisiness value.

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

Опять про scrum
Менеджерские позиции в scrum'е по возможности выводятся за пределы команды. В процессе спринта команда сама решает, как делать ту или иную задачу. Кто будет ее делать, как делить работу.

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

А где в aftragstaktik прописан процесс формирования, анализа и проверки цели, которую командир выдает подчиненному? Что-то я не нашел

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

Все укладывают, и даже в меньшие итерации. Чаще всего — в двухнедельные. Месяц — это реально многовато для итерации.
Кстати, scrum не обязывает описывать требования в виде user story. Это из XP. А в scrum это может быть и в другом виде каком-то, если этот другой вид больше подходит.
Главный враг любой деятельности — это догмы.

По хорошему — в такой ситуации надо свернуть эти стори к простым элементарным операциям, ДОКАЗАТЬ, что в их терминах выразим интересующий нас класс юзер стори, после чего спокойно приступить к проектированию, имея в виду простые операции плюс несколько основных сценариев.
Это — работает, и это эффективно. При таком подходе я могу боротся со сложностью. И это — ничего общего с agile не имеет.

Это никак не противоречит scrum'у. Так и работаем.
Вот только фреймворки проектируем и рисуем не в первую очередь, опрометчиво рассчитывая на то, что у нас уже есть адекватные требования (а адекватных — нет), а когда реально увидим, например, дубляж, который может срезать фреймворк уровня проекта. Это надо делать, конечно, не слишком поздно, но и нельзя сделать слишком рано, на первых этапах. Вы еще не знаете, что у вас должен делать фреймворк. Потратите лишнее время на разработку фреймворка для гипотетического проекта. Реальный будет отличаться.

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

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

Еще раз спасибо за статью!

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

sc>А я вообще не понял разницы между нашим и немецким подходом. Наверное потому что в армии служил

sc>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.
sc>Например в приказе "копать канаву от забора до обеда" понятно только что нужно делать, но не как. Как — это уже твои проблемы. Для чего, всегда объясняли, например, для нового кабеля, старый уже в десяти местах рвался, весь в скрутках. И творческий, нестандартный подход к делу всегда только приветствовался. Например, собрать деньги (спирт) и нанять тракториста с соседней деревни.

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

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

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

sc>>А я вообще не понял разницы между нашим и немецким подходом. Наверное потому что в армии служил

sc>>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.
sc>>Например в приказе "копать канаву от забора до обеда" понятно только что нужно делать, но не как. Как — это уже твои проблемы. Для чего, всегда объясняли, например, для нового кабеля, старый уже в десяти местах рвался, весь в скрутках. И творческий, нестандартный подход к делу всегда только приветствовался. Например, собрать деньги (спирт) и нанять тракториста с соседней деревни.

G>Как, и в немецкой тоже служил?
А подумать? Или Вам нужно расписать место моей службы в мельчайших деталях? А как же Auftragstaktik?
G>Что, и у них тоже рытье канав является важнейшей задачей армии, которую всегда приводят в пример, когда речь о тактике заходит?
После правильного ответа на первый вопрос, это станет не актуален

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

sc>А как же Auftragstaktik?
Ну, во-первых, если уж на то пошло — я гражданский, и мне таких умных штук понимать не положено . А во-вторых — что все думать да думать, могу и я постебаться немного?

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

iT>Классная статья. Очень понравилась!
Рад стараться . Но, как вы поняли по дискуссии в моем ЖЖ, я не могу согласиться с вашим тезисом. По пунктам покажу вам отличие agile и scrum от той реальности, в которой работает auftragstaktik:

iT>

iT>Более того, человеческий фактор там значит не меньше, а возможно и гораздо больше — значимость боевого духа войск по сравнению с другими факторами оценивают как 3 к одному, и большинство специалистов оценивают его как решающий.

iT>Это scrum и agile вообще. "Люди важнее процессов". Самомотивация и стремление к цели.

"Люди важнее процессов" — это означает, что на процесс можно забить штоли? Странное акцентирование у вас в agile. Это похоже не на здравый смысл, а на подачку программистам — это распространенный миф, в который им хочется верить, наряду с мифом Крутого Хакера. Что важнее — танк или экипаж? Обе вещи важны, каждая по своему. Хорошо организованная группа людей очевидно сделает работу быстрее и эффективнее, чем неорганизованная группа очень важных людей. И ради того, чтобы получить эту организованность группы, я считаю вполне допустимым и необходимым жертвовать интересами некоторых людей.

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

iT>

iT>А именно — вы ставите подчиненному четкую цель, которой он должен достичь — по возможности математически точно описав критерии ее достижения, оставляя ему выбор способов ее достижения в соответствии с обстоятельствами, с которыми он столкнется при выполнении.

iT>Это в точности scrum. Sprint goal, backlog item с информацией о том, как это показать на демо.

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

Еще? Вот, например: подготовить техническое задание по проекту Х, срок такой-то.

iT>

iT>Если обстоятельства сильно изменились, принцип aftragstaktik предписывает ему нарушить приказ, чтобы соблюсти его дух, общий принцип.

iT>И это тоже scrum и agile. Нет смысла упираться рогом.

Докажи.

iT>

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

iT>Непременно надо включить вашу замечательную статью в семинар по scrum! Все как на подбор!
Хотите — включайте . Это не делает скрам лучше или хуже.

iT>Например, это — про то, как проводится planning day. Product owner рассказывает, что нужно получить и зачем это нужно в продукте.
Ну, рассказывает. И что? Причем здесь тема-то?

iT>

iT>То есть, они должны понимать, кто будет пользоваться их продуктом, и понимать, какую его потребность удовлетворяет их продукт.

iT>Ну конечно же scrum!
Нет, не scrum, а они должны понимать, кто будет пользоваться их продуктом. Это совершенно не одно и то же. Для этого не рассказы product owner-а нужны на planning day, а целостная маркетинговая концепция продукта.

iT>Каждый backlog item имеет четкий buisiness value.
Это как раз плохо. Следуя этому дурацкому ограничению, я не смогу применить "метод фреймворка" для сложной разработки, когда у меня несколько уровней требований, и между ними прослеживается трассировка. Зачем? Это совершенно необходимо, например, для разработки embedded софта потребительской электроники. Просто, чтобы вопиющий случай показать. Или же, это абсолютно необходимо в разработке разнообразных middleware, и прочих случаев, когда ваш потребитель не является конечным, и вы по сути продаете технологию. Или же, у вас система большая, и имеет "слоеную архитектуру". Ничего из перечисленного таким методом делать нельзя.

iT>

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

iT>Опять про scrum
iT>Менеджерские позиции в scrum'е по возможности выводятся за пределы команды.
Отвратительно. Это вносит дисбалланс в систему субординации и рвет связь между менеджментом и разработкой, делая ее неуправляемой. Сойдет с рук, если вы занимаетесь мелкой заказухой, и менеджеры ваши долдоны, и самоубийство при крупных проектах и продуктовой разработке.

Auftragstaktik — это в первую очередь механизм работы субординации.

iT>В процессе спринта команда сама решает, как делать ту или иную задачу. Кто будет ее делать, как делить работу.
Обычно новые термины (спринт) вводятся с целью запудрить мозги и замаскировать бредовость. А мне не надо, чтобы вы сами решали в процессе спринта, КАК делать фичу. Я хочу решить КАКИЕ фичи я вообще пущу в первую итерацию, с учетом информации по ее реализации и обратной связи. Менеджеров вы из команды вывели — и все, требованиями уже управлять стало невозможно. Ну просто полный autfragstaktik — разработка вслепую.

iT>

iT>Насчет agile. Отказ от управления требованиями на самом деле есть. Вы мне приводите в пример скрам, у него юзер сторисы — реально неплохая практика. Но где в скраме прописан процесс сбора, анализа и проверки этих требований? Да нигде.

iT>А где в aftragstaktik прописан процесс формирования, анализа и проверки цели, которую командир выдает подчиненному? Что-то я не нашел
1) Это leadership principle, которому подчинена вся система управления сверху донизу. А не набор процессов для работы исполнителей нижнего уровня, как ваш скрам. Смешно слушать, когда вы говорите "это скрам".
2) Выдергивать фразы из контекста и менять тему — это демагогия. Обсуждается тема, из которой вы фразу дернули — отказ от управления требованиями в скраме есть или нет? При чем тут auftragstaktik?

iT>

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

iT>Все укладывают, и даже в меньшие итерации. Чаще всего — в двухнедельные. Месяц — это реально многовато для итерации.
Ага. Все, кто пишет веб-сайты на PHP. А ты уложи в двухнедельную итерацию шедулер файберов для сервера базы данных. Или Фрагмент подсистемы хранения данных на диске в BTree, который делает что-то осмысленное.

iT>Главный враг любой деятельности — это догмы.
Ага. Это очень хорошо видно на примере agile. Никто не следует своим догмам настолько слепо и догматично, как сторонники agile. Ни на секунду не допускаете, что жизнь несколько сложнее. Крепка ваша вера, братья, истинно говорю . И главное ведь — fixed cost заказной делать толком не умеют, самую простую, распространенную, и лежащую на поверхности штуку, а рогом упираются, они мол пуп земли .

Поговори на эту тему с Асхатом Уразбаевым. Он организатор сообщества agile russia. Он тебе сразу скажет, что agile применим в узком классе проектов. Это простая и короткая разработка, и очень маленькие команды.

iT>

iT>По хорошему — в такой ситуации надо свернуть эти стори к простым элементарным операциям, ДОКАЗАТЬ, что в их терминах выразим интересующий нас класс юзер стори, после чего спокойно приступить к проектированию, имея в виду простые операции плюс несколько основных сценариев.
iT>Это — работает, и это эффективно. При таком подходе я могу боротся со сложностью. И это — ничего общего с agile не имеет.

iT>Это никак не противоречит scrum'у. Так и работаем.
Это в прямую противоречит скраму. Вы не можете так работать, и соблюдать скрам.

iT>Вот только фреймворки проектируем и рисуем не в первую очередь, опрометчиво рассчитывая на то, что у нас уже есть адекватные требования (а адекватных — нет),
Конечно, откуда они у вас возьмутся, если вы ими не занимаетесь. Было бы странно.

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

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

iT>

iT>А во-вторых — понимаете, auftragstaktik — это стиль руководства, он предполагает наличие единоначалия (у каждого четко прописана своя зона ответственности и свои полномочия принимать решения, никто не берет на себя чужой ответственности и не принимает чужих решений), и иерархии в системе управления

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

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

Единственный реально жизнеспособный процесс у вас во всем agile — это в FDD — он эти проблемы адресует. И то, с рядом оговорок.

iT>Еще раз спасибо за статью!
Не за что. Читайте на здоровье. Главное, чтобы в прок пошло.

iT>>Классная статья. Очень понравилась!
G>Рад стараться . Но, как вы поняли по дискуссии в моем ЖЖ, я не могу согласиться с вашим тезисом.

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

G>"Люди важнее процессов" — это означает, что на процесс можно забить штоли? Странное акцентирование у вас в agile.

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

G>Это похоже не на здравый смысл, а на подачку программистам — это распространенный миф, в который им хочется верить, наряду с мифом Крутого Хакера.

Можно поменьше злого сарказма?

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

Все верно. Речь о том, чтобы не пожертвовать их интересами совершенно "заздря". А в идеале — навести порядок, не жертвуя интересами.

G>Самомотивация — миф.

Нисколько. Никакие деньги не заставят человека работать с таким энтузиазмом, с каким он работает над тем, что ему интересно. Его уже пора палкой от компа отгонять, так ему хочется доделать чудо-фичу! Вот попробуй — заставь, замотивируй! Фигвам!

G>От того, что вы объявите всем, что они теперь самомотивироваться должны — все типа сразу пойдет на лад, да?

Конечно, нет. Передергиваете.
Естественно, нужно сделать так, чтобы человеку было максимально комфортно и интересно. Чтобы он захотел работать, если это есть в его природе.
Естественно, если он в принципе не хочет работать — с ним это не получится. Интересами таких людей действительно пожертвовать не жалко

G>Это не в точности скрам. Ставлю цель: .....Куда в точности скрам подевался? Какой нафиг спринт?
Никуда не подевался. Я не очень понимаю, что вы хотите продемонстрировать своей целью.
Поясняю. "Это в точности scrum" означает, что вы ставите цель, описываете критерии ее достижения, оставляя исполнителю свободу выбора пути ее достижения. Это один из основных принципов организации работы в scrum. Это почти буквально повторяет то, что вы пишете про Auftragstaktik.

iT>>И это тоже scrum и agile. Нет смысла упираться рогом.
G>Докажи.

Пожалуйста. Если в процессе спринта (скажем, в середине) вы вдруг обнаруживаете, что очень сильно отстаете, то не стоит бросаться работать по ночам или забивать на качество. Определите причины и примите решение, например, остановить спринт и перепланировать. Стандартная рекомендация.
Но, догадываюсь, что для вас это, наверное, недостаточно убедительно, и нужны какие-то более веские доказательства Мамой клянусь! Нет смысла упираться рогом! Be agile!

iT>>Например, это — про то, как проводится planning day. Product owner рассказывает, что нужно получить и зачем это нужно в продукте.
G>Ну, рассказывает. И что? Причем здесь тема-то?

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

G>Нет, не scrum, а они должны понимать, кто будет пользоваться их продуктом. Это совершенно не одно и то же. Для этого не рассказы product owner-а нужны на planning day, а целостная маркетинговая концепция продукта.

Мне непонятно, где вы здесь видите противоречие. Да, нужно, чтобы они понимали, кто будет пользоваться их продуктом. Это scrum, scrum, и еще раз scrum. Рассказ product owner'а — это и есть изложение "маркетинговой концепции", если вам так угодно. Естественно, в приложении в первую очередь к функциональности продукта, а не к привлечению инвестиций. Кстати, если ваш продукт только и ценен, что своей "маркетинговой концепции", а реально никому и даром не нужен — то фиг вы заставите разработчика работать эффективно.

iT>>Каждый backlog item имеет четкий buisiness value.
G>Это как раз плохо. Следуя этому дурацкому ограничению, я не смогу применить "метод фреймворка" для сложной разработки

Да можете! Можете! Почитайте "Scrum and XP from the Trenches", о том, как это работает на самом деле. Пообщайтесь с людьми, реально применяющими scrum. С тем же Асхатом обсудите этот вопрос подробнее. Тут у вас явное непонимание. Вспомните, что я писал про догмы. Вот, когда по верхам прочитают чего-нибудь, то и начинают критиковать простые основные принципы, представляя их как догматы.
Естественно, будучи воспринято как догма, это правило может работать сильно во вред! Ну так, если вы это понимаете — ну скорректируйте вы процесс так, как вам надо! От этого он не перестанет быть scrum'ом Честно-честно!

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

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

iT>>Менеджерские позиции в scrum'е по возможности выводятся за пределы команды.
G>Отвратительно. Это вносит дисбалланс в систему субординации и рвет связь между менеджментом и разработкой, делая ее неуправляемой. Сойдет с рук, если вы занимаетесь мелкой заказухой, и менеджеры ваши долдоны, и самоубийство при крупных проектах и продуктовой разработке.

Опять пытаетесь походя оскорбить и унизить Причем сразу весь коллектив менеджеров и организацию в целом. Ой, нехорошо.
Можно попробовать по-вашему: а докажите! Докажите, что "вносит дисбаланс" и "делает неуправляемой". Слова, слова, слова...
У меня вот есть контрпример. Скажем, длительный заказной проект с годовым бюджетом 4 млн.у.е. Я конечно, понимаю, что это для вас так, мелкая заказуха...

iT>>В процессе спринта команда сама решает, как делать ту или иную задачу. Кто будет ее делать, как делить работу.
G>Обычно новые термины (спринт) вводятся с целью запудрить мозги и замаскировать бредовость.

Я смиренно полагал, что так активно наступая на scrum вы соблаговолили хотя бы поверхностно ознакомиться с терминологией. Кварки цвета "charm" вас никогда не смущали своей бредовостью?

G>А мне не надо, чтобы вы сами решали в процессе спринта, КАК делать фичу.

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

G>Я хочу решить КАКИЕ фичи я вообще пущу в первую итерацию, с учетом информации по ее реализации и обратной связи.

Это как раз и есть забота product owner'а. Он и решает, какие фичи он пустит в первую итерацию. С учетом первичной оценки их трудоемкости.
Product owner'у для этого вовсе не нужно (необязательно, даже, скорее, нежелательно) быть членом команды, то есть самому участвовать в реализации этих фич.
Он должен знать свой продукт! Это главное. Донести цели, объяснить, зачем нужна очередная фича и почему она главнее многих других.

G>Менеджеров вы из команды вывели — и все, требованиями уже управлять стало невозможно.
Налицо некоторое непонимание. Отчего же невозможно?

G>2) Выдергивать фразы из контекста и менять тему — это демагогия. Обсуждается тема, из которой вы фразу дернули — отказ от управления требованиями в скраме есть или нет? При чем тут auftragstaktik?
Конечно же нету отказа от управления требованиями, о чем вы говорите??
В принципе Auftragstaktik, как вы его изложили (отлично изложили), так же как и в scrum'е, процесс формирования (и управления, если хотите) требованиями, очевидно, вынесен за рамки методики исполнения этих требований. Разве написано где-то в Auftragstaktik, как должны придумываться приказы, как должна определяться их приоритетность, как следует менять приказы, если что-то пошло не так, как вы планировали? Нет! Речь идет о том, как следует эти требования правильным образом отдавать на уровень исполнения.

iT>>Все укладывают, и даже в меньшие итерации. Чаще всего — в двухнедельные. Месяц — это реально многовато для итерации.
G>Ага. Все, кто пишет веб-сайты на PHP. А ты уложи в двухнедельную итерацию шедулер файберов для сервера базы данных. Или Фрагмент подсистемы хранения данных на диске в BTree, который делает что-то осмысленное.

Ну откуда столько агрессии и желания облить собеседника грязью? (простите, адепты PHP!)
Вы каждый месяц пишете шедулеры? Ну, сделайте одну итерацию длиннее. Не будьте догматиком. А лучше — все-таки найдите способ разбить задачу на несколько, поменьше.
Это правда, возможно гораздо чаще, чем кажется новичкам

iT>>Главный враг любой деятельности — это догмы.
G>Ага. Это очень хорошо видно на примере agile. Никто не следует своим догмам настолько слепо и догматично, как сторонники agile.

В эту игру можно играть вдвоем. Докажи!

G>И главное ведь — fixed cost заказной делать толком не умеют, самую простую, распространенную, и лежащую на поверхности штуку, а рогом упираются, они мол пуп земли .
Я дальше эту бессмысленную злобную ругань буду просто пропускать, ладно? Надеюсь, не будет упреков, что я замолчал тему и не швырнул банановой кожурой в качестве симметричного ответа?

G>Поговори на эту тему с Асхатом Уразбаевым. Он организатор сообщества agile russia. Он тебе сразу скажет, что agile применим в узком классе проектов. Это простая и короткая разработка, и очень маленькие команды.

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

iT>>Это никак не противоречит scrum'у. Так и работаем.
G>Это в прямую противоречит скраму. Вы не можете так работать, и соблюдать скрам.

Докажите, что не можем
И потом, а что вам важнее? Что это "не настоящий скрам", или что работа получается сделана качественно и в срок?

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

G>Конечно, откуда они у вас возьмутся, если вы ими не занимаетесь. Было бы странно.
Буквально парой строк выше писал, ну, повторю еще раз. Фреймворки и у нас есть. И не в один слой Налицо нежелание слушать собеседника, неверие и беспардонность.

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

Ай-ай-ай... Как это не обязан? Ну хоть спроектировать до соплей-то обязан? До последнего имени метода? Нет?? Это что ж — вы его по ходу дела будете дописывать? И может быть, начнете не с мелких утилитарных классов, а с самого главного, самого рискованного, самого нужного? Смотрите, как бы не получилось похоже на scrum

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

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

G>Ну надо же, "команда решает" . Ты сам не замечаешь, где прокол, нет? Ты понимаешь, что оценки сложности реализации фич влияют на приоритет, нет?

А вы понимаете, что ну совсем не представляете себе роль product owner'а при планировании в scrum? И всем это воинственно демонстрируете!
Естественно, оценка сложности фич влияет на приоритет! Команда оценивает трудоемкость, PO расставляет приоритеты! Сначала без, а потом с учетом этой оценки!
RTFM.

G>Не может "команда" здесь решать Ты понимаешь, что отвечать один человек должен всегда? Где у тебя человек в скраме, который несет личную ответственности за результат целиком?
И вот тут на сцену выходит менеджер проекта! Он не ставит задачи. Он их не оценивает, и не решает! Он успокаивает заказчика и следит за тем, как идет процесс в команде. Рулит ресурсами. Он смотрит на то, как работает команда, и что в ней идет "не так". Он может уволить человека из команды, или перевести в другой проект, если видит (а scrum очень много "выметает из под дивана"!), что толку от него ноль или меньше. Команда сама это сделать не может обычно. Менеджер разрешает конфликты, как внутри команды, так и между командой и заказчиком.
Короче, RTFM.

G>Как ты это отмасштабируешь хотя бы на две команды с общим кодом? А на пять? Ну на словах-то понятно, у вас проблем никаких — типа сказал заклинание "люди важнее процессов", и все .
Интересно, какой вас устроит ответ, если ответ "на словах" не устраивает?
Ну съездите к людям, у кого scrum внедрен на общем коде не только на нескольких командах, но эти команды еще и по всему свету разбросаны. Пообщайтесь, позадавайте свои каверзные вопросы! Объясните, почему они не могут работать по scrum, и почему они все такие лохи!
Было бы желание — найти таких людей можно без труда Через того же Асхата.

G>Единственный реально жизнеспособный процесс у вас во всем agile — это в FDD — он эти проблемы адресует. И то, с рядом оговорок.
Смотрели, не понравилось.
Кстати, вам не приходило в голову, что разным людям могет больше подходить разные процессы? Мне вот только сейчас эта мысль в голову пришла.
Кто-то, например, не может работать иначе, чем из под палки.
А кому-то вынь, да положь инструкцию, где написано, во сколько он должен обедать и как часто отлучаться по нужде.
Еще одному главное, чтобы его не трогали, "он работает один!".

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

G>Не за что. Читайте на здоровье. Главное, чтобы в прок пошло.
Видимо, пока не в прок, раз трачу столько времени на ответ, который, по всей вероятности, канет в пустоту непонимания и яростного нежелания понять.
Но, чем хорош публичный форум?
Один огрызнется, второй кинет какашкой, а третьему — на пользу пойдет! Только это и мотивирует на длинные ответы.

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

Удачи в благородных начинаниях!

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

G>>И главное ведь — fixed cost заказной делать толком не умеют, самую простую, распространенную, и лежащую на поверхности штуку, а рогом упираются, они мол пуп земли .
iT>Я дальше эту бессмысленную злобную ругань буду просто пропускать, ладно? Надеюсь, не будет упреков, что я замолчал тему и не швырнул банановой кожурой в качестве симметричного ответа?

Ну разумеется ты замолчал тему. Сказать-то по существу тебе нечего, только банановыми кожурами швыряться остается. Это известная на весь мир дыра твоего agile, не я ее выдумал. Ну не можешь же ты в самом деле начать объяснять, каким именно образом ты будешь вести проект сроком примерно в год, когда от тебя на ранней стадии требуется порезать проект на этапы, определить требования, прикинув сроки этапов и спланировав бюджет. А по итогам первого этапа длиной в месяц-два от тебя требуется внести окончательные коррекции в ТЗ, зафиксировав требования и план.

iT>Я знаком с Асхатом довольно хорошо. Даже если вам он так и сказал (а я в этом не уверен), то я догадываюсь, почему Попробуйте догадаться сами.
Нет, мнеон такого не говорил. Мне достоверные источники рассказывали, что он это в слушателям всех своих семинаров говорит, в самом их начале. Говорит он так потому, что дорожит своей репутацией, и глупостей говорить не хочет — на бизнесе плохо сказывается.

iT>И потом, а что вам важнее? Что это "не настоящий скрам", или что работа получается сделана качественно и в срок?

А что, если я работу и так делаю качественно, и в срок — безо всякого скрама? Я наверное что-то не так делаю?

G>>Не может "команда" здесь решать Ты понимаешь, что отвечать один человек должен всегда? Где у тебя человек в скраме, который несет личную ответственности за результат целиком?
iT>И вот тут на сцену выходит менеджер проекта! Он не ставит задачи. Он их не оценивает, и не решает!
"И тут на сцену вышли клоуны, и стали показывать нумера." Не завидую вашему менеджеру. Надо же, задач не ставит, ничего не оценивает, и ничего не решает. Зато за всю вашу халабуду отвечает на полную катушку, а сам исключительно пьет валидол и заказчика успокаивает. Ответственность не подкрепленная полномочиями, зашибись. Удобно как вы устроились.

iT>Короче, RTFM.
И он мне еще после этого РТФМ-ами тыкает. Простите за солдатскую прямоту, но такие РТФМ-ы я предлагаю вам засунуть туда, где им самое место. Ну, я имею в виду, в красивую рамочку на стенку повесьте, не подумайте плохого .

Есть два правила, которые соблюдать необходимо, чтобы система управления работала. ЛЮБАЯ система.
1) Личная ответственность. Отвечать должен один человек. Отвечает несколько — не отвечает никто.
2) Ответственность должна быть обязательно подкреплена полномочиями. Человек не может отвечать за те факторы, над которыми не имеет контроля.

G>>Как ты это отмасштабируешь хотя бы на две команды с общим кодом? А на пять? Ну на словах-то понятно, у вас проблем никаких — типа сказал заклинание "люди важнее процессов", и все .
iT>Интересно, какой вас устроит ответ, если ответ "на словах" не устраивает?
iT>Ну съездите к людям, у кого scrum внедрен на общем коде не только на нескольких командах, но эти команды еще и по всему свету разбросаны. Пообщайтесь, позадавайте свои каверзные вопросы! Объясните, почему они не могут работать по scrum, и почему они все такие лохи!

Ну зачем мне разъезжать по незнакомым мне людям, и объяснять им, какие они лохи. Оставив в стороне экстравагантность вашего предложения, коллега — пусть остаются какие есть. Бизнес — это война. И с этой точки зрения вовсе не так плохо, что многие компании теряют компетенции в успешном ведении контрактов fixed cost. А следуя правилам "исскуства войны" Сунь Цзы — мне никак не следует к ним ездить. Потому, что "если вы сильны — враг должен думать, что вы слабы". А я правила старика Сунь Цзы чту, так что нипочем не поеду. Кстати, я вижу, что агилисты тоже вольно или невольно следуют советам Сунь Цзы. Потому, что дальше он сказал — "а если вы слабы, то враг должен быть уверен, что вы сильны".

Ну а Time boxing применить при планировании, к чему сводится на самом деле ВЕСЬ ваш скрам, и я смогу, когда это реально потребуется — было бы о чем говорить, это самый тупой и простейший прием. Просто удивительно, сколько всего можно высосать из пальца вокруг одного единственного приема планирования.

G>>Единственный реально жизнеспособный процесс у вас во всем agile — это в FDD — он эти проблемы адресует. И то, с рядом оговорок.
iT>Смотрели, не понравилось.
iT>Кстати, вам не приходило в голову, что разным людям могет больше подходить разные процессы? Мне вот только сейчас эта мысль в голову пришла.
Вовремя вам эта мысль пришла, однако. Столько пикселов исписать успели. Не людям, а организациям. Scrum хорош, если вы делаете веб-сайты на заказ, и прочие проекты, где вы своих технологий не изобретаете, а комбинируете существующие, и вся фишка в юзабилити. И которые слишком короткие, чтобы полномасштабный процесс оправдать. Короче, любой проект, где быстрее сделать и показать, чем с требованиями и спеками возится (это подразумевает "легкие" технологии вроде скриптовых языков), и которые не надо потом поддерживать. Еще одна индустрия, где скрам скорее полезен, чем вреден — это компьютерные игры. Хотя уже здесь скрамом можно проект зафакапить в два счета.

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

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

iT>Врядли буду продолжать дискуссию, т.к. не верю, что кто-то из собеседников сменит мнение, и в дальнейшем обсуждении будет польза.
Вы сначала определитесь с тем, что именно вы хотите мне доказать. А то мне кажется, вы сами этого толком не знаете.

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

G>Помните здесь были дискуссии про военные методы в разработке ПО? Последнее время я очень плотно интересуюсь военными методами управления. И обнаружил массу интересного. У меня для вас есть кое-что — я написал небольшую заметку про немецкий принцип Auftragstaktik. Совершенно великолепный принцип. ЭТО и есть квинтэссенция управления. Постоянно нарушаемая на местах многими "гражданскими" людьми, очень умными, с высшим образованием полученном в неплохих ВУЗах, и, когда доходит до реального руководства людьми — являющихся почему-то классическими образчиками ментальности "сапогов" из начала 19 века.
G>Чему это может научить современного менеджера в разработки ПО? Многому, уважаемые коллеги. Мы раскроем суть этого принципа.
Дык для начала — напишите устав. Потом примите присягу. А потом уж и требуйте по уставу.
А без устава и присяги на верность — какой же дурак будет следовать приказам?!

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

LVV>Дык для начала — напишите устав. Потом примите присягу. А потом уж и требуйте по уставу.
LVV>А без устава и присяги на верность — какой же дурак будет следовать приказам?!

Не, не так. Для начала ткните в ссылку внизу поста. Потом прочитайте, что там написано. А уж потом и пишите в форум! Без этого какой же... замечательный человек будет в форум-то писать?! Или есть такие? Да неужели?!

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

G>Еще одна индустрия, где скрам скорее полезен, чем вреден — это компьютерные игры. Хотя уже здесь скрамом можно проект зафакапить в два счета.
Нет, только не скрам! При написании игры, если речь не идёт о простой Java-игрушке для мобильника, приходится проводить много НИОКР. Поэтому лёгкие методологии не подойдут. Можно загубить проект.

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

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

G>>Еще одна индустрия, где скрам скорее полезен, чем вреден — это компьютерные игры. Хотя уже здесь скрамом можно проект зафакапить в два счета.
КЛ>Нет, только не скрам! При написании игры, если речь не идёт о простой Java-игрушке для мобильника, приходится проводить много НИОКР. Поэтому лёгкие методологии не подойдут. Можно загубить проект.

Знаешь, насчет игр я только предполагаю — сам в их разработке не участвовал. Предполагаю потому, что обычно
1) Там относительно небольшая команда разработчиков (насколько я слышал).
2) Там надо много экспериментировать с "играбельностью" на живых прототипах (мне так кажется) — это может радикально сказаться на результате.
3) Есть много публикаций о применении скрамоподобных штук в game development.

Но на самом деле — насчет игр я не уверен совершенно, опыта нет.

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

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

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

есть одна книга, посвященная этому вопросу
написана психологом, оказавшимся в одном из таких лагерей

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

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

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

Рассматривайте. Потом статью напишете.

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

КЛ>Т.е. вместо "самолёт должен иметь не шасси, а лыжи" пишут "самолёт должен приземляться на льдины и ледяные лётные поля".

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

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

G>Итак, что же делать с документами требований? Очень просто. Они просто обязаны на половину состоять из маркетинговой части. Которая должна давать внятные ответы на вопросы, для кого делается продукт, и какую потребность мы удовлетворяем. Почему продукт крут. За что его будут покупать. Почему именно от него будут в восторге. Это — важнее деталей, это просто обязано не потеряться по дороге. Кроме того, надо внятно и точно обозначить критерий успеха проекта.

То, что ты описал, и есть BRD (Business Requirements Document)

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

IT>Should — это, конечо, правило ... для американца. А для русского?

А по-русски "should" будет "должен".

IT>Я правила изучал в Атланте много лет назад и специально искал тогда упоминание о помехе справа. Не нашёл

Возможно потому-что искал предложение без слова "should".

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

COFF>Ну, в конце-концов, Германия ведь проиграла. Так что практика не на стороне данного подхода =)

В СССР тоже ведь нередко приказывали не "как", а "что":

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

(http://www.trud.ru/issue/article.php?id=200003230530802)

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

A>Самое время вспомнить книгу Алана Купера "Психбольница в руках пациентов: Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие"

О да! Этот Купер придумал Visual Basic!

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

IT>>Should — это, конечо, правило ... для американца. А для русского?
I>А по-русски "should" будет "должен".
Нет, про русски "should" будет "рекомендовано".
Именно об этом и говорит IT, должен это "must" ну или "have to" (менее должен чем must).

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

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

IT>>>Should — это, конечо, правило ... для американца. А для русского?
I>>А по-русски "should" будет "должен".
A>Нет, про русски "should" будет "рекомендовано".
"Should" is most commonly used to make recommendations or give advice. It can also be used to express obligation as well as expectation. // первый ответ гугла на слово should

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

I>А по-русски "should" будет "должен".

Не должен, а следует. I should go — мне нужно (пора) идти, в отличии от I gotta (have to) go — я должен идти (и хрен ты меня остановишь).

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

IT>Не должен, а следует.

Почему же тогда should не правило для русского?

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

A>"Should" is most commonly used to make recommendations or give advice. It can also be used to express obligation as well as expectation. // первый ответ гугла на слово should

Ну и как нужно переводить в контексте ПДД: recommendation, obligation или expectation?

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

A>>"Should" is most commonly used to make recommendations or give advice. It can also be used to express obligation as well as expectation. // первый ответ гугла на слово should
I>Ну и как нужно перевотить в контексте ПДД: recommendation, obligation или expectation?
should -- это модальный глагол переводить его существительным бессмысленно, как минимум нужно добавить к этому существительному предшествующий глагол.
В итоге получим: "to make recommendations" (давать рекомендации), "to express obligation" (выражать обязательства), "to express expectation" (выражать предположения).
К правилам выражение обязательств и предположенй (со стороны правил) не относятся, получается should используется в смысле "давать рекомендации".

Только вот непонятно зачем вы к этому цепляетесь? Вам скучно и нечем заняться?


СУВ, Aikin

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

A>К правилам выражение обязательств и предположенй (со стороны правил) не относятся, получается should используется в смысле "давать рекомендации".

В правилах дорожного движения даются рекомендации, а не выражаются обязательства?