Ускорение работы пользователей 1с
Разработки

Об универсальных инструментах

Что значит универсальный инструмент на платформе 1с? Много встречаются на просторах интернета разработок с признаком «универсальный». Что это? Действительно удобный инструмент или попытка втиснуть все мыслимое и не мыслимое в одно целое. А для чего?


Когда такие инструменты в руках специалиста (чаще всего программиста), то тогда конечно он понимает как он работает и ему удобно с ним работать.

 

А также есть еще один момент: очень долгое изучение инструкций может не дать результата, что он будет правильно понят и с ним можно будет эффективно работать. Человеческий фактор не дремлет и можно с этим инструментом много чего наворотить, что не разгребешь в дальнейшем.

 

Не весь универсальный инструмент — это «хорошо». Лучше специально заточенный инструмент под определенное действие, логичное действие.

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

 

«Важное правило: можно делать что угодно и как угодно. Главное, чтобы в основе работы лежал принцип»
Артемий Лебедев


 


Приведем пример. Есть универсальная обработка по оформлению заказов поставщику. И в ней заложен настолько большой функционал, что реально такой инструментарий не нужен заказчику. Ему нужны точечные конкретные действия. Чтобы он не терял времени даже на лицезрение не нужной информации на экране. А в универсальном инструменте он будет присутствовать и возможно его убрать не будет возможности. И вот именно этот пример и будет нашим доказательством нашего утверждения. Не все то, что универсально хорошо.


 

Мнение пользователей

 

Не бывает одинаковых моделей бизнеса. Моделей бизнеса очень много. Очень много конфигураций поддерживаемых и написанных, доработанных специалистами 1с. Практически каждый 1с-программист, если он действительно специалист, написал и поддерживает полноценную конфигурацию, возможно не одну. Возможно даже написанную с нуля. У нас четыре полноценных специализированных решений. Хорошо или плохо сделанные. Судят сами конечные пользователи, кто с ними работает. Но они работают и позволяют бизнесу выполнять свои функции.


Мы старались транспонировать многие функции в универсальные решения и применяли параллельно инструменты в нескольких местах. Надо сказать, что концепция юзабилити (удобства работы) работает во всех этих конфигурациях. Отличия возникают в небольших вещах, моментах.


Например, в одном месте установка ограничения по отгрузкам потребовалась более глубокая с ограничением доступа редактирования данных, а в другом понадобилась система только указания ответственных, кто будет работать с документом по отгрузке. Но подход к организации форм списков документов, работы с инструментами универсальных отчетов, общими формами по распечатке все это применялось на универсальном способе — унифицированном подходе разработки.


Проецируя на одном предприятии, происходила трансформация и доработка в другом месте и тут же происходило обновления в остальных.


Да, есть инструменты специфичные и имеющие отношения только к данному предприятию (бизнесу). Но подход оставался единым. Если был необходим механизм более удобной работы со справочником номенклатуры, то он был сделан в самом начале универсальным способом, чтобы в дальнейшем было легко адаптировать к другой схеме. Ведь структура справочника номенклатуры везде была  не одинаковой и подход к его реализации везде разный. А вот инструмент только на 90% имел отличие в исполнении. Вот это и есть правильный, с нашей точки зрения, универсальный инструмент. Не пользователи должны мучиться с настройками, а разработчик, используя универсальный подход в разработке целенаправленных узкоспециализированных инструментов для решения конкретных бизнес-задач.


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


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

 

Приведем еще пример. Существует множество обработок (опять же универсальных), которые позволяют импортировать из различных форматов файлов данные в 1с. Предоставляется возможность самим пользователям выбирать из какой колонки и какие значения забирать и куда их вставлять. Конечно возможно кого-то и это устраивает. Но слабо верится, что оператор или бухгалтер, будет заниматься тем, что раскладывать по каждой строчке файл загрузки. И тогда этот инструмент остается в руках программиста. И он делает эту загрузку, так как в этом хоть что-то понимает. Гораздо правильней когда инструмент отдан в руки пользователя и по нажатию пару кнопок, происходит загрузка данных. При этом, пользователь и знать не знает, что находится в файле загрузки. Он проверяет только наличие данного файла. И это правильно. Ведь пользователю нужно сосредоточиться на правильности самой информации, а не выстраивании схемы загрузки. Пусть этим занимаются специалисты (программисты). Зачем же пользователя этим напрягать. Да и на практике кто эти пользователи? Операторы, менеджеры, бухгалтера? Спросите их, а будут ли они это настраивать? 


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

 

