Негатив от пользователей: как относиться и извлекать из него пользу

Обычно в блогах делятся скринами с благодарными отзывами. А я покажу вам негативные (подобрал такие, где не было мата 🙂). Отмечу то у меня такие ситуации возникают крайне редко, но уметь работать с ними полезно. Это в продолжение темы факапов. Заодно расскажу, как стараюсь действовать, когда заказчик чем-то недоволен.

1️⃣
Обсуждали с пользователем отчет, который разрабатывали уже несколько месяцев, но правильных цифр никак не могли получить. А сроки сдачи уже поджимали (если совсем честно, они давно прошли).
В моменте очень хотелось ответить собеседнику что-то в том же стиле. Тем более он просто не разобрался, как отчет работает. Ну а должен ли был разбираться?
Моя ошибка: когда начал работу, увидел, что в базе недостаточно данных, чтобы рассчитать все показатели. Но не предупредил об этом пользователя сразу. Пришлось объяснять, когда уже потратили кучу времени, сил, нервов. Взял на заметку, что все проблемы и риски лучше озвучивать и обсуждать сразу, на ранних стадиях.

2️⃣
Думаю, из диалога суть конфликта понятна.
В моменте хотелось завершить сотрудничество с клиентом, ведь с задачей действительно пришлось прилично повозиться.
Моя ошибка: не согласовал трудоемкость заранее, на берегу. Взял на заметку: даже если просят что-то сделать срочно, не стоит сразу кидаться в бой, лучше согласовать все условия. Ну или быть готовым к тому, что может возникнуть недопонимание. В этом случае объяснил заказчику, что разбор чужого кода — тоже непростая работа. Предложил оплатить столько, сколько он считает справедливым.

3️⃣
Возникло простое недопонимание по рабочему вопросу. Но негатив обычно не возникает на пустом месте. Дело в том, что из-за большой загрузки я отвечал на письма заказчика через день, а то и несколько. В итоге у него сложилось впечатление, что я стараюсь отвязаться, а не решить вопрос.
В моменте хотелось предложить передать задачу кому-то другому. Так я и сделал… 🙂 Но предварительно ответил на рабочий вопрос более подробно, чтобы точно поняли правильно, и объяснил ситуацию с высокой загрузкой.
Моя ошибка: у заказчика возникало впечатление, что его динамят. Так быть не должно. Взял на заметку: если не можешь ответить оперативно, напиши хотя бы, когда именно ответишь.

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

Как реагируете на такие ситуации?
🤬 — чаще обижаюсь или отвечаю тем же. Надо же как-то показать человеку, что он не прав.
👍 — обычно отвечаю спокойно и по делу.
🔥 — работаю исключительно на позитиве, негатива не бывает.

Предлагаю поиграть в угадайку — как думаете, чем закончилась каждая из ситуаций? А может поделитесь своими историями?

#истории

Картинка иллюстрирует курсы 1С для начинающих и выход на реальную работу 1С-ником во франч. 🙂

Как-то в школьные годы я участвовал в олимпиаде по математике. Она проходила в Дудинке, куда съехались школьники со всего полуострова Таймыр. В нашем поселке (откуда я – рассказывал здесь) были замечательные учителя, но математику давали не на высоком уровне. Почему отправили именно меня — загадка, не сказать, что я чем-то выделялся.

В той олимпиаде участвовало около 30 человек. Я набрал 0,2 балла из 12 и занял 4 место. 🙂 Так и молодые 1С-ники: когда выходят после курсов, зачастую мало что могут сделать в реальных задачах. Но тот, кто набирает хотя бы 0,2 балла, уже выделяется! Реальный мир сильно отличается от учебных задачек.

Кого бы вы предпочли нанять в свою команду?
👍 — опытного спеца, дорогого, но которому не надо все объяснять и разжевывать.
🔥 — джуна, на которого придется тратить время, но он недорогой, не капризный, и его можно «настроить под себя».
🤔 — я бы сам к кому-нибудь нанялся.

#юмор #истории

Штрафы в договоре: нужны или нет?

Пост о рабочих процессах, не связанных непосредственно с 1С. Обратилась к нам одна компания с запросом на автоматизацию нескольких участков учета. Задачу сформулировали примерно так же, как на картинке к предыдущему посту. Но это обычная ситуация — наладили контакт, все уточнили, проект разбили на части.

Договорились, что начнем с чего-то небольшого. Если сотрудничество всех устроит, будем работать дальше. Если нет — передадим наши наработки другому подрядчику.

Вышли на оформление сделки, получили проект договора и... офигели. В нем штрафы буквально за каждый чих:
❗ Задача не сдана в срок? Счетчик пошел!
❗ Задача сдана, но заказчику что-то не понравилось? Устраняйте за свой счет.
❗ Разгласили конфиденциальные данные? С вас сразу сто пятьсот тысяч (без лишних разговоров и оценки ущерба).

Может, конечно, я жизни не знаю, и эти условия — нормальные. Но у меня такого еще не было. Заключали договоры в том числе с крупными холдингами. Да, иногда подолгу согласовывали, но в результате фиксировали: порядок работы и расчетов, часовую ставку, отчетность и ответственность сторон в разрешении споров «в соответствии с законодательством РФ». Без каких-либо штрафов, пеней и т.п.

Не то чтобы я чего-то боялся, к нам претензий по срокам и качеству обычно не бывает. Просто сотрудничество с кем-то по 1С — это надолго, часто на годы. Сначала проект, потом сопровождение. И начинать с недоверия, создавая подрядчику риски на ровном месте, я считаю, неправильно.

Кроме того не всегда исполнитель полностью виноват в срыве сроков или несоответствии функционала требованиям. Может случиться так, что и заказчик что-то вовремя не предоставил или не проверил. Эти проблемы обычно решаются в рабочем порядке. А штрафы, прописанные в договоре, воспринимаются как попытка переложить ответственность.

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

Нам сказали:

«Вернемся к разговору с вами, если с другими не получится договориться».

Что ж, пока ищут. Оказалось, мы были уже третьи кандидаты. Выводы оставлю за вами. 🙂

Как считаете, нужно прописывать штрафы в договоре?
👍 — конечно, добросовестные подрядчики штрафов не боятся.
🔥 — нет, адекватные люди договорятся сами, а если что — суд назначит, кому что причитается по законодательству.
🤔 — не знаю, я простой специалист, далекий от этого всего.

#истории #мнение_о_важном

Мистический баг: как его отловить?

Этот пост — детективная загадка для спецов. Я вам расскажу историю одной необъяснимой ошибки и несколько вводных. Ваша задача в комментах задать вопросы (чтобы собрать улики) и раскрыть «преступление». 🙂 Справиться смогут, предполагаю, только мидлы и выше. Поехали!

В серверной базе 1С работает регламентное задание, которое списывает спецодежду по окончании срока износа. Запускается каждый день в 00:00, получает остатки спецодежды, у которой подошел срок износа, и создает документ списания.

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

Я, как аккуратный детектив Скотленд-ярда программист, начал расследование с очевидного предположения: проблема в коде. Исследовал его вдоль и поперек, и никаких проблем не обнаружил… Ну не может он давать дубли! Что еще выяснил:
— Пользователи клянутся, что вручную ничего не создают.
— Других регламентных списаний нет.
— Магнитных бурь в дни, когда возникали дубли не было.
— Пара дублей появилась в полнолуние, но в других фазах луны дубли тоже возникали!

Что скажете, Пуаро? Приглашаю в комменты. 🙂

Встречались с мистическими багами?
👍 — да, доставал шаманский бубен и совершал обряды изгнания.
🔥 — нет, чудес не бывает, достаточно напрячь «маленькие серые клеточки».
😱 — для меня все баги мистические, ничего с ними сделать не могу!

Итоги расследования:
Сначала участники заподозрили программиста или пользователей. Ну а кто еще кроме них косячит в 1С? 🙂 Самые подозрительные указали на платформу 1С, уборщицу, и даже садовника. И почти никто не обратил внимание на тихого сисадмина, который зарегистрировал базу 1С на двух независимых серверах приложений, и рег. задание стало выполняться два раза одновременно, что и привело к дублям. Раскрыл негодяя рассеянного спеца Vsevolod, браво ему!

#истории

Как 1С-нику разобраться с непонятной задачей

Волны касторовая суть
ушла сатином со двора
ей больше нечего косить
когда дитя ее двурог.
(с) Даниил Хармс, русский и советский писатель, поэт.

Бессмыслица какая-то, да? Хотя по отдельности слова понятные... Такие же ощущения иногда возникают после знакомства с иной постановкой задачи. Некоторые фразы вроде бы ясны, но в целом картина не складывается. Что требуется от разработчика — вопрос.

Почему так получается? Причины могут быть вот в чем:
— У вас не хватает знаний о подсистеме 1С, в которой нужна доработка, или об автоматизируемом бизнес-процессе. И это нормально, работа 1С-ника — во все вникать.
— Задача слишком большая и монолитная. Дочитав ТЗ до конца, спец напрочь забыл, что было в самом начале. И это тоже нормально. По некоторым данным человеку сложно держать в памяти более семи сущностей одновременно.
— У постановщика нет времени или умения формулировать задачи кратко и понятно. Писать ТЗ (да и любой текст) с заботой о читателе сложно. Часто проще сделать самому, чем хорошо поставить задачу другому 🙂

Понятна задача или нет — выполнять ее надо. Что можно сделать, чтобы разобраться?

1️⃣ Созвониться с постановщиком (ну а как без совета от кэпа?). Запустить 1С, включить демонстрацию экрана, пройтись вместе по заданию или по его частям, вызывающим затруднение. Желательно записать видео созвона: если этого не сделать, то через пару дней вспомнится в лучшем случае половина.
Хорошо, если в процессе созвона удастся найти или подготовить тестовые примеры к задаче и зафиксировать ожидаемые результаты для этих примеров. Разработка тогда идет гораздо увереннее.
После созвона можно оформить краткое резюме: с чем разбирались, что решили, что конкретно делаем. И желательно согласовать его с постановщиком, чтобы удостовериться, что все поняли правильно.

2️⃣ Порисовать. Нет, не картины, а схемы. Можно от руки, что-то понятное только тебе. Можно более формальное, вроде интеллект-карты (mind-map).
Цель — выгрузить на бумагу свое понимание задачи (объекты, взаимосвязи между ними). Имея схему, будет проще ориентироваться, удобнее разбить задачу на части и начать наконец работать 🙂

3️⃣ Сделать прототип решения в Экселе. Это может быть небольшой набросок функционала с простым примером, который позволит проработать задачу, выявить нестыковки. Или детальная модель, учитывающая все нюансы финансовых расчетов.
Такой Эксель можно показать постановщику и согласовать нюансы, о которых не говорится в ТЗ. Или даже начать использовать его вместо разработки в 1С! Как-то у нас был такой случай: прорабатывали в Экселе модель расчета комиссионных менеджерам — получился настолько удобный документ, что не стали делать этот расчет в 1С. Вместо этого реализовали перенос из 1С данных для расчетов в этот Эксель.

А кто у вас чаще виноват, если разработчик не понял задачу?
👍 — разработчик.
🔥 — постановщик.
🤔 — задача.

#кейсы

Канал не канал без котиков!

👍 – у моего котика бывают такие же приключения;
🔥 – я дома не работаю;
🤔 – нет у меня котика, и вообще я не программист.

#юмор

ИИ нас всех заменит! Что делать?

Смотрели «Космическую одиссею 2001 года»? Этот фильм Стенли Кубрика вышел в 1968 году. Один из героев — сверхразумный компьютер HAL 9000. Он управляет космическим кораблем, общается с экипажем, и, я уверен, даже программировать умеет. Но точно не на языке 1С, потому что платформа «1С: Предприятие 8» появилась только в 2002-м. 😜

Да, в 60-х годах прошлого века казалось, что в начале 2000-х такие технологии будут обыденностью. И что мы видим? Это даже сегодня не так! Но все же некоторые считают, что ИИ уже наступает человеку на пятки, вот-вот лишит его работы. Стоит ли опасаться 1С-никам?

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

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

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

