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

    С пользователями мне приходится работать довольно много. И удаленно, и напрямую. С пользователями в своем городе — и в городах, которые на 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