Четко выраженная универсальность должна преобладать лаконичностью и обоснованностью. Чаще всего универсализация уводит разработку (проект) в противоположное направление. В целом такие разработки добавляют сложности вместо того, чтобы их уменьшать. Теряется реальность для чего создавался данный инструмент. В универсальности чаще всего превалируют множество вариантов, которые могут никогда не понадобиться и будут только в дальнейшей эксплуатации только мешать.

 

Складывается ощущение, что разработчики испытывают гордость за проявленный «героизм» при соединении всего этого «багажа знаний» в одном месте, забывая при этом кто будет им пользоваться. Не следует забывать о реальных требованиях в решении конкретных задач, а то можно слишком увлечься и оказаться в среде не слишком отчетливых возможностей функционала. Отсюда и вытекают такие примеры как бюджетирование в управлении производственного предприятия (УПП 1.3). Когда сама конфигурация очень востребована на рынке, как хороший способ вести учет в одной программном комплексе и по управленческому учету, бухгалтерскому, налоговому, МСФО, учет кадров, расчету заработной платы. Но, по-видимому, из-за наличия системы бюджетирования стоимость такой конфигурации явно переоценена в стоимостном выражении. И об этом уже говорит конфигурация Комплексная автоматизация (КА 1.1), где этого функционала нет. А тем не менее на практике бюджетирование в УПП мало кто всерьез использует из-за того, что она требует глобальной настройки. И специалистов по этой настройке очень и очень мало. Конфигурация КА несколько потеряла в дополнительном функционале, который присутствует в УПП.

 

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

 

Мы, например, не гнались за увеличением функционала у универсальном отчете по-максимум. Но тем не менее доработали все отчеты под единую форму. Вот смотрите как выглядит типовой универсальный отчет:


Универсальный типовой отчет 

А вот как выглядит после доработки:


 Универсальный отчет доработанный

Разница заметна? Даже без подробного описания, что изменено думаем будет понятно, что на форме стали присутствовать «мелочи», помогающие работать с универсальным отчетом более универсально. Ну, а если не понятно, то пользователям специально добавлена кнопка «Инструкция».

 

 

Формат превалирует над содержанием

 
Форма отчета если не гибкая, то не позволяет многого. Интересный был выявлен совершенно недавно изъян оптимальности формирования универсального отчета. Вполне себе типовой универсальный отчет «Продажи» пытались сформировать данные за 1,5 года по группам контрагентов по списку торговых точек и по-номенклатурно. Указали группировать по колонкам месяца, выставили всего три показателя и нажали сформировать. Отметим еще тот момент, что пользователь «торговые точки» вывод поставил не само значение «торговая точка», а его реквизит «адрес» — строковой реквизит (250 символов). Пользователь просто до сумашествия запускал данный отчет: долго ругался и удивлялся, что он его не выводит и выходит с ошибкой. И заново его запускал. Результатом такого упорства выявилось, что просто вся система вставала колом. В 1с ужасные появились блокировки. SQL зависал на 100% и не отпускал. 1с-сервер тоже показывал зависание. Несколько перезагрузок серверов не давало результата. Перезагружаем сервера — все заходят, пять минут хорошо и снова зависания. А он (пользователь) ведь тоже заново заходил и сразу жал на формирование отчета. При этом видимых причин вообще не показывала система. И только более менее показывал процент больше по этому пользователю количества захваченных объектов. Подозревать его в том, что именно отчет мог так подвесить систему было даже не логично. Все же подозрений больше ни на кого не падало. Когда же его остановили и он прекратил формировать отчет, все сразу моментально наладилось. Вывод: даже простое формирование универсального отчета может повлиять на всю систему 1с. Удивительно, но факт!     
 
При этом вы можете сколько угодно закупать оборудования, но если простой способ выбора настроек отчета повесит систему, то это будет бесполезной тратой финансов. Здесь только по-наитию мы поняли причину. Конечно уже приготовились через profiler смотреть кто, что может делать. Только удалось обнаружить довольно простым способом. Виноваты ли в этом программисты? Совсем нет. Отчет универсальный и за малый период выводит данные без проблем. За больший период при выборе не индексируемого реквизита он может сыграть такую злую шутку. SQL просто не вывез такой формат формирования данных. Стоило только не использовать это дополнительное поле, а вывести просто по реквизиту «торговая точка», как отчет сформировался за пару минут.

 

