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

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

Впервые термин «ментальные модели» был использован шотландским психологом Кеннетом Крейком (Kenneth Craik) в работе «Природа объяснения» в середине XX века. Крейк предположил, что мозг создает «уменьшенные модели действительности» и использует их для оценки грядущих событий.

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

В этой статье мы постараемся осветить несколько наиболее важных из них.



/ фото Hey Paul Studios CC

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

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

Термин «процессное управление» применяется к двум разным сферам деятельности:

1. В случае, когда не производится автоматизация исполнения бизнес-процессов. Задача — составить описание бизнеса в виде графических диаграмм, которые легко воспринимаются людьми. Такие диаграммы фактически представляют собой специальный язык общения менеджеров, бизнес-аналитиков и руководителей предприятий и используются для выработки и объяснения базовых решений по организации бизнеса предприятия.
   
   
2. В случае, когда бизнес-процессы непосредственно исполняются в компьютерной среде предприятия. Будем называть процессы этого вида — исполнимые бизнес-процессы. Для исполнения таких бизнес-процессов на предприятии устанавливается специальная компьютерная система — BPMS (Business Process Managrment System) в английском варианте наименования, или СУБП (Система Управления Бизнес-Процессами) в русском варианте. Этим бизнес-процессам и посвящена данная статья.

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

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

Антон Антипин
Генеральный директор компании «Business Set»

«Если вы хотите понять систему и быть в состоянии предсказать ее поведение, необходимо изучить ее в целом. При разделении её на части могут разрушиться связи и, следовательно, сама система».

Денис Шервуд

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

Автор: Владимир Алексеев, ведущий системный архитектор, 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 был задан вопрос: «Какие программерские термины вы придумали, так чтобы они стали популярны в ваших кругах (то есть вы слышали, что кто-то их повторяет)?

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