Автоматизация
2 поста
2 поста
Если вы собираетесь отправить посылку родным и друзьям до нового года, остановитесь на секундочку, пост для вас.
Пост написан исключительно для информации, если вы не знали.
В прошлые годы я отправлял новогодние посылки почтой России (долго и не удобно) или СДЭК (дорого).
В этом году мне посоветовали отправить через озон.
Ниже будут пруфы:
- коробка сладостей Туапсе – Подмосковье (332 рублей доставка 5 дней 2000 км);
- коробка сладостей Туапсе – Татарстан (388 рублей доставка 5 дней 2000 км).
Ну это ли не охренительно? Еще можно успеть!



Джва года у меня лежала данная тема и, вот, настало время ее немного раскрыть.
И так: был большой ИТ-проект, на который были собраны самые опытные специалисты в своей области: опытные руководители проектов, бизнес- и системные аналитики, мидл и сеньоры разработчики, несравненные тестировщики, отчаянные девопсы, классичесике техписы, бесшабашная техподдержка и возглавил все это необычайно мудрый и опытный руководитель (если я кого-то забыл, можете добавить). Но проект не влетел. Кто виноват?
Давайте заглянем немного под капот этой кухни.
Аналитики: Мы опросили потенциальных заказчиков, применили мировой и свой опыт описания бизнес-процессов и системной аналитики и изготовили самые потрясающие спецификации!
Разработчики: Мы реализовали спецификации как поняли, применив мировой опыт и свой опыт разработки по самым передовым и классическим технологиям!
Тестировщики: Мы сделали тесты как поняли, применив мировой опыт и свой опыт тестирования, и говорим, что больше половины наших тестов не проходят и они были отправлены на доработку!
Девопсы: Не нужно нам рассказывать как разворачивать ваши приложения, дайте нам код, мы сами его развернем так, чтобы он работал в высоконагруженных гетерогенных системах.
Руководители проектов: давайте все сделайте в сроки, которые вы сами же и согласовали и мы к вам не будем приставать.
Руководство: что за херню вы сделали? мы хотели совсем другое!
Вдруг кто-то крикнул из ветвей: Ребята мы сделали MVP, давайте отдадим его клиентам? Сейчас так делаются все современные системы: разработали - потестили - доработали.
Нужно найти того, кто виноват, был вердикт руководства, что вес получилось не так как мы хотели, а потом все переделать так, как мы считаем нужным!
Так кто же во всем виноват?
P.S. Не нужно относится к этому кейсу, он должен был что-то всколыхнуть из вашего опыта. Расскажите про свой опыт, кто во всем виноват на ваш взгляд и почему...
P.S.S. В одной из моих прошлых жизней, виноватым за возгорание шкафа назначили начальника охраны, потому что он не был на больничном, и ничего не мог сказать в свое оправдание, а виноватым кого-то нужно было сделать.
P.S.S.S. Ни что не ново под луной...
Программисту нынче мало быть программистом, он должен быть еще и аналитиком, девопсом, тестером, техническим писателем.
Ах, да, раньше это называлось инженер...
Если у пользователя утром не заварился кофе, перед тем как он решил воспользоваться твоей системой, то виноват тоже ты!
Сегодня я проснулся с двумя мыслями, которые являются квинтэссенцией моего четвертьвекового опыта автоматизации:
Нельзя автоматизировать бардак;
Системы без обратной связи не работают.
Попробую пояснить.
Нельзя автоматизировать бардак. Можно автоматизировать процесс. Процесс есть всегда.
Процесс - это не обязательно документ или схема, это может быть то, как заведено или установлено на словах. Если никак не заведено - это бардак. Однако, если правила меняются раз в неделю и о их изменении менеджер узнает от директора в курилке, это тоже бардак, в автоматизацию такого процесса не стоит и соваться.
Проблема в том, что каждый понимает и выполняет процесс по своему. Люди часто косноязычны и некомпетентны спокойно рассказать про свой процесс, чтобы его можно было описать.
Люди часто ленивы и некомпетентны, чтобы прочитать, что написано о процессе даже полстранички.
Любой процесс можно описать на полстраницы так, чтобы любому было примерно понятно о чем он. Даже если процесс описан на ста листах, можно сделать выжимку на полстраницы.
Если мы говорим про автоматизацию процесса, то вторые полстраницы верхнеуровневого описания процесса должны занимать ответы на вопросы:
Чем установлены правила процесса? Закон, приказ или иной документ, в которых можно почерпнуть информацию по автоматизации, ограничениях и правилах;
Какие ресурсы участвуют в процессе? Департамент, подразделение, производственная линия и т.д. - со всеми нужно будет пообщаться, всё учесть;
Что подается на вход процесса? Заявки устные и письменные, накладные и т.д. - все что нужно зафиксировать и понять, как оттуда брать информацию;
Что является выходом процесса? Документы, программы, детали - все что нужно зафиксировать и понять, как вход преобразуется в выход.
Таким образом процесс - это знания о том, как с использованием установленных ресурсов и правил, то, что попадает на вход процесса превращается в результат процесса. Такой описанный процесс можно автоматизировать, главное чтобы это описание было утверждено владельцем процесса.
Этого достаточно для автоматизации процесса, но не достаточно для управления процессом.
Если мы говорим про управление процессом, должны быть установлены:
Владелец процесса - это ОДНО ответственное лицо с кого спрос за процесс и которое принимает решение, что процесс работает правильно;
Количественные метрики (характеристики) процесса, которые позволяют оценить, что процесс работает эффективно или нет. Например: если за неделю отработано менее 95% поступивших заявок, то процесс работает не эффективно.
Установка количественных метрик процесса - это высший пилотаж, доступный единицам.
Количественные метрики желательно рассчитывать автоматическим способом на основе записей, которые появляются в ходе выполнения процесса - журналы, логи и т.д. Если записей в процессе не хватает, их нужно расширить.
Здесь сломано много копий, потому что зачастую, чтобы измерить эффективность процесса, нужно учитывать временные метрики работы персонала. А персонал ох как не любит, чтобы его рабочее время учитывалось, эффективность рассчитывалась и саботирует это любыми способами. Поэтому делать это нужно как можно менее заметно. Например: не заставлять работника отмечать сколько часов он потратил на задачу, а засекать время, сколько задача находилась у работника.
С первого раза невозможно правильно установить количественные метрики процесса, которые правильно будут показывать эффективность работы процесса. Они устанавливаются эмпирически за несколько итераций.
Типичный пример проблемных метрик: среднее время выпуска продукции сократилось с двух недель до одной, но количество жалоб по качеству продукции увеличилось вдвое.
Если метрики процесса показывают, что он работает неэффективно, можно изменить:
метрики процесса;
ресурсы процессы;
сам процесс.
Зачем нужны метрики? Потому что системы без обратной связи не работают. Точнее работают, но нельзя быть уверенным, что они работают так, как этого требовалось.
Самая классическая автоматизированная система с метриками - это воронка продаж в CRM системе. Имея информацию по метрикам в воронке продаж, можно управлять каждой составляющей процесса продаж, несмотря на то, что сам процесс продаж может быть не формализован и не автоматизирован.
Важно помнить, что процессов в компании может быть несколько и они могут быть связаны между собой. Но нужно выделять основные процессы - процессы, нарушение которых приводит к тому, что компания перестает функционировать. Концентрироваться нужно на них. Закупка туалетной бумаги в кабинки - это тоже процесс, но не основной для большинства компаний.
Мы тут, знаете ли, делаем софт и оборудование для дистанционных предрейсовых медицинских осмотров ака телемедициной занимаемся.
И иногда от клиентов приходят интересные перлы.
Вот вчера пришла служебная записка. По понятным причинам скрин я вставлять не буду, но текст приведу:
“Я девятого августа пришел проходить телемедицину. Перед этим был на ремонте автомобиля, замарался, сходил дома в баню, помылся, побрился, намазался лосьоном после бритья и прыснулся туалетной водой. Прошел телемедицину и у меня показало ноль два алкоголя. Подошел к медику на алкотестере показало ноль”.
Оставлю суть инцидента за рамками поста, ибо 99.99% это гониво.
В тексте служебной записки, как мне кажется, есть определенный ритм. Возможно водитель слушал Кровосток, когда писал.
Помню, в детстве байка такая была, что для приезжих отдыхающих за армянский коньяк выдают настойку самогона на перегородках грецкого ореха и черного чая.
А оказывается это и не байка вовсе...


У меня немного другой взгляд на мессенджер МАХ - со стороны разработчика. Если мне дают мессенджер, в котором функционал не хуже, чем у телеграм, то, почему бы и нет.
И, судя по описанию API на официальном сайте, функционал чат-бота заявлен как надо. А если посмотреть, сколько народу из списка моих контактов добавилось, пора бы им воспользоваться.
Но, есть одно "но". Я не могу им воспользоваться. Видимо открыт ранний доступ только для избранных.
Спрашиваю когда, поддержка говорит позже.
Пробую с 1 июля пробую, 40 дней прошло...
Так и что, и когда? Может все-таки какой секрет есть?