Вот реальный пример, что система может позволять многого в универсальном формате при правильном понимании ее, и не позволять, если не обращать внимание не то, что она сообщает в виде ошибки. Если уж ошибка повторяется множество раз, то лучше проконсультироваться в тех.поддержке, что за ошибка. Возможно вы делаете что-то не так. Мы сами как разработчики были несколько в шоке, от того как можно было совершенно маленьким отчетом повесить всю платформу 1с. Но факт остается фактом. Оказалось вполне реально. Оперативная память и процессор были на 100% заняты. И объяснение даже нашлось: что если не индексируемое поле, то отчет будет формироваться значительно дольше. Если уж такой именно отчет с этими группировками необходим, лучше дать задание программистам — они его сделают как отдельный отчет и там постараются оптимизировать внутри запроса. В конце концов могут там проиндексировать нужные поля. В универсальный же отчет все поля не заложить в индексацию, это может также сыграть на быстродействии. Уж лучше индивидуальный целенаправленный отчет. А универсальный использовать для оперативных вещей. Конечно же это в случае, если он выходит в ошибку или вешает всю систему. А сколько таких отчетов используется каждый день? Все ли отчеты оптимальны и по настройкам и по написанию кода?

 

На днях появилось продолжение этой истории. Не только реквизит текстовый выставленный в группировку строк через «точку» делает зависание, но и оказалось любой реквизит так может сыграть. Нашелся ответ очевидный. Когда выводят отчет с измерением «через точку», например «Номенклатура.ЕдиницаХраненияОстатков», за большой период с многообразными группировками строк и колонок. Допустим за год, по-месячно по колонкам и в разрезе каждого контрагента, то на больших базах такой отчет может чисто заблокировать даже работу пользователей. И это при условии что формируется всего-лишь отчет. Не записываются данные. Тут и гибкие блокировки не помогут. Поможет только правильное написание кода запроса в отчете. Т.е. в самом запросе следует заведомо прописать поле «НоменклатураЕдиницаХраненияОстатков» без «точки» и обязательно поле «НоменклатураЕдиницаХраненияОстатковПредставление», чтобы на форму выводилось текстовое представление реквизита «ЕдиницаХраненияОстатков», а не его ссылка в базе. Именно тот момент, что на печать выводится ссылка катастрофично влияет на производительность всей системы. И таких узких мест в базе предостаточно. Их следует находить, выявлять, поправлять, делать правильно. Даже если ваш отчет работает 30 секунд, это не гарантирует, что он правильно выводит на экран информацию. У нас множество было примеров с этим пользователем, когда в универсальном отчете «Ведомость по партиям» он просто вешал базу, хотя выбирал реквизиты стандартно. При этом всегда по-разному отчет показывал разную скорость вывода. Когда быстро, когда просто вешал базу. На малых данных (отфильтрованных) это не заметно. А вот стоило взять для аналитики период по-больше, то сразу все это замечали. Процессор сервера уходил в потолок под 100% и никто уже ничего не мог проводить ни один документ. Здесь очевиден совет: если отчет долго выводится, то направьте программистов ваших на то, чтобы они опытным взглядом посмотрели и его ускорили. У нас таких случаев просто пруд пруди. И не только в чужих отчетах находим не оптимальности, но и в своих отчетах также постоянно делаем доработки. Конечно мы уже не делаем простых ошибок, которые явным образом видно, но пользователи умудряются нас постоянно удивлять.

 

 

 

 

Вывод

 

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

 

Заявленный функционал во многих типовых конфигурациях или дополнительно разработанных обработках крайне скуден или излишне усложнен, но при его презентациях выглядит все шоколадно. Но это на словах. На деле все оказывается не так радужно.

 

Мы на практике поняли, что лучше пользоваться универсальным подходом в реализации проектов и делать шаблонным методом узкоспециализированные разработки так, чтобы конечные пользователи максимально меньше тратили время на выполнение своих задач.

 

Нравится 0 Не нравится
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо зайти на сайт под своим именем.
Добавить комментарий
Ваше имя: *
Ваш e-mail: *
Вопрос: Юзабилити - это удобство работы в программе?
Ответ:
Код: Кликните на изображение чтобы обновить код, если он неразборчив
Введите код: