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

Изложенное ниже – очевидно большинству директоров по развитию партнерских сетей и channel sales, но, часто, совершенно не известно внутренним заказчикам этого самого развития. Пишу на примере своего опыта на рынке b2b IT, но подобная сегментация, в целом, применима и на других рынках и в других ситуациях.

Почему вообще важна сегментация партнеров?

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

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

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

Авторы: Veilosophy, глава проекта Opensophy, и Аносов Роман, директор по маркетингу.

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

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

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

О том, как архивисты и программисты десятилетиями искали выход из этой ситуации, и как цифра меняет основы архивного дела рассказывает германский архивист Кристиан Кайтель. С его разрешения (и благословения издательства) мы публикуем отрывок из его книги «Двенадцать путей в архив. Контуры открытого и прикладного архивоведения».

Keitel C. Zwölf Wege ins Archiv. Umrisse einer offenen und praktischen Archivwissenschaft. Stuttgart: Franz-Steiner-Verlag, 2018. S. 188-202. Перевел Никита Ломакин (телеграм-канал Архивный гик), редактировала Анастасия Тарасова.

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

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

Привет Хабр!

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

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

По данным GitHub, количество открытых библиотек растёт экспоненциально. Только в экосистеме npm (JavaScript) насчитывается более 2 миллионов пакетов. При этом:

А вы всегда пьёте коньяк на завтрак или только по выходным?

Привет всем, я – Соня, IT HRD. Начинала как QA инженер. Люблю tech и инженеров за то, что помимо работы тут всегда узнаёшь разные крутые понятия и термины полезные не только для работы но и для жизни. За 20 лет работы накопилось много продуктово-инженерных жаргонизмов, пратик, законов и принципов, которые я была бы рада узнать пораньше. Можно прям в старших классах школы вместо ОБЖ.Ниже — мои любимые. Добавляйте в комменты свои.

1. Ложная дихотомия
Ложная дилемма, чёрно-белое мышление — это логическая ошибка и манипулятивная тактика, при которой из множества вариантов предлагаются только два (обычно крайних), игнорируя промежуточные или иные альтернативы. Этот приём сужает выбор, вынуждая принять одну сторону, часто ложно представляя одну из альтернатив как приемлемую, а другую — как неприемлемую. Мир не чёрно-белый. Наш коньяк с этой полки.

2. Бритва Оккама
Методологический принцип: при наличии нескольких объяснений одного и того же явления нужно выбирать самое простое. Не следует множить сущности, добавлять лишние предположения без необходимости. Не надо усложнять. Оккам, кстати, — английский монах-философ. Считается одним из отцов современной эпистемологии и современной философии в целом, а также одним из величайших логиков всех времён.

3. Игра с ненулевой суммой
Ситуация в теории игр, где выигрыш одного участника не обязательно означает равный по модулю проигрыш другого. Сумма результатов (выигрышей и проигрышей) может быть больше или меньше нуля, что позволяет сторонам получить взаимную выгоду (win-win) или совместно проиграть. В играх с нулевой суммой выигрыш одного игрока всегда равен проигрышу другого. Шахматы или шашки: если один победил (+1), второй обязательно проиграл (-1). Сумма: 1 + (-1) = 0.

Позиция CTO (Chief Technology Officer, технический директор) появилась не вместе с интернетом, а задолго до этого – еще в эпоху больших корпораций и лабораторий. Ещё в 1950-х годах в США и Великобритании крупные компании создавали удалённые R&D‑центры и поняли, что там нужны не просто учёные, а техподкованные руководители, эдакие техножрецы, которые могли бы объединять науку и бизнес . К концу 1980-х технологии стали настолько важны, что «технических директоров» начали официально назначать в крупных фирмах, ориентируя их уже не только на внутреннюю лабораторию, а на развитие бизнеса в целом . Веяние новой роли быстро перекинулось и в CIS (после 2000-х главным образом), когда ИТ‑компании и стартапы стали брать на себя модели западных корпораций. Так, например, в Яндексе с основания в 2000 году одним из CTO стал сооснователь Илья Сегалович – из первых сигнальных звоночков, что даже в России формируется такой управленческий пост.

Интересно, что сами исследователи подчеркивали: изначально CTO не был просто «главным инженером». Когда корпорации 1980–90-х годов в США «переводили» директоров R&D в CTO, выяснялось, что их навыки оказываются слишком узкими. Классический научный руководитель не годился в нового тех­директора, потому что задачи CTO кардинально отличаются от задач заведующего лабораторией. Пост CTO сформулировали как задачу перевести технические возможности в стратегические бизнес-решения. Проще говоря, CTO — это уже не просто суперпрограммист с магистром, а гибрид менеджера и технаря, который одновременно понимает код и умеет объяснить его влиянию на маркетинг. Как пишет компания Splunk, CTO — это топ‑менеджер, «балансирующий техническую и бизнес‑стороны, чтобы стимулировать инновации и рост».

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

В этой статье мы рассмотрим основные категории инструментов безопасности приложений: DAST (Dynamic Application Security Testing), SAST (Static Application Security Testing), SCA (Software Composition Analysis) и IAST/RASP (Interactive/Runtime Application Security Protection). Мы разберем их назначение, преимущества и недостатки, а также предоставим список бесплатных инструментов, которые можно интегрировать в вашу инфраструктуру разработки.

