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

Наверно, многие из моих читателей как раз закончили квартальный (и/или годовой) цикл планирования, так что сейчас будет подходящее время напомнить, что процесс, которым мы пользуемся как стандартом в технологической отрасли, на самом деле — полная чушь. Разумеется, я имею в виду методологию Objectives and Key Results. Давайте же поговорим об OKR, что это такое и откуда они взялись, а ещё о том, почему это ужасная идея.

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

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

Как оформить процессы?

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

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

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

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

В удивительном мире информационных технологий, где айтишники и клиенты встречаются регулярно, царствует терминологический Хаос! Казалось бы, все говорят на одном языке, но когда речь заходит про «данные для авторизации», клиенты впадают в ступор. Бизнес говорит «учетки», «логины», «доступы» — как правило, подразумевая под этим пары «логин и пароль» для доступов к облачным сервисам. Однако не все новые типы информации подпадают под эти термины. Мы в TeamDo сталкиваемся с таким регулярно, потому стали искать другое емкое определение.

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

Любой компании, которая стремится сохранить конкурентоспособность на рынке, необходимо создание «золотой записи» (профиля) клиента во внутренних базах. Для этого многие используют системы управления мастер-данными (MDM, master data management), но сталкиваются с рядом проблем, другие – применяют CDP-платформы (Customer Data Platform), которые также имеют свои недостатки. А теперь представьте, если от каждого из решений можно было взять лишь лучшее, оставив за бортом все слабые стороны. Как это сделать – в новой статье CleverData под катом.

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

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

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

Эта статья – ответ на статью «Обращение к издательствам: пожалуйста, не переводите термины».

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

– Какие-такие «узлы» и «фрагменты»? – спросит программист, работающий с MongoDB. – Наверное, ты имел в виду «чанки» и «шарды»?

– Что за «чанки»? – переспросит аналитик, хранящий данные в GreenPlum. – У нас данные делятся на «регионы», которые потом распределяются по «регионсерверам»!

Можно было бы продолжать этот воображаемый спор, но я лучше приведу табличку:

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

Всем привет! Меня зовут Владислав Москалёнок, и я работаю техническим переводчиком и редактором в сфере телекома и IT уже более 20 лет. Сегодня хочу поделиться опытом команды Bercut в цифровизации переводческих процессов. Из статьи вы узнаете, как мы реализовали комплексное решение, где сочетается технология накапливаемой памяти (TM) и нейронного машинного перевода (NMT). Если вы технический переводчик или вам просто интересна тема  локализации ПО —

На днях мы работали над переводом глоссария CNCF и начали спорить о том, как писать словосочетание cloud-native. Раньше мы использовали название с дефисом — такое правило применяется к составным прилагательным в английском языке (пример — well-known actor). «Википедия» в статье «Cloud-native computing» тоже следует этому правилу, с другой стороны, название CNCF расшифровывается уже без дефиса: Cloud Native Computing Foundation. Так что нам пришлось провести небольшое расследование.

Все начинается с имени, даже в мире IT-технологий и стартапов. Это статья для всех, кто хочет выбрать идеальную доменную зону для IT-проекта и не ограничиваться доменными зонами .RU или .COM. Однако, среди большого количества доменных зон выбрать идеальную может быть настоящим вызовом. Я исследовал больше 800 доменных зон и выбрал 20 подходящих для IT сферы.

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

В том, что управленческая концепция BPM (Business Process Management, управление бизнес-процессами) до сих пор не имеет строгих непротиворечивых основ и долгое время не может «вырасти» в научную \ инженерную дисциплину во многом лежит вина низкого качества терминологии BPM (имеем семантический «зоопарк»). Точной дисциплине нужны единые универсалии, концепты, понятия, категории, таксономии, которые сверены и сведены в единый талмуд под названием Толковый словарь BPM. Эти универсалии (образы, шаблоны) должны быть четко обоснованы (логически выведены, взаимоувязаны) и систематизированы в онтологию в рамках единой непротиворечивой концепции, включающей идей (идеологию), методы (методологию), систему логических рассуждений и математическую основу. К сожалению, в BPM усиливается путаница в понятиях и прогрессирует различное толкование одних и тех же терминов, т.е. сегодня классический BPM не развивается, а скорее деградирует.

Появляются новые BPM инструменты, например, только в 2023 появились отечественные «очередные убийцы BPM-мастодонта Business Studio»: PIX Process Studio и Арахис (не путать с BPMN\ low code \ no code инструментами), но они не только не привносят чего-либо теоретического «свежего», концептуально нового, а зачастую и не содержат теоретических основ (базовых концепций) классического BPM, хотя бы в объеме ARIS четверть вековой давности (конца 90-х).

Появляются новые BPM инструменты, например, только в 2023 появились отечественные «очередные убийцы BPM-мастодонта Business Studio»: PIX Process Studio и Арахис (не путать с BPMN\ low code \ no code инструментами), но они не только не привносят чего-либо теоретического «свежего», концептуально нового, а зачастую и не содержат теоретических основ (базовых концепций) классического BPM, хотя бы в объеме ARIS четверть вековой давности (конца 90-х).

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

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

Примеры формулировок требований в соответствии с руководством по написанию требований от INCOSE

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

Метрика CLV/CAC – это метрика, которая вводит в заблуждение.

Ели коротко, то вывод о том, что метрика CLV/CAC вводит в заблуждение является прямым следствием, в том числе, и моей предыдущей статьи, которую можно посмотреть по ссылке:

Юнит-Экономика - главное о метрике CLV (Customer Lifetime Value)

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

CLV = NPVc = PVc - CAC , где

CLV – Customer Lifetime Value (пожизненная стоимость клиента);

NPVc – Чистая приведенная стоимость денежных потоков по клиенту;

PVc – Чистая приведенная стоимость операционных денежных потоков по клиенту;

САС – первоначальные затраты на привлечение клиента.

Не так давно у меня появился интерес узнать, какие вообще нынче есть подходы и отношения к Юнит тестированию. Сделано это было скорее в познавательных целях. Сравнив труды по популярности, я решил ознакомиться с книгой "Unit Testing: Principles, Practices, and Patterns (Vladimir Khorikov)". Я не ставлю своей задачей полностью рецензировать данный труд, но не могу не обратить внимание на некоторые тезисы данной книги, которые часто вижу и слышу и о которых хотелось бы поговорить.