Менти желательно оставлять не с абстрактными размышлениями на тему его будущего, а с визуальным стратегическим планом. Карта гипотез визуализирует стратегию, помогает избавиться от сверхценных идей, мешающих жить.
Андрей Морозов и Александр Бындю на канале Токсичный манагер обсудили всё, что связано с эффективной стратегией: стратегия редко востребована, беда современных стратсессий, выработка стратегии на примере спортивного тренера, важно оценивать предлагаемые цели и метрики на реализуемость, люди мыслят задачами и многое другое.
Если вы хотите расти в стратегическом управлении, то изучите руководство фасилитатора, который использует Карту гипотез. Это человек, который умеет проводить стратсессию так, что после неё появляется стратегия и создаётся стратегический план, а не просто цели с календарным планом задач.
Как проводится такая сессия фасилитации? Как к ней подготовиться самому? Как подготовить участников? Четкий план действий смотрите на этом видео и получившейся схеме.
Бесплатный вебинар для аналитиков и продактов с участием Александра Бындю - создателя интересной техники анализа «Карта гипотез». Александр рассказал об этой методике и вместе с участниками построил карты гипотез по их кейсам.
Если в компании нет понятного всем и принятого стратегического плана, то возникают вот такие типичные проблемы:
В докладе расскажу, как выйти на уровень стратегии с помощью Карты гипотез. Это позволяет решить все вышеперечисленные проблемы и разгоняет внутри компании маховик инноваций.
Расскажу о новом методе стратегического планирования и покажу на примерах, как с помощью него описывать следующий шаг развития. Это метод помогает определять причинно-следственные связи между бизнес-целями, задачами и гипотезам.
Вышло очень важное для меня интервью, где я впервые подробно рассказал:
Интервью проводил Александр Поломодов – это технический директор Тинькофф в юните «Клиентские интерфейсы, маркетинг и вовлечение». Описание нашей беседы он разместил у себя в канале Книжный клуб.
В интервью с Дмитрием Голубовским обсудили, как ИТ обслуживает бизнес-модель, эволюцию от проектной разработки к продуктовой, тему формирования и управления командами, а также поговорили о притоке в индустрию специалистов без технического бэкграунда и Low Code.
В интервью с Анной обменялись мыслями на темы, которые для нас обоих оказались важны:
Смотрите запись мастер-класса по созданию Карты гипотез. На видео разобраны основные элементы метода, создано несколько карт по запросу аудитории. Также были раскрыты секреты и нюансы создания стратегического плана с помощью Карты гипотез.
Вышло моё интервью на канале «Teamlead. С места в career». Это канал для руководителей в сфере IT. Он помогает погрузиться в роль руководителя, увеличить свой управленческий масштаб и узнать какие есть трендовые инструменты.
В интервью мы рассматривали один из инструментов целеполагания – Карта гипотез. Ещё мы обсудили, что важно для карьерного роста, как появляются цели бизнеса, как ставить цели на уровне команды и что способствует их достижению.
В этой дискуссии мы поговорим о концепции антихрупкости в ИТ, о том, зачем разработчикам понимать бизнес-процессы и архитектуру своего продукта, как строить отношения в команде, с тимлидами и заказчиками и что нужно делать, чтобы вас не уволили и повысили зарплату.
На коференции Стачка 2023 обсудили применимость low-code решений для решения бизнес-задач. Мои тезисы можно прочитать в статье Применение low-code платформ в энтерпрайзе.
Расскажу о новом методе стратегического планирования. Много лет я смотрел, как другие делают Impact Map, сам его делал для своих проектов и проектов заказчиков. В итоге, пересобрал этот метод в новый, чтобы можно было точнее определять причинно-следственные связи между бизнес-целями, задачами и гипотезами достижения целей. Назвал этот метод “Карта гипотез”.
Если на переменах вы больше зарабатываете, чем теряете, вам будет хотеться перемен. В мире, где всё быстро меняется, где конкуренция возвышает одни компании и уничтожает другие, нужно выстраивать работу так, чтобы перемены приносили пользу, а не разрушения.
В докладе поразмышляем как выстроить процессы работы, архитектуру IT-систем и взаимодействия людей, чтобы придать IT-продуктам свойства антихрупкости.
Интервью провел Алексей Пименов из компании Neogenda в рамках рубрики «Нетипичные вопросы профессионалам».
Как IT компания эффективно работает без проджект-менеджеров? Чего хотят заказчики? Сколько стоит разработка ПО? Про антихрупкость в IT, продажу разработчиков - об этом и не только в видео.
Ссылки, которые упоминаются в видео:
Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.
Я разобрал, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложил «лекарства», которые помогают нивелировать проблемы.
Читайте по ссылке статью с подробным раскрытием этой темы.
Алексей Пикулев пригласил меня в качестве эксперта на мастер-класс по Impact Mapping. Онлайн-встреча прошла в рамках его сообщества Scrum Mastery Club.
Я уже много лет работаю с этим инструментом, подробно описывал его в своей книге Антихрупкость в IT, поэтому мне было чем поделиться с участниками встречи.
Читайте по ссылке как создается Impact Map.
В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?
Я опишу факторы, которые затягивают процесс перехода на микросервисы и делают его сильно дороже, чем ожидалось вначале. Вы получите чеклист для оценки этих факторов и будете более реалистично считать бюджет перехода.
InnerSourcing и микросервисы дополняют друг друга и одновременно повышают порог вхождения новичков в эту тему. Я расскажу с точки зрения IT-архитектора и организатора процесса разработки:
Продуктовый подход описан в книгах давно, но только недавно крупные российские компании начали на него переходить.
При новом подходе IT-продукт создается внутренней кросс-функциональной командой, а процесс основывается на метриках, “гибкой” культуре, машинном обучении и постоянных поставках новых фич. Это подход позволяет бизнесу не просто держаться на плаву, а создавать инструменты для конкурентной борьбы за доли рынка.
Обсудим почему компании больше не хотят писать ТЗ для проекта, разбивать ТЗ на части, раздавать отделам и аутсорсерам. Расскажу, как создаются продуктовые команды в аусторсе, какие качества отличают крутых Product Owner'ов от посредственных и какие инструменты и подходы стоит применять уже сейчас.
Статистика популярности языков программирования:
Отчет IT Market Clock for Programming Languages: жизненный цикл языков
Идея микросервисов звучит красиво, пока вы не создадите десятки и сотни микросервисов. Раньше приложение запускалось на одном мощном сервере и работало на одной СУБД, а теперь надо управлять сотней микросервисов, которые связаны между собой паутиной API вызовов и шин сообщений. Разработка, выпуск релизов, тестирование, соблюдение версионности превратятся в кошмар, если не использовать правильные подходы и инструменты.
В докладе будут показаны инструменты и принципы, которые помогают облегчить создание и управление микросервисной архитектурой. Рассмотрим пример переезда конкурса «Мисс Россия» на Azure, где инфраструктура развернута кликами мышкой на чистом PaaS, а за счет изменения архитектуры сайт выдерживает в 40 раз больше посетителей без увеличения бюджета на серверные мощности.
Тема перехода на микросервисную архитектуру стала одной из самых горячих на конференциях по архитектуре ПО. Заказчики и разработчики захотели раздробить монолитные приложения на множество маленьких сервисов, чтобы увеличить скорость доставки релизов до пользователей, разделить ответственность команд, уменьшить взаимозависимость бизнес-функций приложения и использовать горизонтальное масштабирование вместо вертикального.
Идея микросервисов звучит красиво, пока вы не создадите десятки и сотни микросервисов. Раньше приложение запускалось на одном мощном сервере и работало на одной СУБД, а теперь надо управлять сотней микросервисов, которые связаны между собой паутиной API вызовов и шин сообщений. Разработка, выпуск релизов, тестирование, соблюдение версионности превратяться в кошмар, если не использовать правильные подходы и инструменты. В докладе покажу инструменты, которые помогают облегчить создание и управление с микросервисной архитектурой.
Для создания ПО мы выбрали эмпирический подход и почти отказались от детерминистского. Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь оказывается всегда шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта.
Делать задачи, которые приносят прибыль, и не делать задачи, которые прибыль не приносят — естественное желание. Но, когда мы не погружаемся в планирование и кодирование, возникает вопрос — как отделить первые задачи от вторых? Что мешает нам увидеть разницу и что помогает?
Расскажу о подходе, которым мы стартуем каждый проект. С помощью Impact Mapping синхронизируем с заказчиком видение продукта и пути достижения успеха.
Типовые проекты, где в центре системы стоит реляционная БД, перестают удовлетворять современным требованиям рынка ПО. В норму входит использование очередей, поисковых движков, NoSQL решений, облачных технологий. Всё это требует перехода от «классической» архитектуры к дроблению системы на набор низкосвязанных компонентов, взаимодействующих друг с другом через сообщения или интерфейсы.
Корпоративные системы состоят из множества подсистем, которые написаны на разных языках и платформах. Используются общие БД, репликации, обмен сообщениями и другие средства интеграции.
Мы рассмотрим шаблоны и инструменты интеграции, которые сейчас есть на платформе .NET для реализации взаимодействия различных систем.
Принцип Command Query Responsibility Segregation (CQRS) довольно давно был описан, но не так давно оброс примерами реализаций и готовыми фреймворками с открытым исходным кодом.
Какие проблемы и решения возникают при применении CQRS? Я рассмотрю ряд вопросов, всплывающих в реальных проектах, покажу, где появляются возможности по масштабированию и построению гибких решений.
Scrum, XP и Kanban — это всего лишь инструменты и мы можем затачивать их под себя в зависимости от реалий проекта. Я буду вычеркивать и комбинировать практики из разных методологий в зависимости от типа проектов и стадии работы.
У меня всё меньше времени на преподавание, поэтому я вижу ценность в выкладывании записи лекций. Возможно в ближайшие годы я вообще перестану ходить в университет. Ниже две части одной лекции, где мы общаемся на тему Agile. Там есть про манифест, отношения между заказчиками и исполнителями и истории из жизни.
Подробнее в статье в моем блоге.
У меня всё меньше времени на преподавание, поэтому я вижу ценность в выкладывании записи лекций. Возможно в ближайшие годы я вообще перестану ходить в университет. Ниже две части одной лекции, где мы общаемся на тему Lean Software Development. Обсуждаем историю и причины возникновения, ценности и принципы.
Самая эффективная команда та, в которой каждый участник имеет правильную жизненную позицию. Команда в данном случае — это участники процесса создания программного продукта, т.е. программисты, руководители и заказчик. Сразу такую команду не создать, нужен инструмент. Agile — это «инструмент» создания такой команды.
Мы рассмотрим влияние ценностей и практик на успешность команды, а также границы применимости Agile.
В этом видео я разрабатываю приложение с помощью TDD на языке C#. Кроме демонстрации того, как надо писать модульные тесты, я постарался показать, как работает TDD на уровне приложения в целом.
При разработке применил принцип инверсии зависимости, а также использовал IoC-контейнер.
Подробности в статье TDD для начинающих. Ответы на популярные вопросы.
Я рассмотрел, как эволюционировал подход к управлению зависимостями в коде. Какие проблемы возникали на каждом этапе и как эти проблемы решались. Возможно на каком-то этапе вы узнаете свой проект и поймете куда двигаться дальше.
Основные темы:Перед этим видео желательно посмотреть пример разработки приложения с помощью TDD.
Цикл статей о техническом задании:
Докладчик расскажет об опыте работе в найме, нескольких лет консультирования IT-компаний, а также ответит на следующие вопросы, исходя из своего опыта: