Решение проблем по 1С-ному и дао бухучета

14.02.19

Саморазвитие

Цикл исправления ошибок и взаимодействия с пользователями - как сделать его максимально комфортным для всех заинтересованных лиц

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


    Шаг первый - локализация проблемы. К сожалению, очень часто даже вполне продвинутые пользователи обозначают проблему в стиле - “Все пропало” и сакраментальное “Ничего не работает”. Нередко такие сообщения сопровождаются излишне эмоциональной реакцией (крики, истерика ну или опять же пресловутое “Мне срочно нужно, у меня машина стоит” - прессингом по времени). На этом шаге нужно проявить терпение - и очень желательно дать пользователю некий императив на будущее. Ну то есть чтоб в следующий раз было сообщение не вида “1С не работает”, а вида “В реализации № 12345 на печати в ячейке №8 вышла цифра 48, а нужно - 48.00001”.
    Иногда для выяснения даже к гиперболам приходится прибегать. “Здравствуйте. У вас ничего не работает? Ну то есть вы нажимаете на значок 1С и у вас сразу монитор гаснет? Нет, картинка есть? Какая картинка, с ошибкой? А можно скриншот ошибки? Спасибо, теперь я понял”.


    Шаг второй - воспроизведение ошибки. Если есть возможность - подойти к пользователю и ошибку посмотреть. Или - удаленно подключиться и поглядеть. Это вроде бы очень простое действие - но оно отсеивает никак не меньше трети ошибок. То ли пользователю показалось. То ли он просто не дождался и решил, что программа зависла. То ли он нажимал не на ту кнопку, потому что забыл или не знал, как нужно. То ли это некая мистика была. Но факт в том, что ошибки не воспроизводятся, и бывает это очень часто. Подключился к пользователю, нажал с ним вместе вроде бы те же самые кнопки, что и он, как он утверждает, нажимал - и о чудо, все в порядке.
    Как кто-то из великих сказал - “Человеку свойственно заблуждаться”. Один мой знакомый программист сформулировал более нетолерантно - “Пользователи всегда врут”. Обвинять пользователей не нужно, пользователя нужно любить братскою любовью - но проверять его слова нужно в обязательном порядке. 
    И да - механизм версионирования в 1С сейчас очень хорош. Рекомендую всем включать. Достаточно один-два раза в отчет на “А у меня здесь стояла совсем другая цифра (дата, контрагент, номенклатура), а потом программа сама поменяла (враги поменяли), что за безобразие!” - показать такому человеку, что ничего-то другого у него не стояло (стояло и он сам поменял, стояло и поменял кто-то другой) - и вопрос снимается надолго, если не навсегда. И наоборот - когда нет возможности посмотреть, кто же поменял заветную цифру - вопрос будет возникать снова и снова, доводя вас до безумия. Включайте версионирование! Ну, я отвлекся. 


    Шаг третий - воспроизвести ошибку у себя. Под полными правами, на том же документе, а затем - на другом. Настройка прав у 1С становится все мощнее и изощреннее, ну а если попадаешь на некие самописные релизы авторства отдельных умельцев - то можешь вообще совершеннейшие чудеса увидеть. Под тобой работает - значит, дело скорее всего в правах. Работает на другом документе, а на этом нет - дело может быть в наборе данных. Ну например, смышленый пользователь копирует документ с некоего старого документа, где какие-то реквизиты не заполнены (в старые времена, может, и не было таких реквизитов). И у него идет ошибка. А вы создали с нуля такой же документ, сделали по инструкции - и у вас все прекрасно. Если на другом документе проблем не возникает - проблема локализована. Возможно, нужно всего лишь пользователю показать, как нужно - ну или выяснить, как делает он.


    Шаг четвертый - ошибка ли это?  Ситуация, описанная пользователем, реальна и воспроизводима. Но - ошибка ли это? Тут мы вступаем в терра инкогнита, землю неизведанную, страну чудес, где могут водиться драконы и динозавры. Наверное, у каждого, кто работает в отрасли более-менее давно, бывали случаи, когда пользователь яростно и бескомпромиссно утверждал, что правильно - вот именно так, как он сказал. А у фирмы 1С - неправильно. Это - крайний и критический случай. Бывает также не крайний и менее критический случай. Не крайний - например, такой.
    Пользователь: “Я не могу провести документ! А мне надо срочно!
    Вы: “Здравствуйте. Все верно, не можете провести. У вас нет прав
    Пользователь: “А мне надо работать! Я буду жаловаться (в ООН)
    Вы: “Ограничение прав было по указанию сотрудника такого-то. Прошу Вас обсудить вопрос полномочий с ним”.

    Такие ситуации могут быть болезненны и конфликтны. Но до совсем плохого варианта доходит только в совсем гнилых конторах. Как например, сегодня директор говорит - “Права у всех забрать, доступ выдавать только через меня”. Назавтра к вам прибегает скандалить главбух, у которой доступ забрали. А после обеда директор вызывает вас и ругает: “Как так, я же сказал - доступы у всех забрать, но главбуха это не касается”. Имхо,  в таких конторах работать смысла нет - есть смысл увольняться, потому что эта ситуация будет воспроизводиться раз за разом, и крайним будут делать вас. Но, повторю, это все же редкий случай.
    А вот случай намного более частый - когда сотрудник уверен, что он познал верный путь учета (дао бухучета - каждый познает его по-своему, обрети свое дао), а 1С - ошибается и лажает. Спору нет, бывает, к сожалению, что иногда ошибается и 1С. Но намного чаще бывает (намного, намного чаще!! почти всегда, если точнее), когда очередной “гений учета”, познавший дао, выдвигает совершенно чудовищные идеи о том, как надо считать НДС (НДФЛ, прибыль, себестоимость) - а вы слушаете, и тихо сходите с ума. Помнится, был в моей практике случай, когда главный бухгалтер предложила замечательную идею - в бухгалтерии документы поступления дополнительных расходов к документам поступления товаров не привязывать. Ну типа пришла услуга хранения - закинуть ее на 41 счет да и все. И огромного труда стоило доказать, что вообще-то какая-то болтающаяся сама по себе себестоимость без количества и товара на 41 счете - не спишется никогда. Не говоря уж о том, что есть правила отнесения расходов на себестоимость, и правила эти не нами придуманы. Иногда такие споры могут несколько месяцев продолжаться. Находишь статью в Консультанте, почему нужно делать именно так, тебе кидают другую статью, и так по кругу. Иногда убеждаешь в своей правоте. Иногда говоришь - “ок, то, о чем вы говорите, можно реализовать так и так, но это неправильно”. А иногда - отказываешься работать. Встречались на жизненном пути такие фирмы, где программисты менялись в месяц раз - и так годами. Посмотришь на базу в такой компании - и все ясно становится. Например, видел, когда в УТ 11 расчет себестоимости за 3 года ни разу не проводили. Решили, что не нужно. Доводилось видеть и компании, где просто люди себестоимость получить не могли годами. Есть продажи - а какие в убыток, какие в прибыль - непонятно. Каждый раз все упиралось в позицию руководства. Есть в руководстве человек, который уверен, что он знает, как нужно (а на самом деле не знает, или как-то совсем по-особому знает) или которому просто бардак выгоден - и не сдвинешь ты эту гору с места. 
Какой-то программист в такой фирме может и прижиться - сидеть и клепать абсурдный код километрами, денежка-то капает. Но в целом это путь к профессиональной деградации. 
    Но мы отвлеклись. Шаг четвертый - понять, ошибка ли это - или же так и должно быть - методологически или в силу других причин.


    Шаг пятый - когда и как исправлять. У нас есть ошибка. Безусловно. Нужно ли ее сразу исправлять? Тут тоже не так все однозначно бывает. Даже самое безобидное действие в разных конторах может иметь самые причудливые пути решения. И я сейчас говорю о согласовании. Не так уж и редко бывает, что вот прибежала бухгалтер Марья Ивановна, закричала, что ошибка у нее - а вы взяли, да и исправили. И вызывает вас к себе главный бухгалтер Петр Петрович, и очень неприязненно спрашивает - “А пошто ж ты, мил человек, у сотрудников моих заявки берешь, да и без моего ведома их делаешь? Аль вы за моей спиной меня и свергнуть решили?”. Абсурд? Нет. Всего лишь - субординация. 
    Возможно, на предприятии вопрос власти не до конца решен, и вы попали в чьи-то чужие расклады ненароком. Возможно, у Петра Петровича было своих вопросов к вам 150 штук, и то, что вы его вопросами не заинтересовались, а стали с места в карьер что-то другое делать - его обидело. А может быть - на предприятии есть жесткий порядок исправления. Ну там - сегодня исправляем на локальной копии, завтра тестируем, и только в следующий понедельник (или наоборот - пятницу) ставим на рабочую базу. Этот порядок может быть выстрадан болью и слезами, когда ваши предшественники раз за разом косячили. Этот порядок может быть оправдан потому, что база распределенная, или по специфике бизнес-процессов. Суть в том, что нужно заранее узнать - как исправляются ошибки в компании, и с кем этот вопрос согласовывать. Нет двух компаний, где бы эти процедуры совпадали до мелочей. 


    Шаг шестой - согласовать график изменений. Очень актуально, когда помимо одной проблемы вам поставили еще 120 других. Или - когда ваши действия могут продолжительное время занять. Например, нужно вам базу обновить. Сильно измененную. Которую три года уже не обновляли. В которой несколько сторонних подсистем - часть из которых нужно убрать, а часть - оставить. И вы понимаете, что можно провозиться и неделю, и две можно, а может и больше времени займет - нужно ведь и текущие задачи решать, их никто не отменял. В этих условиях нужно перед руководством озвучить примерные сроки - оптимистические, пессимистические. Возможно, руководство посмотрит и скажет - “Ок, эту задачу снимаем пока, есть задачи более высокого приоритета”. Или - “Ок, объем работы ясен, сроку тебе - месяц, через месяц спросим, но раньше - не тревожим”. И пользователи в курсе, что быстрого результата не будет, и у вас есть ориентир. Все довольны. 


    Шаг семь - тестирование изменений. Собственно кодинг я пропускаю, это отдельная и большая тема. Так вот, о тестировании. Идеально - чтоб тестировал на свежей копии базы именно тот человек, которому эти исправления и нужны. Самое скверное - когда тестируешь сам, свои ошибки увидеть труднее всего. Когда это делает тестировщик - какой-то промежуточный результат получается между двумя этими крайностями. Было в практике, когда от тестировщика было больше траты времени, чем пользы, было и наоборот. Но конечного пользователя никто не заменит, увы.  
    И еще раз - тестировать можно и нужно на копии базы, а не на живую. На живую - только если исправление незначительно, изменения данных не повлечет и вы исправления можете моментально откатить. Очень часто бывает, когда пользователь заявляет- “Ставьте на рабочую базу, я проверю, нет у меня времени играться с копиями”. Разные ситуации бывают - но в общем и целом лучше тактично объяснить, что ставить непроверенный функционал на рабочую базу - чревато осложнениями, и экономия 5 минут сейчас может обернуться месяцами восстановления потом.


    Шаг восемь - обучение и документирование. Есть известная максима, или мнение - “Инструкции никто не читает никогда”. Недавно довелось почти в лабораторных условиях эту теорию проверить. Написал инструкции, разослал. Многим также говорил лично - “Прочтите, прочтите инструкции, это важно”, писал письма отдельно, звонил в рабочее и нерабочее время, ну и в Whatsapp даже некоторым писал. Итог? Не сказать, что совсем никто не прочел. До того момента, когда нужно было уже непосредственно инструкцию в жизнь применять, прочел в среднем один человек из десяти. Всего пользователей было несколько десятков - несколько человек прочло. Мало? Очень мало. Но - это лучше, чем ничего. Во-первых, когда проект стал запускать - многие пользователи к этим нескольким людям шли за справкой, а не ко мне. Во-вторых, когда час “Икс” настал - еще какая-то часть пользователей все же инструкции нашла и что-то из них почерпнула. Так что - документируйте, коллеги, это не столь уж и бесполезное дело. 
    И да, из тех нескольких человек, которые прочли инструкции, как ни странно, заметно больше половины относились к менеджменту. Люди в возрасте, семейные - нашли время и изучили. А их молодые, динамичные и несемейные подчиненные - нет. Я ожидал обратного, честно сказать. Но это скорее лирическое отступление. 


    Шаг девятый - установка изменений. Что тут можно сказать? Всегда бэкапьте базу непосредственно перед изменениями. Всегда. Несколько раз было, что база прямо на изменениях падала и не запускалась. Не из-за моих изменений - чаще сервер был виноват. 
    Случалось, что и конфигурация поставщика портилась. Казалось бы - ну подумаешь, конфигурация поставщика, возьми неиспорченную и накати. А если конфигурация не из самых распространенных? Нужно писать разработчику, получать актуальный CF, это может затянуться - а нужно, как на грех, именно сейчас. Поэтому - очень хорошая идея последние несколько CF хранить на всякий случай. 
    Так что - сохранили CF до изменений, забэкапили базу - и меняем. Как говорил в начале - есть разные стратегии обновлений. Кто-то предпочитает в пятницу вечером обновлять, когда никто не работает и есть время поправить. Кто-то наоборот - в понедельник вечером. Чтоб во вторник пользователи сразу проверили, и все программисты были на работе - сразу исправить, если что (а если править в пятницу вечером, то народ на выходные может разъехаться, кто куда - и работающие в выходные коллеги окажутся не в состоянии трудиться, и пара дней пропадет у них).
    Какого-то золотого правила тут нет - но я все же предпочитаю минимальный промежуток между обновлением и работой пользователей. То есть чтоб люди как можно быстрее проверили. Почему?
    Потому что иначе люди проверят в самое неудобное для вас время и ошибка выскочит когда не надо (закон подлости, никто не отменял его). Вот совсем недавний пример. Поставили коллеги-админы на выходных новый RDP сервер, я платформу 1С поставил на него, запустил, проверил, все крутится, ну что может пойти не так? Все элементарно. В ночь с воскресенья на понедельник мне начали звонить коллеги-юзеры. Примерно с 2 утра. Оказалось, что админы каким-то образом криво поставили RDP. В результате два человека могли подключиться - а больше нет. Имея одно - свое - подключение, я это никак проверить не мог (да и в голову не приходило, честно сказать). А у коллег-юзеров  - другой часовой пояс, они реально начинают работать в два ночи по Москве. Моей вины в случившемся - не было никакой. Но вот разбудили в два ночи меня, и всю ночь кому-то сквозь сон писал и звонил - я (коллеги-админы примерно в то же время работать как раз заканчивали, да и говорили юзеры и админы на разном языке, буквально). Так что - при возможности тестировать максимально сразу после установки,  пока все заинтересованные сотрудники онлайн. Что непросто, когда кто-то работает в режиме +8 по Москве - а кто-то в режиме -8 по Москве (а кто-то вообще в пятницу отдыхает, зато воскресенье - рабочий день). Однако варианты можно и нужно искать.

    Ну и напоследок универсальный совет - вежливость и терпение, это те ключи, которые открывают почти все двери. И лучше - больше вежливости, чем меньше. Особенно, если работаешь с людьми другой культуры. В нашей стране в деловой культуре, в IT-среде очень часто принят лаконичный, функциональный стиль общения - “Нажми кнопку {А} и получи результат  {Б}” - примерно так у нас зачастую говорят. Этот стиль не то что плох - он зачастую непозволителен при общении с людьми другой культуры. Да и в общении со своими если ты вместо этого скажешь  - “Пожалуйста, нажмите кнопку {А} и у вас должен на экране получиться результат  {Б}, спасибо” - никто у нас за такое построение фразу не расстреляет. А зачастую наоборот - прослывешь вежливым и клиентоориентированным человеком. А в каких-то культурах и последний вариант будет считаться крайне грубым. А правильным будет вариант - “Здравствуйте! Как ваши дела? Спасибо, мои хорошо. Не могли бы вы нажать на кнопку {Б}, пожалуйста?”. Есть такие культуры, другой раз человек звонит на трубку - потому что вопрос срочный, у человека горит, письмом слишком долго. И он хочет тебе немедленно прокричать свою проблему, потому что ему немедленно нужно решение. И ты просто в трубке слышишь, как он открывает рот и начинает - “У нас все не работае… ”, останавливается, и начинает с другого “Привет, как дела?”. Потому что в культуре этого человека не спросить в начале разговора, как у тебя дела - крайняя грубость. И я не могу сказать, что это неправильно (хотя в известном фильме “Брат-2” этот момент жестко высмеивается, правда, там говорится о США, а я все же больше о людях восточной культуры пишу, хотя и на западе тоже принято так говорить). 
    Это на порядок более правильно, чем с места в карьер кричать - “ВСЕ ПЛОХО НИЧЕГО НЕ РАБОТАЕТ!!!!”, даже не представившись. Это то, что нужно в себе развивать - вежливость, корректность, и много терпения. Часто вежливость путают с готовностью идти на уступки, - нет, это совершенно разные черты. Очень часто на какие-то запросы пользователя можно и нужно отказывать - если это вразрез с чьими-то вышестоящими установками идет, если противоречит политике фирмы, если законодательству противоречит и правилам учета - но делать это нужно всегда тактично. Как сказал поэт - “Умей прощать, и не кажись, прощая, великодушней и мудрей других”. 

    Вот так у меня проходит цикл устранения неполадок и нарушения безобразий. 

Alexander Chernykh

исправление командное взаимодействие пользователи

См. также

Радио "Аналитик", 15 выпуск 2 сезона. "Путь аналитика" с Ильёй Никитиным. Переход от технической поддержки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

вчера в 09:10    175    0    Radio_Analyst    0    

3

Радио "Аналитик", 14 выпуск 2 сезона. "Путь аналитика" с Натальей Лосевой. Переход от разработки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

04.03.2024    326    0    Radio_Analyst    0    

5

Измерение и развитие потенциала сотрудников

Обучение и наставничество Бесплатно (free)

Тема измерения и развития потенциала сотрудников является ведущей последние два года в компании Proaction. Елена Дуюн, руководитель направления «Развитие корпоративной культуры», поделится с нами откровением, которое возникло в процессе исследовательского проекта на платформе Proaction. Елена расскажет о текущей кадровой ситуации, о видах потенциала сотрудников, о том, как оценивать этот потенциал и как мотивировать персонал на саморазвитие.

01.03.2024    337    0    DuyunElena    0    

3

Радио "Аналитик", 13 выпуск 2 сезона. "Путь аналитика" с Анастасией Лощиловой. От финансового директора на заводе до функционального архитектора

Обучение и наставничество Бесплатно (free)

Что отличает аналитика от самурая? Аналитик не прокладывает путь, пока не поставит цель. В серии “Путь аналитика” поговорим, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

