?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Инжиниринг [09 Sep 2007|08:31am]
TWIMC: я планирую отсутствовать в Москве с 10 по 13 сентября -- буду изучать судьбы отечественного инжиниринга на Ростовской АЭС (Волгодонск).
* * *
Я, наконец, могу выразить словами, что меня очень-очень заводит: этот самый инжиниринг. Меня впечатляет, как люди могут за конечное время делать очень сложные продукты. И волнует тут меня не рыночная часть, а именно плановая. Как ASUS ухитряется выпускать новые компьютеры в срок и в соответствии с бюджетом, и в огромных количествах моделей -- и при этом ни одна деталька в них не является пропущенной?! Как японцы ухитряются монтировать атомную станцию за 36 месяцев?! Любая такая задача требует стыка между проектированием сложнейшего технического объекта, планированием разбиения работ, заключения порядка тысячи контрактов, координации всех этих контрактованных работ. Как это вообще возможно?! Какие титаны мысли это могут держать в голове?!

И тут быстро выясняется, что держится все это обычно не в голове -- ибо не бывает таких голов. Вот тут и наступает самое для меня интересное: разобраться в том, как это все устроено, и как можно улучшить и без того чудесную инжиниринговую машинку. Инжиниринг инжиниринга, моя любимая мета.
* * *
Работы по http://praxos.ru интенсивно используются в клиентской работе. Другое дело, что значительная часть этих работ еще не оформлена текстом -- семинары в последнее врмя шли отнюдь не только по четвергам, и сделано было довольно много.

Будем делать машинима по управлению нормами и управлению работами.

Дальше фокус будет на управлении ресурсами, управлении показателями и объединяющем все это организационным моделированием.

