А нужно ли удобство работы?
- 21-01-2015, 19:24
- Блог
- 0
- 1077
Довольно часто, заказчик, выставляя свои требования к разработке (проекту), не задумывается над тем, а будет ли удобна эта программа в эксплуатации. Детально прорабатывается функционал под выставленные бизнес-процессы. А вот дальше всегда полагаются на типовые механизмы конфигурации, на то, как это реализовано в типовых прикладных решениях.
Давайте ответим себе на вопрос:, а нужно ли удобство работы в интерфейсе программы 1с?
 |
На практике, внедряя программу 1с, мы тоже не задумывались над этим. Пока не встретились с неожиданной проблемой у одного заказчика. Этот заказчик напрочь не понимал при переходе на платформу 1с, почему достаточно простые вещи у них работают в текущей программе (не 1с), а в 1с все так сложно?
«Когда я работаю над проблемой, я никогда не думаю о красоте. Я думаю только, как решить эту проблему. Но когда я закончил, если решение не красивое, я знаю, что это неправильно»
R. Buckminster Fuller
R. Buckminster Fuller
Каким бы профессионалом разработчик не был, всегда найдется другой разработчик (программист), который скажет, что нужно было делать все не так и совсем по-другому. Мы немного дополним это утверждение и скажем, что также всегда найдется пользователь, который скажет, что программа жутко не удобная и будет все воспринимать в штыки. Даже если программа в себе заключает огромный функционал, полезный функционал и кучу всевозможных вещей, которые необходимы для учета.
В первом случае, нужно с большой осторожностью относиться к таким разработчикам (программистам). Нужно узнавать больше конкретики и требовать примеров, как это можно решить. Если он в действительности сможет это доказать, то тогда можно с этим согласиться. Во втором случае, такие пользователи могут быть очень полезны сделать действительно качественный продукт и в целом будут реально положительно влиять на опыт самого разработчика. Отрицательный результат ведь тоже результат.
 Например, одно предприятие решило отказаться от услуг своего разработчика-программиста, который порекомендовал конфигурацию Бухгалтерия 1.6 и на ней построил весь управленческий учет как бы внутри прикладного типового решения. И стали работать с другим разработчиком, который сразу же предложил другую конфигурацию – Управление торговлей 10.3 и стал выстраивать всю цепочку бизнес-процессов в новой конфигурации. Он всех убедил, что это будет удобней правильней. По-сути благая идея была в том, что управленческий учет должен быть в отдельной базе, а бухгалтерский учет в другой базе. Аргументируя тем, что бухгалтерская база будет постоянно меняться согласно законодательства и именно поэтому будут присутствовать постоянные обновления, а стало быть могут нарушить управленческий учет. Предприятие даже закупило сразу эту программу с десятью лицензиями. За целый год было потрачено уйма времени самим заказчиком и разработчиком (последнее ставилось под сомнение). Но так и не смог новый разработчик добиться того, чтобы в новой конфигурации начали работать все пользователи. Чтобы это преодолеть, всегда необходимо влезать в шкуру конечного пользователя и рассматривать программу с той точки зрения, если бы пришлось работать в ней самому. Нужно постоянно производить тестирование программы на предмет удобства пользования. И здесь профессионал в написании кода в программе, совершенно не умеющий разглядеть потребности конечных пользователей, не сможет дать то, что требуется им. Предыдущий разработчик прежде всего на себе испытывал весь функционал, путем того, что сам лично вбивал информацию и с головой окунался в сам процесс. Для этого требуется гораздо больше времени и сил. |
Неужели разработчики настолько не уверены в своей работе, что за ними надо ее проверять? Разве они не должны сразу делать то, что работает хорошо и правильно? В реальности же, использование стандартных методов разработки свидетельствует о профессионализме, но совсем не говорит об умении планировать разработку проекта. Необходим опыт в 10 лет, чтобы разглядеть то, что действительно необходимо людям. А также необходимо чтобы разработчик себя ставил постоянно на место конечного пользователя и сам попытался свести учет в программе, который внедряется. Вы не поверите. Если разработчик сам будет каждый день вносить информацию в базу и делать одно и тоже и несколько ней, можно будет добиться интересного эффекта, так как он со своим видением автоматизации процессов действительно поймет каким образом это можно сделать так, чтобы это облегчило работу.
 |