Предлагаю голосовать:
👍 — Ничего не делать. Прогресс не остановить. Когда-то автомобили заменили лошадей, только лучше стало, все адаптировались.
🔥 — Учиться тому, что ИИ освоит не скоро. Повышать soft-skills (ведь человеку нужен человек), разбираться в нуждах пользователя и как их перевести в функционал системы.
🤔 — Нужно ограничить исследования в области ИИ. Закрыть OpenAI и прочие компании. Их исследования до добра не доведут.
#мнение_о_важном

Челлендж: как перевести данные в 1С на другой язык

В комментариях к прошлому посту затронули тему: 1С в других странах. Да, в ней работают не только у нас, но и, скажем, в Румынии, ОАЭ, ЮАР. Мне, если честно, за 20-летнюю практику не приходилось разрабатывать что-то для людей, не владеющих русским. Если не считать доработку Шаблонов вместе с Алексеем Снитковским, чтобы запустить их в англоязычном окружении платформы (Алексей, кстати, о международности 1С знает не понаслышке).

Но совсем недавно наш клиент решил сделать англоязычный сайт. И вывести свой каталог (на английском, естессно). Причем вытащить его с остатками и ценами прямо из 1С.

Нам поставили задачу: перевести всю номенклатуру в базе 1С с русского на английский. Вручную это сделать нереально, все-таки в каталоге порядка 300 000 позиций.

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

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

Допущения и требования:
👉 Названия многих позиций каталога похожи:
Гидрораспределитель пропорциональный 4WRPEH6CB24L
Гидрораспределитель 4WRZ25W8-325
Гидрораспределитель 4WRA6E15-L2X
👉 Пользователи хотели бы контролировать процесс перевода, вносить корректировки.
👉 Артикулы, состоящие из английских символов и цифр, должны остаться неизменными.

Жду в комментариях! 🙂

Традиционный опрос. Приходилось иметь дело с другими языками в 1С?
👍 — да.
🔥 — нет, у нас все только на русском.
🤔 — я и русского-то 1С-а не видел, о чем вы.

#кейсы

Мое решение к челленджу из поста выше 👆

1️⃣ Даем возможность пользователю переводить не весь каталог сразу, а по частям (например, по группам). Это позволит разбить перевод на несколько итераций и на каждой переводить похожую номенклатуру.
2️⃣ Выделяем из наименований фразы на кириллице (это можно сделать регулярным выражением). Уникальных фраз у нас получалось гораздо меньше (иногда на порядок), чем наименований номенклатуры.
3️⃣ Выполняем перевод фраз переводчиком, предъявляем результат пользователю для проверки. После проверки и корректировки перевода сохраняем его для использования на следующих итерациях.
4️⃣ Подменяем в наименованиях отобранной номенклатуры выделенные фразы на кириллице их переводом. Ну и сохраняем переведенное наименование, конечно. 🙂

Реализовали переводчик номенклатуры в виде обработки, делюсь.

Спасибо всем, кто поучаствовал, предложил в комментах свои идеи! (Александр, Сергей, Татьяна, Всеволод, Дмитрий, Илья).
Кто-то предложил примерно то же, что сделали мы. А у кого-то другие идеи:
– обучение нейросети,
– поиск подходящих классификаторов, где уже есть наименования позиций каталога на разных языках,
– поиск в базе похожей номенклатуры, у которой уже есть перевод.

Если бы программисты строили самолеты

… или как выглядит типичный запуск в работу 1С: ERP.

https://youtu.be/lf5FpI6bzts

Как по вашему – это нормально, когда программу дорабатывают в процессе ее рабочей эксплуатации?
👍 – конечно, ведь только тогда и всплывают все нюансы, которые заранее предвидеть невозможно.
🤔 – нет, это не нормально, но в сфере 1С к подобному давно привыкли.

Ролик старый, но зато с моим переводом и озвучкой (строго не судите 🙂)

#юмор

Стоп-фразы при общении 1С-ника с заказчиком

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

1⃣ Тут надо все переписывать
Когда я, программист, это слышу, всегда солидарно киваю. Конечно, бывает полезно все переписать. Вполне вероятно, что новый код станет лучше. Ведь еще Фредерик Брукс в «Мифическом человеко-месяце» писал о разработке ПО: «Планируйте выбросить первую версию — вам все равно придется это сделать»

Но для заказчика эта фраза означает: я не хочу копаться в этом.
Да, разбираться в чужом коде сложно. Аккуратно доделать его — еще сложнее. Но такая у 1С-ника работа.

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

