Волшебные таблетки и автоматизация

Как меня бесит любовь людей к поиску волшебных таблеток! Всем надо решить все проблемы быстро, бесплатно и вообще вчера.

Помните пик популярности Low-code/no-code решений? Обещали заменить программистов и оставить только методологов. Технология сама по себе хорошая, заняла свою нишу и выполняет поставленные задачи. Но эти задачи катастрофически далеки от того, как её продавали бизнесу. Сэкономить на разработчиках не получилось.
Есть ощущение, что история повторяется с ЛЛМ: внедри ИИ и всё будет работать само, нужен будет только небольшой контроль. Об этом поговорим отдельно, у меня уже прилично накипело)

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

На одной из конференций вынес с доклада об автоматизации золотую мысль:

“Если автоматизировать то, что работает плохо, у вас будет плохо работающее автоматизированное решение”

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

⚡️Сначала налаживаем, а только потом автоматизируем хорошо выстроенные и проверенные процессы. Согласны со мной?

P.S. Про разрушение существующего и стройку автоматизации с нуля расскажу в следующем посте 🔔

Волшебные таблетки и автоматизация Ч2

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

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

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

📢 А вы внедряли готовые решения в существующие процессы? Как прошло?

Ловушка невозвратных затрат

Как я могу это бросить? Ведь вложено уже столько сил/денег/времени…

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

Но есть одна простая истина:

Не решаясь признать потерянные ресурсы, мы продолжаем их терять

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

Однажды мы занимались очень крупным и сложным процессом.
Окружение и черновик процесса изначально были построены «на коленке» без нормального задела на будущее. Когда же пришлось его дорабатывать и выпускать в мир, оказалось, что здание буквально держится на костылях, скотче и честном слове. Мы потратили месяцы и кучу нервных клеток, чтобы запустить все в срок. В итоге все заработало, но под капотом тихий ужас: в документе закончились цвета для выделения доработок, ломалось и чинилось оно сотни раз на ходу, по коду там вообще был «сын полка» пяти разработчиков. Голос архитектора внутри кричал: «Да тут все сжечь надо и писать заново!!!».
Но как вы понимаете, заново никто писать не стал. Сначала были сроки, а потом нецелесообразность (ну оно же работает!) и отсутствие бюджета.

Вот и получается: потенциальная боль от утраты вложенных ресурсов и устройство процессов заказной разработки не позволяет вот так просто бросить убыточное и начать все заново. 😭

📢 А какая у вас самая запоминающаяся история с невозвратными затратами?

Всем привет!

Настало время познакомиться поближе📍
Давайте устроим небольшую перекличку. Выбирайте в опросах свою роль и что вам интереснее всего читать в этом канале🙂

Четвертое февраля… 😨 Больше месяца не было статей в канале.

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

Откладывание — коварная ловушка, потому что планируя дело на потом, «в долгий ящик», мы чаще всего в нем его и бросаем. Как в том анекдоте: «Ну что ты каждый день спрашиваешь о долге, сказал же, завтра отдам!».

И каждый раз нужно приложить колоссальные усилия, чтобы попытаться реализовать это будущее в настоящем. Рассказать вам, сколько я уже планирую выучить язык программирования Go? Если честно, эти мысли впервые пришли ко мне примерно в 20-21 году. А дальше все как обычно: ждал удачного момента, уменьшения нагрузки, или что материалы какие-нибудь сами попадутся. За пять лет так и не попался ни удачный момент, ни курс, ни книжка, волшебного пинка тоже не случилось. Получается, если я не сделаю над собой усилие, я никогда этим не займусь? Не совсем.

В спасении из ловушки откладывания главное даже не усилия. Усилия — это костыль. Главное — системность и планирование. Именно они помогут выстроить вехи, дедлайны и крючки, которые будут постепенно двигать задачи. Самое базовое — делить сложные дела на маленькие кусочки. «Выучить язык программирования» — громоздкая необъятная цель, не понятно, как вообще к ней подступиться, и в каком случае она будет исполнена. Когда я получу грейд сеньора? А вот «поставить среду разработки» или «посмотреть вводный урок» — уже вполне понятно, измеримо и выполнимо в реальные сроки.

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

📌 А вы часто откладываете дела? Как справляетесь с этим? Может, смогли разработать уникальную индивидуальную систему? 🐱

Предметная область: как глубоко нужно погружаться?

За последние 2 года я сменил 2 места работы с абсолютно новыми предметками и каждый раз приходилось погружаться с нуля. В процессе всегда возникает вопрос: а можно ли не разбираться досконально? Спойлер: можно. 😨 Но обо всем по порядку.

📌Что дает глубокое понимание предметной области?
- Меньше времени и сил на исследование контекста для каждой новой задачи
- Знание подводных камней
- Возможность обучать других
- Проектировать проще, потому что можно заранее определить направления развития

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

Обычно при выходе на новое место есть 2-4 недели на раскачку. Можно спокойно разбираться, читать документы, ходить на встречи. Дают задачи на погружение с большими сроками. Но в среднем через месяц появляются реальные задачи, в которых от тебя начинают требовать немалых результатов, особенно если ты архитектор) 😬

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

А что делать в первые пол года, чтобы не просто выжить, но и укрепиться на новом месте?
📎Мои рекомендации: определять границы процесса, искать ответственных и как можно больше копать и расспрашивать. Но здесь важно не попасть в ловушку погружения: когда выяснил один вопрос, но обнаружил три новых. Сразу хочется разобраться во всем. Для изучения предметной области это полезно, но для конкретной задачи — избыточно. Решения в рамках ограниченного контекста могут быть не идеальными, но на старте этого и не нужно.

Я часто возвращаюсь к своим прошлым решениям и смотрю на них с высоты наработанного опыта. Думаю ли я, что сейчас сделал бы по-другому? В 90% случаев да, как минимум в деталях. Жалею ли я, что все сделал не так? Нет, такого не было ни разу.

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

Какими бывают наставники?

Что обычно имеют ввиду под словом наставник? От места к месту в это слово закладывают совершенно разные смыслы и часто недооценивают. Иногда это человек, который помогает адаптироваться. Или коллега, который изредка подсказывает, куда бежать и что делать. Бывает, что наставник полностью ведет обучение. А где-то это надзиратель, который только контролирует.

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

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

Здорово, если наставничество — это часть работы и закреплено официально. Тогда у вас есть выделенное время, единый контекст, общая предметная область и пересекающиеся задачи. Это сильно помогает именно в профессиональном развитии.

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

📢Расскажите, предусмотрено ли наставничество на вашем месте работы и в каком формате? Вы бы решились на внешнее менторство?

Хочется верить, что вы заметили мое долгое отсутствие. Причина этому — не аврал или перегрузка, а выгорание, отсутствие моральных сил 😬

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

Я сейчас в отпуске. И только на десятый день из 16-ти у меня только-только появились моральные силы и желание что-то сделать. Оказывается, когда ты много-много лет выгораешь, две недели — просто пшик.

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

Рабство цифровых процессов 🐱

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

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

У меня недавно случилась забавная ситуация. Я хотел переприкрепиться к поликлинике. В Москве такие вещи обычно делаются просто: онлайн через мос.ру. Но тут алгоритм просто выбивал меня и не давал сделать заявку. Оказалось, нужно идти и ручками писать заявление в поликлинику, чтобы тебя прикрепили. Для меня это было шоком. Бумажное заявление (его не будет на мос.ру!), которое где-то рассмотрят, примут решение, а потом даже не известят о результате. Мне сказали «Ну, в приложении посмотрите, если будет другой список врачей к выбору, значит, вы переприкрепились» 🤔
Это сильно ломает привычный ритм: мы привыкли к жесткости и четкости цифровых процессов, но при этом явно теряем в гибкости.

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

📢 Что думаете? Сталкивались с подобными проблемами цифры в жизни?

Давайте делать плохо!

Такой фразы я ни разу не слышал от менеджеров. Зато слышал другие:

А можно упростить?
А давайте побыстрее?
Нужно все тоже самое, но бюджет в два раза меньше.

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

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

А зачем было экономить вначале? Если мы понимали, что рано или поздно оно выстрелит, а суммы на исправление будут многократно выше. Понимаю, вопрос риторический. Так устроена наша сфера: с экономией, эффективностью и вынужденными мерами. Возможно, так не везде, и кто-то относится внимательно и предупреждает проблемы заранее.

Для себя я понял одно: надо говорить честно, когда от вас ждут удобной лжи. Быстрее? Значит хуже. Дешевле? Окей, потом потратим в два раза больше сэкономленного на исправление.

Что думаете? Буду ждать ваши истории 😇