|
Например, на практике так случилось что на предприятии требовалось внедрение новой системы расчета заработной платы на новой программе. Техническое задание писать было бессмысленно, так как заказчик ничего не может объяснить, что действительно нужно сделать, а уж тем более не понимает как это должно работать в этой программе. Разработчик самостоятельно внес все данные в программу руками, произвел расчет каждого сотрудника, выверял данные на предмет правильности расчета. И в процессе всего этого вполне естественного разработчик для облегчения «своего» (!) процесса ввода данных и обработки и проверки сделал инструменты, которые позволили это делать быстрее. Если бы он не принял 100-процентное участие в этом процессе, то так и мучился бы расчетчик зарплаты дальше, вбивая и проверяя вручную. А так получился эффект, что разработчик на свое шкуре ощутил потребности в этом. |
Собственно на сегодня программы позволяют самим пользователям выставлять все настройки по расчету зарплаты и дают возможность не прибегать к услугам дорогостоящих внедренцев. Само собой разобраться в этом можно. Но вот сколько будет проб и ошибок? И с какой скоростью вы это освоите? И с какой скоростью вы в этом будете работать через год, два, три. В процессе всей работы вы будете самостоятельно изучать и осваивать. Вы не замечали, что программисты делают гораздо быстрее с теми вещами, что вы каждый день делаете? Думаете дело в их профессионализме? Но ведь они не расчетчики зарплаты. Они не сводят все эти цифры каждый месяц, не корпят над каждой копейкой. Они быстрее делают из-за того, что они знают программу изнутри! Они знают как это работает и знают точно как этот процесс увеличить по быстродействию.
 |
«Для каждой проблемы есть решение: простое, аккуратное и неправильное»
H.L. Mencken
H.L. Mencken
Хотите узнать как увеличить эффективность работы в программе?
Стоит ли заказчику раскошеливаться на тестирование удобства своей программы? Это еще называют модным словом «юзабилити». Советуем на это тестирование заранее включать стоимость проекта, а не взимать плату как за отдельную работу. Тестирование удобства работы в программе это всего лишь инструмент, и никто не говорит, что он должен быть исключен из проекта или быть дорогим. Даже простой тест с пользователями в течение 3-5 дней, даст значительное улучшение в работе. Если заказчик не настаивает на предоставлении красиво оформленного отчета, вы можете провести несколько тестов в течение нескольких недель и считать, что это просто стандартная часть вашей работы над проектом.
А вы довольны тем как выглядят отчеты на управляемых формах?
 |
Все они по большей части построены из лучших побуждений на системе компоновки данных (СКД), что предполагает ускорение получение самих данных. Но то, как они безлико выглядят в типовых решениях, просто диву даешься. И колонки почему-то разной ширины? Если это можно настроить, то почему не настроено по-умолчанию? Уж чего-чего, а ведь стоило их сделать более красивыми расцветками (имеется ввиду, сами данные в отчете), то от этого выиграет только программа. Но по-умолчанию они бледного цвета. Данные не выделены цветными блоками. Все это отдано на откуп самим пользователям. Мол вот вам инструмент и вы можете в нем сами все сделать. Но вот только сами пользователи согласны с этим утверждением? У них есть время настраивать все это? Они знают что это возможно? Опять же кто это решил за них? Программисты? Разработчики?
Пожалуй, самым лучшим аргументом по поводу тестирования будут цифры, свидетельствующие об эффективности вложения средств в проработку удобства работы в программе. Простой тест стоит не дорого, тратится на него всего-лишь несколько дней. И, тем не менее, результат позволяет иной раз увеличить эффективность работы в программе в два и более раз.
«Все должно быть просто, как только возможно. Но не проще простого»
Альберт Эйнштейн
Альберт Эйнштейн
Вывод
Как добрый совет, пригласите к себе специалиста в вопросе настройки удобства работы в программе. Вы сами не поверите, насколько иной раз «замыливаются» глаза и тяжелая работа покажется как элементарная вещь. И специалист сможет вам автоматизировать или ускорить ваш бизнес-процесс совершенно другим способом. Речь идет не о программисте, который выполняет все Ваши требования неукоснительно. Речь о специалисте, который реально может это сделать и демонстрирует это своими примерами. Главное в этом моменте, чтобы именно была демонстрация на конкретных примерах возможностей этого специалиста. Не пустые слова, что это все возможно сделать. Не стоит верить пустым обещаниям. Пусть на деле покажет и докажет. Не верьте в слова: «все будет хорошо». Пусть это будет небольшие фрагменты или куски, но обязательно чтобы были.
Вот например, когда вы обращаетесь к разработчику сайтов, разве вы не будете настаивать на том, чтобы он показал свои наработки, портфолио? Если этого портфолио нет, то и не стоит вообще начинать с ним работу. Ну так и в программе 1с все тоже самое. Платформа позволяет сделать очень многое. А приглашенный специалист умеет этим пользоваться? Имеет ли опыт в области того, что вам нужно? И очень важно, чтобы этот разработчик действительно понимал со стороны конечного пользователя будет ли ему удобна эта программа.
На этом сайте вы найдете множество примеров по улучшению работы в 1с. Возможно, что-то вам понравятся, а может быть и нет. В любом случае, вы найдете для себя начало к мыслительному процессу, как увеличить скорость работы пользователей в программе.
«Хороший интерфейс как хороший официант – делает свою работу незаметно»
@LeveyOS
@LeveyOS
Главная
Блог
База знаний
Контакты
О сайте