Терминология IT

Уроки после первых пилотных проектов с блокчейн

Автор: Владимир Алексеев, ведущий системный архитектор, IBM Россия и СНГ


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

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

В предыдущей статье «Зачем нужно моделировать индивидуальные и типовые сценарии?» я рассказал про необходимость моделирования как типовых, так и индивидуальных сценариев в тех случаях, когда заказчик хочет автоматизировать три функции:

1. Моделирование операций и сценариев на основе типовых схем.
2. Сравнение полученных результатов с планируемыми.
3. Корректировка планов.

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

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

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

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

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

Сегодня много говорят о решениях для автоматизации бизнеса. Но, если по-честному, многие ли из менеджеров (топ или пониже – неважно) действительно разбираются в том, чем различаются СЭД, ECM, CRM, BPM и другие аббревиатурные ИТ-системы? Если вы с уверенностью ответили да, объясните – для кого все эти обзоры, ролики, вебинары о том, что это за решения, как и для чего с ними работать?

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

При внедрении любой CRM-системы один из первых этапов работы – описание бизнес-процессов. Важно изучить особенности работы компании, учесть все факторы, которые влияют на тот или иной процесс, выявить ключевые моменты работы и «тонкие места». В результате мы получаем грамотное и подробное описание бизнес-процессов, которые подлежат автоматизации.

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

Таким образом, при работе по внедрению CRM лично я придерживаюсь следующей последовательности действий, которую также рекомендую всем коллегам, как доказавшую на практике свое удобство и жизнеспособность:

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

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

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

Сегодня в отечественном бизнесе набирает популярность новый вид программного обеспечения для управления бизнес-процессами, а именно, BPMS-системы. И, естественно, их появление вызвало много вопросов. Зачем они нужны? Как они работают? В чем их принципиальное отличие от других вариантов автоматизации бизнеса?

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

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

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

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

Данную статью надо рассматривать как продолжение одной из моих ранее написанных статей “Что такое CRM-системы и как их правильно выбирать?”

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

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

Во многих языках это имеет большое значение. В японском, например, у слова «отменить» есть разные переводы (キャンセル или 取消). Если слово «отменить» играет значительную роль в вашем приложении (скажем, расположено на кнопке), переводчики должны знать, какой из переводов использовать, и придерживаться единого варианта во всех случаях. Особенно важно сохранить единообразие слов, специфичных для бренда.

Хороший глоссарий обепечит понятный, согласованный перевод. Веря в это, мы в Alconost перевели статью о том, как создать такой глоссарий для вашего приложения.

До сих пор, мое продвижение по карьерной лестнице было быстрым. В 2008 году, я начал работать на полную ставку программистом в должности Junior Developer. Там был славный босс и классные коллеги, и я получил навыки использования Java и .NET, вместе с первым полезным опытом. Поработав так пару лет, я чувствовал, что настало время двигаться дальше…

Есть три фундаментально разных способа описания объектов. Первый – это описание объекта как целого. В таком описании объект рассматривается как целое и неделимое. Например, «Самолет – это транспортное средство для перевозки грузов и пассажиров по воздуху». Второй способ описания – это описания объекта как конструкции. Такой метод описаний называется представление в виде композиции. Например, «Самолет – это конструкция из фюзеляжа, крыльев и двигателей». И третий способ – это описание объекта как агрегации других объектов. Например, «Песок, что лежит во дворе – это тот песок, что привезли вчера плюс тот, что привезли сегодня». Далее мы рассмотрим два из них, как наиболее востребованные: описание объекта как целого и описание объекта как композиции.

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

Много терминов может показаться банальными и очевидными, но есть и такие, для которых я не нашёл добротных, годных переводов (например grid, toggle button, extender). Т.ч. приглашаются все желающие в комментарии для дополнений, исправлений, размышлений.

Утром во вторник 10 апреля 2012 года я увидел, что некий аноним в моём формспринге задал вопрос о том, что я думаю о статьях «Межсистемность» и «Межобозревательность», появившихся в сетевой вики-энциклопедии «Викиреальность» в феврале трудами участника, действовавшего под псевдонимом «Five Dollars».

А так как сообщество Хабрахабра проявляет заметный и неослабный интерес к вопросу о выборе между варваризмом и словородностью при переводе иностранных терминов (чего стоит хотя бы обсуждение перевода «Retina display», перевалившее далеко за сотню комментариев!), то я счёл формат Хабрахабра куда более подходящим для изложения своих воззрений, нежели формат Формспринга, где даже редактирование не предусмотрено.

Начну прежде всего с того, что термины «межсистемность» и «межобозревательность» представляются мне шагом, совершённым в правильном направлении — от варваризмов «кросс-платформенность» и «кросс-браузерность» к языку несколько более русскому.

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

Стартап не может кончиться потлачем,
В противном случае его зовут иначе.

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

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

Как известно, на русский технический перевод колоссальное влияние оказывают два фактора: переводчики-дилетанты и маркетологи. В данном случае мы имеем некую смесь первого со вторым. В английском языке благодаря его аналитизму и атрибутивным конструкциям подобные названия имеют однозначное представление: Yandex Money. Или Google Money, и т.д. И вот нам потребовалось создать в русском языке что-то похожее. На логотипе с помощью дизайна можно абстрагироваться от этих проблем, но что делать при текстовом написании? Наших маркетологов уже можно похвалить за то, что они не написали просто Яндекс Деньги, как сделал бы совершенный дилетант. Они проявили… гхм… креативное мышление и поставили посередине точку. Но это тоже не самый удачный вариант, потому что он не характерен для русского языка.

Посетителям сайта stackoverflow.com был задан вопрос: «Какие программерские термины вы придумали, так чтобы они стали популярны в ваших кругах (то есть вы слышали, что кто-то их повторяет)?

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

Екатерина Лажинцева занимается русификацией продуктов Microsoft ещё со времён Windows for Workgroups. Некоторое время она публиковала в своём ЖЖ занятные случаи из прошлых локализаций, включая историю приснопамятного «приложеньица» в IE 4.0.

И он отчасти от неопытности, отчасти в пылу молодого задора переводил не совсем обычным образом. Много чего мы все-таки вернули в более привычный вид, но вот «приложеньице запущено» было замечено слишком поздно, когда строка уже ушла из Ирландии в Редмонд для включения в Java-машину, и исправить это нам уже не дали. (из других интересных переводов: Access denied «В притязаниях отказано».)

В настройках JVM необычные переводы отыскиваются до сих пор:

Обратите внимание на вот эту видеозапись, взятую из статьи на Membrana.Ru от 27 апреля:



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

Пилот наблюдает дополненную реальность через наголовный шлем, а зрители — при помощи большого компьютерного экрана или (как сообщил закадровый голос диктора видеоролика) при помощи собственных iPhone и iPad.

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

Когда-то, на заре Интернета, переводом английских текстов и слов занимались все кому не лень, в основном технари. В результате в русский язык вошел целый корпус переводных полуфабрикатов, плохо приспособленных к русской грамматике, синтаксису и стилистике. Та же проблема, кстати, относится к сфере бизнеса. Бедные, бедные Карамзин и Белинский, которые в свое время из кожи вон вылезали, создавая добротные русские аналоги иностранных терминов…

Не всем этот топик будет интересен, но думаю, что размещение его здесь оправдано, так как хабр — один из ведущих ИТ ресурсов Украины.

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

Printer, принтер — друкар [друк’ар] (рус. печатник)
Сейчас в украинском языке, как и в русском, используется транслитерация с английского — «принтер» [пр’ынтэр]. Слово «друкувать» (рус. печатать) в украинский язык пришло из немецкого через польский. И как в немецком, так и в польсоком «printer» переводиться как «печатник»: нем. Drucker, польск. Drukarka.