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

У каждой команды должно быть ответственное лицо, которое будет курировать свою часть работ. Обычно это либо Project manager, либо тимлид со стороны подрядчика.

Чем чаще менеджеры команд синхронизируют действия, тем лучше. Раз в день или раз в неделю - решать вам. Для синхронизации действий мы используем ежедневные созвоны до 15 минут, где подводим итоги вчерашнего дня, фиксируем планы на день и обозначаем трудности, если они есть.

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

Обязательно должен быть человек, который видит всю картину целиком: либо собственник продукта, либо IT-менеджмент заказчика, который согласует действия всех команд. Также должен быть техлид, который соберет результаты работы нескольких групп разработки воедино. Это либо менеджер проекта, либо ведущий программист.

Когда продукт монолитный и пока не интегрируется с сервисами, то удобно привлекать одного подрядчика на все направления: front, back, QA и аналитика. Если подрядчик не может закрыть потребность полностью, то делить лучше, например, в формате front+back, QA+аналитика.

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

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

Часто причина в неправильном описании задачи. Эту ошибку обычно допускает бизнес с небольшим опытом во взаимодействии с компанией-разработчиком и ставит задачи в формате "надо добавить фичу" и все. Но такая постановка задачи тратит ресурс.

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

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

Признаки хорошо описанной задачи:

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

Как происходит на практике: после обсуждения или анализа рынка было принято решение разработать фичу для сайта или дополнительную функциональность в приложении. Для описания задач потребовалась аналитика.

Когда аналитика готова, то она передается backend и frontend разработчикам на оценку. В то время, когда backend готовится к работам, можно сделать независимые задачи для фронтовой части.

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

Советуем руководствоваться простым правилом: не вносить изменений, пока спринт не закончен. Кажется, что внести изменение в ходе работы быстрее, но по факту это сильно вредит качеству продукта в перспективе.

Лучше планировать работу небольшими спринтами. По опыту: две недели - оптимальный срок. Команда успеет спланировать, как выполнить задачи, провести тестирование и внести правки. Следите, чтобы в этот период DevOps поддерживал высокую скорость и надежность CI/CD. Также прогнозируйте увеличение нагрузки на систему и ее расширение, чтобы подготовить сервера и ресурсы.

Чаще всего ошибка в синхронизации front и back версий, нужно наладить коммуникацию об изменениях между менеджерами команд.

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

Наш офис расположен в трехэтажном коттедже. До центра города можно прогуляться пешком за 10 минут.

На первом этаже - две переговорки и рабочая зона frontend отдела. Здесь вы часто можете услышать холивары “что лучше: реакт или вью”.

На втором этаже можно найти специалистов backend отдела, менеджеров проекта и аналитиков, QA специалистов и бухгалтера.

На третьем этаже сидят специалисты отдела продаж и аккаунтинга, основная часть backend разработчиков и hr-специалисты.

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

Для любителей чая всегда есть выбор черного и зеленого чая. Ценители кофе могут приготовить себе капучино с молочной пенкой с помощью кофемашины. И, конечно, тут есть печеньки.

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

Рабочее утро для всех начинается по разному и в разное время. Если ты - ранняя пташка, то тебе дадут ключи от офиса и ты первым сваришь себе горячий кофе. Если ты - сова, и любишь работать в пустом вечернем офисе, то ключи тебе тоже положены.

Вы никогда не останетесь голодными. В чате “Еда” ребята собирают совместные заказы на доставку пельмешек, роллов, бургеров и другой вкусноты. Если вы вдруг проголодались посреди рабочего дня, то в 5 минутах ходьбы есть магазин.

Все сотрудники в курсе текущих проектов. Для этого каждую неделю мы проводим демо, на котором мы делимся кейсами с проектов, рассказываем о продуктах, технологиях, трудностях и успехах.

Для поддержки уровня английского языка ребята ходят в Speaking club. Участники сами выбирают тему дня: от любимых фильмов до лайфхаков как найти вторую половинку.

Сплачивает не только работа, но и совместный отдых. Мы уже катались на картинге, играли в пейнтбол и страйкбол, катались по ночному городу и искали клад, ходили на интеллектуальные квизы. Джедаи-велосипедисты ездили в 5-дневное путешествие и накрутили 500 км! А чтобы размяться посреди рабочего дня у нас есть баскетбольная площадка и турник.