Привет, Хабр! С наступившим!

После небольшого перерыва на связи вновь Татьяна Маркина, ведущий системный аналитик в Positive Technologies. В дополнение к этой роли я преподаю системный анализ на старших курсах ИТМО, а также в китайском университете города Ханьчжоу — студенты с неуемным энтузиазмом погружаются в разбор сложных систем, и я стараюсь передать им не только сухую теорию, но и живые уроки из реальных проектов. В этот раз хочу поговорить о терминах, почему это важно, особенно в работе системного аналитика. Почему термины — это не просто слова на бумаге, а мощный инструмент нашей профессии, способный определять успех проектов и карьеры. Почему проблема с терминами настолько актуальная для специалистов нашего круга, что я готова душнить на эту тему.

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

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

              Небольшой дисклеймер: речь в статье, в основном, про родной для меня рынок B2B IT. Содержание статьи отражает как личный опыт, так и мнения многих коллег. Под ролями BizDev подразумеваются: BDM, BDO, менеджер по развитию бизнеса, руководитель направления по развитию бизнеса, руководитель группы/отдела/департамента развития бизнеса и т.д.. Под Sale – роли, связанные с продажами и сопровождением клиентов и подразумевающие обязательное наличие функционала управления продажами/пайплайном/воронкой, регулярных встреч с заказчиками и развития взаимоотношений – т.е. менеджер по продажам, account manager, solution sale, менеджер по развитию продаж, руководитель направления по развитию продаж, руководитель группы/отдела/департамента продаж и т.д. Роли, предполагающие взаимодействие с заказчиками строго в рамках ограниченного функционала, определенного скриптами/инструкциями – специалисты по холодным продажам, поддержке, активациям, сотрудники колл-центров и т.д. – находятся за пределами scope данной статьи.

За последние несколько месяцев, погрузившись в активности на рынке труда, я заметил следующую массовую ошибку в описаниях вакансий и дальнейших диалогах с представителями HR и бизнес‑заказчиками — пишут «нужен BizDev», и далее перечисляют стандартные требования к Sales‑роли. Часто подобное расхождение заметно уже на этапе изучения описания позиции, иногда — выявляется только в ходе разговоров, устного обсуждения требований и представлений руководства о том «что эта роль должна делать». А бывает, что подобные скрытые ожидания и представления нанимающей стороны становятся явными только уже в процессе трудовой деятельности. Это характерно для вакансий как на линейные позиции, так и на руководящие. Чаще — это ошибка непредумышленная, реже — сознательная. И очень укоренённая. А почему ошибка?

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

Если вы когда-нибудь пытались построить стабильный VPN поверх реального Интернета, то знаете: ключевая проблема не в криптографии и даже не в пропускной способности канала. Проблема — в том, как протокол ведёт себя, когда сеть начинает «качать».

Мы много лет экспериментировали с OpenVPN, WireGuard и разными вариациями UDP-туннелей. В хорошей сети → работают все. В плохой сети → перестают работать почти все. Поэтому когда в экосистеме QUIC появился MASQUE, мы решили проверить: а можно ли собрать VPN, который действительно переносит нестабильные условия?

Оказалось, что можно.

Всем привет, меня зовут Рома, я работаю во ВкусВилле, руковожу портфелем ИИ-проектов. Пишу про продукты и управление проектами у себя на канале: https://t.me/gde\_value. Сегодня расскажу, как спор между командами привел нас к пересмотру методов планирования рабочей недели. 

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

Недавно обсуждал это с тимлидом из Ozon. Мы крутились вокруг темы эффективного количества рабочих часов, и ближе к концу он вкинул фразу: «Ну, сорокачасовая неделя ведь не зря придумана; наверное, кто-то исследовал и доказал, что так эффективнее всего». Эта фраза зацепила. Она звучит как успокаивающий миф, как будто есть универсальная «магическая» цифра, и если не выходить за её пределы, то и продуктивность, и здоровье в порядке. Но внутренне я вижу другое: одни люди успевают сокрушительный объём за те же часы, в которых другие тонут в бесконечных переключениях и «шуме».

ИТ-отдел работает как часы: заявки обрабатываются за 2 часа, доступность услуг выше 99%, пользователи довольны. Но каждый месяц финансовый директор спрашивает, почему ИТ-бюджет растёт быстрее бизнеса.

ITSM-система помогла навести порядок в процессах, но не дала ответа на главный вопрос: сколько на самом деле стоит порядок и можно ли тратить меньше без потери качества?

Меня зовут Евгения Асоскова, я владелец продукта SimpleOne ITAM. Давайте поговорим о том, почему компаниям с внедрённой ITSM-системой целесообразно автоматизировать управление ИТ-активами и как это усилит возможности бизнеса.

Это началось со статьи «Алгебраические типы данных на самом деле не такие страшные». Мы знаем о типах‑суммах и типах‑произведениях. Но задумывались ли вы когда‑нибудь о том, откуда они получили такие имена, и как вообще были открыты они и их свойства? Я провел последнюю неделю в кроличьей норе истории, и я просто обязан поделиться тем, что я нашёл.

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

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

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

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

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