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

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

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

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

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

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

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

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

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

data Maybe a = Nothing | Just a

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

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

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

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

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

Программные теневые стеки могут обеспечить до 8 раз более быструю трассировку стека в Go рантайме по сравнению с раскруткой указателя фрейма, которое было реализовано в go1.21. Это не означает, что данная идея должна сразу же вырваться из лаборатории, но она предлагает интересный взгляд на потенциальное будущее трассировки стека с аппаратным ускорением через теневые стеки.

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

Получить лучшую, преданную ИТ-команду, можно только целенаправленно сконструировав ее.

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

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

Для начала, давайте придем к общему пониманию, что мы будем вкладывать в термин «Социальное сообщество», а также ее представление - «Социальная среда».

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

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

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

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

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

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

От читателя поста ожидается, что он на базовом уровне понимает Rust, обычные структуры данных, а также концептуально представляет, как выделяется память (в стеке и куче).

Дополнение (14.05.2024): Я учёл поступившую обратную связь и подчеркнул, какие идеи объективно плохи, прояснил некоторые отступления и удалил идею о imbl.

Чтобы было проще прослеживать этапы реализации и исследовать код, отсылаю вас к репозиторию, сопровождающему этот пост.

Хабр, привет!

Меня расстраивает несправедливость в мире IT: для новичков-разработчиков есть куча пошаговых инструкций, о там, как разработать API или мобильное приложение. Хочу немного уровнять баланс вселенной, поэтому я написал небольшой гайд для аналитиков для составления документации.

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

Всем привет!
Меня зовут Семен Бакумов. Последние несколько лет мне очень интересна тема Счастья в деятельности. Я считаю, что очень важно, чтобы человек в своей деятельности был Счастлив.

Если немного конкретизировать определение, то человек Счастлив в своей в деятельности, когда ему нравится то, что он делает, он получает удовольствие, питается от этого энергией, а не тратит её, выгорая… Когда он реализует свои сильные стороны и таланты.

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

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

Публикация носит теоретически-просветительский характер, практика применения будет изложена в следующих статьях.
Аннотация: В настоящей статье поднимается вопрос процессного управления жизненным циклом ИТ-предприятия c помощью методологии PDCA. Сравниваются ITIL v3 и COBIT 5, это получилось сделать благодаря "Циклу Деминга".

Важнейшая роль конкурентоспособности ИТ-предприятия отводится системе менеджмента качества (СМК). Это связано, прежде всего, с важностью предоставления качественной продукции или услуги в установленный договором, или любым другим регламентирующим документом. Соблюдение принципов: качественно и своевременно; характеризует предприятие как стабильное, что позволяет удерживать клиентов, таким образом, получая доступ к контролю некоторой ниши рынка или его сегмента. 

Процесс внедрения и использования СМК обуславливает необходимость применения методологии управления процессами, деятельностью предприятия. Одна из них PDCA (Plan – Do – Check – Act), разработанная Эдвардом Демингом, также называемая, «Цикл Деминга». По «Циклу Деминга» управление процессом состоит из четырёх шагов (Рис. 1):

1) Планировать (Plan) – это разработка целей системы и ее процессов, а также определение ресурсов, необходимых для достижения результатов в соответствии с требованиями потребителей и политикой организации, определение и рассмотрение рисков и возможностей;

2) Делать (Do) – выполнение того, что было запланировано;

3) Проверять (Check) – мониторинг и (там, где это применимо) измерение процессов, продукции и услуг в сравнении с политикой, целями, требованиями и запланированными действиями и сообщение о результатах;

Я считаю, что планирование — полезный навык. Это касается не только производственной, но и любой деятельности, в которой хочется достигать более быстрого и, главное, стабильного прогресса.

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

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

Сегодня в нашем кружке «оч.умелые клавиатурки» возврат блудных заметок домой. Долго пользовался платным Evernote, но оплатить его все труднее и дороже. Вернее даже так, сейчас я знаю всего один способ оплатить подписку через Билайн / МТС и Apple. Притом без оплаты подписки Evernote ужасен и порезан самым неприятным образом. Конечно есть ещё Notion, но кто знает как и когда он окуклиться как это случилось со временем с Evernote.

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

Веб-разработка часто требует реализации механизмов обновления контента на странице в реальном времени. Существуют различные сценарии, где это необходимо, например, отображение прогресса выполнения тяжелых задач на бекенде, обновление каких-либо часто меняющихся данных, будь то курсы валют или мониторинг какой-то активности, чаты, различные уведомления. Эти сценарии объединяет одна общая особенность: источник события необходимости обновления данных находится не на клиентской стороне, поэтому мы хотим получать события с бекенда. В данной статье мы рассмотрим четыре популярных подхода к реализации этой функциональности: WebSocket, Server-Sent Events (SSE), Long Polling и Short Polling.
Мы проанализируем каждый метод, выявим их плюсы, минусы и сложность реализации.

Сегодня мы попробуем разобраться и дать ответ на часто возникающий вопрос. 

Как правильно создавать задачи?

• сильно оптимизировали работу фреймворка и обогнали основных конкурентов в бенчмарках высокопроизводительных фреймворков;
• значительно упростили конфигурирование;
• обзавелись install, докер-образами, Yandex Cloud-образом и DEB-пакетами;
• обросли новой функциональностью, включая серверные мидлвари для HTTP, и YDB-драйвером;
• перешли на новую ежемесячную схему релизов и упростили версионирование.