Введение
Хочу с вами поделиться ходом одного недавнего проекта (а по сути это даже не проект, а небольшая задача). Этот текст скорее написал для ретроспективы лично для себя. Но вам тоже полезно будет почитать. Ни к чему в нем не призываю, просто представляю на всеобщее обозрение один из проектов. Может быть, вы почерпнете какую-то информацию для себя, и не позволите другим сделать ошибки, которые позволили мы.
С чего все началось
В один прекрасный вечер пятницы звонит клиент со словами "Здравствуйте. Нам надо за 1 неделю сделать маркировку пива в бутылках на конвейере. Оборудование мы уже купили. Документацию к нему выслали на почту.". На этом моменте вечер пятницы перестал быть прекрасным по очевидным причинам. Сразу было обозначено, что за неделю это сделать невозможно, минимум месяц.
Этап 1. Обследование задачи
Клиент прислал документация купленного оборудования, а именно способ обмена с ним данными. Бегло глянув в документацию я сразу определил формат обмена - это же обычный XML файл! Да и у оборудования оказывается стояло программное обеспечение на том же сервере, что и 1С. Перспективы были радужные: пару десятков методов для обмена и готово.
Тут важно отметить, что документация была пару десятков страниц, поэтому изучать её за бесплатно - не радужная перспектива. За подготовительный этап обследования было выставлено 6 часов клиенту. Благо клиент сам все понимал и быстро согласился.
Заглушив все радостные (и не очень) мысли, я с холодной головой стал изучать, что же требуется передать и принять от системы. Изучая строку за строкой, я обнаружил низкое качество документации. Некоторые поля в файлах вообще были без пояснений, хотя и имели какие-то значения.
Изучив весь файл, вот что стало понятно:
- На вход нужно подать заранее заказанные коды маркировки.
- На выходе нужно забрать список кодов, успешно нанесенных на банки.
Картина архитектуры была довольно простой, делалась на 2 этапа:
- Формирование входных данных. Заказ кодов на эмиссию в 1С - получение кодов от Честного Знака - формирование XML для передачи - передача в стороннее ПО.
- Разбор выходных данных. Чтение XML с отчетом по смене - формирование документа выпуска продукции в 1С - отправка данных в Честный знак.
Решив, что для пятницы это вполне хороший результат анализа, пошел со спокойной душой домой. Задача была оценена в 50 часов. Насколько мы попали в эту цифру - узнаете в конце статьи.
Этап 2. Собрание рабочей группы
Сразу после согласования стоимости работ был создан чат в WhatsApp (желание заказчика). В него были включены на первом этапе:
- Со стороны заказчика: системный администратор.
- Со стороны исполнителя: разработчик (он же мини аналитик) и руководитель проекта.
В конце документации для оборудования быстро обнаружился телефон поддержки. Немедленно связался с поддержкой для получения информации: возможна ли поддержка на период внедрения. Как оказалось - возможна. Правда чтобы получить такой ответ мне пришлось 1 час дозваниваться по разным телефонам, меня переводили с одного сотрудника на другого, кто-то в отпуске, кто-то болеет. В конце я почти отчаялся.
Через несколько дней в рабочую группу был добавлен специалист-консультант со стороны оборудования. Чат стал насчитывать 4 человека.
Этап 3. Разработка
Формирование входных данных
Первое, что необходимо было сделать - передать список номенклатуры, которая будет маркироваться на конвейере, на программное обеспечение оборудования. Для этого была написана самая простая обработка с подбором номенклатуры и сохранением в .xlsx файл. Тут не было никаких сложностей. Заказчик четко знал, что будет выпускать и как это называется в базе 1С. Удивил тот факт, что это знает системный администратор... Как я в дальнейшем понял - он и швец, и жнец, и на дуде игрец.
Дальше все по классике, разворачиваем тестовый контур - разворачиваем тестовую базу, подключаем к Честному Знаку, для обмена с программным обеспечением оборудования определяем папку. Все готово для разработки обмена.
На стороне 1С не возникло никаких проблем, за исключением автоматического заказа кодов на эмиссию - там половина методов на клиента. Поэтому сделали так: оператор 1С вручную формирует документ и нажимает кнопку "Заказ кодов" - они приходят - оператор нажимает кнопку "Отправить на оборудование". Заказчика такая схема устроила более чем. Уточню, что заказ кодов происходит только при начале партии, а это раз в несколько дней (обычно понедельник и четверг). На операцию тратится около 3 минут, соответственно трудозатраты можно считать около нулевыми.
Когда коды были у нас в кармане - мы наткнулись на первый подводный камень. Позже оказалось, что это была горная каменистая река. Первая проблема - сама структура GTIN кода. У неё есть видимая и невидимая часть, служебные символы и прочее. И если с видимой частью все понятно, то как формируется невидимая часть в 1С - для нас осталось загадкой. Решение было найдено простое: в одной из клиентских процедур формирования картинки GTIN (мы специально вызывали эту процедуру), мы перехватывали выполнение на отправке кода маркировки в Base64 для формирования картинки и расшифровывали обратно в обычную строку. К этому решению пришли не сразу, помучавшись парочку дней и досконально изучив, как строится GTIN. Способ оказался вполне рабочий, не вызывал никаких проблем производительности, не искажал данные, работал незаметно для пользователя. Как раз то, что доктор прописал.
Ну а теперь дело техники. Берем охапку дров, и плов готов! Берем документацию, формируем XML, кладем в папочку и... Ошибка чтения.
Просто программное обеспечение оборудование пишет в логах "Файл не распознан". И ничего больше. Увидел такую формулировку и сильно раздосадовался. Кто так формирует ошибки - горите в аду. Это значило только одно - нам предстоит адская мука с подгонкой XML. К счастью, у нас был консультант. Кстати, почему-то только он мог смотреть в логи программного обеспечения.
На наши вопросы, что же не так с файлом, был дан простой ответ - сверяйтесь с документацией. Сверились. Скидываем скрин файла с подробным описанием, что и куда мы ставим. Ответ, как говорится, убил. Это устаревшая документация. Тут почувствовалось тепло с задней стороны моего тела. Сразу начались нехорошие мысли, что оценка будет провалена на тысячу процентов, и проект надо срочно останавливать и переоценивать. Но решил посмотреть на правильный документ. Вот только его не оказалось. Просто нет актуальной документации. С консультантом я воевал 2 дня, в конце внаглую писал "вы ничего не понимаете, добавьте в чат разработчика". Но консультант не сдавался. Видимо, подключила разработчика, но добавлять его не стала в нашу рабочую группу. Как я это понял? По итогу 2 дня нам пришел пример XML рабочей (видимо, с другого проекта), которая читалась. Мы взяли её структуру за основу, и все заработало.
Чем дальше в лес - тем больше дров.
В один прекрасный день тестов программное обеспечение перестало отвечать, успешно прочитан входной файл или нет. Мы уже бились несколько часов, думая, что не так. Рабочий чат молчал. Оказалось, что они программное обеспечение отключают каждый раз. Просто так, чтобы вдруг ничего не произошло.
Вдруг клиент заявляет в один из четвергов - мне надо на конвейере маркировать продукцию в понедельник!
Но прошла только половина срока, у нас ещё все в сыром виде, только-только сделали отправку кодов, и то толком не тестировали. Клиенту сразу же было обозначено - в понедельник ничего не запустится. К слову: мы не договаривались о таком исходе событий, клиент просто либо забыл об этом, либо начальство по шапке настучало. Утро пятницы сразу же не задалось. От лица заказчика позвонил технический директор и на повышенном тоне объяснил, сколько они будут терять денег за простой конвейера. Он позвонил с одинаковой речью в нашу компанию: разработчику, руководителю проекта, в отдел продаж, директору, консультанту. Как вы прекрасно понимаете, это только затянуло процесс. Каждый из этого списка (за исключением первых двух) ходил ко мне с вопросами. Мне каждому пришлось рассказывать всю суть проекта, что мы делаем, объяснять и посвящать в детали, пояснять требования и т.д. Конечно, все они просто транслировали техническому директору заказчика то, что я говорил ему в самый первый звонок - в понедельник ничего не заработает. В понедельник, когда ничего не заработало, технический директор поменялся ролями с главным бухгалтером - все по кругу. Опять ходят с вопросами. В итоге примерно 8 часов вместо того, чтобы продолжать делать проект, я посвящал каждого желающего в его детали, потому что "директор от заказчика звонил!". С этого дня в наш рабочий чат добавились ещё 2 человека: директор и бухгалтер заказчика. Это и положительно сказалось на консультанте: она сразу увидела директора и на вопросы стала отвечать медленнее, но качество ответа повысилось в разы.
Пробная печать маркировки
Несмотря на все наши предостережения, клиент принимает непростое решение - сделать выпуск 10 000 продукции на тестовой базе "лишь бы не останавливать конвейер", который и так уже стоит. Конечно, с первого раза ничего не получилось, посыпались ошибки. Все силы были брошены на запуск. Это, несомненно, сбило нас с пути и растянуло проект. А сроки мы называли с запасом (как мы думали) на 1 неделю (срок был назван 1 месяц). С горем пополам все напечатали, запустили.
Разбор выходных данных
Тут была только одна проблема - в выходных данных писался код маркировки полностью, с символом GS. А 1С не умеет его читать по-человечески. Пришлось просить заменить его на последовательность символов. Не буду расписывать в красках. Скажу только одно - мы с консультантом воевали 3 часа. Дальше дело техники: получили данные, создали документы. Договорились, что пользователь сам нажмет кнопку для ввода GTIN в оборот (опять же половина методов на клиенте). Благо делают такое в конце партии только. Ну и ещё нюанс - пользователь сам выбирает дату производства, т.к. она не равна текущей дате зачастую.
Этап 3. Запуск
Установили все на рабочую базу после тестов. На удивление все заработало почти с первого раза (со второго, перезагрузить номенклатуру забыли). Клиент работает без каких-либо проблем, поддержка ему не требуется.
Выводы
- Консультант со стороны программного обеспечения оборудования попался отвратительный.
- Клиент не озвучил самое главное требование - ранний запуск.
- 1С не умеет на сервере нормально формировать полноценный GTIN (ну или мы тупые и не разобрались, не исключаю).
- Паника только удлиняет проект.
- Отклонение от плана только удлиняет проект.
Результаты проекта
Проект завершили успешно в установленный срок. Правда планировали закончить заранее, но получилось день в день. По трудозатратам получилось около 95 часов. Я считаю, что это нормальный показатель, т.к. в проекте был неопытный разработчик, который первый раз ковырял маркировку и XML обмен. Если бы был опытный человек, думаю, управились бы за 60-65 часов с панической атакой технического директора. Без неё четко бы уложились. Дополнительно выставлять клиенту ничего не стали больше в маркетинговых целях, надо все таки рынку соответствовать. Да и должным образом не были все простои зафиксированы.
Полезные ссылки
Взял мемы с канала Мемы 1С
Обратите внимание на другие статьи в моем профиле:
- Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1
- Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2
Приглашаю всех в комментарии для обсуждения и вопросов!
