Итак, день 1 (20.12.2023).

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

Мысли, почему задача, кажется, реальной:
1. Процесс, который надо на старте представить, условно типовой для отрасли (заявка, тендеровка у подрядчиков, фиксация ставки, формирование документов, контроль перевозки, финансовые документы, финансовые показатели).
2. В качестве системы реализации мной предложен, а заказчиком согласован Битрикс24
3. У меня есть отработанная конфигурация битрикса под процессы экспедирования и ТО (я ее назвал Logistix24), которая имеет несколько успешных внедрений. То есть мы четко понимаем, как конкретная ВЭД задача может быть решена на механиках и инструментах Битрикс24.
4. Битрикс24 + отраслевая конфигурация (это даже не корбочное решение, а именно набор логик и алгоритмов) дает удивительное сочетание, которое я называю «коробка трансформер», то есть оно позволяет решить базовые функциональные потребности, но при этом достаточно гибко адаптируется под специфику конкретной компании (последовательность этапов, выполняемые функциональные роли, перечень автоматизаций и интеграций).
5. Мне и команде не надо сильно объяснять, что должно получиться, так как все это уже делалось неоднократно, и мы из отрасли и про отрасль. Отсюда возможность сэкономить время на технической документации в классическом ее проявлении.
6. Заказчик, в целом, понимает свой процесс, и имеет опыт работы с цифровыми инструментами. Нарисованный, как я называю, на салфетке схематический процесс, подкрепленный сессией вопрос-ответ, в целом позволяет сформировать технические требования к результату.
6. Заказчик адекватно (как кажется) понимает, что через неделю это что-то среднее между MVP и прототипом. Уже не прототип, потому что в нем реально можно работать, но и не полноценная 100% отстроенная система. То есть тут именно MVP с которым реально можно работать или его тестировать, но с пониманием, что марафет и монстр-фичи надо будет проработать и реализовать отдельно.

Нюансы и риски:
1. Основной риск – это моя самонадеянность, что я без классического «согласуй технические требования и потом техническое задание» берусь что-то делать. По сути я проявляю за заказчика особую активность, где-то додумываю и как бы говорю, что вот тебе надо именно вот так, как я сделал. Но эта достаточно рискованная практика, и были достаточно неприятные опыты.
2. В нашей настройке Logistix24 мы не делали модульным блоком «тендеровку» (названо громко, но суть именно такая), так как по практике процесс «согласуй заявку с подрядчиком», часто заказчики оставляют в формате «на откуп исполнителю». Я не считаю, что это правильно. Но рынок есть рынок. И мы в рамках делай то, что тебя просят, фокус внимания уделяли наиболее часто запрашиваемому функционалу. А в этом проекте, этот модуль является одним из ключевых. И его надо как-то (хотя бы приблизительно) реализовать на уровне логики и инструмента.
3. Уже в группе с заказчиком началась активное обсуждение функционала, и есть высокая вероятность, что та идея продукта, которая была озвучена при первом общении, может радикально измениться вот в этом обсуждении. Это по сути продолжения п.1 из рисков.
4. Сроки, так как неделя – это прям очень не много, даже с условием опыта меня и команды.

Но как бы там ни было, взялся за гуж не говори что не дюж.

План выглядит так.
Четверг: составить структуру данных, логику статусов и перечень автоматизаций – отправить на согласование заказчику.
Пятница: получить обратную связь и корректировки.
Далее: перенести в режиме турбо-экспресс все это на Битрикс24.
Среда: презентовать заказчику и провести инструктаж по работе для тестирования.

А вот получится выдержать темп или не получится – время покажет.

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

День 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 по МСК.