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

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

Мы не можем и не хотим рисковать здоровьем наших докладчиков, участников и всех, кто помогает нам организовывать наши мероприятия. Поэтому мы приняли нелегкое решение отменить конференцию JEEConf в 2020 году. Этот год стал очень непростым для многих, и для нас в том числе, но мы надеемся, что переждем это время и все станет на свои места. И мы обязательно встретимся с вами в следующем году на JEEConf 2021!

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

Мы очень просим вас с пониманием отнестись к ситуации и готовы предложить несколько вариантов на выбор для участников конференции. Итак, есть несколько способов использования вашего билета на JEEConf 2020:

- «заморозить» билет и воспользоваться им для посещения другой нашей конференции (Selenium Camp или XP Days Ukraine) без доплат, как только снимут ограничения;

- перенести билет на конференцию JEEConf 2021;

- воспользоваться билетом без доплат для посещения одного их наших публичных тренингов, которые мы планируем начать проводить как только снимут ограничения;

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

Как это сделать? Просто напишите нам на электронный адрес, какой из способов вам удобен и мы в ближайшее время ответим вам.

Спасибо и до встречи!

#конференции #Java

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

Первый путь уже давно прорабатывается крупными игроками на рынке и даже начал показывать первые результаты. Это автоматизация типовых задач в разработке. Если есть понятная декомпозиция доменной модели на гранулярные сервисы (эта работа уж точно останется на людях), то дальше следует их разработка. И вот тут мы раз за разом делаем одно и то же: декларируем API, реализуем правила бизнес-логики работы с данными, вычитываем и записываем данные в хранилища, вызываем другие сервисы, генерируем события, пишем тесты на всех уровнях...

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

Описанный подход уже давно не мечты, а вполне реализуемая задача. За последний год было показано уже несколько прототипов от разных компаний. Да, пока они мало что могут. Да, пока решения ещё сырые. Но когда-то ровно такая же ситуация была в создании AI для игры в шахматы или Go...

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

Вместо этого предлагается сосредоточить куда большие усилия на продуктовом дизайне. И речь не о UI/UX дизайне, а о полном спектре уровней продуктового дизайна. В реализацию нужно запускать только то, в чем бизнес уверен и что точно принесёт задуманную ценность. Практика показывает, что такой подход позволяет сэкономить 50-90% усилий разработки и значительно ускорить получение конечной ценности. А это, в свою очередь существенно упрощает технические решения и радикально уменьшает потребность в таком большом количестве разработчиков.

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

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

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

Первая ловушка весьма очевидна и заключается в увеличении погрешности с увеличением оценки. Если задача кажется большой, сложной, непонятной или рискованной, то все эти показатели легко закладываются в оценку. И растёт разбежка между оптимистичной и пессимистичной оценкой. Как результат, мы можем видеть оценки 30-45 и они кажутся разумными с точки зрения относительной погрешности, но абсолютная погрешность очень большая. При этом, очень тяжело придти к единому командному мнению, поэтому многие команды просто берут пессимистичную оценку для надежности.

Вторая ловушка полностью противоположная. То есть, каждая задача разбивается на несколько маленьких, полностью понятных и простых подзадач, которые потом оцениваются. Такие задачи часто получают оценки 1-2 часа за счёт уровня гранулярности оценок. В результате, мы видим маленькую абсолютную разбежку всего в 1 час и не замечаем огромную относительную погрешность в 50%. Если просуммировать все оценки, то можно «потерять» до 50% всей скорости команды.

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

Что же делать? Об этом поговорим в следующем посте. :)

#оценки #планирование

Продолжим тему оценок и сегодня обсудим как бороться с проблемами, о которых я писал прошлый раз. Я не буду писать очевидные вещи о том, что оценки должны быть командными и максимально исключать якоринг с помощью таких техник как planning poker. Это само собой разумеется и является обязательным базисом.

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

Поэтому, данные критерии нужно максимально исключить из оценок. Задача должна быть полностью понятна исполнителям и не иметь видимых значимых рисков. Если в процессе обсуждения выяснилось, что непонимание либо подобные риски присутствуют, то необходимо уточнить, что нужно сделать для их устранения. Зачастую, помогают технические спайки или прототипы. Реже помогает более детализированный технический дизайн. Лучше проверять задачи ещё на уровне проведения PBR (aka груминг), но лучше поздно чем никогда.

Вторым важным моментом я бы назвал гранулярность задач. Мы увидели, что слишком мелкие или слишком крупные задачи приносят проблемы. Поэтому Капитан Очевидность подсказывает нам держаться среднего размера. Что это значит? На моем опыте, лучше всего работают задачи размером от 4 часов до 2 дней. Речь конечно об идеальных часах/днях в capacity-based планировании (ссылку на видео моего доклада на эту тему скоро опубликую). Если задача получилась мельче, то лучше не обьединить с соседней. Если крупнее, то декомпозировать. При таком размере задач также лучше ощущается прогресс команды в рамках спринта и растёт приятное ощущение от законченности работы.

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

Надеюсь, эти советы помогут вам с командными оценками!

#оценки #планирование

В предыдущем посте я обещал поделиться видео своего доклада про capacity-based планирование с февральской конференции Agile Magic 2020. Оно действительно уже доступно, ссылку можно найти ниже. Надеюсь в карантинном онлайн мире видео докладов вам ещё не наскучили и вы открыты к новым знаниям и опыту. :)

#Agile #планирование

Маленький пост «от кэпа» в период карантина и бесконечной череды онлайн встреч, наполненный болью. Очевидные советы, но при этом единицы им следуют... :(

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

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

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

3. Используйте онлайн инструменты для фасилитации встреч. Люди гораздо лучше воспринимают информацию визуально чем на слух. При этом, у вас остаётся отличный артефакт для продолжения работы и участников, желающих быстро получить представление о результатах встречи. Как минимум, это может быть mind map. Желательно использовать подготовленные шаблоны под конкретные типы встреч.

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

Эффективных вам встреч!

#митинги #эффективность

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

Мы со старшей дочкой начали использовать Kanban доску для ее ежедневных планов. В комплекте идёт набор карточек с разными активностями и несколько пустых, на которых можно писать маркером. Есть настоящий WIP лимит в 1 задачу на исполнение одновременно, чтобы убрать многозадачность и снизить переключение контекста. В конце дня можно перед сном сделать ревью выполненных пунктов плана и выдать медальку в случае успеха. За N медалек можно выдавать что-то ценное для ребёнка.

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

Ссылка на проект со всеми деталями ниже. ⬇️

Давненько я ничего не писал в канал. Участие в двух масштабных трансформациях не оставляло времени для «творчества». :) Отпуск позволил слегка перезагрузиться. Так что буду стараться снова наладить регулярные публикации.

Сегодня в очередной раз поговорим о микросервисной архитектуре. Недавно пролетала горячая новость о том, что мол Uber разочаровался в микросервисах и планирует их собирать обратно в монолиты. По факту же это очередная кривая интерпретация заголовков статей. На деле Uber дошёл таки до группировки микросервисов по доменам и уровням. Очень странно, что дотянули без этой концепции аж до 2000+ микросервисов. Мы обычно на меньшем масштабе сразу закладываем данную концепцию в архитектуру.

Данный подход очень помогает структурировать API и архитектуру вокруг доменных областей для тех компаний, где доменов несколько или же весьма масштабные. Группировка по уровням позволяет разделить клиенто-ориентированные сервисы и внутренние (части серверной платформы). Также, значительно упрощается владение сервисами в рамках одного домена.

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

В общем, рекомендую почитать самим и не вестись на громкие заголовки. :)

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

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

2. Вторым обязательным фактором успеха является сильный лидер-руководитель во главе трансформации, искренне верящий в необходимость трансформации. Культура большинства компаний построена на базе ценностей и принципов ее руководителей. И эта культура сожрет любую трансформацию, даже глазом не моргнув, если та не возглавляется с самого верха. Чем больше компания, тем больше будет общий поток сопротивления системы изменениям. Временами он будет приводить к очень сложному выбору: откатить изменения и вернуться к «стабильному прошлому» или идти вперёд, не смотря на временные жертвы. И этот выбор можно сделать только с самого верха. Я не верю в формат трансформации «локальная революция» (мы в одном месте поменяем и покажем как круто получилось). Даже при явной победе в одном месте, результат получается очень хрупким и легко убивается или нивелируется культурой при первом удобном случае.

