Рамки и баланс у процессов

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

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

Потому что типовые решения для типовых задач:

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

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

Вот вам красивая схемка (все же любят схемки!). Зеленое вам дёшево и предсказуемо. Желтое — дорого, непредсказуемо, но дает на выходе материал для построения «зеленых» блоков.

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

Первое, что следует отметить — количественный баланс. Между зеленой и желтой зоной.

Упихать всё в зеленую типовую зону — прикольно, дешево, предсказуемо. Можно мозг не включать. Но во-первых, не получится: процессы типовые, а входящие запросы разные. И с ними что-то придется делать. Во-вторых, типовые цепочки надо откуда-то брать, а существующие корректировать.

Упихать всё в желтую зону — долго, дорого и больно. Этого мы себе позволить не можем. И зеленые процессы надо откуда-то брать и формализовывать.

Отсюда, какие у вас задачи:

• обеспечить корректный беспрерывный переход задач из желтой (исследовательской) зоны в зеленую (типовую)
• сделать так, чтобы зеленых задач было кратно больше, чем желтых. Например, 80%/20% если наугад
• обеспечить корректные «обратные» цепочки из зеленой зоны в желтую, с количественным и качественным контролем таких ситуаций

Баланс будет стараться постоянно куда-то уползать.

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

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

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

Второе, что следует отметить — желтая зона неоднородная. Просто идти и думать головой задорого — это долго и дорого. Надо стремиться этот вопрос оптимизировать. Где-то побыстрее, где-то подешевле.

Самый простой путь — capitalize on the experience, все накопленные знания, примеры, аналитика, косяки и постмортемы, всё что было найдено и пройдено непосильным трудом, должно формализоваться и, как следствие, капитализироваться. На схеме «бледно-желтые» части. Если вы обработали нетиповую ситуацию с каким-то выходом — это ваша ценность и база для активов. Вы за нее уже заплатили, постарайтесь не потерять, а иметь возможность найти и использовать дальше.

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

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

У полезного, но штучного решения (дорогого) есть положительных результата минимум два:

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

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

Вот эти «девять», они пока 1) точно просраны 2) пользу от их возможной капитализации мы пока только выдумали. Вера в перспективу стоит нам 9 рублей, против одного. Точно надо было? Если да, то почему, где это зафиксировано.

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

Вместе с тем, даже задачи категории «нахер» следует обращать в свою пользу

• вы можете оставить себе вводные для анализа, количественного и/ли качественного (например, по частотности или доле рынка, капасити, профитов)
• вы можете передать такую задачу тому, кому не лень ей заниматься (даже за процентикъ, почему нет). Так строятся партнерские экосистемы

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

На общей схеме еще такой неочевидный момент.

Когда у вас 2-3-5 типовых процессов, выбор между ними выполнить легко. Если у вас их там 10-20-50, выбор типового решения становится сам по себе достаточно дорогим и сложным.

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

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

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

Hope that helps.

Занудно отмечу, что если мы рассматриваем исходную схемку как модель и механизм, то внутри нее работают механики и инструменты. По стрелочкам. Это если хочется перейти в прикладную часть «как сделать».