Любители ламповых вечеров играют в настолки и смотрят фильмы на большом экране через проектор.

Пока у нас один офис - в Ульяновске. Но у нас много удаленных сотрудников по всей России. Наши ребята живут в Самаре, Керчи, Саратове, Геленджике, Нальчике, Калуге, Москве, Санкт-Петербурге, Воронеже, Ростове-на-Дону, Набережных Челнах.

Мы приглашаем ребят поработать в Ульяновском офисе и на корпоративы. Все презентации и демо проходят в скайпе или зуме. Speaking club тоже можно посещать удаленно.

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

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

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

Проблема заключается в том, что сбор котировок со всех бирж займет у пользователя время, а обилие вкладок браузера (на каждую биржу — как минимум по одной) усложнит работу. Учитывая, что эта задача регулярная и повторяющаяся, количество затрачиваемого времени переходит все разумные границы. Нужно оптимизировать!

Как это работает? Зарегистрировавшись на портале, пользователь может привязать свои учетные записи с крупнейших бирж, используя API ключи, и получить всю необходимую информацию в одном месте — своё полное портфолио с учётом всех валют на всех биржах, глобальную историю продаж, курс интересующей пары на каждой бирже и его изменение, уровень спроса и предложения, и, что самое важное, ещё и в один клик провести нужную операцию, не уходя с портала.

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

В общих чертах разработка делится на следующие шаги:

Было выбрано несколько наиболее популярных и стабильных бирж криптовалют (Binance, Bitfinex, Bitstamp, Bittrex, Coinbase, Hitbtc, Huobi, Kucoin, Okex, Poloniex). Поскольку пользователи решали одни и те же задачи на каждой из них, интеграцию в Tokenplace выполнял один модуль с универсальным интерфейсом и различной реализацией в зависимости от той или иной биржи. Например, каждая биржа имеет свой формат обмена данными и API, или например, пара биткоин — доллар США может иметь вид: btcusd, BTCUSD, BTC-USD и BTC_USD. Поэтому для каждой биржи реализованы свойственные только ей методы защиты, списки поддерживаемых действий, а управление и обмен данными с главным приложением унифицированы. Такой подход позволил быстро подключать новые биржи в приложение, минимизировать затраты на обеспечение качества продукта, так как при отладке интеграции с каждой новой биржей невозможно испортить работу уже существующих.

Большое внимание уделено информационной безопасности. Применены как стандартные подходы к криптозащите (обмен данными по защищенному протоколу HTTPS, шифрование данных с помощью уникальных одноразовых токенов (nonce), “соль” для защиты от атак через “радужные таблицы” и т.д.), так и ряд специальных мер.

Имея многолетний опыт интеграций с различными финтех-сервисами мы учитывали следующие особенности:

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

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

Так как мы не хотели заставлять посетителей ждать по 30 секунд, пока их данные загрузятся, нужно было действовать.

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

Для этого клиентская часть выполнена в виде легкого и функционального SPA (Single Page Application) с использованием vue.js и хранилища vuex. Хранилище сыграло огромную роль в «облегчении»: с одной стороны, точно зная, что требует обновления, мы могли гораздо меньше обращаться к серверу, пользуясь хранилищем, а с другой — пока пользователь просматривал курсы в одной бирже, мы могли незаметно для него обновить данные по другой в бекграунде.

Описанная архитектура и накопление исторических данных дает возможность без ущерба для скорости доступа к данным отображать динамику баланса пользователя на графиках по всем биржам в зависимости от его торговли и изменения курса валют.

Для отображения свечных диаграмм, индикаторов и инструментов теханализа применены компоненты от TradingView — на наш взгляд они одни из самых удобных.

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

Реальные биржи:

Чтобы обойти данные ограничения мы приняли решение мокировать (симулировать) действия биржи через наш внутренний сервис и проверять поведение именно приложения. Мы знали, как сервис “общается” с биржами, какие запросы отправляет и какие ответы ожидает получить. Были созданы скрипты, которые максимально точно имитировали действия разных пользователей во время клиентской сессии. А что обычно делает клиент в этом приложении? Покупает, продает монеты и отслеживает динамику портфеля. Зная времена ответа на запросы реальных бирж, мы настроили работу приложения таким образом, что с увеличением числа пользователей нагрузка росла линейно, что позволяло развернуть приложение на любых популярных облачных серверах.

На первом графике видно увеличение количества запросов в секунду (requests per second) с течением времени теста. При этом время ответа сервера на 3 самых популярных пользовательских запроса (второй график) не превысило 0,911 секунды.

Мы заметили, что биржи в своих API почти не предлагает т.н. отложенные заявки или shadow order (невидимый заказ, который разместится только тогда, когда заранее заданные условия будут выполнены). А ведь у нас уже были все детали пазла в руках: мы и так регулярно получали свежайшие котировки разных бирж и состояние балансов, а, значит, вполне могли заодно проверить, не сработал ли триггер для размещения подобного заказа. Пожалуй, получившаяся платформа была просто создана для такой возможности.

Главное в работе — это положительный результат, признанный нашими клиентами. Мы были рады помочь владельцам Tokenplace в развитии отличного финтех-продукта.

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

Аналогичная ситуация происходит, когда в спешке мы ставим галочки при установке программы, проговаривая “да, согласен, согласен”.

При создании программного обеспечения для наших клиентов мы постоянно уделяем внимание лицензионной чистоте создаваемого ПО.

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

Право может распространяться на следующие формы представления ПО:

На такие условия непосредственно может влиять вид готовой программы.

1.1. Custom software / bespoke Создание программы является предметом договора. Заказчику принадлежит исключительное право на использование программы, а разработчику — право использовать программу для собственных нужд на неисключительной основе.

1.2. Mass-market, off-the-shelf software Программы для массового использования. Условия договора определяются в одностороннем порядке и заключаются проставлением галочки “Принимаю условия” (click-wrap license) или разрывом упаковки программы (shrink-wrap license).

2.1. System and Application Системные программы, к которым прежде всего относятся операционные системы, и прикладные программы (ПО, предназначенное для выполнения каких-либо задач). На эти виды также распространяется правовая охрана.

3.1. Proprietary software Проприетарное ПО (частное, несвободное), в рамках которого за правообладателем сохраняется весь объем прав, а пользователь может использовать ПО в объеме, который обозначил правообладатель.

3.2. Open source software ПО с открытым исходным кодом в противопоставление проприетарному ПО предоставляет больше прав конечному пользователю. Например, возможность модифицировать программу и распространять ее копии. В настоящее время существует множество лицензий с открытым исходным кодом, мы рассмотрим их чуть позже.

3.3. Public domain software ПО в общественном достоянии, т.е программа выходит из под контроля автора, и каждый может использовать программу в любой форме, не противоречащей закону.

4.1. Commercial software Коммерческое ПО, т.е. то, которое распространяется на возмездной основе (плата за лицензию или за экземпляр программы). Коммерческим ПО могут выступать как проприетарные ПО, так и ПО с открытым исходным кодом.

4.2. Freeware Бесплатное ПО, которое распространяется на безвозмездной основе, обычно содержит ограничения для пользователей и скрывает исходный код.

4.3. Free software Следует выделить данный вид, чтобы объяснить разницу с бесплатным ПО. Free software — это свободное ПО, разновидность ПО с открытым исходным кодом, которое может распространяться на возмездной основе.

4.4. Shareware Условно-бесплатное ПО, которое имеет период бесплатного использования программы или предоставляет в бесплатное использование только ограниченный набор функций. Пользователь может получить доступ ко всем функциям на какой-либо срок после оплаты.

4.5. Adware ПО с размещением рекламы, при использовании которого пользователь просматривает рекламу, проплаченную рекламодателем правообладателю.

Каким же образом можно защитить ПО? Существует несколько правовых режимов охраны программ, набор способов варьируется в зависимости от той или иной юрисдикции, в которой происходит регистрация правообладания. В России набор следующий:

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

2.1. Авторское право По желанию ПО может быть зарегистрировано в Роспатенте. В рамках авторского права защищаются, как правило, исходный код и объектный код. Срок авторского права действует в течение жизни автора и 70 лет после его смерти.

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

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

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

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

Предмет договора, способы использования предмета договора, объем лицензии (однопользовательская лицензия, лицензия с ограничением количества пользователей, лицензия, привязанная к количеству процессоров и прочее), срок лицензии, территория действия, право сублицензирования и распространения третьим лицам — все это обычно отражается в лицензиях.

Формат проприетарных лицензий и лицензий с открытым исходным кодом одинаковый. Отличаются только условия и объем прав.

