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

Этап интервьюирования и поиска решения прошли хорошо.

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

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

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

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

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

Если уж совсем уходить в детали, то в программах декларирования (в данном случае Альта-Заполнитель есть удивительный нюанс, что в зависимости от того, какой именно документ будет формироваться из заполнителя (ДТ или инвойс) то там разный набор разметок столбцов. То есть, из заполнителя можно сразу формировать документ ДТ – и тогда будет использоваться один набор связей «таблица – заголовки», а может формироваться документ «мастер инвойс» - и тогда будет совсем другой набор связей «таблица – заголовки». Справедливости ради надо сказать, что в мастер инвойсе полей и возможностей больше, и то, что есть в рамках набора полей для документа инвойс, может не быть для документа ДТ. И если сотрудник из заполнителя всегда делал мастер-инвойс (из которого в свою очередь потом делает все остальные доки, включая ДТ), и не делал ничего другого, то для него единственная правда в том, что там все очевидно и вариативности быть не может. А для разработчика, который знает, что на этом этапе есть логическая вариативность использования различных схем заголовков, необходима конкретика).

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

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

Описанное выше яркий пример нескольких моментов:
1) разрыв в компетенциях и коммуникации между заказчиком – бизнес-аналитиком – разработчиком;
2) различные ожидания сторон от коммуникации, и что есть «нормальный вопрос», а что «излишний»
3) общая напряженность от совмещения «текущая работа» отвлечение на «что-то иное».

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

О разрывах компетенций и искажениях в процессе реализации проекта.

В видео часть выступления по этому вопросу. Ссылка на видео в конце поста. Это самая-самая боль. Я бы сказал, что это 90% успеха или неуспеха проекта. Она же причина и объяснение ситуации, которая была описана вчера.
И тут лучше посмотреть, чем пытаться это тезисно описывать.

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

Чего нет в видео, но на чтобы я отдельно обращу внимание.
1. Взаимодействию в процессе реализации проекта сильно помогает понимание с двух сторон, чего стоит ждать и чего не стоит ждать от участников команды. Какие компетенции и скиллы обязательно должны быть со стороны разработчика (не важно на сколько он в курсе специфики отрасли) и со стороны заказчика.
Тут я готовлю отдельный материал по этому вопросу.

2. С любой адекватной командой разработки можно синхронизироваться в контексте (то есть, если они не из ВЭД, то через +- 3-6 месяцев общее понимание того, что происходит придет). И если этот адаптационный период именно со стороны заказчика включить режим цифровой сознательности, то это может стать залогом дальнейшего длительного конструктивного обоюдоудобного взаимодействия.

Можно быстрее? - Да можно.
Можно еще быстрее? - Да. Ищите разработчиков из области.
Но уверенно говорю, все текущие уникальные разработчики из ВЭД когда-то ничего не понимали в специфики логичстических и таможенных бизнес-процессов.

Ссылка на видео.

Микро финал про то, как я нелюбимые проекты по автоматизации декларирования превратил в любимые.
(Часть 1)

Напомню, почему именно автоматизация декларирования стала лично для меня самым нелюбимым видом проектов:

По мере важности:
1. Сопротивления со стороны декларантов больше, чем помощи, высокий уровень скепсиса и недоверия
2. Много нюансов (почти каждый заказчик своя специфика обработки), которые часто вылезают не на старте обсуждения проекта, а в момент тестирования готового решения
3. Разный уровень подготовленности декларантов (в том числе владения программными средствами для декларирования)
4. Несоответствие финансовой оценки целесообразности проекта со стороны заказчика и исполнителя.
Об этом как раз сейчас немного подробнее.

Как я ранее писал, самая "ок" команда для такого проекта – это:
бизнес аналитик/руководитель проекта, декларант (со стороны разработки на подхвате), и программист.
В идеальном варианте совместить декларант+программист в 1 человека (но это скорее исключение из правил, чем правило). Бизнес-аналитика/руководителя проекта исключить вряд ли получится, потому что при прочих равных шероховатости в коммуникации необходимо компенсировать эмоциональным интеллектом, и, в очень большом количестве случаев, программист в этом плане не сильно «клиентоориентирован». То есть, в проекте, где и так все идет не гладко, эмпатию убирать не стоит.

И проект при хорошем раскладе (с учетом занятости декларанта клиента текучкой) будет длиться не менее 2х недель, а то и больше.
Сколько должен стоить такой проект для команды разработки, чтобы он был более-менее финансово интересен? 100 тыс. руб. это прям минимальный минимум, и то со скрипом с учетом того, что сроки, как правило, растягиваются. И это еще с учетом того, что не надо сильно придумывать изысканные способы формирования товарной базы и поиска хитрых ключей для подтягивания кода, описания и разрешиловки.
Предположим, что заказчику повезло, и за разработку отвечает команда стартующих фрилансеров (которые еще готовы хвататься за работу без излишних ожиданий), и возьмут подобный проект скорее для портфолио. Цена может составить 60-70 тыр.