Кстати, иногда предложение воспринимается так: те кто вам это разработал — так себе спецы, а вот я — профессионал хоть куда, в белом пальто пришел к вам такой красивый. 🙂
Согласитесь, выглядит не очень. Ведь заказчик может быть доволен работой предыдущих разработчиков и остаться в хороших отношениях с ними. Или представьте, как после вас придут новые спецы с предложением переделать то, что сделали вы. Неприятно, да?

2⃣ У нас проблема
Этот пункт — моя боль в рабочих контактах с помощниками. Само по себе возникновение проблем по ходу проекта — дело обычное. Но почему бы не сообщать о них деликатнее, чтобы это не воспринималось так: готовься, друг, у нас все плохо, сейчас тебе придется серьезно напрячься.

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

3⃣ А сразу сказать нельзя было?
Обычно эта фраза произносится, когда всплывают какие-то нюансы в проекте, и разработчику предстоит что-то переделать. Заказчик при этом слышит: как с тобой можно работать, если ты сам не знаешь, чего хочешь.

Тут важно понимать, что с ходу поставить задачу идеально очень сложно. А конечная цель работы 1С-ника — сделать максимально полезную систему, пусть и не точно по ТЗ. В комментах расскажу историю на эту тему (не из сферы 1С).

Но что делать, если задача превращается в сплошные изменения и дополнения? Как выразить клиенту свою досаду? Можно обсудить с ним увеличение бюджета и сроков. Это заставит заказчика задуматься, так ли ему нужны изменения проекта.

Если советы полезные, ставьте 👍

#мнение_о_важном

Как мы избавляли бухгалтеров от работы в выходные (и вы так можете)

Расскажу историю одной автоматизации — и научу вас плохому. Главным образом программистов, потому что поделюсь наработками с «неправильным» решением задачи.

Один из наших клиентов из сферы оптовой торговли решил, что пора отказаться от выходных. Заказчики готовы были покупать и принимать товар в субботу и воскресенье, а компании не хотелось терять продажи. Основной вопрос: как договориться с сотрудниками?

С кладовщиками, у которых работа по сменам, наладить контакт удалось без особых проблем. С менеджерами, у которых зарплата — это процент от продаж, тоже. Но вот с бухгалтерами, работающими по обычному графику с окладом, — никак не получалось. А они готовили и отправляли документы по ЭДО перед отгрузкой товара.

Решили с руководством: пусть бухгалтеры отдыхают, но документы все равно должны отправляться. Компания пользуется ЭДО Контрур.Диадок: все делалось вручную, специальным модулем для 1С. Готовых решений для автоматической отправки документов на тот момент мы не нашли.

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

По опыту было предчувствие, что легко сделать такую подсистему не получится. Задача трудоемкая. На первых порах обязательно будут проблемы, возможно, штрафы за предоставление документов не в срок. А виноваты будут кто? Конечно, 1С-ники!

С другой стороны, в штатном модуле Диадока для 1С все эти вопросы уже решены. Есть хорошая техподдержка. Модуль обновляется, если выходят новые версии 1С или что-то меняется со стороны Диадока. Только вот автоматической отправки документов (без участия пользователя) нет. Напрашивалось простое решение: добавить в штатный модуль такую возможность.

Но дорабатывать его тоже очень не хотелось. После каждого обновления модуля пришлось бы переносить свои доработки в новую версию. И тут я вспомнил, что в платформе 1С есть режим «автоматизированного тестирования», в котором можно имитировать работу пользователя — автоматически выполнять действия в 1С так, как если бы это делал пользователь.

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

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

Механизм работает у клиента уже несколько лет. Отчитывается электронной почтой об отправленных документах. Сообщает в TG, если возникают какие-то проблемы.

Как вам решение?
👍 — беру на вооружение!
🤔 — так себе, что-то из серии «как тебе такое, Илон Маск».
🔥 — ничего не понятно, но очень интересно.

#кейсы

Сегодня короткая рекомендация

Канал для поиска работы специалистом 1С, можно подписаться и мониторить интересные и денежные вакансии, которые возникают на рынке - https://xn--r1a.website/esres_1c