Category: армия

cartoon

О типичном вопросе начинающих руководителей

Из дискуссии на РСДН. Вопрос кажется мне важным (хоть и элементарным), публикую здесь. Черным - мои ответы, здесь я склеил несколько сообщений, чтобы был понятен контекст. Курсивом - мои комментарии, сделанные сейчас.

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

S>>> "Есть мнение, что проекты они и в африке проекты. И качественный ПМ одинаково хорошо разрулит проект разработки новой соц. сети и проект по постройке нового стадиона"
 
S_D>>Оно конечно качественный пм может и разрулит проект стадиона...


Вы всерьез готовы предположить, что "качественный ПМ" может что-то "разрулить" в проекте стадиона, не зная профильных ГОСТов, не имея понятия о том, что такое СНИП, не представляя основ техпроцесса, особенностей логистики данного типа проектов, и типовых проблем проблем строительства?  Правда? 

S>если ПМу нужно знать ГОСТы, то например, кирпичи класть ему тоже нужно уметь?
Collapse )


cartoon

Современные командные принципы: слайды презентации с SWP'11

Аннотация:
- Цель управления как выполнение скоординированного и целенаправленного командного действия
- Понятие "трения", как основного отличия плана на бумаге от практического действия.
- "Тактика миссии" (Auftragstaktik) как философия управления, необходимая для преодоления "трения".
- 5-paragraph order и процесс планирования корпуса морской пехоты США, как пример системы, реализующий принцип тактики миссии.
- "Трение" в различных типах оргструктур в компаниях разработчиках ПО, и их совместимость с "тактикой миссии"

Collapse )

PS: US Marine Corps - рулят. 5§П - рулит со страшной силой. Для понимания стоящего за ним принципа - понимание разницы между Auftragstaktik и Befehlstaktik совершенно необходимо. Если, конечно, вы не прошли специальный тренинг в специально предназначенных для этого местах :).

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

Практика применения ГОСТ (ЕСКД/ЕСПД) в больших программах (в которых используются ЧТЗ) - удивительно близка к описанному подходу. Прямой аналог 5§П - это наше ТЗ.

Вот такие выводы на текущий момент, уважаемые коллеги. Доклад представляет собой последний и актуальный "срез" моего взгляда на проблему управления.
cartoon

Пять принципов

- Слушай, я вот что подумал. Ты ведь руководящей работой занимаешься давно. А ты не пробовал обобщить свой опыт, и выделить основные принципы, которым по твоему должен следовать хороший руководитель? Принципы, определяющие успех. Главное в работе. Так, чтобы списком тезисов, кратко, и в порядке убывания важности. Не менее трех, но не более семи.
- Хм... Интересная постановка вопроса... Ни разу в таком ключе не думал.
- Интересно попробовать?
- Интересно...
- Ну так что молчишь?

Collapse )
cartoon

О психологических аспектах инженерной работы

DRAFT. Продолжение следует вместе с редакторской правкой.

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

Я буду по-простому рассказывать, без зауми.

Начну с такой простейшей штуки, как... гхм... как это назвать... вы играли в Heroes of Might & Magic? :) Там когда сражение происходит в пошаговом режиме, иногда бывает, что ваши войска пропускают ход, а иногда - делают второй ход вне очереди? Помните?

Это происходит в данной игре благодаря такому механизму, как "мораль". Если "мораль" войск высокая - они могут с некоторой вероятностью сходить дважды за ход. Ну, а если мораль низкая - то могут ход пропустить.

Так вот, эта самая "мораль" (т.е. фактически - "боевой дух") присутствует и в нашей работе. И так же, если не сильнее, влияет на результат.

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

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

И те же самые задачи кажутся легкими, если "мораль" высокая. Знакомо? :) Бывает такое? :) И это ощущение, бывает, что меняется от задачи к задаче в течении одного проекта! Некоторые задачи вызывают приступы неизбывной тоски, некоторые - наоборот, охотничий азарт.