Развитие IT-отрасли несоизмеримо по масштабам с другими сферами нашей жизни. Каждый разработчик вносит свой вклад ежедневно. Чтобы делиться результатами своей работы, совместно развивать технологии, давать доступ к свободному изучению, исправлению и модифицированию своего продукта, существуют лицензии с открытым исходным кодом (open source license). Данный формат ПО существенно отличается от ПО в общественном достоянии. Ведь несмотря на то, что автор предоставляет исходный код, его права охраняются лицензией. Так как свободы, которые разные авторы готовы предоставить, отличаются, существует большое количество видов лицензий с открытым исходным кодом. Мы рассмотрим наиболее распространенные.

Лицензии с открытым исходным кодом отличаются также степенью детализации документации, так как были созданы разными организациями для разных целей. Кто-то хотел продвинуть эту философию в массы, как создатель GPL-лицензии, а кто-то создавал лицензию под конкретный продукт, как Mozilla.

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

Для разработки продуктов наши front-end разработчики используют фреймворки и библиотеки с MIT-лицензией, такие как React, Angular, Redux. Back-end разработчики используют, в основном, фреймворки, лицензированные Apache License 2.0 (Apache Camel, Spring и т.д), и фреймворки с MIT-лицензией (Laravel, Symfony). Это позволяет нам использовать, модифицировать и распространять разрабатываемые продукты, открывая исходный код или скрывая его, с любой удобной лицензией.

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

Эквайринг – оплата услуг, товаров с использованием платежных карт, может осуществляться как через платежные терминалы (POS-терминалы, которые используется в магазинах), так и через интернет (интернет-эквайринг).

Проще говоря, эквайринг – это возможность расплатиться карточкой, не используя наличку.

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

Предложения на рынке можно сегментировать следующим образом:

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

После оплаты пользователь переадресовывается на заданную страницу сайта.

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

Фишинг — это вид интернет-мошенничества, целью которого является получение данных карты непосредственно от ее хозяина.

В сводной таблице представлены платежные системы с разбивкой по наиболее важным параметрам.

Если у разрабатываемого портала крупный ежемесячный оборот (более одного миллиона), то стоит обратить внимание на интернет-эквайринг от банков, т.к., несмотря на частые трудности с заключением договора и подключением эквайринга, данный способ позволяет серьезно экономить на комиссии.

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

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

Например, веб-сайт. Где лучше расположить логические блоки на странице? Принято считать, что курсор мыши человек воспринимает как продолжение руки. Следовательно, логические блоки по бокам страницы лучше размещать таким образом, чтобы пользователю не приходилось «тянуться» к ним, загораживая информацию на экране. Кроме того, при просмотре сайта логические блоки должны хорошо отмечаться периферийным зрением, однако не отвлекать пользователя от просмотра основного содержания.

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

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

На старте мы поставили перед собой три важных вопроса:

Прежде чем перейти к работе мы проанализировали целевую аудиторию.

Системой пользовалось около 400 операторов, условно их можно разделить на две группы: опытные пользователи (работают с системой 2 и более месяца), новички (до 2х месяцев опыта работы с системой). Разделение целевой аудитории по данному признаку было обусловлено выявленной корреляцией в результатах опроса пользователей по вопросу “вызывает ли интерфейс системы трудности в работе или нет?”.

Для оценки интерфейса мы использовали метрику SUS (System usability scale) — шкала удобства использования системы по ее функциональным модулям. Средние значения представлены в таблице:

Значение метрики SUS при котором можно уверенно говорить об удобстве системы — 68 и более. Это значение получено авторами метода статистически. Будем использовать наши измерения как отправную точку в исследовании и в последствии сравним их с итоговыми значениями.

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

1.1. Частые прерывания и многозадачность 2.1. Сотрудники склада — неопытные пользователи ПК

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

На основе проведенного анализа наша команда выдвинула несколько гипотез, которые позволят повысить удобство использования интерфейсов:

1.1. Снабдить сотрудников склада портативными планшетами с адаптированной версией интерфейса системы, чтобы по мере нахождения товаров в ячейках от нескольких клиентов работник склада отмечал получение сразу. Тем самым удалось бы уменьшить время прерывания специалиста склада в работе с приложением.

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

2.1. По возвращении со склада сотрудник обновлял одинаковые вкладки клиентов со статусами товаров пользователей. В случае повреждений груза и иных рекламаций заполняется отдельная форма.

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

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

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

