Текст книги "The Programmers' Stone (Программистский камень)"

Автор книги: Alan Carter

Соавторы: Colston Sanger
сообщить о нарушении

Текущая страница: 7 (всего у книги 13 страниц)

Рецензии и анонсы

Фундаментальный элемент взгляда паковщика на работу – управление посредством угрозы. Выполни действие так и так, и не иначе. Чтобы сделать угрозу эффективной, исполнение правил должно контролироваться (полицейскими методами), поэтому мы должны следить, гарантируя этим следование правилу. Тогда ленивые и ненадежные работники будут знать, что их уволят, и будут выполнять действия как предписано из страха наказания. Действительно, важное соображение, из-за которого отвергают стиль работы картостроителя, поддерживается заблуждением, что работа картостроителя может быть специфицирована по шагам (microspecified), а единственная причина, почему это необходимо делать – то, что правила должны быть специфицированы. Только для записанных на бумаге правил можно выявить их нарушение программистами, и возможность этого выявления поставлена в центре всей модели!

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

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

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

Инспектирование кода и пошаговые проверки

Инспектирование кода составляет важную часть процесса многих организаций. Изначальная причина, почему его делают – удовлетворить здравый смысл. TQM требует: «Если вы сделали работу, посмотрите на то, что вы сделали, и убедитесь, что с этим пунктом все в порядке». Но в инспектировании кода появляется нечто забавное, часто искажающее его назначение. Это вызвано тем, что инспектирование кода похоже на Рождество. Это старое действо, которое старше структур, с которыми оно имеет дело. И, как и Рождество, содержит множество мишуры, происходящей из Старой Религии.

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

Сейчас у нас на столе мощные редакторы и процессоры, поэтому изначальные мотивы больше неприменимы, но нам по-прежнему нужно продолжать проверять наш код, чтобы можно было идентифицировать логические ошибки до того, как они уронят систему. Здесь заключается причина помрачения сознания. У некоторых организаций так же помрачено сознание, как у того IT менеджера, который недавно сказал, что работники должны выполнять инспектирование кода по листингу перед тем как его компилировать. Чтобы избежать неприятностей, у нас есть стадия проектирования для получения правильной большой картины и компилятор для обнаружения синтаксических ошибок. Ручной просмотр кода в поиске синтаксических ошибок не дает ничего полезного, а является очень дорогим и ненадежным методом поиска синтаксических ошибок, несмотря на то, что так делали всегда! Баланс изменился, и нам нужно свериться с нашими мысленными картами, как и во всем, что нам приходится делать в этой насыщенной информацией игре.

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

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

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

Стандарты кодирования и руководства по стилю

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

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

Поэтому стандарты кодирования отражают частично мотивацию картостроителей, частично мотивацию паковщиков, и в результате цели создателей стандартов перепутываются. Проявляется коммуникационный барьер между картостроителями и паковщиками, поэтому картостроители рвут на себе волосы, поскольку паковщики растирают сложность, пока она не станет невидимой на каждой отдельной странице, цитируя Пакет Знаний 47684 (Ясность Это Хорошо) и в то же самое время вытирая ясность из работы.

Если мы примем, что картостроение и TQM – основы хорошего программирования, и что суть картостроения и TQM – понимание и управление (контроль), мы можем посмотреть на цели и увидеть, что мы можем сделать для улучшения стандартов кодирования и руководств по стилю.

