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