Кстати, вышла очередная версия текста по организационному моделированию -- http://praxos.ru/index.php/Рассказ_об_организационном_моделировании.
* * *
Мой доклад в Светлогорске (http://praxos.ru/index.php/Презентации) продолжает получать отзывы. Я узнал, что
-- в нем совсем не затронут софт PraxOS -- а ведь это должна быть очень важная часть,
-- в нем много говорится о софте,
-- он на такие важные темы, как организационное бессознательное.

Мне становится самому интересно: что же я там такого сказал?!
* * *
Осень намечается очень суетная и рабочая.
6 comments|post comment

Переоткрытие Slim Devices. [09 Sep 2007|11:39am]
Коробочка SlimDevices, играющая "коробочным звуком" у меня на кухне (за что она мной была не слишком любима -http://ailev.livejournal.com/384867.html), была опробована в качестве плейера на моем рабочем месте. Я просто притащил эту коробочку, поставил на полку и вместо ноутбука воткнул в микшер ее.

И обалдел. Ошизел. Офонарел.

Ибо я вдруг услышал -- ЗВУК. Прозрачный, детальный, с восхитительной панорамой, как раз то, чего мне не хватало все эти годы. Ибо для коробочки Burr-Brown DAC просто не хватало студийного звукового тракта. Уж не знаю, в чем там передрались электрические боги с акустическими музами, но эта коробочка напрочь переигрывает любой из моих ноутбуков (включая "медийный" Sony). Поэтому ноутбук в качестве плейера уволен без выходного пособия.

Звук на рабочем месте у меня сейчас такой, что захотелось переслушать все 523 часа (547 альбомов), которые болтаются у меня на сервере. Оказывается, я не только меломан, но и аудиофил тоже.

UPDATE: все оказалось не так радужно -- SlimDevices играют точно так же, как ноутбуки. Один в один -- я сделал сейчас хитрую схему перепроверки, заведя на микшер оба сигнала, и выяснил это прямым сравнением. Видимо, я соскучился по музыке за последнюю неделю, если вдруг возбудился от того же самого звука вчера вечером. Более того, в режиме эффекта довосстановления высоких частот (BBE) в ноутбучном плейере JetAudio звук становится даже более прозрачным, чем в SlimDevices. Что не меняет факта: я оставлю SlimDevices в качестве штатного. Ибо с его пультом дистанционного управления теперь можно менять треки и громкость, не вылезая из постели.
post comment

Алан Купер, "Психбольница в руках пациента": половину пишем, половину на ум кладем. [09 Sep 2007|10:48pm]
У меня в комментах часто цитируют Алана Купера "Психобольница в руках пациента" (http://www.fictionbook.ru/author/kuper_alan/psihbolnica_v_rukah_pacientov/kuper_psihbolnica_v_rukah_pacientov.html). У меня к этой книжке смешанное отношение: половина ее крайне полезна безусловно, а половину нужно применять строго "по рецепту врача" -- ибо полезность рекомендаций Купера может сильно зависить от конкретной ситуации.

Начнем со странного понимания Купером функций:
Что я могу сказать хорошего о функциях? Они поддаются измерению. И это свойство измеримости придает им ауру ценности, которой в действительности они не обладают. Отрицательные качества функций полностью съедают все их положительные качества. Функции – причина одной из серьезных проблем проектирования, потому что каждая возможность, предложенная из лучших побуждений и потенциально полезная, оттеняет некоторые возможности, которые, вероятно, будут действительно полезны. Разумеется, реализация возможностей не бесплатна. Каждая из них усложняет продукт. Они требуют увеличения размера и сложности документации и системы контекстной справки. Что еще важнее, с точки зрения затрат они требуют раздувания штата технической поддержки, занятого в консультировании пользователей относительно этих самых возможностей.

Для нашего зациклившегося на функциях мира мысль, наверное, непривычная – вы не достигнете своих целей, используя набор функций, как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.
Забавный этот Алан Купер: разве "на этом удобно сидеть" или "быстро и легко срезает траву" -- это не функции?! Ведь другое слово для функции -- это предназначение. "Рулевое колесо" -- это не предназначение, однозначно. Это не функция, не возможность (feature, фича). Фича -- пользовательская story "возможность срезать траву в заданном направлении", а "рулевое колесо" -- это story разработчика. Или это все ошибки перевода, и у Купера все много корректней?

А вот прямо про наши заботы:
Ошибочно одно из фундаментальных предположений программ для управления проектами, а именно: людям необходимо помочь понять, как надо действовать в рамках проекта. Большинство людей довольно успешно справляются со своими проектами; ведь такова их работа, в конечном итоге. Увязывание нескольких проектов в единое расписание – вот в чем действительно требуется помощь. Ресурсы (обычно подразумеваются люди) одновременно задействованы в нескольких проектах. Они начинают и заканчивают проекты один за другим, иногда с некоторым наложением, так что большая часть проектов стоит в очереди, ожидая своей судьбы. Недостаточно распределить людей по проектам, необходимо иметь возможность назначить одного человека на работу в нескольких проектах.
Из книжки мне понравилась модель не самого Купера, а Larry Keely из Doblin Group -- трехногая табуретка качеств продукта в бизнесе высоких технологий.
Первое качество -- потенциал, его обеспечивают инженеры, он отвечает на вопрос "что технически возможно".
Второе качество -- жизнеспособность, его обеспечивают бизнесмены, оно отвечает на вопрос бизнес-модели, "можем ли мы этим торговать".
Третье качество -- привлекательность, "чего люди хотят" (и не путать с "в чем люди нуждаются"):
Алан Кей пишет "Меня привлекает возможность провести полтора месяца на Бермудских островах, но мне это не нужно. Если у меня желчные камни, то я нуждаюсь в операционном лечении, но меня это не привлекает. Риэлтор Салли нуждается в том, чтобы продать четыре дома в этом году. А возможность обеспечить четыре семьи счастьем и уютом ее привлекает. ... На короткий срок человек может оказываться под мощным влиянием своих потребностей, но в долгосрочной перспективе его желания могут оказывать более сильное и более выраженное воздействие. Желания людей всегда находят выход после того, как удовлетворены потребности. Когда человеку что-то нужно, он сделает то, что необходимо, чтобы это получить, но если человека что-то привлекает, он предан этому. Он знает, что тратит свободные средства, оставшиеся после удовлетворения потребностей, и поэтому купит то, что приносит счастье, причем, не обязательно исходя из рациональных суждений.
Про homo logicus очень хорошо сказано: "Программисты пожертвуют простотой ради контроля. Обменяют успех на понимание. Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. И, наконец, ведут себя грубо и прямолинейно, как быки". Я сам с огромным трудом избавлялся от этих своих свойств, и до сих пор не полностью избавился! Купер тут пишет многие вещи, которые мы неоднократно обсуждали в другом языке. Так, "очень простой в использовании софт без лишних настроек" Г.Лебедев неоднократно сравнивал с учебным автомобилем и предлагал делать как учебный (см. пункт 6 из http://ailev.livejournal.com/450527.html), а конфликт интересов между пользователем и программистов мы обсуждали еще двадцать пять лет назад, когда обратили внимание, что многие суперпрограммисты работают парами -- и один из них обычно защищал интересы пользователя и задачи, а второй -- эффективности программирования и ресурсы компьютера (именно так парой мы в свое время работали с А.Акопянцем).

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

Часть четвертая -- про целеориентированное проектирование -- интересна, но тоже набор общих уже мест. Автор явно обращается к подходу "мощных идей" (http://praxos.ru/index.php/Мощные_идеи:_принципы_и_практики): "В основе метода лежат нетрадиционные подходы к проблемам, ряд мощных руководящих аксиом, а также некоторые поразительно эффективные мыслительные инструменты".

Первая мощная идея тут -- проектирование под выдуманного "персонажа", и требование того, чтобы такой персонаж был один (а не удовлетворение "коллективного интереса"). Мы точно такой ход используем при организационном проектировании, когда выдумываем персонаж "идеального акционера" (http://praxos.ru/index.php/ИдеальныйАкционер). Персонаж должен целиться в "длинную шею", а не "длинный хвост": тут верное замечание, что "homo logicus думают об исключениях, а проектировщики -- о наиболее частом случае".

Точное описание пользователя продукта и его целей -- это ведь уже не про "персонаж", а тоже общее место: если вы проектируете систему, то должны определить ее функцию, назначение. Для этого вы должны понять, что нужно ее владельцу/пользователю. Это говорит и Голдратт в книжке "Цель", и многие другие авторы. Это суть системного подхода: смотреть не сразу внутрь системы, а определить, чьей подсистемой является наша целевая система -- и внутрь лезть только после этого, только после определения чья это система и какие ее функции.

Вторая идея -- про различение стабильных целей (назначения) и промежуточных (в терминологии Купера -- целей и задач, в терминологии Голдратта про то же самое говорится как о глобальном максимуме и локальном максимуме). В принципиальных конфликтах это же разделение задается как "истинные потребности" сторон против "высказываемых предложений". Купер указывает на то, что тут чрезвычайно легко все перепутать:
Противопоставление целей и задач встречается сплошь и рядом. Если президент желает, чтобы за океаном наступил мир, он посылает пехотинцев, вооруженных автоматами, самолетами, бомбами. Его задача – война. Его цель – мир. Когда адвокат корпорации желает избежать конфликта с коллегой, то вступает в прения о положениях контракта. Цель адвоката согласие, а задача – спор.
Цель – стабильная сущность. Задачи преходящи. Вот одна из причин, по которой проектирование под задачи не всегда уместно, а проектирование под цели уместно всегда.
Тут нужно только договориться о терминологии, и будет готовый паттерн мощной идеи. Дается эвристика: цели стабильны и выражаются "вечными словами" типа "удобно, быстро, дешево". Промежуточные цели (т.е. задачи по Куперу) зависят от используемой технологии и меняются с ее использованием, они не так важны. Классификация целей -- личные, корпоративные, практические (в порядке убывания важности). Тут добавить нечего, это общее правило при проектировании любых систем.

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

Иначе говоря, у людей есть особые инстинкты, подсказывающие, как надо вести себя рядом с другими разумными существами, и как только произвольный объект демонстрирует достаточно серьезное когнитивное сопротивление, эти инстинкты включаются, и мы реагируем так, будто имеем дело с другим разумным человеческим существом. Эта реакция бессознательна и неизбежна, она присуща каждому человеку.
Отсюда требование к программам быть вежливыми и дружелюбными (не в смысле говорить "спасибо" и "пожалуйста", а в смысле соблюдения длинного списка принципов -- "программа интересуется мной, относится ко мне уважительно, обходительна, ведет себя разумно, предвидит мои потребности, отзывчива, не склонна делиться личными проблемами, в курсе происходящего, проницательна, уверена в себе, всегда сосредоточенна, покладиста, дает мнгновенное удовлетворение, ей можно доверять". Каждый из принципов подробно расписывается (особенно мне понравилась "покладистость" -- "человеческую способность выполнять действия непоследовательно или до удовлетворения предварительных условий я называю «покладистостью». Покладистость обычно становится одной из первых жертв компьютеризации, а ее отсутствие – главная причина нечеловечности цифровых систем), но сознательная антропоморфность формулировок по отношению к техническим системам говорит тут сама за себя.

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

А конец книги посвящен вроде как антигибкости: предварительному проектированию взаимодействия, проводимому до программирования и сопровождающемуся письменной фиксацией подробнейших спецификаций с передачей спецификации команде программистов. Но тут есть множество "но", не позволяющих говорить о прямом противоречии с гибкими методами. Прежде всего, само программирование тут выделяется в "субподряд" для проектирования взаимодействия:
Главная рекомендация этой книги: за качество продукта в конечном итоге должен отвечать проектировщик взаимодействия. Необходимо разрешить ему определять содержание и поведение программы. Он должен работать со списком функций, и даже график разработки, в основном, должен быть на его совести. Он защищает пользователя и должен обладать властью над всеми внешними аспектами продукта.
...
Управляемый процесс, сосредоточенный на проектировании вместо программирования, позволяет компаниям избежать игры с огнем высоких технологий. Они заранее могут узнать, что должно понравиться пользователям и как это обеспечить. Они будут знать, когда процесс разработки завершен, а у специалистов различных дисциплин появится единое, объединяющее видение продукта.
Обратите внимание, что это совсем не отказ от выпуска версий -- хотя и выглядит очень похоже! Это просто фиксация того факта, что user stories должны писать совсем не те люди, что пишут development stories. Вся эта книга про то, как писать user stories, и почему нельзя сразу писать developer stories. Это и есть главная идея книги.

Полноценными представителями менеджеров из гибких методов являются разработчики взаимодействия, и Купер просто пытается обосновать, почему эти разработчики взаимодействия имеют полное право на свой собственный (вплоть до менеджерского!) Билль о правах (pun intended). Так, на разработку взаимодействия (получение user stories) требуется выделять достаточно времени, ибо
...простой программистов обходится недешево, но гораздо дороже обходится заливка бетонной смеси программного кода не там, где требуется.
...
Проектирование взаимодействия может сократить затраты времени на разработку продукта. Если вы заранее знаете, что именно следует создавать, то потратите меньше времени на поиски верного пути.

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

Процесс разработки удешевляется, если версий становится меньше и код выбрасывается не в таких количествах. Программисты часто жалуются, что наши проекты требуют создания более сложного кода, и зачастую они правы. Однако в целом размер кода получается обычно меньшим. Стоимость кода не сильно растет с увеличением сложности, однако значительно растет с увеличением объема. Каждую лишнюю строку кода необходимо тестировать, отлаживать и поддерживать.
Можно согласиться с разумностью этих доводов, но никогда не следует забывать о том, что неожиданно нашел Александер -- тот самый архитектор, который дал начало "паттернам программирования". Он неожиданно нашел свое счастье в проекте, где команда архитекторов по каким-то причинам оказалась в одном помещении с командой строителей. И это в той отрасли, в которой согласно требованиям действительно заливается бетон! Собака "живой архитектуры" оказалась зарыта именно в этом месте, в общении архитекторов-проектировщиков взаимодействия и строителей (см., например, его предисловие к книжке Габриэля http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf).

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

Тем самым книжка Купера для меня в смысле PraxOS -- это книжка про практики различения потребительских (в том числе -- функциональных) требований и требований разработчиков, т.е. относится к практикам нормирования. Но никак не является для меня безусловным руководством по практикам планирования и выполнения работ.
9 comments|post comment

navigation
[ viewing | September 9th, 2007 ]
[ go | previous day|next day ]