Иногда это свойство отдельных задач, а иногда - мы впадаем во временную депрессию, и нам все задачи кажутся неподъемными и геморройными. Пальцы - не печатают! А делать надо! И это ощущение нас гнетет, и от этого тоска становится еще сильнее - замкнутый круг. Но - бывает и наоборот! Еще как бывает!

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

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

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

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

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

Если мы сталкиваемся с такой задачей, мы находим массу рациональных причин отложить ее. И это вполне естественно.

Ибо, мы, работая над этой задачей, длительное время не получаем положительного "подкрепления". Ничто не поднимает "боевой дух" так, как победа.

Примерно то же самое (отсутствие значимого "подкрепления"), кстати, происходит при длительной работе с задачами категории (1) - какая это нафиг "победа". Но там хоть прогресс четко виден.

Однако, что получается, если мы знаем _весь_ план работ? Что, если мы знаем, что в проекте таких задач _много_?

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

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

Описанные эффекты лежат в природе известного явления - когда проект бодрячком продвигается по графику до 90%, после чего намертво встает на месте. И все забегали. Потому, что инженеры вдруг, внезапно, разводят руками, и не в состоянии ни перепланирование сделать, ни сроки уточнить.

Почему? Да потому, что они субъективно "геморройных" задач в конец надвигали. С сугубо рациональным, техническим, конечно же, обоснованием. Догадываетесь, что произойдет с инженерной "моралью" в этот момент, когда проект "почти" завершен, а там, в конце плана, _такое_? Да что там. Думаю, многие бывали в такой ситуации.

Технические риски, ага. Сложность. Неизвестность. Надо, типо, учитывать и планировать. Квадрат Кантора, и все такое - критичные рискованные задачи вперед. Писал про это.

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

То есть, что получается. Уровень риска технических задач - величина сугубо субъективная, и зависит не только от знаний, опыта, и компетенции исполнителя, но и очень во многом от "боевого духа" и психологического состояния. Шансы справиться с задачей зависят от того, верит-ли исполнитель в то, что у нее должно быть простое решение, или же он уверен в обратном.

Итак, главное - что же делать.
1) В обязательном порядке планируйте свою работу, чтобы видеть, сколько осталось до конца.
2) Всегда отделяйте планирование от выполнения. Категорически противопоказано выдумывать себе следующую задачу после окончания предыдущей!
3) Следуя заветам GTD, составив план, немедленно запишите его и забудьте, сконцентрировавшись на текущей задаче и только на ней. Составили - все, нехрен над ним раздумывать. На план глядите только для отмечания прогресса.
4) Вам надо столкнутся с задачами (3) _сразу_, в начале проекта, пока у вас высок "боевой дух". Если они настигнут вас в конце - вы этого не переживаете. Чтобы с самого начала проекта попасть в ад, используйте квадрат риск-приоритет Кантора.
5) Не питайте иллюзий, что у вас легко получится использовать квадрат Кантора, если вы планируете собственную работу. Использовать квадрат кантора для планирования своей работы крайне тяжело психологически. В ситуации, когда от правила Кантора наибольший эффект, для того, чтобы им воспользоваться - надо буквально, по ощущениям, наступить себе на яйца. Гусары, молчать! Включаются очень интересные механизмы избегания, выражаясь научным языком. :)
6) Очень хорошо, когда у вас есть толковый менеджер, который может выполнить правило кантора, и лично не вовлечен в работу над задачей. Это нивелирует пункт 5).
7) Не бойтесь задач. Термины вроде "эта задача - пиздец" употреблять противопоказано. Старайтесь убедить себя, что задача проста, что у нее есть простое решение, и вы его сейчас просто не видите. Но еще немного, - и увидите. И тогда скажете - ну я же говорил, это простая задача! :)

DRAFT. Продолжение следует вместе с редакторской правкой.
cartoon

Производственная ментальность

Из дискуссии на RSDN. Давно хотел об этом написать, и подвернулся повод.

Собственно, с лекции о "производственной ментальности" я начинал свой трениг в Одессе для Codedgers". Это - основополагающая "лекция", необходимая для правильного понимания всего моего материала. Здесь - в ужатом варианте. В полном варианте я очень детально рассматриваю конкретные проявления "производственной ментальности" в методологии PSP/TST, основанной на CMMI (могу, благо работал под ней и официально сертифицирован), и в сетевом планировании.

...

Ну да. Позже я пришел к выводу, что разделение на defined и empiric процессы само по себе не вполне корректное и не самое точное. Более правильно взглянуть на проблему под чуточку другим углом.

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

Collapse )
cartoon

Декларативное планирование: презентация

Как и обещал, выкладываю презентацию к своему докладу.

http://files.rsdn.ru/20496/Auftragsplanning%20pre-final.pptx
Краткое содержание.

Текущее состояние дискуссии о процессах разработки - специалисты разбились на два лагеря. defined process (CMMI), empiric process (Agile).

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

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

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

Сетевой график, состоящий из активностей, в духе defined, не адекватен проектам разработки ПО - он из альтернативной реальности, в которой работает waterfall. Процесс разработки ПО представляет собой по сути процесс решения проблем, а не процесс доставки артефактов, и характер активностей так же как и структура артефакта может меняться по ходу работ. Активности просто нельзя заранее расписать.

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

Truth is out there. Как на проблему глядят военные. Более практичный взгляд.

Auftragstaktik vs Beheflstaktik. Приказ в терминах действий. Приказ - миссия.
- как отдавать приказы
- как исполнять приказы, тип подчиненного, и корпоративная культура.
- Behefldtaktik как микроменедмент.

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

Как решается проблема планирования. Сетевое планирование = befehlstaktik. Потому и плохо работает. Активности -> цели = решение проблем = auftragstaktik = разработка ПО. Альтернатива традиционному подходу к группировке задач. Разработка плана от конечной цели. Свойства предлагаемой модели.

Паттерны в планах = "процессы". То, что будет часто встречаться в ваших планах. Цикл разработки RUP - как общий процесс решения проблем. Как обходится с итеративной активностью. Как выражается параллельная активность, и "параметрические" планы (aka процессы). Семантика "декларативного" плана и его связь с активностями.

Планы в разработке ПО. Как их все-таки составлять. Подход к составлению плана от функций и тестов. "Декларативное" определение понятия связности. Общие "системные" функции, и как отражать их в плане.
cartoon

Аннотация к моему докладу на SoftwarePeople



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

В докладе будет представлена методика планирования, основанная на опыте кросс-дисциплинарных проектов в области разработки ПО, аппаратных комплексов, и микроэлектроники. Методика представляет собой систематический подход к планированию эмпирических процессов, увязывающий воедино problem solving и process engineering, и решающий обозначенную проблему. Данный подход делает практичным кастомизацию процесса разработки под каждый проект, позволяет проверять планы на логическую корректность, и в целом значительно упрощает групповую работу над планом, повышая его качество.

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

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

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

Второй способ использования данной модели близок по духу к agile - работать непосредственно с "картой целей", применяя тайм-боксинг планирование для определения их дат.

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

Происхождение auftragstaktik

Происхождение Auftragstaktik,
Major General Werner Widder, German Army
MILITARY REVIEW
September-October 2002

This article is adapted from an address MG Widder gave to CGSOC class 2002 on 3 April 2002 at Fort Leavenworth, Kansas.—Editor

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

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

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

Collapse )
cartoon

Auftragstaktik!

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

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

"The concept of Auftragstaktik or "mission tactics" … made it the responsibility of each German officer and NCO … to do without question or doubt whatever the situation required, as he personally saw it. Omission and inactivity were considered worse than a wrong choice of expedient. Even disobedience of orders was not inconsistent with this philosophy."

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

Collapse )