3. Следующим пунктом идут профессионалы-лидеры на всех уровнях для превращения стратегии в тактику. Изменения - очень трудоемкая задача и работа с сопротивлением системы может отнимать практически все время. Невозможно делать ее одновременно на уровне стратегии и тактики. Лидер трансформации должен как ледокол прокладывать новый путь, но позади кто-то должен развивать успех и продолжать строить новую реальность. Поэтому очень важно определить внутри компании или нанять на рынке тех, кто может на ежедневном базисе решать тактические задачи трансформации в рамках общей стратегии. Без этих локальных лидеров на местах система будет норовить вернуться в исходное состояние как только внимание с конкретного фронта ослабится. Тут очень важно не ошибиться в выборе. Это должны быть люди, которые так же сильно как и лидер трансформации, верят в неё, при этом являются профессионалами в своей тактической зоне. В зависимости от зоны, это могут быть инфраструктурные инженеры, Agile коучи, технические менеджеры, продукт оунеры и т.д. На эти роли часто нанимают консультантов-практиков.

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

Про этапы трансформации достаточно хорошо рассказывал в своём докладе Антон Зотин. Правда там речь идёт только об одном из типов - Agile трансформации. Но этапы, их особенности и большую часть выводов можно смело перенести на любой тип трансформации. Я приложил ссылку на статью по мотивам данного доклада.

Удачных вам трансформаций!

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

#инфраструктура #kubernetes #конференция

Давненько не анонсировал никаких мероприятий. А тут подкинули анонс бесплатного DevSecOps митапа. Тематика отличная, свежие организаторы, интересные темы докладов и спикеры. В общем, если у вас нет планов на завтрашний вечер, то у меня есть для вас вариант. :)

Вот лайн-ап докладчиков:

1. Darko Meszaros, Developer Advocate, Amazon Web Services.
2. Nikhil Barthwal, Tech Lead, Google Cloud Platform.
3. Mohamed Labouardy, DevSecOps Evangelist, Senior Software Engineer/DevOps, Foxintelligence.
4. Dmytro Vedetskyi, Lead DevOps, Intellias.

Модератор - Максим Сальников, Developer Engagement Lead, Microsoft.

Начало 24 сентября в 19:00. Ссылка на регистрацию под постом.

#devops #конференции

С этим переходом в онлайн режим работы после объявления карантина и отменой большинства живых конференций, я уже давненько нигде не выступал. А на завтра меня пригласил на посиделки в прямом эфире Сергей Немчинский. Будем говорить на разные архитектурные темы и не только. Если у вас еще нет планов на завтрашний вечер, то присоединяйтесь к онлайн трансляции 8 октября в 18:00. Услышимся в эфире!

Кстати, я совсем забыл сделать анонс интересных конференций на осень. А прямо сегодня проходит совершенно БЕСПЛАТНО в онлайн формате конференция DevOps Stage:

Track A: https://youtu.be/jDFNGpxbGA4
Track B: https://youtu.be/zPCTMH8wrUs
Track C: https://youtu.be/Pu4-T1zGdsY

Узнать расписание выступлений и описание докладов можно на сайте конференции.

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

Поэтому, я для себя сформировал четкие критерии для выбора онлайн мероприятий:

- бесплатное или условно платное участие (до $50 за билет);
- действительно крутой уникальный контент, которого не найти на просторах интернета;
- серьезный вклад организаторов в создание уникальной онлайн площадки, чтобы хоть как-то компенсировать отсутствие живого общения.

Итак, перейдем к списку рекомендаций...

Буквально вчера, 9 октября, прошла конфренция DevOps Stage 2020, участие в которой было БЕСПЛАТНЫМ. Кто пропустил, ждите записей.

