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

Десять лет назад я писал пару статей - Как загрузить последний Office с сайта Microsoft без всякого App-V / Хабр (habr.com) и Как загрузить Microsoft Office 16 с сайта Microsoft / Хабр (habr.com), при помощи на тот момент еще мало кому известным Office Deployment Tool.

Время бежит стремительно, за Office 2016 выходит Office 2019, Office 2021, и вот сейчас подошло время для Office 2024. Что ж, посмотрим, что поменялось в плане загрузки, установки и активации продукта за десять лет.

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

Microsoft давно перешел на систему распространения продуктов семейства Office по разным, так называемым, "каналам" (channels), в зависимости от того как часто вы хотите получать нововведения и обновления.

Ключевым отличием в текущей загрузке и установке Office от того, что было актуально во времена Office 2016, является то, что вы должны определить, каким каналом распространения вы собираетесь пользоваться, - то есть с какого канала собираетесь устанвливать сам продукт. Тем, кто хотел бы подробно изучить разные каналы распространения я предложу почитать первоисточник - Обновления Office - Office release notes | Microsoft Learn. Остальным кратко резюмирую - Microsoft сейчас предпочитает всем продать подписку на Microsoft 365 (то, что ранее называлось Office 365), с регулярно обновляемыми возможностями в течении так называемой Современной политики жизненного цикла. По этой же современной политике распространяется пользовательские (коробочные, ретейл) версии Office 2021. Office 2021, например, поддерживается лишь до 13 октября 2026. А более старые версии следуют, так называемой политике фиксированного жизненного цикла, в рамках которой Office 2016 и Office 2019 поддерживаются лишь до 14 октября 2025. В целом, они не перестанут работать после, однако, перестанут обновляться. И у тех из вас, кто пользуется почтовыми сервисами на базе Microsoft Outlook.com или Office365, а возможно и пользователям Microsoft Exchange, с обновлениями выпущенными после 14 октября 2025 уже пора призадуматься об обновлении.

Я люблю когда все просто и понятно (оригинальный текст картинки)

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

Слой «орг-стурктура» в пирамидке компании иногда рисуют выше процессов, а иногда ниже (процесс-центричный взгляд на компанию), но это всегда важный элемент «Архитектуры» (Enterprise Architecture) любого предприятия.

Часто говорят, что процессная и функциональная орг-структура – это условность и в чистом виде таковых не бывает. Ниже - попытка показать «чистые» конфигурации и четкую логику их идентификации (классификации), т.е. раскрыть содержание (идею, формулу) соответствующего орг-концепта и его противопоставление другому.

История орг-диаграмм начинается с МакКаллума (1855), принципы изложены Файолем (14 принципов менеджмента, 1916), Вебером (концепция рациональной бюрократии) и другими (как минимум пол сотни). В интернете лежат сотни статей по теме с разной классификацией орг-структур. Более того, не нашел даже сопоставлений типов из одной классификации с другой (например, Минцберга).

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

Привет! Меня зовут Настя, я старший системный аналитик в X5 Tech. Я рисую sequence-диаграммы каждый день на протяжении четырёх лет. За это время я прошла все круги ада по Данте, то есть попробовала разные инструменты для рисования этих самых диаграмм. Пока не встретила его – PlantUML. 

Что удивительно, инструмент довольно не новый, но тем не менее лучше него я пока не встречала. А ещё удивительно, что он не особо популярный. Когда мы запустили в управлении системного анализа первый воркшоп по PlantUML, за 3 минуты после анонса пришли 12 заявок от аналитиков разных грейдов – от Junior до Lead. 

В процессе подготовки материалов к воркшопу мы искали статьи и литературу, которые помогли бы дополнительно изучить sequence-диаграммы в PlantUML. Ничего интересного мы не нашли. 

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

Поэтому и появилась эта статья. 

Седьмая версия UUID (Universally Unique Identifier Version 7, UUID Version 7, UUIDv7) является модифицированной и стандартизованной версией ULID. Проект стандарта (далее стандарт) находится в ожидании окончательной проверки редактором. Но уже имеется большое количество реализаций UUIDv7, применяемых в действующих информационных системах. В интернете доступно большое количество информации по ключевому слову UUIDv7.

