День 2. Пока двигаемся по плану.

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

Сегодня позже (завтра все-таки) поделюсь итогами дня и рефлексией и проблематикой.

И да, ТЗ действительно существует🤣🤣🤣🤣 Также как заказчик и проект

День 2 (21.12.23) Рефлексия и нюансы.

Задача была подготовить ТЗ и отправить заказчику на согласование.

На этот момент имели:
1) образцы таблиц, которые у себя ведёт заказчик (Эксель)
2) общую схему процесса «на салфетке»
3) общение с описанием что есть и чего хочется.

Задача, как ее поставил я у себя в команде:
1) на основе имеющихся у заказчика таблиц собрать состав данных для информационной карточки сущности, вокруг которой будет строиться процесс в Б24
2) указать тип данных (текст, даты, выпадающий список и т.д.)
3) на базе имеющейся информации от заказчика разработать систему статусов, которые должна иметь информационная сущность (поставка на согласовании, ожидается, в пути, отгружена, выставить счёт и т.д.)
4) определить перечень автоматизаций, которые нужны в целом и на первом этапе
5) предложить варианты оперативных отчётов, которые предполагается формировать для оперативного управления.

Задача в целом типовая для подобного проекта. С учётом того, что все экспедиторы +- работают одинаково, Таблицы выедут +- схожие и процесс в целом тоже схожий, то тут проблем не было.
Плюсом является то, что отрасль знакомая и нам не надо лишний раз уточнять, что значит поле «отметка СКК» или «СВХ/терм. приб.».

ТЗ вчера отправили. Так что пока идём по плану.

Про нюансы
Нюансы, как обычно, вылезли на этапе формирования выпадающих списков. Когда это ведётся в ручную то условный «отправитель А» имеет несколько вариаций написания:
- отправитель А
- отправитель_А
- отпр. А (а латинская) и т.д.
А чистота данных такого не терпит.

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

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

Ну и вопрос достаточности, о котором я говорил раньше в видео.

Достаточности обобщения частностей и отклонений. И достаточности детализации информации в технической документации. Тут, кончено, со мной многие ИТ интеграторы и/или IT-службы могут вступить в спор, что чем дательнее, тем более гарантированный результат итого. И я даже не буду с ними, спорить. В этом есть правда.
Но и есть другая правда, у любой задачи есть уровень достаточности «усложнения подхода». Уметь находить компромисс достаточности - это по сути компромисс ресурсов «время - деньги - результат».

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

Через 15 минут, кстати, созвон с заказчиком по ТЗ. Но это уже в отчёт сегодняшнего дня.

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

День 3 – 4 (22 – 24.12.2023)

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

22.12.2023 был запланирован созвон и он состоялся. Было долгова-то для созвона. На 2,5 часа стараюсь подобные встречи не растягивать, но тут уже надо было все в одно успеть.
Все обсудили.
Из положительного, в целом основные вопросы сняли.
Из обычного, в ходе общения вылезло конечно же куча нюансов, основной из которых логическое продолжение «грязи в классификаторах».
Суть в том, что на первом этапе внедрения данные в битрикс24 будут попадать извне (и точнее из экселей). Не будем сейчас о том, «почему именно так, и что это все структурно не правильно». Да, неправильно, да не круто, да лишние проблемы, которых можно было бы избежать.
И как всегда в логистики, так надо.
Раз надо, значит надо. Опять же я не могу все детали раскрывать «почему так, а не иначе», а там есть аргументы.

Вернемся к проблеме:
во входящих данных бардак, в битриксе надо этот бардак исправлять на классификаторы.
Возникает вопрос на каком из этапов и в какой среде:
- при сборе данных
- при подготовке данных на загрузку
- уже внутри битрикса?

И тут тоже много нюансов из серии, чем осуществляем чистку данных (VBA, PHP, Python), «битрикс коробока» и «битрикс облако», все это разные возможности на программирование.
Итого вопросов поприбавилось.
Положительный момент, что встреча состоялась. И со стороны заказчика организационный контроль выдержан. Потому что у меня очень много опытов, когда в силу текущей «перегруженности» участников проекта со стороны заказчика встречи переносятся постоянно.
Итог:
- обсудили, пул проблемных вопросов с учетом глубокого погружения в материалы;
- сформулировали часть необходимых логических решений;
- ожидание от демонстрации во вторник синхронизировали.

23-24.12 выходные.
🔥🔥🔥🔥
Тут должен выразить огромную благодарность моим партнерам по команде. Несмотря на выходные коллеги нашли несколько часов, чтобы сделать то, что необходимо было, чтобы двигаться дальше.
Вошли в ситуацию и поддержали темп.

По факту по состоянию на сегодня 25.12.23 утро имеем ровно то, что на скрине, который был отправлен заказчику.

Это про доделки в последний момент... И так бывает)))

Я вчера пол дня думал, что можно показать из сдачи проекта.

Понял, что обрезанные фразы от заказчика «за неделю сделали 100%», «в этом уже можно работать» и «мне нравится» или тоже самое с замазанными лицами и ФИО ну так себе контент.
(Вчера порядка часа обрабатывали запись сдачи проекта, чтобы посмотреть получится ли из этого скрин-каст не нарушающий ничьих интересов. Как ни крути – нарушает NDA, если только не замазать весь экран).

Но потом появилось другое понимание.

Я готов провести эфир, в котором пошагово покажу по этапам каждого дня, какие задачи стояли и как они решались, а также что в битрикс24 за это время можно было сделать.
Показывать буду на других документах и составах данных, чтобы не было нарушений NDA, но в целом логика схожая.
И ключевое тут не про то, как столбец назван или какой выпадающий список.
Ключевое – это подсвечивание вызовов, с которыми сталкивались и как их решали. Именно этим я и готов поделиться на эфире.
(А эти вызовы они встречаются в 90% цифровых проектов в логистике)

Как минимум будут озвучены следующие вопросы:
- как быстро из запроса (идеи) сделать понятную для разработчика задачу;
- как разработчик может эту задачу обрабатывать (быстро/разумно по деньгам, долго/не разумно по деньгам, и где тут компромисс);
- как не споткнуться о малозначимые «хотелки», которые затянут результат и увеличат бюджет, но не дадут значимого эффекта;
- в какие сроки и что можно сделать в рамках реализации проекта;
- как может выглядеть реализация сквозного процесса экспедирования на примере битрикс24.

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

Эфир в записи выкладывать не буду, так что тут уже Ваше желание и готовность сыграет решающую роль.

Ниже опрос, о желающих принять участие в таком эфире.
Если наберется 10 человек и более, то эфир проведу. Предварительно время эфира на 11.00 по МСК.