Большая часть клиентов (80%) — это физические лица, интерфейсы для разных типов клиентов были разделены и упрощены. Поиск клиента осуществлялся по номеру заказа, паспорту или номеру телефона. В новой версии достаточно было вбить несколько цифр — система сразу осуществляла поиск, сужая выдачу по мере заполнения поля. Ранее номер заказа представлял из себя число, у которого изменялись на единицу последние цифры по мере отгрузки заказов. Для повышения скорости поиска формат номера заказа был переделан так, чтобы изменяемая часть находилась в начале числа.

4.1. Приложение изобиловало окнами подтверждения действий пользователя. Этот неудобный элемент интерфейса добавили разработчики системы, желая снизить процент неправильных действий неопытных операторов системы.

Мы решили переработать интерфейс таким образом, чтобы перейти от существующего принципа “несколько тяжелых, но универсальных страниц” к принципу достаточного количества “простых легких страниц заточенных под определенный вид простых действий”. Это повысит однозначность восприятия информации пользователем и позволит отказаться от окон подтверждения.

5.1. Несмотря на то, что работа оператора системы не требовала высокой квалификации персонала, мы предположили, что, существующие интерфейсы интуитивно непонятны для неподготовленного пользователя. Решили провести детальный UX-анализ, который позволил исправить ошибки валидации полей ввода данных, выводить понятные пользователю сообщения об ошибках, скрывать неактивные элементы управления и полей ввода и т.д.

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

Мы имеем дело с тем самым случаем, когда сотрудник, используя компьютер для управления рабочим процессом, неизбежно отвлекается на обслуживание оборудования и др. рабочие моменты (телефонный звонок, электронное письмо, совет коллеге и тд). Как выстроить интерфейс программного продукта, минимизируя потерю скорости работы и потерю фокуса внимания?

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

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

2.1. Автоматически заполняем поля новой записи значениями введенных ранее. Это увеличило производительность ввода данных, уменьшая количество необходимой для ввода информации пользователем, из базы подгружались данные по мере ввода первых символов с клавиатуры. Это в том числе позволило избежать дублирования данных, например ранее Иванов Иван Иванович мог быть занесен в систему в виде Иванов И.И.

3.1. Фоновый режим выполнения задач: Вывели выполнение длительных операции в фоновый режим. Потребность вмешательства пользователя минимизировали: если процесс предположительно будет длительным, система убеждается, что она получила всю информацию от пользователя до начала этого процесса.

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

Средний срок работы сотрудников склада в компании клиента не превышал одного года.

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

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

1.1. Существенно упростить интерфейс для самых частых операций: Наиболее часто используемый интерфейс — это форма выдачи товара. Изначально отображалась вся информация о клиенте из ЦРМ- системы, товарах. Расположение нужного товара на складе указывалось в другой форме. Схема проста: оператор фиксирует факт выдачи товаров и удостоверяет личность получателя. Новый интерфейс по номеру накладной или номеру удостоверяющего документа сразу отображал товары с подсказкой о нахождении товара на складе и подтверждении выдачи.

2.1. В манипулирование объектами была добавлена возможность дублировать основные действия системы посредством drag and drop, что позволило неопытным пользователям интуитивно перетаскивать объект в нужное состояние. Например, продвижение накладной в раздел оплаты, перемещение определенных товаров в отдельную накладную и тд.

3.1. Визуализация объектов манипулирования. Например, пользователь сможет быстро сориентироваться, если раздел оплаты будет оформлен в виде пиктограммы.

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

5.1. Ограничение принятия решений. Программа не должна задавать пользователю вопрос, на который он не может ответить, не обратившись за информацией куда-то еще. Или, к примеру, вопрос программы о том, стоит ли обновить содержимое накладной лишь тратит время пользователя. Конечно, стоит! Другой пример — это разделение форм отображения юридических и физических лиц, что позволило минимизировать количество отображаемых полей ввода.

6.1. Автосохранение. При внесении или изменении данных поля формы автоматически сохраняются, что сокращает время работы с интерфейсом и исключает потерю несохраненных данных.

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

Как результат, внедрение ПО с эргономичным интерфейсом привело к:

Снижение индекса SUS у опытных пользователей сразу после внедрения обусловлено привыканием к сложному интерфейсу старой системы.

Если Ваша цель — эргономичный пользовательский интерфейс, то наша команда профессионалов с удовольствием поможет её достичь.