6-7 ноября состоится Devoxx Ukraine 2020. Так как остальные Devoxx и большую часть других Java конференций похоже перенесли на 2021 год, то придется довольствоваться малым. Но участие БЕСПЛАТНОЕ, поэтому точно можно что-то интересное в программе для себя найти.

17-20 ноября пройдет KubeCon + CloudNativeCon North America 2020. На эту конференцию собираются все, кто имеет хоть какое-то отношение к миру Cloud Native и Kubernetes. Лучше материала из первых рук на данную тематику не найти. Участие условно платное, билеты стартуют от $50.

25-28 ноября пройдет конференция Joker. Ребята неплохо вложились в онлайн платформу, в программе будет много интересного в разных форматах, но для меня очень странно выглядит ценовое предложение в виде $200 за билет. Имеет смысл разве что рассмотреть билет на весь сезон конференций и посетить заодно Devoops (2-5 декабря) и Heisenbug (4-7 ноября).

Вот такой план на осень. Из плюсов, можно отдохнуть от выступлений и накопить новых интересных тем. :)

#конференции #java #инфраструктура #devops #kubernetes

Добавлю ещё одно мероприятие на осень для интересующихся DevOps направлением. 12 ноября пройдёт БЕСПЛАТНАЯ онлайн конференция ALL DAY DEVOPS 2020. 180 докладов на любой вкус, как по культуре так и по технологиям.

Как известно, энтерпрайз разработка (особенно ее аутсорсная составляющая) славится жесткими дедлайнами и овертаймами на пути к ним. Об этом уже много сказано в плане выгорания команд, ухудшения качества и других очевидных последствий. Я хотел бы затронуть ещё одну интересную сторону данной проблемы. Жесткие дедлайна и постоянная гонка делают нас тупее.

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

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

Хорошо ли это для продукта? Нет конечно! С большой долей вероятности, на выходе продукт получится ГОВНОМ. Зато вовремя, с соблюдением дедлайнов и радостью менеджеров!

В современной разработке давно придуманы альтернативные подходы. Нужно делать фокус на управление скоупом, а не датами дедлайнов, и куда больше времени уделять продуктовому дизайну. Делать не больше фичей, а самые нужные фичи, крутые фичи, используемые фичи. Очень хочется вложиться в дедлайн? Убираем или упрощаем часть скоупа, реализуем гипотезы вместо законченной функциональности, проверяем их и меняем направление в зависимости от результатов. Вот это называется продуктовой разработкой, а не «мы расписали релизы продукта на ближайший год и теперь работаем по Scrum». Такие «фича фабрики» сжигают ещё больше денег чем майнинг криптовалют...

Когда меня просят охарактеризовать современную Agile разработку, я всегда вспоминаю это видео. :) https://youtu.be/SDWqwlsGJCQ

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

Я в этом году хотел сделать доклад на тему ролевых дисфункций в компаниях. Но так как коронавирус поставил крест на офлайн конференциях, то поделюсь основными тезисами в наборе постов. Мне кажется, что именно ролевые дисфункции являются одной из ТОП причин возникновения проблем в компаниях и командах.

Давайте начнём с простого. Я разделяю уровни работы в компании на 3: стратегический, тактический и операционный. Данное разделение существует ещё много где, включая армию, госуправление и т.д. Очевидно, что каждый следующий уровень должен драйвиться предыдущим и быть с ним очень тесно связанным. То есть, стратегия реализуется тактикой, а тактика - операционной работой.

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

Почему происходят такие ситуации? Зачастую, потому что конкретные должности и роли в компании сосредоточены только на одном уровне и не участвуют вообще в других. То есть, такие супер-стратеги руководители, которые без понятия как реализуются их стратегии на тактическом уровне. Или тактики, совершенно оторванные от операционки. Тут все могут вспомнить PowerPoint-архитекторов, которые рисуют абстракции, но ни разу не попробовали сесть и поучаствовать в их практической реализации. Ну и конечно же, цепочки менеджеров со своими KPI...

В следующем посте мы продолжим и поговорим о разных конкретных ролях, паттернах и анти-паттернах на основании этой модели. А пока можете высказать своё мнение в комментариях. :)