Я работаю техническим писателем в компании documentat.io. Мы занимаемся заказной разработкой технической документации, в том числе на английском языке. Иногда я дорабатываю уже существующие документы или спецификации к API на английском. Как правило, такие документы написаны русскоязычными разработчиками, которые неплохо владеют английским. И всё же они часто допускают характерные грамматические, пунктуационные и стилистические ошибки.

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

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

Мой первый on-call выдался нелегким. Недели тренингов и обучения не подготовили меня к тому что придется бегать по Slack каналам различных команд и искать того, кто может что либо знать о какой-то из частей системы. Оказалось что многие страницы в корпоративной Wiki уже не обновлялись несколько лет. Команды хранили свою документацию кто где хотел: кто в Wiki, кто в Google Docs, кто в GitHub и т.д. Наш on-call был не идеален: 2 человека выходили на дежурство 24/7. Один был ответственен за всю инфраструктуру (MySql, Cassandra, Kafka, ElasticSearch, Nomad и т.д.), второй же был Developer on-call и отвечал за все микросервисы и различные легаси системы, что в сумме давало около 300 различных сервисов от 7 команд на самых различных стеках и фреймворках (Java, Scala, Node, Go). Но что меня больше всего раздражало - так это невозможность быстро оценить на высшем уровне как проходит и обрабатывается запрос от пользователя. Диаграммы для разных бизнес частей точно также были либо устаревшими, либо без прилегающей документации, либо для какой-то бизнес логики не было ничего. И вот тогда мне пришла идея, что было бы неплохо иметь диаграммы, в которых можно не только нажать на любой элемент и добыть о нем более детальную информацию, но также получить ссылки на другие диаграммы и динамически их подгружать. Мне хотелось иметь возможность быстро разобраться в неизвестной распределенной системе, не переключаясь между диаграммой и документацией в Google Docs или Wiki. Именно так я начал работать над проектом Schem.io.

Предупреждение: в статье содержится большое количество GIF-изображений.

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

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

Улучшение Том и Джерри из 480p в 1440p

С чего всё началось? Как-то я решил в третий раз с детства пересмотреть всю оригинальную коллекцию "Том и Джерри", но я, в отличие от маленького ребёнка, не потребляю любой контент вне зависимости от его качества. И вот я собрался посмотреть самую доступную версию, а там вот это цветошоу с постоянными царапинами на всём экране.

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

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

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

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

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

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

Наверняка у многих бизнес-аналитиков есть цель использовать особые артефакты: Impact Map, CJM (Customer Journey Map), USM (User Story Map). Особые, т. к. не так часто они встречаются в бизнес-требованиях, и даже бывалый аналитик может с непривычки растеряться, если не создаёт их каждый день. 

Меня зовут Ирина, я ведущий бизнес-аналитик с более чем пятилетним опытом. Сейчас работаю в X5 Tech в направлении “Цепочки поставок”.

В статье описываю общие принципы построения Impact Map, CJM и USM и вариации их использования не только на примере своих рабочих кейсов, но и на бытовых примерах (буквально на жареной картошке и строительстве дома). Для опытных специалистов разобранные примеры пополнят копилку насмотренности. А для новичков в бизнес-анализе статья будет полезна с точки зрения постижения азов.

Изучение логических ошибок помогает в развитии критического мышления, необходимого во всех сферах жизни. School of Thought проделала отличную работу, описав 24 наиболее распространенные логические ошибки.

Почти под каждым моим постом на Хабре восхищенные читатели пишут мне доброжелательные комментарии вроде этого:

Автору с таким перепутанным мировоззрением светит только психиатрическая палата или монастырь (первое предпочтительнее — там есть лечение и хоть какие‑то перспективы)

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

У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).

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

Данная статья - перевод с английского языка итоговой сводки по написанию требований.

"Отдайте этот функционал в другую системы - он относится к ним" - ворчал мой собеседник. Ему с пылом отвечали: "Так быть не должно. Мы сами должны его сделать!" Спор грозил затянуться до вечера. Ни одна из сторон не могла привести ни одного настоящего аргумента, почему новый функционал нужно поместить в ту или иную автоматизированную систему.

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

Но методика на самом деле есть, и весьма неплохая. Называется она Предметно Ориентированным Дизайном (Domain Driven Design, DDD). С помощью DDD деление большой системы на (микро)сервисы становится простым и понятным.