Как ожидание идеального и несвоевременное тестирование мешают внедрить управленческий учет в 1С

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

При внедрениях, время от времени сталкиваемся с проблемой, что пользователи  ожидают от нас сразу же идеального результата. Как правило, чаще всего это происходит, когда мы первая компания, к которой заказчик обратился за внедрением и у него еще мало опыта в этой сфере. Скорее всего, эта статья где-то будет выглядеть будто, я “оправдываюсь”, но люди с опытом поймут, что все это ежедневная реальность любой компании.

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

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

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

Кстати, из этого появляются такие “сверхъестественные” заявления: “Вы уже 3 месяца не можете доделать такую-то доработку!”. А то, что такая доработка проверяется пользователем только 1 раз в месяц, и то, только в день, когда ему она нужна — здесь не учитывается. И при этом, из-за спешки, у пользователя нет времени описать, как именно она не работает, чтобы потом решить этот вопрос с нами. И нет, ведь, никаких проблем, на самом деле, встретиться с программистом, выделить час времени и, в конце-концов, все доделать. И это нами предлагается неоднократно. Но на это же нет времени. За то, есть время, запускать доработку и злиться, что она все еще не работает. И, снова, делать все вручную. И, опять-же, есть время потом заявлять, что мы не можем доделать ее уже много месяцев.

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

Вот, буквально, на днях общался со своим партнером Олегом Горбенко, который закрывает управленческий учет в нашей базе. Говорит, что тоже допускает те же ошибки. Не проверяет вовремя работу программистов, а потом, в день, когда доработка нужна — оказывается, что в ней что-то не так. Но злится, при этом, уже только на себя. Что вовремя не проверил. Понимает, что по-другому не бывает, а значит, тут он сам виноват.

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

И немного насчет наших ошибок, которые могут оставаться, даже, после тестирования аналитиком. Скажу так, что внутри своей компании, я к любым ошибкам отношусь ОЧЕНЬ строго. Когда ошибки доходят до заказчика, то люди получают и выговор и штрафуются. И процент качества у нас достаточно высокий. Это могут подтвердить наши клиенты, которые уже поработали до нас с кем-то другим и перешли потом к нам. Но если Вы оглянетесь вокруг, то увидите, что производитель автомобилей может отозвать целую партию автомобилей на доработку после обнаружения в ней ошибки. А это миллионы долларов потерь. А Ваши телефоны никогда не “глючат”? А это притом, что одной и той же программой в телефоне пользуются сотни тысяч людей. А тестирует каждую версию программного обеспечения — целый штат тестировщиков. Я могу приводить еще много примеров…

В общем, с ошибками нужно бороться, но они неизбежны. Особенно, в сфере индивидуальных заказов, таких как внедрение 1С, где каждая новая доработка обкатывается только одним нашим тестировщиком, а, затем, максимум, несколькими пользователями заказчика. Кроме того, по ряду задач, не всегда удается смоделировать все возможные рабочие ситуации, возникающие, именно, у этого конкретного заказчика. Это приводит к тому, что в будущем доработка может «повести» себя не так как ему нужно, ведь этот инцидент не был предусмотрен на этапе разработки. Часто, даже, постановщик задачи со стороны заказчика не знает всех нюансов, которые происходят на его предприятии.

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

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер».