В целом последнее, что происходит на этом канале
у нас постепенно раскрывается нейросетевой HR-хоррор «я не знаю, что Вы будете делать следующим летом» , где мы оцениваем на сколько нейросети смогут поддержать/заменить какие-либо функции в компаниях таможенно-логистической отрасли.
В рамках этого опуса подробно задержались на вопросе подходов к автоматизации декларирования – и эта тема будет раскрыта до конца в ближайшее время.
Попутно, после вчерашнего моего выступления в информационных каналах началось относительно живое (на сколько это применимо к нашей отрасли) обсуждение вопросов ИИ в применении к ВЭД. Приличная доза хейта (что в общем логично) тоже имела место быть. И это здорово, значит вопрос актуальный.
По этому поводу немного подробнее напишу/расскажу где ключевое заблуждение, и как имеет смысл рассматривать технологии, чтобы не было «либо черное» (все отстой ничего не работает), «либо белое» (робот работает, человек не работает, что тоже по факту отстой).
И еще после моего выступления были вопросы, а как все это нейросетевое своими руками попробовать.
Поэтому тоже в ближайших постах напишу ссылки на нейросети и приложения, которые решают те задачи, о которых я говорил на выступлении, покажу сравнительные примеры генераций одного и того же через разные источники.
Да, я не пишу каждый день по 3 раза в день, лишь бы поддерживать эфир и подогревать ажиотаж. Этот блог не ведет нейросеть «водяным контентом». Все что пишется – пишется человеком, но человеком, который работает с цифровыми инструментами.
Как в свое время сказал один из топов очень крупного таможенного представителя, с которым мы начали делать совместный проект: «ЦифроВЭД – это для ценителей».
у нас постепенно раскрывается нейросетевой HR-хоррор «я не знаю, что Вы будете делать следующим летом» , где мы оцениваем на сколько нейросети смогут поддержать/заменить какие-либо функции в компаниях таможенно-логистической отрасли.
В рамках этого опуса подробно задержались на вопросе подходов к автоматизации декларирования – и эта тема будет раскрыта до конца в ближайшее время.
Попутно, после вчерашнего моего выступления в информационных каналах началось относительно живое (на сколько это применимо к нашей отрасли) обсуждение вопросов ИИ в применении к ВЭД. Приличная доза хейта (что в общем логично) тоже имела место быть. И это здорово, значит вопрос актуальный.
По этому поводу немного подробнее напишу/расскажу где ключевое заблуждение, и как имеет смысл рассматривать технологии, чтобы не было «либо черное» (все отстой ничего не работает), «либо белое» (робот работает, человек не работает, что тоже по факту отстой).
И еще после моего выступления были вопросы, а как все это нейросетевое своими руками попробовать.
Поэтому тоже в ближайших постах напишу ссылки на нейросети и приложения, которые решают те задачи, о которых я говорил на выступлении, покажу сравнительные примеры генераций одного и того же через разные источники.
Да, я не пишу каждый день по 3 раза в день, лишь бы поддерживать эфир и подогревать ажиотаж. Этот блог не ведет нейросеть «водяным контентом». Все что пишется – пишется человеком, но человеком, который работает с цифровыми инструментами.
Как в свое время сказал один из топов очень крупного таможенного представителя, с которым мы начали делать совместный проект: «ЦифроВЭД – это для ценителей».
👍3
До недавнего времени из всех возможных задачи по автоматизации - автоматизация декларирования была моя самая нелюбимая.
Последнее, о чем я писал по этому вопросу, это то, что был сформирован общий концепт подходов (вариативности) решения задачи, исходя из этапов и возможных инструментов. Этот концепт всегда мной отправляется в начале разговора заказчикам, для того, чтобы ввести к контекст решений, обрисовать существующие направления и дать возможность провести у себя самостоятельную предварительную подготовку. Более того, я еще обычно скидываю инструмент поиска тех самых проектов, которые соответствуют критериям потенциала автоматизации, напомню:
повторяемость номенклатуры
регулярность поставок
документы на входе, которые могут быть корректно распознаны.
И как Вы думаете, что происходит дальше?
А несколько моментов и они всегда одни и те же:
1. Самостоятельно вопрос внутри компании не прорабатывается (классика: нет времени, а скорее желания разбираться в вопросе самостоятельно).
2. На подробную информацию о том, как автоматизировать декларирование реакция приблизительно следующая: «это не про нас», «у нас ничего не повторяется, все уникально и т.д.».
В общем Элла Владиленовна во всей своей красе.
Дальше сценарий тоже схожий.
Если руководитель, который вышел на мою команду с задачей, все-таки твердо решил попробовать, то дается команда коллегам из отдела декларирования «работаем, несмотря ни на что». И дальше работаем и приходим к результату/решению, которые разные, с точки зрения технологии, но все попадают под описанную выше логику.
Если у руководителя интерес был скорее найти волшебную кнопку «автоматизация», а по факту оказалось, что тут надо всем коллективом активно участвовать в проекте, а сильного внутреннего желания нет, то вопрос закрывается, и все довольны. Я и моя команда не потратили лишнего времени, Эллы Владиленовны не вышли из зоны комфорта и тихо вернулись в привычный теплый мир своей рутинной ручной обработки документов. Более того, еще и самоутвердились, что очередного «шарлатана и сказочника» слили. Волшебная кнопка автоматизация (в случае с таможенным оформлением), это такая же волшебная кнопка, как «бабло», которой в общем не существует до тех пор, пока не поработаешь в этом направлении.
И ключевой вопрос, почему я не пытаюсь как-то продавить, допродать услугу во втором случае.
Отвечу.
Потому что, в этом нет никакого смысла. 90% этот проект пойдет тяжело, растянется во времени, и с большой вероятностью суммарно выйдет в минус по затратам и эмоциональному фону. Сотрудники такой компании будут не пытаться помочь команде разработки решить общую задачу, а будут больше сил тратить на то, чтобы найти недостатки/ошибки/недочеты в работе команды разработки. То есть тут будет не общая цель «решить сложную задачу для блага компании», а будет холивар отвоевать право на то, что «как я говорил/говорила что тут ничего невозможно, так оно и есть».
И именно до недавнего времени из всех возможных задач по автоматизации, автоматизация декларирования была моя самая нелюбимая.
Она максимально хорошо показывала, что если в проекте нет обоюдного интереса, то проект хорошо не получится.
В отличии от других решений (например учетные системы, автоматизация отчетности и т.д.) тут сложно сделать проект условно «на спор и вопреки». В процессе обработки документов куча нюансов.
И даже с супер командой:
- бизнес аналитик из отрасли, понимающий про все, что тут делается;
- декларант практик (для консультации по специфике отдельных моментов в программах по декларированию);
- программист;
при отсутствии содействия со стороны исполнителя заказчика результат будет не очень.
Но, ситуацию радикально изменилась, когда я изменил подход к этим проектам. Об этом в следующем посте.
Последнее, о чем я писал по этому вопросу, это то, что был сформирован общий концепт подходов (вариативности) решения задачи, исходя из этапов и возможных инструментов. Этот концепт всегда мной отправляется в начале разговора заказчикам, для того, чтобы ввести к контекст решений, обрисовать существующие направления и дать возможность провести у себя самостоятельную предварительную подготовку. Более того, я еще обычно скидываю инструмент поиска тех самых проектов, которые соответствуют критериям потенциала автоматизации, напомню:
повторяемость номенклатуры
регулярность поставок
документы на входе, которые могут быть корректно распознаны.
И как Вы думаете, что происходит дальше?
А несколько моментов и они всегда одни и те же:
1. Самостоятельно вопрос внутри компании не прорабатывается (классика: нет времени, а скорее желания разбираться в вопросе самостоятельно).
2. На подробную информацию о том, как автоматизировать декларирование реакция приблизительно следующая: «это не про нас», «у нас ничего не повторяется, все уникально и т.д.».
В общем Элла Владиленовна во всей своей красе.
Дальше сценарий тоже схожий.
Если руководитель, который вышел на мою команду с задачей, все-таки твердо решил попробовать, то дается команда коллегам из отдела декларирования «работаем, несмотря ни на что». И дальше работаем и приходим к результату/решению, которые разные, с точки зрения технологии, но все попадают под описанную выше логику.
Если у руководителя интерес был скорее найти волшебную кнопку «автоматизация», а по факту оказалось, что тут надо всем коллективом активно участвовать в проекте, а сильного внутреннего желания нет, то вопрос закрывается, и все довольны. Я и моя команда не потратили лишнего времени, Эллы Владиленовны не вышли из зоны комфорта и тихо вернулись в привычный теплый мир своей рутинной ручной обработки документов. Более того, еще и самоутвердились, что очередного «шарлатана и сказочника» слили. Волшебная кнопка автоматизация (в случае с таможенным оформлением), это такая же волшебная кнопка, как «бабло», которой в общем не существует до тех пор, пока не поработаешь в этом направлении.
И ключевой вопрос, почему я не пытаюсь как-то продавить, допродать услугу во втором случае.
Отвечу.
Потому что, в этом нет никакого смысла. 90% этот проект пойдет тяжело, растянется во времени, и с большой вероятностью суммарно выйдет в минус по затратам и эмоциональному фону. Сотрудники такой компании будут не пытаться помочь команде разработки решить общую задачу, а будут больше сил тратить на то, чтобы найти недостатки/ошибки/недочеты в работе команды разработки. То есть тут будет не общая цель «решить сложную задачу для блага компании», а будет холивар отвоевать право на то, что «как я говорил/говорила что тут ничего невозможно, так оно и есть».
И именно до недавнего времени из всех возможных задач по автоматизации, автоматизация декларирования была моя самая нелюбимая.
Она максимально хорошо показывала, что если в проекте нет обоюдного интереса, то проект хорошо не получится.
В отличии от других решений (например учетные системы, автоматизация отчетности и т.д.) тут сложно сделать проект условно «на спор и вопреки». В процессе обработки документов куча нюансов.
И даже с супер командой:
- бизнес аналитик из отрасли, понимающий про все, что тут делается;
- декларант практик (для консультации по специфике отдельных моментов в программах по декларированию);
- программист;
при отсутствии содействия со стороны исполнителя заказчика результат будет не очень.
Но, ситуацию радикально изменилась, когда я изменил подход к этим проектам. Об этом в следующем посте.
👍1
Нейросетевых досмотровый зайчиков в ленту, и пусть в реальной жизни досмотров будет меньше, а автовыпусков больше)
Хорошей недели.
Хорошей недели.
🔥2
Имеем: проект по автоматизации декларирования, в компании опыт подобный первый раз.
Декларанты и менеджеры, участвующие, которых руководитель выбрал для проекта - отзывчивые, готовые к изменениям, но конечно же вовлеченные в текущую работу.
Этап интервьюирования и поиска решения прошли хорошо.
Этап уточнения логики автоматизации подбора кода прошли в 2 этапа:
гипотеза 1, хорошая, но не оправдалась, гипотеза 2, не самая лучшая, но жизненная в контексте специфики товара была принята за рабочую.
Этап разработки начался тоже хорошо. На этом проекте со стороны разработки вообще уникальный состав, в том числе программист с опытом декларирования и работы в декларантских программах (у меня в команде и такие есть).
И начался неизбежный этап уточнения деталей, которые всегда возникает, когда техническое задание попадает в разработку.
Почему?
Да в общем потому, что крайне сложно предусмотреть сразу все нюансы, это раз, ну и когда начинаешь программно разбирать то, что руками не прототипировал тоже может вылезти что-то.
В данном случае это обработка большого текстового массива для его формирования в единый блок для заполнения очень специфической части ДТ (в котором большое количество технических символов, в том числе «’», которые могут быть в начале ячейки и при переносе в ДТ могут быть считаны некорректно).
А еще, когда программист (который непосредственно работает с решением) начинает что-то делать у него могут появиться дополнительные мысли/вопросы/уточнения, которые могут даже улучшить решение. Но они возникают именно тогда, когда программист начинает работать, а не на этапе интервьюирования и/или описания задачи (когда работает больше бизнес-аналитик).
Так вот, начался этап уточнения нюансов в процессе разработки. И вот тут уже сотрудник со стороны заказчика однозначно дает понять, что по его мнению, вопросов много, они излишние ну и вот это все.
Если уж совсем уходить в детали, то в программах декларирования (в данном случае Альта-Заполнитель есть удивительный нюанс, что в зависимости от того, какой именно документ будет формироваться из заполнителя (ДТ или инвойс) то там разный набор разметок столбцов. То есть, из заполнителя можно сразу формировать документ ДТ – и тогда будет использоваться один набор связей «таблица – заголовки», а может формироваться документ «мастер инвойс» - и тогда будет совсем другой набор связей «таблица – заголовки». Справедливости ради надо сказать, что в мастер инвойсе полей и возможностей больше, и то, что есть в рамках набора полей для документа инвойс, может не быть для документа ДТ. И если сотрудник из заполнителя всегда делал мастер-инвойс (из которого в свою очередь потом делает все остальные доки, включая ДТ), и не делал ничего другого, то для него единственная правда в том, что там все очевидно и вариативности быть не может. А для разработчика, который знает, что на этом этапе есть логическая вариативность использования различных схем заголовков, необходима конкретика).
И надо поблагодарить сотрудника заказчика за стойкость, эмоциональный интеллект и умение слушать и слышать. Обычно подобные моменты возникают раньше.
Компромисс был найден, ответы получены, разработка продолжается.
Но
В данном случае желание людей услышать друг друга с двух сторон позволило вопрос вывести в конструктивное русло. Но в других ситуациях эта же ситуация могла свести всю работу на нет, а еще навсегда в голове сотрудника поселить мысль о том, что «все автоматизаторы шарлатаны, проходимцы, бездари, сказочники», а еще, как недавно деликатно выразился один руководитель известного логистического оператора «лодыри, если не работают 5/8 в офисе» (тут тоже явное когнитивное искажение, но о нем как-нибудь потом).
Декларанты и менеджеры, участвующие, которых руководитель выбрал для проекта - отзывчивые, готовые к изменениям, но конечно же вовлеченные в текущую работу.
Этап интервьюирования и поиска решения прошли хорошо.
Этап уточнения логики автоматизации подбора кода прошли в 2 этапа:
гипотеза 1, хорошая, но не оправдалась, гипотеза 2, не самая лучшая, но жизненная в контексте специфики товара была принята за рабочую.
Этап разработки начался тоже хорошо. На этом проекте со стороны разработки вообще уникальный состав, в том числе программист с опытом декларирования и работы в декларантских программах (у меня в команде и такие есть).
И начался неизбежный этап уточнения деталей, которые всегда возникает, когда техническое задание попадает в разработку.
Почему?
Да в общем потому, что крайне сложно предусмотреть сразу все нюансы, это раз, ну и когда начинаешь программно разбирать то, что руками не прототипировал тоже может вылезти что-то.
В данном случае это обработка большого текстового массива для его формирования в единый блок для заполнения очень специфической части ДТ (в котором большое количество технических символов, в том числе «’», которые могут быть в начале ячейки и при переносе в ДТ могут быть считаны некорректно).
А еще, когда программист (который непосредственно работает с решением) начинает что-то делать у него могут появиться дополнительные мысли/вопросы/уточнения, которые могут даже улучшить решение. Но они возникают именно тогда, когда программист начинает работать, а не на этапе интервьюирования и/или описания задачи (когда работает больше бизнес-аналитик).
Так вот, начался этап уточнения нюансов в процессе разработки. И вот тут уже сотрудник со стороны заказчика однозначно дает понять, что по его мнению, вопросов много, они излишние ну и вот это все.
Если уж совсем уходить в детали, то в программах декларирования (в данном случае Альта-Заполнитель есть удивительный нюанс, что в зависимости от того, какой именно документ будет формироваться из заполнителя (ДТ или инвойс) то там разный набор разметок столбцов. То есть, из заполнителя можно сразу формировать документ ДТ – и тогда будет использоваться один набор связей «таблица – заголовки», а может формироваться документ «мастер инвойс» - и тогда будет совсем другой набор связей «таблица – заголовки». Справедливости ради надо сказать, что в мастер инвойсе полей и возможностей больше, и то, что есть в рамках набора полей для документа инвойс, может не быть для документа ДТ. И если сотрудник из заполнителя всегда делал мастер-инвойс (из которого в свою очередь потом делает все остальные доки, включая ДТ), и не делал ничего другого, то для него единственная правда в том, что там все очевидно и вариативности быть не может. А для разработчика, который знает, что на этом этапе есть логическая вариативность использования различных схем заголовков, необходима конкретика).
И надо поблагодарить сотрудника заказчика за стойкость, эмоциональный интеллект и умение слушать и слышать. Обычно подобные моменты возникают раньше.
Компромисс был найден, ответы получены, разработка продолжается.
Но
В данном случае желание людей услышать друг друга с двух сторон позволило вопрос вывести в конструктивное русло. Но в других ситуациях эта же ситуация могла свести всю работу на нет, а еще навсегда в голове сотрудника поселить мысль о том, что «все автоматизаторы шарлатаны, проходимцы, бездари, сказочники», а еще, как недавно деликатно выразился один руководитель известного логистического оператора «лодыри, если не работают 5/8 в офисе» (тут тоже явное когнитивное искажение, но о нем как-нибудь потом).
👍2
Описанное выше яркий пример нескольких моментов:
1) разрыв в компетенциях и коммуникации между заказчиком – бизнес-аналитиком – разработчиком;
2) различные ожидания сторон от коммуникации, и что есть «нормальный вопрос», а что «излишний»
3) общая напряженность от совмещения «текущая работа» отвлечение на «что-то иное».
И вот эта описанная ситуация еще лучше и полнее подводит к двум вещам:
- про искажения коммуникации и компетенций в процессе реализации проекта (следующим постом выложу видео на эту тему, которые было записано на одном из выступлений про «цифровую сознательность»).
- про мое переосмысление подходов к проектам по автоматизации декларирования, о котором обещал рассказать ранее.
1) разрыв в компетенциях и коммуникации между заказчиком – бизнес-аналитиком – разработчиком;
2) различные ожидания сторон от коммуникации, и что есть «нормальный вопрос», а что «излишний»
3) общая напряженность от совмещения «текущая работа» отвлечение на «что-то иное».
И вот эта описанная ситуация еще лучше и полнее подводит к двум вещам:
- про искажения коммуникации и компетенций в процессе реализации проекта (следующим постом выложу видео на эту тему, которые было записано на одном из выступлений про «цифровую сознательность»).
- про мое переосмысление подходов к проектам по автоматизации декларирования, о котором обещал рассказать ранее.
👍2
О разрывах компетенций и искажениях в процессе реализации проекта.
В видео часть выступления по этому вопросу. Ссылка на видео в конце поста. Это самая-самая боль. Я бы сказал, что это 90% успеха или неуспеха проекта. Она же причина и объяснение ситуации, которая была описана вчера.
И тут лучше посмотреть, чем пытаться это тезисно описывать.
В видео наглядно о причинах дискоммуникации и о том, как надо:
чтобы было хорошо
и
чтобы в будущем сделать цифровые проекты быстрее и бюджетнее.
Чего нет в видео, но на чтобы я отдельно обращу внимание.
1. Взаимодействию в процессе реализации проекта сильно помогает понимание с двух сторон, чего стоит ждать и чего не стоит ждать от участников команды. Какие компетенции и скиллы обязательно должны быть со стороны разработчика (не важно на сколько он в курсе специфики отрасли) и со стороны заказчика.
Тут я готовлю отдельный материал по этому вопросу.
2. С любой адекватной командой разработки можно синхронизироваться в контексте (то есть, если они не из ВЭД, то через +- 3-6 месяцев общее понимание того, что происходит придет). И если этот адаптационный период именно со стороны заказчика включить режим цифровой сознательности, то это может стать залогом дальнейшего длительного конструктивного обоюдоудобного взаимодействия.
Можно быстрее? - Да можно.
Можно еще быстрее? - Да. Ищите разработчиков из области.
Но уверенно говорю, все текущие уникальные разработчики из ВЭД когда-то ничего не понимали в специфики логичстических и таможенных бизнес-процессов.
Ссылка на видео.
В видео часть выступления по этому вопросу. Ссылка на видео в конце поста. Это самая-самая боль. Я бы сказал, что это 90% успеха или неуспеха проекта. Она же причина и объяснение ситуации, которая была описана вчера.
И тут лучше посмотреть, чем пытаться это тезисно описывать.
В видео наглядно о причинах дискоммуникации и о том, как надо:
чтобы было хорошо
и
чтобы в будущем сделать цифровые проекты быстрее и бюджетнее.
Чего нет в видео, но на чтобы я отдельно обращу внимание.
1. Взаимодействию в процессе реализации проекта сильно помогает понимание с двух сторон, чего стоит ждать и чего не стоит ждать от участников команды. Какие компетенции и скиллы обязательно должны быть со стороны разработчика (не важно на сколько он в курсе специфики отрасли) и со стороны заказчика.
Тут я готовлю отдельный материал по этому вопросу.
2. С любой адекватной командой разработки можно синхронизироваться в контексте (то есть, если они не из ВЭД, то через +- 3-6 месяцев общее понимание того, что происходит придет). И если этот адаптационный период именно со стороны заказчика включить режим цифровой сознательности, то это может стать залогом дальнейшего длительного конструктивного обоюдоудобного взаимодействия.
Можно быстрее? - Да можно.
Можно еще быстрее? - Да. Ищите разработчиков из области.
Но уверенно говорю, все текущие уникальные разработчики из ВЭД когда-то ничего не понимали в специфики логичстических и таможенных бизнес-процессов.
Ссылка на видео.
YouTube
Компетенции и искажения в проекте
О разрывах в компетенциях и искажениях в ходе реализации цифрового проета.
Больше информации на телеграм канале ЦифроВЭД:
https://t.me/ciberved
Больше о проекте Руна-IT:
https://www.runa-it.ru
Больше информации на телеграм канале ЦифроВЭД:
https://t.me/ciberved
Больше о проекте Руна-IT:
https://www.runa-it.ru
👍1
Микро финал про то, как я нелюбимые проекты по автоматизации декларирования превратил в любимые.
(Часть 1)
Напомню, почему именно автоматизация декларирования стала лично для меня самым нелюбимым видом проектов:
По мере важности:
1. Сопротивления со стороны декларантов больше, чем помощи, высокий уровень скепсиса и недоверия
2. Много нюансов (почти каждый заказчик своя специфика обработки), которые часто вылезают не на старте обсуждения проекта, а в момент тестирования готового решения
3. Разный уровень подготовленности декларантов (в том числе владения программными средствами для декларирования)
4. Несоответствие финансовой оценки целесообразности проекта со стороны заказчика и исполнителя.
Об этом как раз сейчас немного подробнее.
Как я ранее писал, самая "ок" команда для такого проекта – это:
бизнес аналитик/руководитель проекта, декларант (со стороны разработки на подхвате), и программист.
В идеальном варианте совместить декларант+программист в 1 человека (но это скорее исключение из правил, чем правило). Бизнес-аналитика/руководителя проекта исключить вряд ли получится, потому что при прочих равных шероховатости в коммуникации необходимо компенсировать эмоциональным интеллектом, и, в очень большом количестве случаев, программист в этом плане не сильно «клиентоориентирован». То есть, в проекте, где и так все идет не гладко, эмпатию убирать не стоит.
И проект при хорошем раскладе (с учетом занятости декларанта клиента текучкой) будет длиться не менее 2х недель, а то и больше.
Сколько должен стоить такой проект для команды разработки, чтобы он был более-менее финансово интересен? 100 тыс. руб. это прям минимальный минимум, и то со скрипом с учетом того, что сроки, как правило, растягиваются. И это еще с учетом того, что не надо сильно придумывать изысканные способы формирования товарной базы и поиска хитрых ключей для подтягивания кода, описания и разрешиловки.
Предположим, что заказчику повезло, и за разработку отвечает команда стартующих фрилансеров (которые еще готовы хвататься за работу без излишних ожиданий), и возьмут подобный проект скорее для портфолио. Цена может составить 60-70 тыр.
А сколько готов платить заказчик за подобный проект, с учетом того, что по сути на каждого клиента поделка на этап 1 (обработка входящих документов и вычислительные операции) будет почти уникальная. 50 тыр. максимум. Заказчик хочет универсальный продукт, а в текущем контексте это мало осуществимо.
Кажется, что на этом месте. как я последнее время люблю говорить, доклад можно закончить. "До 50 тыр." и "от 100 тыр." стыкуются между собой "никак".
Но
Я продолжу в следующем посте.
(Часть 1)
Напомню, почему именно автоматизация декларирования стала лично для меня самым нелюбимым видом проектов:
По мере важности:
1. Сопротивления со стороны декларантов больше, чем помощи, высокий уровень скепсиса и недоверия
2. Много нюансов (почти каждый заказчик своя специфика обработки), которые часто вылезают не на старте обсуждения проекта, а в момент тестирования готового решения
3. Разный уровень подготовленности декларантов (в том числе владения программными средствами для декларирования)
4. Несоответствие финансовой оценки целесообразности проекта со стороны заказчика и исполнителя.
Об этом как раз сейчас немного подробнее.
Как я ранее писал, самая "ок" команда для такого проекта – это:
бизнес аналитик/руководитель проекта, декларант (со стороны разработки на подхвате), и программист.
В идеальном варианте совместить декларант+программист в 1 человека (но это скорее исключение из правил, чем правило). Бизнес-аналитика/руководителя проекта исключить вряд ли получится, потому что при прочих равных шероховатости в коммуникации необходимо компенсировать эмоциональным интеллектом, и, в очень большом количестве случаев, программист в этом плане не сильно «клиентоориентирован». То есть, в проекте, где и так все идет не гладко, эмпатию убирать не стоит.
И проект при хорошем раскладе (с учетом занятости декларанта клиента текучкой) будет длиться не менее 2х недель, а то и больше.
Сколько должен стоить такой проект для команды разработки, чтобы он был более-менее финансово интересен? 100 тыс. руб. это прям минимальный минимум, и то со скрипом с учетом того, что сроки, как правило, растягиваются. И это еще с учетом того, что не надо сильно придумывать изысканные способы формирования товарной базы и поиска хитрых ключей для подтягивания кода, описания и разрешиловки.
Предположим, что заказчику повезло, и за разработку отвечает команда стартующих фрилансеров (которые еще готовы хвататься за работу без излишних ожиданий), и возьмут подобный проект скорее для портфолио. Цена может составить 60-70 тыр.
А сколько готов платить заказчик за подобный проект, с учетом того, что по сути на каждого клиента поделка на этап 1 (обработка входящих документов и вычислительные операции) будет почти уникальная. 50 тыр. максимум. Заказчик хочет универсальный продукт, а в текущем контексте это мало осуществимо.
Кажется, что на этом месте. как я последнее время люблю говорить, доклад можно закончить. "До 50 тыр." и "от 100 тыр." стыкуются между собой "никак".
Но
Я продолжу в следующем посте.
👍1
Немного понедельничного трендвотчинга и кринжа
Во всех группах про нейросети постоянно ходят картинки про героев Гарри Поттера в альтернативных реальностях (СССР, зомби-апокалипсис и т.д.).
Гарантирую такого прочтения ещё никто не делал.
Гарри Поттер и волшебный мир ВЭД.
Всем волшебной недели.
ПС: наша родная Российская нейронка от Сбера максимально отразила «настроение». Ванильные фотки от зарубежных сетей в комментах, и оно вообще не то.
Во всех группах про нейросети постоянно ходят картинки про героев Гарри Поттера в альтернативных реальностях (СССР, зомби-апокалипсис и т.д.).
Гарантирую такого прочтения ещё никто не делал.
Гарри Поттер и волшебный мир ВЭД.
Всем волшебной недели.
ПС: наша родная Российская нейронка от Сбера максимально отразила «настроение». Ванильные фотки от зарубежных сетей в комментах, и оно вообще не то.
😁4
Микро финал про то, как я нелюбимые проекты по автоматизации декларирования превратил в любимые.
(часть 2)
Начало тут
Финалом моих экзистенциальных мучений по вопросу «как сделать автоматизацию декларирования чем-то конструктивно-позитивным» стала ситуация, когда наша команда общалась с одной из компаний-таможенных представителей.
Выяснилось, что у них проекты по автоматизации декларирования поставлены на поток и декларанты (или менеджеры) сами взаимодействуют с «прикормленным программистом». Стоимость такого взаимодействия минимальна. На столько минимальна, что тут даже не каждый фрилансер возьмется за задачу. Более того, когда я увидел техническое задание, у меня выпал глаз, потому что я в нем ничего не понял. Но этой отработанной связке «декларант – прикормленный программист» было достаточно взаимопонимания, чтобы условно «на салфетке» описывать задачу.
И вот где-то после этой ситуации плюс еще одного сложного (на грани экономической и эмоциональной целесообразности) проекта по автоматизации декларирования мне пришло понимание, как можно поменять фокус внимания.
Раньше задача была такая: сделать проект и попробовать потом еще сделать много таких проектов. При этом «сделать проект» получалось формате «серый ящик» (уже не черный, но в целом много непонятного), где:
1) на входе ты получаешь информацию от декларанта, как он работает и типовые формы входящих документов для оформления;
2) предлагаешь декларанту, как и что можно улучшить (на этом этапе где-то 50% информации от тебя воспринимается, как «ну давай-давай, говори-говори», как раз получается именно серый ящик, потому что как ни объясняй – тебя не особо слушают, либо слушают, но не понимают)*;
3) получаешь очень формальное одобрение своей гипотезы улучшения (см. п.2), такое одобрение, когда тебя не сильно слушали, но проще согласиться, чтобы просто отстал;
4) делаешь под гипотезу прототип решения;
5) тестируешь, выявляешь упущения на этапе 2 (а они однозначно будут);
6) переделываешь (5 и 6 может повторяться несколько раз);
7) вот где-то тут что-то похожее на победу и итог.
* уточнение по п.2: актуально все что писал ранее, плюс образность мышления у заказчика стремится к нулю (в большинстве случаев). То есть если ты даже покажешь схожий кейс (но не совсем один в один как у конкретного декларанта), то «додумывать, что в демонстрационном кейсе с документом и информацией делаем вот это, а в нашем случае это будет тоже самое, но немного по другому» никто не будет.
Как недавно мне сказал один из очень опытных бизнес-аналитиков. Давай конкретнее, я не работаю с абстракциями.
В рассматриваемом взаимодействия с декларантом «не работаю с абстракциями» - это что-то из серии: «покажи мне готовый кейс решения именно моей задачи один в один, и я готов буду с тобой дальше разговаривать».
И я окончательно понял, что такие задачи и формат я поддерживать больше не готов.
Я понял, что задача просто сделать готовое решение в конкретно этом типе проектов – этого мало.
Я понял, чтобы получился действительный профит для компании-заказчика, надо сделать так, чтобы поменялось мировоззрение декларанта и, чтобы он смог стать таким же, как те ребята, о которых я написал в самом начале. Декларанты, которые сами генерят задачи для программиста на салфетке.
Букв опять получилось много, поэтому будет еще часть третья, завершающая. Но по сути даже тут уже озвучена основная идея, которая легла в основу переосмысления подходов к проектам по автоматизации декларирования.
ПС: Для всех очень опытных бизнес-аналитиков, которые скажут, что п.2 это твоя личная ошибка, типа не надо додумывать, не умеешь взаимодействовать с клиентом и вот это все. Я с Вами соглашусь. И даже спорить не буду. Только покажитесь пожалуйста. С удовольствием обменяюсь опытом взаимодействия с декларантами в ином ключе.
(часть 2)
Начало тут
Финалом моих экзистенциальных мучений по вопросу «как сделать автоматизацию декларирования чем-то конструктивно-позитивным» стала ситуация, когда наша команда общалась с одной из компаний-таможенных представителей.
Выяснилось, что у них проекты по автоматизации декларирования поставлены на поток и декларанты (или менеджеры) сами взаимодействуют с «прикормленным программистом». Стоимость такого взаимодействия минимальна. На столько минимальна, что тут даже не каждый фрилансер возьмется за задачу. Более того, когда я увидел техническое задание, у меня выпал глаз, потому что я в нем ничего не понял. Но этой отработанной связке «декларант – прикормленный программист» было достаточно взаимопонимания, чтобы условно «на салфетке» описывать задачу.
И вот где-то после этой ситуации плюс еще одного сложного (на грани экономической и эмоциональной целесообразности) проекта по автоматизации декларирования мне пришло понимание, как можно поменять фокус внимания.
Раньше задача была такая: сделать проект и попробовать потом еще сделать много таких проектов. При этом «сделать проект» получалось формате «серый ящик» (уже не черный, но в целом много непонятного), где:
1) на входе ты получаешь информацию от декларанта, как он работает и типовые формы входящих документов для оформления;
2) предлагаешь декларанту, как и что можно улучшить (на этом этапе где-то 50% информации от тебя воспринимается, как «ну давай-давай, говори-говори», как раз получается именно серый ящик, потому что как ни объясняй – тебя не особо слушают, либо слушают, но не понимают)*;
3) получаешь очень формальное одобрение своей гипотезы улучшения (см. п.2), такое одобрение, когда тебя не сильно слушали, но проще согласиться, чтобы просто отстал;
4) делаешь под гипотезу прототип решения;
5) тестируешь, выявляешь упущения на этапе 2 (а они однозначно будут);
6) переделываешь (5 и 6 может повторяться несколько раз);
7) вот где-то тут что-то похожее на победу и итог.
* уточнение по п.2: актуально все что писал ранее, плюс образность мышления у заказчика стремится к нулю (в большинстве случаев). То есть если ты даже покажешь схожий кейс (но не совсем один в один как у конкретного декларанта), то «додумывать, что в демонстрационном кейсе с документом и информацией делаем вот это, а в нашем случае это будет тоже самое, но немного по другому» никто не будет.
Как недавно мне сказал один из очень опытных бизнес-аналитиков. Давай конкретнее, я не работаю с абстракциями.
В рассматриваемом взаимодействия с декларантом «не работаю с абстракциями» - это что-то из серии: «покажи мне готовый кейс решения именно моей задачи один в один, и я готов буду с тобой дальше разговаривать».
И я окончательно понял, что такие задачи и формат я поддерживать больше не готов.
Я понял, что задача просто сделать готовое решение в конкретно этом типе проектов – этого мало.
Я понял, чтобы получился действительный профит для компании-заказчика, надо сделать так, чтобы поменялось мировоззрение декларанта и, чтобы он смог стать таким же, как те ребята, о которых я написал в самом начале. Декларанты, которые сами генерят задачи для программиста на салфетке.
Букв опять получилось много, поэтому будет еще часть третья, завершающая. Но по сути даже тут уже озвучена основная идея, которая легла в основу переосмысления подходов к проектам по автоматизации декларирования.
ПС: Для всех очень опытных бизнес-аналитиков, которые скажут, что п.2 это твоя личная ошибка, типа не надо додумывать, не умеешь взаимодействовать с клиентом и вот это все. Я с Вами соглашусь. И даже спорить не буду. Только покажитесь пожалуйста. С удовольствием обменяюсь опытом взаимодействия с декларантами в ином ключе.
👍2