Связанный SWOT-анализ

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

Что изменилось с изначального метода:

1. В середине не 4 сектора, а открытое поле
2. Жёлтые карточки связываются тэгами с карточками SWOTа
3. Карточки по SWOT отмечены номерами, чтобы к ним можно было ссылаться
4. Карточки по SWOT приоритизированы положением: кто выше, тот и приоритетней
5. Если карточка SWOT использована в стратегической ставке (желтая в центре), то отмечаем ее маркером. Например, жёлтая карточка может вобрать две силы, одну слабость и одну угрозу. Все их отмечаем как использованные +1 раз.
6. Жёлтые карточки отмечаем маркером, когда они перешли в Карту гипотез

Какие проблемы решены:

1. Видно какие карточки SWOT повлияли на создание желтой карточки. Реализована связь многие ко многим.
2. Видно есть ли влияние карточек SWOT на стратегические ставки
3. Есть связка с Картой гипотез
4. Визуализация приоритетов

Сссылка на шаблон https://app.holst.so/share/b/6d59cb73-35a5-4527-9d94-00781e542d40

Видеоурок о Карте гипотез. Исправление преждевременной конкретизации на примере

При создании Карты гипотез скорее всего вы столкнетесь с типовой проблемой, когда в гипотезе в «если» будет написана задача, а не принцип срабатывания.

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

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

Как обосновать работу над IT-архитектурой и техдолгом бизнесу?

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

Для просмотра в полном масштабе — скачайте pdf

Рисуйте Карту гипотез, когда вам требуется связать ваши задачи с бизнес-целью, чтобы получить бюджет и ресурсы! Причем это работает для любой сферы и вида деятельности. Даже для жены можно нарисовать карту, чтобы обосновать покупку новой удочки (но это неточно).

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

Фасилитация стратсессий с помощью Карты гипотез

Андрей Шапиро и Александр Бындю собрались, чтобы описать процесс фасилитации стратегической сессии с Картой гипотез. Результатом стала визуализация процесса с помощью Карты процесса-опыта.

Видеоурок о Карте гипотез. Разбор типовых ошибок в гипотезах

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

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

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

Видеоурок о Карте гипотез. «Потому что» не о субъекте

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

Я люблю клубнику со сливками, рыба любит червяка. Когда я иду на рыбалку, я беру не клубнику со сливками, а беру червяка.

Давайте посмотрим на Карту гипотез, которую создал один из участников моего тренинга:

Карта гипотез на бумажных стикерах

Есть эксперты по управлению проектами, которые рекомендуют работать не с электронными досками типа Миро, а с бумажными стикерами. Если вы проходили тренинги по Scrum, Kanban, User Story Mapping или, например, Event Storming, то скорее всего обучение строилось на бумажных стикерах. В повседневной практике тоже довольно много людей использует бумажные стикеры в качестве основного инструмента для записи карточек.

Видеоурок по Карте гипотез. Задача вместо цели

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

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

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

Видеоурок о Карте гипотез. «То» не о субъекте

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

Посмотрите на эту карту:

Видеоурок о Карте гипотез. Преждевременная конкретизация

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

Посмотрите на эту карту:

TrueTechDay 2023. Применение low-code платформ в энтерпрайзе

Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.

Я разобрал, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложил «лекарства», которые помогают нивелировать проблемы.

Мастер-класс по Карте гипотез в Омске на IT-субботнике

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

Сообщение в группе IT-субботника с этим видео.

Бизнес-гибкость через микросервисы

Почему микросервисы помогут вам ускорить поставку бизнес-ценности

История появления микросервисов

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

Стачка 2023. Карта гипотез как метод стратегического планирования

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

Где и как применять low-code платформы

Разговоры о программировании без программистов идут постоянно. За последние 14 лет моей работы в IT идёт уже вторая волна любви к low-code решениям. Если вы дольше наблюдаете IT-рынок, то наверняка вспомните ещё пару подъёмов этой темы.

Не-программистов, которые создают бизнес-приложения в визуальных редакторах, назвали Citizen Integrator или Citizen Developer. Слоганы продавцов этой темы сводятся к следующему:

...with no-code/low-code platforms, anyone can build applications without software expertise, significantly faster, and at a fraction of the cost.

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

От микросервисного монолита к оркестратору

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

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

Эволюция управления зависимостями в коде

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

Dapper + QueryObject, как замена ORM

Не так давно я утверждал, что нужно использовать высокоуровневую ORM и даже делал опрос на эту тему. Как показал опрос, не многие пишут SQL-запросы руками.

Проблематика

Для работы с типовыми проектами действительно не надо углубляться в вопросы специфики SQL. Но сейчас я веду проект, где без этого просто не обойтись. Речь про базы данных по 700ГБ и требования к отклику на UI менее 1 секунды. При этом происходит много разных расчетов, строятся графики и т.п.

Для начала я по привычке использовал NHibernate. Уже через пару итераций оказалось, что эта ORM мне не подойдет (не говоря уже про EntityFramework) по следующим причинам:

• Скорость: создание сессии, маппинг и другие сопутствующие вещи отнимали до 200 мс. В моем случае это 20% времени, которое тратилось впустую;
• Гибкость запросов: сначала я писал запросы на Linq, потом понял, что трудно сделать хитрые запросы и добавлять хинты через высокоуровневые интерфейсы типа Linq, QueryOver или Criteria. Из всех возможностей NHibernate я начал использовать только функцию ExecuteSql, но скорость маппинга была слишком низкой;
• Утечки памяти: увы, но в NHibernate есть утечки памяти. Когда в вашей системе делается много запросов, это становится критичным. Сервисы через 20-30 часов работы падали с OutOfMemoryException и MemProfiler указал на NHibernate;
• Много чтения, мало записи: в проекте мне надо считывать очень много данных, получается такой cRRRRud, поэтому UoW от NHibernate оказался тоже не нужен.

Заменяем QueryFactory на бестелесный IQueryFactory

В статье Проблемный шаблон Repository и судя по комментариям многим не понравилась та часть, где объекты *Query скрываются за IQueryFactory. С первого взгляда кажется, что QueryFactory превращается в очередной god-object.

Дополнение к LSP

Прежде, чем прочитать дополнение LSP, изучите и попробуйте применить Принцип замещения Лисков (Liskov Substitution Principle).

---

Недавно у меня состоялся разговор с опытным программистом, который разбирался, как программирование по контракту связано с LSP. В примере статьи я использовал интерфейс IList, создал объект DoubleList и унаследовал DoubleList от IList. Дальше, при каждом использовании DoubleList в проекте будет происходить нарушение LSP. Это можно сразу понять, если обратить внимание на контракт интерфейса IList.