20.02.2024    476    0    Radio_Analyst    0    

1

Презентация продукта как искусство

Презентации и публичные выступления Бесплатно (free)

Никакой продажник не продаст ВАШ продукт лучше ВАС. Но презентация продукта – это не только наука, но и искусство. О том, как сделать выступление запоминающимся, насколько важны базовые ораторские навыки, сторителлинг и инструментарий для наглядного погружения в детали, расскажем в статье.

12.02.2024    915    0    comol    4    

17

Личный бренд в IT: а оно вообще надо?

Личная эффективность Бесплатно (free)

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

01.02.2024    827    0    mitinskiy    2    

7

Зачем программисту книжки читать

Личная эффективность Бесплатно (free)

Нам с детства постоянно твердят, что книга – лучший друг, книга – лучший подарок, книга – вообще лучшая вещь в мире. Да, это действительно так. Книги явно и значительно влияют на нашу работу, карьеру и жизнь. О том, как правильно читать книгу, как книга вообще влияет на человека, и главное: зачем вообще читать эти книги программисту, сисадмину, аналитику, расскажем в статье.

31.01.2024    2774    0    a_a_burlakov    25    

46

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

Сейчас на рынке много объемных проектов, и специалисты часто сталкиваются c перегрузками. Чтобы сохранить ресурсное состояние и не допустить выгорания, нужна личная работа человека и грамотный подход руководителей. В статье рассказываю, как мы помогаем сотрудникам справиться со стрессом.

15.01.2024    1650    0    KChebykina    0    

31
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. mavlenkov 25.02.19 21:14 Сейчас в теме
Очень интересно, в каких ещё странах, кроме постсоветских используют платформу 1С? И какие конфигурации, если это не секрет конечно.
3. Lus_85 07.10.19 12:11 Сейчас в теме
(1) 1С на импорт целое направление разрабатывает. Тут можно почитать https://www.1ci.com
2. Alex_Japanese_Student 454 26.02.19 09:44 Сейчас в теме
1с как система учета у меня в постсоветских странах, а не-постсоветские пользователи - это либо проверяющие учетные данные, либо еще какие-то супервайзеры, для которых отчеты формируются и шлются
раньше вот такую штуку юзали упп с английским интерфейсом - My Webpage, сейчас есть системы на базе ERP тоже с английским интерфейсом
Оставьте свое сообщение