Рабочий набор: инструмент, процесс, метод и инструкция

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

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

Без доступного инструментария разруливание чего угодно превращается в творческое применение молотка, WD40 и изоленты. С ними беды, кстати, нет; беда в том, что творчество у каждого своё, одноразовое и трудно-прогнозируемое. Навыки с опытом — тоже. И каждый сам себе Вася-слесарь, что качеству и прогнозируемости не слишком способствует.

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

Просто запиши

Начнем с простого: фиксация опыта. В любой форме. Если мы что-то сделали, и результат нам понравился и/ли подошел — значит, это самое «что-то» имеет прикладную полезную ценность.

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

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

Чтобы не получилось имитаций и карго-культа, надо идти дальше.

Best practices

Идем дальше: практики, best practices. Это когда мы делаем так, это приносит ожидаемый результат, и почему-то нам кажется, что так делать = правильно. Например, потому что предсказуемо и быстро. Или приносит чуть больше плюшек, нежели имеющиеся доступные альтернативы (и мы это знаем).

Что тут важно: мозг все еще можно особо не включать; если вы его не используете вовсе, то практики все еще работают — вы это проверили.

Вам плюс-минус пофиг, насколько они реально best в лучшем возможном виде; они best именно для ваших реалий. Плюс здесь в том, что они зафиксированные и однотипные — нажимаешь на кнопку, получаешь сахар, проверили, даже мышъ справится. А вы себя и остальных дистанцируете от нездорового креатива, и связанной с ним непредсказуемости (а значит и рисков).

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

Пример (use case)

Частный случай практик, из них логически произрастающий — пример, use case. Хорош тем, что вы можете показать решение задачи в динамике, точки принятия решений. Описать не только положительный, но и отрицательный исход событий. Предусмотреть в решении необходимую коммуникацию и акторов; кто вам понадобится, что будет делать, куда надо кого послать.

Не будем выделять в отдельный пункт, но примерно сюда же попадают история (story) и сценарий (scenario). Это скорее паттерны описания для usecase-примера, в данном контексте, разной степени развесистости.

Всё еще мозг не задет: «обучение на примерах» работает на достаточно низком уровне, потому что в базовой прошивке есть способы восприятия опыта (зеркалирование) без необходимости задействовать аналитические возможности. Возможно, мы даже не знаем, как это делать, мозгом. Но все равно сработает. Это очевидный плюс. Минус — репрезентативность примера. Бывают неудачные, просто какие под рукой были.

Playbook (набор сценариев)

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

Возможно поэтому людям так нравится подход «рецептов».

В противовес flow, здесь плейбук — это тупой сборник готового. Задача только выбрать и сделать, все вопросы решаются в точке «а что из этого нам подходит», no-brainer. Про flow будет далее.

Метод

Когда нет готового решения или рецепта, что надо делать?
Решение искать. А как это делать?

Методов много. Не все одинаково полезны (но большинство полезны). Самый простой — «метод проб и ошибок», кидай говно в стену пока не прилипнет. Если прилипло — запиши в опыт, если повторилось — запиши в практику.

В противовес тупому, есть умный «научный метод». Это когда мы формулируем гипотезу, ставим эксперимент, фиксируем результаты, изучаем их аналитическим способом, выносим решение, повторить. Долго, сложно, нужно мозги, сильно полезно и двигает прогресс.

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

И да, «спроси умного соседа» это тоже метод. Метод тиражирования опыта, то есть мета-метод, метод при помощи которого вы выбираете нужный из представленных. Из чего выбираете, что в меню, what’s in the meta? — ответ:

Методология

Методов у нас дофига. И у соседа тоже есть. Есть даже специально обученные методисты, у которых есть специальная для них дисциплина, как раз заточенная на то, чтобы: знать, выбирать и применять подходящие методы там, где это уместно и необходимо. Пока в нашем контексте просто зафиксируем, что «их есть у нас», иначе меня покусает Аня за влезание на её поле грязными лаптями.

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

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

Инструкция

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

Это не готовое решение, и даже не его пример (хотя могут быть очень похожи). Это способ сделать так, чтобы готовое решение у вас появилось; не «как тупо делать», а «как решать, чтобы найти решение и потом сделать». Уровень выше на лестнице абстракции.

Набор инструкций тоже playbook по своей логической сути, просто содержание разное. Если вы заметили, мы тут в тексте идем от топорных и прикладных no-brainer методов, ко все более абстрактным и местами универсальным.

Ограничения (constraints)

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

Ограничения предполагают проверки; собственно, набор ограничений и есть набор постулатов, для которых мы можем определить, выполняются они или нет — и сделать выводы. Как определить? Можем наугад, у нас удача прокачана. Можем экспериментом или сверкой результатов. Можем эвристически и/ли критериально, «оно крякает как утка, значит это утка». Можем кому-то умному на слово поверить. Обратите внимание, что метод проверки — тоже метод.

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

Чеклист

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

Чеклисты прекрасный инструмент для тех случаев, когда для каждой их проверки есть инструкция. Готовая точка принятия решения, а главное — простая. Следует отметить тот факт, что проверять чеклист может совсем не тот, кто собственно эти проверки проводил, и по инструкциям работал; даже роботы справятся, и часто это делают. Нам в известной степени пофиг, как результаты получены, главное что они есть (или нет).

Процесс

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

Без понятности процесс невозможно декомпозировать в действия. Если у вас нет подходящего решения в процессе — не беда, вы процессом и собираетесь его искать. А вот если нет описания «как будем искать», то есть методов, с этим процессом что-то не так.

Без работоспособности процесс бесполезен, он оторван от реальности. Невозможно описать работающий механизм того, что заранее не работает.

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

Схема (flow)

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

Flow, отдельно подчеркну: это данном случае не самоцель, а инструмент. Он может быть подходящим, или неподходящим. Решать вашу задачу, или даже не решать (но предписывать процессы, которые должны пойти), а просто показывать взаимосвязи акторов.

В этом смысле даже линейная схема «1.Жопа — 2.??? — 3.Profit!» не бесполезная схема, если к ней прилагается инструкция и/ли методики, как сделать второй пункт понятным.

Что делать со схемой, которая тоже схема, но не про действия, а про устройство? — ответ:

Модель

Если есть «его величество» процесс, то «её величество», в данном случае — модель. Она описывает устройство конкретной предметной области, как минимальная отправная точка — реального мира. В той части, в которой он нам интересен.

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

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

К примеру, модель атома Н.Бора всех устраивала, пока её не доломали об квантовые «две дельты» Гейзенберга — и она никуда не делась, в макромире все равно «ну плюс-минус похоже», значит мы ее используем только там, где уверены в результате.

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

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

Ревью (проверка)

Занудно говоря, это тоже метод. Same time, для нас это прикладной инструмент. Как следует из названия — это проверка. Так и в чеклисте тоже проверка, мало ли тех проверок. В чем основное отличие?

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

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

Поэтому на производстве классический review выглядит так: берем 100 изделий из партии в 10000. Если в этой сотне обнаружился брак (=1%+), вся партия идет в отбраковку. Отдел технического контроля = тот самый процесс для инструмента review, встроенного в общий механизм, верхнего уровня.

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

Сложные проверки очень любят матстат (а матстат — их). Есть почти полностью математические методы, которые могут сказать: вот тут в результатах что-то явно не так. См. «чего не проверяешь, того не знаешь», тут и тут. Поиски отклонений/аномалий, смещения распределений, интегрально-дифференциальные методы — всё сюда.

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

Карта влияния

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

Даже протоколы у инструмента могут быть базовыми и топорными наглухо: типа, голосом через рот. Особенно для сторонних систем и всякого внешнего-неизученного. Вы понятия не имеете, и не сможете достоверно иметь, как там извне всё работает. Но если выполняется условие карты «вот этот вопрос касается и относится туда», значит вы идёте — куда? — туда, куда предписывает карта.

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

Ессно это не весь инструментарий, а только самая простая и наглядная его часть. Мне, для иллюстрации подходов. Так что это, никакой энциклопедичности — раз, всё на пальцах, и узкий срез — два.

Если я поставлю крупный вопрос «а чем и как всё это мерить?» то be assured, еще список инструментов предстоит рассмотреть, точно не меньший.

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

Тогда разруливание бардака — то, ради чего всё — органически обрастает инструментами, способами, решениями. Если где-то накосячите — ничего страшного, шаг обратно, изучили выводы, приняли меры.
Это тоже — что? — процесс.

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

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

Попытки «счас мы сами» обычно заканчиваются понятно чем: хромым кадавром. И почему не работает, удивительно. Наверно скрам-говно, напридумывают тоже. Хотя скрама все равно я не фанат, есличо.

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

Hope that helps.