Сначала о ясности. Есть идея, что использование синтаксического богатства языка – это Плохая Вещь, поскольку это «сложно». Ни когда составной синтаксис образует идиому. Ни даже когда эта идиома вводится и обсуждается в документации. И вообще не нужна ни при каких условиях. Когда Ньютон писал «Принципы» (Newton's Principia), то написал их словами, хотя мог использовать алгебраические символы, поскольку был сооткрывателем флюксий, или исчислений. В наше время мы решили, что в математике лучше иметь дело с алгебраической нотацией даже при описании. Сейчас то, что потребовало бы нескольких страниц текста, в алгебраической нотации займет всего страницу, и хотя при этом скорость чтения страницы снижается, общее время чтения стопки текста больше, поскольку в стопке текста гораздо труднее проследить мысль. Итак, следует ли нашим программам быть более похожими на прозу по концентрации сложности на страницу или на выражение, либо им следует быть ближе к математике? Мы предполагаем, что если человек – новичок в языке, то лучше, если он сможет отчетливо увидеть всю структуру и тратить на каждую страницу несколько минут, чем читать каждую идиотскую строчку и не понимать, для чего это написано! Как часто нам приходится видеть напряженных людей, сидящих перед стопкой кода, не имеющих понятия, с чего начать, и думающих, что это их вина.

Второй момент – соглашения. Прежде чем принять соглашение, убедитесь в том, что оно даст больше, чем будет стоить. Мы приводили ранее пример, в котором если кто-то не знает назначение переменной, то он ничего не получит от знания ее типа [тут идет речь о венгерской записи – С.К.]. Но это не просто вклад в перегрузку мозга соглашениями, которые, как предполагается, «хорошие» программисты должны хранить в виде пакетов знаний, что само по себе проблема. Дело еще и в том, что наличие слишком большого количества соглашений делает код некрасивым и даже уродливым. Если стремиться к красоте минимального кода, то этого сложнее достичь постоянно натыкаясь на обвешанных мусором уродцев типа gzw_upSaDaisies. Никогда не делайте того, что подавляет стремление команды создать великий продукт. Было место, где думали, что соглашения – Хорошая Вещь. Несколько людей были назначены Создавать Правила, и они делали это должным образом. Один из них объявил, что длина имен переменных должна ограничиваться 31 символом. Очень разумно – многие компиляторы могут различать имена не длиннее указанного. Другой объявил, что переменные, описанные в подсистеме, должны начинаться с трехбуквенного альфа-кода подсистемы. Любая переменная, даже если никто не использует ее глобально. (Еще один предложил помечать глобальные переменные.) Еще один произвел причудливую схему типов, параллельную собственным составным типам языка, и потребовал включения информации об этих типах в имена. Зачем – мы не знаем. Еще один опубликовал список сокращений имен модулей кода, известных менеджеру конфигурации и сказал, что это тоже необходимо включить в каждое имя переменной. И т.д. Наступило настоящее веселье, когда оказалось, что все эти обязательные штучки плюс пометка типа «указатель на функцию, возвращающую указатель на запись» превысили 31 символ. Создатели Законов просто сказали, эта конструкция очень сложна и ее не следует использовать, хотя это было главным для архитектуры, и топтались вокруг описывания промежуточных переменных и приведения типов во время присваивания им значений, что совершенно не помогало ни ясности ни эффективности. Поэтому, наконец, пузырь лопнул и мы разработали некоторые прагматические стандарты, которые хорошо выглядели и говорили нам, как с помощью словаря проекта быстро образовать имя и некоторые разумные сокращения. Если посмотреть с точки зрения картостроитель/паковщик, мы видим, что ситуация развивалась подобным образом потому, что Создатели Законов были Объявителями Полезных Правил, что Хорошая Вещь, но цена, цена...

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

Четвертый момент – об этих императивах. Есть некоторые средства, которые вообще не стоило изобретать, например scanf() и gets()в UNIX. Указания никогда не использовать их в разрабатываемом коде разумны. Но есть цели, которых просто невозможно безопасно достичь другим, лучшим путем. И всегда остается проблема баланса ясности. Мы рассмотрим два конкретных примера, из которых станет видно, что в Си все же существует хороший повод для использования goto – хотя вам могли говорить, что таких поводов нет.

Вот первый, здесь нет другого способа. Представьте рекурсивный обход двоичного дерева:

void Walk(NODE *Node) { // Do whatever we came here to do... // Shall we recurse left? if(Node->Left) Walk(Node->Left); // Shall we recurse right? if(Node->Right) Walk(Node->Right); }

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

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

void Walk(NODE *Node) { Label:// Do whatever we came here to do... // Shall we recurse left? if(Node->Left) Walk(Node->Left); // Shall we recurse right? if(Node->Right) { // Tail recursion elimination used for efficiency Node = Node->Right; goto Label; } }

Мы используем стек для отслеживания того, куда мы попали слева, но после того, как мы обошли левую часть, переход на правую ветвь не требует хранения положения. Поэтому мы устраняем 50% вызовов и накладные расходы на возвраты. Это может изменить ситуацию при выборе между реализацией на Си или добавлением ассемблерного модуля. Чтобы увидеть другой пример, посмотрите на конструкцию Даффа (Duff's Device) в книге Страуструпа "Язык программирования C++" (Stroustrup's The C++ Programming Language).

Второй пример касается чистоты стиля – вообще нет необходимости применять язык ассемблера. Помните, что когда Дейкстра посчитал goto вредным, он имел в виду привычку использовать goto для организации управления в неструктурированном коде 60-х годов. Идея заключалась в том, что меньше используя goto мы могли бы улучшить ясность. Идея не состояла в жертвовании ясностью избегая goto любой ценой. Представьте программу, которой нужно открыть порт, инициализировать его, инициализировать модем, установить соединение, зарегистрироваться (logon) и загрузить файл (download). Если что-то не так, в любом месте, нам нужно вернуться обратно в самое начало. Доморощенный структуралист мог бы написать нечто вроде:

BOOL Done = FALSE; while(!Done) { if(OpenPort()) { if(InitPort()) { if(InitModem()) { if(SetupConnection()) { if(Logon()) { if(Fetch()) { Done = TRUE; // Ouch! Hit the right hand side! } } } } } } }

Что нам кажется просто глупым. Есть более понятная альтернатива, использующая то, что оператор && прекращается сразу, как только встречается выражение, принимающее значение FALSE – "неправильное использование" языка, обычно запрещаемое в большинстве стандартов кодирования:

while(!(OpenPort()&& InitPort()&& InitModem()&& SetupConnection()&& Logon()&& Fetch()));

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

Start: if(!OpenPort())goto Start; if(!InitPort())goto Start; if(!InitModem())goto Start; if(!SetupConnection())goto Start; if(!Logon())goto Start; if(!Fetch())goto Start;

Это в точности то, что позволяют нам делать специализированные скриптовые языки, разработанные для такого вида работ!

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

Значимые метрики

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

Имеется три мотива коллекционирования чисел. Все они ценные, но всегда важно понимать, в чем состоит наше намерение. Их три:

Описательная наука. Сюда относятся получение и коллекционирование данных о предмете, чтобы увидеть, можно ли найти какие-либо интересные свойства данных. При этом не нужно знать, что ожидают найти. Нецензурированные сырые данные – источник всего. Современная этимология в огромном долгу перед леди времен Виктории и Эдварда, которые проводили свое время в создании очень детальных акварелей каждой бабочки или насекомого, которых они только могли найти. Уже стало традицией, что действительно интересные кометы одновременно открываются профессионалами и астрономами-любителями. Наша дисциплина пострадала от непродуманного переноса «метрик» массового производства на интеллектуальную, трудоемкую деятельность. Если мы хотим построить аналогии с фабриками, то нам нужно задать вопрос о том, что оптимизирует сложные человеческие факторы в нашем производстве. Нам нужно проводить больше времени у истоков. Например, много ли дает знание того, что проверка потерпела неудачу в коде, написанном летом, когда есть много других вещей, которые мы могли бы сделать вместо того, чтобы поставить время проверки? Можно заложить окна кирпичом или сезонный фактор в планы работы предприятия, чтобы максимизировать качество. Что есть индикатор качества? Внутренние или внешние отчеты об ошибках на одну функцию? Число строк кода на одну функцию?

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

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

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

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

Надежда на инструменты

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

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

Картостроители не рассматривают инструменты как копиры, они рассматривают их как протезы ума. Они – мыслительный эквивалент Рипли из фильма "Чужие" (Ripley in Aliens), взятой в рубку космического корабля, чтобы победить главное чудовище. Картостроители оставляют за собой ответственность за все и используют инструменты для расширения своего кругозора и силы мысли. Картостроители не любят помещать все свои штучки в один инструмент, где их другой и не найдет. Им нравятся коллекции инструментов и чтобы ввод/вывод был текстовым и анализируемым (parseable), так чтобы они могли объединять (соединять) инструменты вместе.

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

Имеются великолепные инструменты картостроителя – браузеры, инструменты восстановления исходного текста (reverse engineering – дизассемблеры), даже некоторые "интегрированные среды разработки" (IDE). Однако, стоит держать в уме, чего можно достичь на большинстве систем просто с помощью нескольких скриптов и системного редактора. Одна команда пришла в волнение, когда им показали инструменты, которые давали им все возможности для просмотра и средства получения перекрестных ссылок. Но отличия между этими инструментами и пучком скриптов, которые у них уже были, и на написание которых понадобилось одно утро заключались в том, что:

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

Когда кто-то с энтузиазмом рассказывает о новом продукте, остановитесь на минутку и проверьте, может быть правильной реакцией будет: "Ну и что?"

Структуры программы – структуры проблемы

Можете себе вообразить Марго Фонтейн (Margot Fonteyn) с ногами и руками в гипсе и парой кандалов на лодыжках? Очень не грациозно.

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

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

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

Это не преступление – быть умелым и квалифицированным.

Разбор полетов

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

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

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

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

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

На самом деле, источники проблем можно классифицировать с точки зрения вовлеченности в процесс как:

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

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

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