А сколько готов платить заказчик за подобный проект, с учетом того, что по сути на каждого клиента поделка на этап 1 (обработка входящих документов и вычислительные операции) будет почти уникальная. 50 тыр. максимум. Заказчик хочет универсальный продукт, а в текущем контексте это мало осуществимо.

Кажется, что на этом месте. как я последнее время люблю говорить, доклад можно закончить. "До 50 тыр." и "от 100 тыр." стыкуются между собой "никак".
Но
Я продолжу в следующем посте.

Микро финал про то, как я нелюбимые проекты по автоматизации декларирования превратил в любимые.
(часть 2)

Начало тут

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

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

Раньше задача была такая: сделать проект и попробовать потом еще сделать много таких проектов. При этом «сделать проект» получалось формате «серый ящик» (уже не черный, но в целом много непонятного), где:
1) на входе ты получаешь информацию от декларанта, как он работает и типовые формы входящих документов для оформления;
2) предлагаешь декларанту, как и что можно улучшить (на этом этапе где-то 50% информации от тебя воспринимается, как «ну давай-давай, говори-говори», как раз получается именно серый ящик, потому что как ни объясняй – тебя не особо слушают, либо слушают, но не понимают)*;
3) получаешь очень формальное одобрение своей гипотезы улучшения (см. п.2), такое одобрение, когда тебя не сильно слушали, но проще согласиться, чтобы просто отстал;
4) делаешь под гипотезу прототип решения;
5) тестируешь, выявляешь упущения на этапе 2 (а они однозначно будут);
6) переделываешь (5 и 6 может повторяться несколько раз);
7) вот где-то тут что-то похожее на победу и итог.

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

Как недавно мне сказал один из очень опытных бизнес-аналитиков. Давай конкретнее, я не работаю с абстракциями.

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

И я окончательно понял, что такие задачи и формат я поддерживать больше не готов.
Я понял, что задача просто сделать готовое решение в конкретно этом типе проектов – этого мало.

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

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

ПС: Для всех очень опытных бизнес-аналитиков, которые скажут, что п.2 это твоя личная ошибка, типа не надо додумывать, не умеешь взаимодействовать с клиентом и вот это все. Я с Вами соглашусь. И даже спорить не буду. Только покажитесь пожалуйста. С удовольствием обменяюсь опытом взаимодействия с декларантами в ином ключе.

Микро финал про то, как я нелюбимые проекты по автоматизации декларирования превратил в любимые.
(Часть 3 - гранд финал)
Начало тут и тут

Решение оказалось в пересмотре и комбинации подходов.

Как я уже написал ранее, задача стала не только сделать проект (решение для заказчика), но и дать возможность сотрудникам компании дальше подобные проекты делать максимально самостоятельно, быстро и с минимальными затратами.

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

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

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

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

И таких проектов реализуется 2: один, где больше мы показываем и объясняем, как надо, а второй, где сотрудники уже сами пробуют, а моя команда курирует, корректирует и подсказывает.

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

При этом качественно меняется взаимодействие с декларантами. Они вовлекаются в процесс, понимают что и зачем происходит.
Конечно есть нюансы, кончено есть недопонимания, отрицания и прочее. Но оно проходится сильно проще, конструктивнее, а главное результат получается лучше и с первого раза.

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

Для нас это: проекты, которые проходят совсем в других настроениях. И я не буду играть роль одухотворенного цветочка. Финансово такие проекты более интересны.
И, что самое классное, что финансовый профит тут двусторонний. То есть то, что в моменте для заказчика стоит дороже в сроки 2-3 месяца отбивается, компенсируется и потом начинает приносить прямые и косвенные профиты.

Все, тему раскрыл, по крайней мере то что хотел сказать - сказал.

Единственное, мне на днях написали, цитирую
«…С интересом читаю твои последние посты, к тому же ты смотрю затронул тему денег, как мне кажется впервые .. А ты планируешь как то осветить вопрос а зачем условно брокеру все это нужно именно в разрезе финансовой экономии?”

И вот вопрос, надо вопрос экономики раскрыть или нет.
Оставлю опрос ниже, по результату ответов сделаю отдельный пост, если будет виден интерес.

Исчезновение бизнеса таможенных представителей как вида - сценарий первый.

Сегодня в 10.00 побеседуем в прямом эфире с Александром Мякотой на канале Открытая таможня.

С моей стороны тема будет несвойственная - не совсем про цифровые инструменты и технологии. Рядом, но с другой стороны.
Разговор будет в продолжение начатой темы про декларирование без декларации, которое обсуждалось 05.05 с участием Анастасии Чурсиной и Галины Баландиной.

Рекомендую посмотреть этот эфир, интересные темы поднимались, а сегодня их разовьём