Ниже цитата из переписки, которая состоялась в начале осени 2023 года: «По поводу маркетплейса хочу сказать, что вы были правы. Если человек решил завести „коробочку“, то эту идею из его головы просто так не выветришь. В итоге ребята выкатили ему маркетплейс, который не работает». Поясним, что имеется в виду: заказчику развернули готовый маркетплейс из «коробки», но на продажи это никак не повлияло.

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

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

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

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

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

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

Я уже много лет занимаюсь созданием IT-продуктов. Всё это время для себя и коллег собираю метафоры, которые позволяют наглядно показать, как нужно и как ненужно выстраивать работу по созданию ПО.

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

Я рассмотрю 5 моих любимых метафор, которые помогают сонастраивать общее видение процесса для команды разработки и заказчика:

InnerSource мне, как инженеру, очень симпатизирует, потому что позволяет сделать цепочку поставки бизнес-ценности децентрализованной. При всей красоте этого подхода у него есть трудности в реализации. Эти сложности можно разделить на технические и организационные. И те и другие «лечатся», если знать о правильных подходах.

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

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

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

В конце статьи я составил чек-лист, по которому рекомендую проверять low-code платформу, прежде чем вы решитесь использовать её для решения своих бизнес-задач.

Статья состоит из шести разделов:

Больше 8 лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этом подходе: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map, т.е. с теорией нет проблем. Тем не менее, я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

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

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

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

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

Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.

Когда мы общаемся с коллегами, заказчиками или пользователями, я использую фразу «кнопочное мышление». Что я имею ввиду под этим термином? Текущая статья — развернутый ответ на этот вопрос.

Синонимами кнопочного мышления я считаю «экранное мышление» или преждевременную концептуализацию. Я раскрою мышление кнопками на десятке примеров из практики. А здесь для начала история, которая наверняка случалась с каждым. Представьте к вам приходят и рассказывают о падении конверсии на сайте. А вы ему сразу: «Давайте кнопку покупки сделаем побольше и поярче!». Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Вот в таких случаях я говорю о кнопочном мышлении.

Для тех, кто любит смотреть, а не читать, есть видео и слайды.

1. Manifesto for Agile Software Development
2. Agile Manifesto — IBM version
3. MoreAgile Manifesto
4. Agile Manifesto 2.1
5. Manifesto for Half-Arsed Agile Software Development
6. Declaration of Interdependence
7. Programming, Motherfucker
8. Software Craftsmanship Мanifesto
9. DevOps Manifesto

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP