Антихрупкость в IT
- -
- 100%
- +
Отзывы о книге
Александр – практик, создавший успешную ИТ-компанию, интересную своей культурой и решениями. Эта книга – результат жизненного опыта, пройденные грабли и ошибки. Позволяет с разных сторон посмотреть на задачи, решаемые с помощью ИТ. Послужит отличной точкой входа для понимания дальнейших направлений профессионального развития
Заостровцев Николай – коуч-консультант организаций и первых лиц
Книга является настольным руководством для заказчика, который решил воспользоваться услугами заказной разработки ПО, или для директора, который решил завести в своей компании айтишников. Книга вводит вас в необходимую терминологию и инструменты, необходимые для достижения успеха в IT-проектах.
Книга изобилует примерами из личного опыта автора, который, находясь по другую сторону контракта, объясняет вам, как правильно стоит пользоваться услугами разработки. Десятки примеров из практики, засады и ловушки, а также немного юмора делают процесс чтения захватывающим и полезным.
Алексей Пименов – тренер и консультант по современным методам менеджмента, сооснователь компании Neogenda
В моих руках лежит Книга – плод долгих изысканий Александра Бындю в области практического использования IT-решений как в области организации собственного бизнеса, так и при построении подобных решений по заказам его клиентов. Автор показал отличное владение предметом, широкие знания зарубежных авторов и подходов. Мне, как финансисту, преподавателю и в прошлом проджект-менеджеру Мирового банка, особенно понравились следующие вещи. Умение донести сложные понятия и процессы простым языком, используя картинки, блок-схемы, аналогии и т. д. Также мне импонирует глубокое знание работ американского финансиста и трейдера ливанского происхождения Нассима Талеба, числе которых «Одураченные случайностью», «Антихрупкость» и др. Читателю, безусловно, понравится стиль изложения автора – с юмором, с примерами из практики. Чего только стоит раздел «Я бухгалтер, я так вижу» – сколько из нас сталкивались с этой буквально обезоруживающей фразой! Автор явно знаком с книгой известного американского психолога Эрика Берна «Люди, которые играют в игры. Игры, в которые играют люди», – примеров из этого эпохального труда в данной книге немало.
Особый интерес у меня вызвало сравнение технических долгов с финансовыми, подтверждаю их сходство, исходя из собственного опыта финансового директора.
Уверен, что данная книга и последующие на её базе курсы послужат делу цифровой трансформации общества, о которой так много говорится с высоких трибун, но пока так мало делается. Книга А. Бындю была бы полезна в сфере образования государственных служащих в указанной сфере.
Трегубов Владимир Андреевич – доцент РАНХиГС при Президенте РФ, к.э.н., квалифицированный инвестор, финансовый консультант, журналист.
Я рекомендую эту книгу по трем причинам. Первая причина. Автор книги, Александр Бындю – практик, книга написана на основе многолетнего успешного опыта ведения бизнеса. Вторая причина. Александр самостоятельно и независимо мыслит. Смотрит на устоявшиеся в отрасли каноны свежим взглядом, не боится перерабатывать в котлеты "священных коров". Третья причина – книга читается легко, у автора хороший слог.
Павел Буков – консультант по управлению стрессом в организациях, спикер TEDx, врач психотерапевт.
Предисловие
Однажды я рассказывал топ-менеджеру крупной российской компании про микросервисы. Руководителям, подумал я, было бы полезно разбираться в том, что именно в IT работает на благо бизнеса, а что им пытаются продать как «серебряную пулю», которая не сработает. Я хотел рассказать об этом без лишних деталей и технических глубин, но при этом донести необходимые для понимания основы: как устроено создание IT-продуктов, в чем состоят плюсы и минусы разных подходов и каковы их границы применимости. Так и появилась эта книга.
В моём понимании IT занимается обслуживанием бизнеса. Код пишется и макеты рисуются для того, чтобы компания быстрее и точнее конкурентов попадала в потребности своих клиентов. Для этого следует понимать, какие инструменты работают, а какие мало применимы в мире постоянных перемен.
Название этой книги отсылает к близкой мне работе Нассима Талеба «Антихрупкость». Я часто буду использовать термины из его книги, поэтому надеюсь, что вы прочитали его книгу или хотя бы ознакомились с её основными тезисами.
Меня вдохновляют идеи Талеба: как в условиях неопределённости извлекать выгоду из хаоса и быть готовым к случайным внешним событиям. Главными инструментами «Антихрупкости» указаны прилаживание, основанное на рациональности, и метод проб и ошибок. В своей книге я рассказываю, как можно выстроить внутреннее качество IT-систем и процессы разработки таким образом, чтобы успевать вовремя подстроиться под любые изменения.
То, что я описываю, обычно обсуждается на узкоспециализированных профессиональных конференциях. Мои знания живут на уровне техлидов, техдиректоров, арт-директоров и тимлидов и почти не поднимаются выше: до инвесторов, стейкхолдеров, руководителей и владельцев бизнеса. С другой стороны, не опускаются ниже – до разработчиков, QA и дизайнеров. Между тем, в процессах цифровой трансформации и создания сложных IT-продуктов важно, чтобы все члены команды понимали основные концепции продукта и видели его движение.
Я хочу, чтобы эту книгу прочитали менеджеры и будущие ведущие разработчики, а также студенты, интересующиеся разработкой сложных продуктов.
Кому нужна эта книга
Вам – если вы хотите обогнать конкурентов за счёт развития IT внутри своего бизнеса. Владельцы компаний, топ-менеджеры, руководители подразделений и проектов узнают из книги, как крутятся шестерёнки IT-мира и как эффективно выстраивать развитие IT-продуктов.
Тимлидам и техлидам книга даст правильное представление о пользе IT в достижении бизнес-целей.
Особенно полезна книга будет тем, кто занимается цифровой трансформацией и вовлечён в переход от проектного подхода к продуктовому, а также всем IT-специалистам и инженерам, готовым взглянуть на свою работу под новым углом.
Об авторе
Александр Бындю
IT-архитектор, Agile и Lean эксперт
Я всю жизнь занимаюсь IT. Самостоятельно прошёл путь от программиста до владельца IT-компании. Обожаю инженерное дело, создание IT-продуктов, разработку IT-архитектуры и участие в трансформации бизнеса.
1. С 2012 года владелец и IT-архитектор в компании Byndyusoft, выпустившей много критически важного софта для электронной коммерции, ритейла, логистики и других областей.
2. С 2009 года преподаю в университетах принципы разработки ПО и управлению IT-проектами.
3. Выступаю на профессиональных IT-конференциях, рассказываю об управлении IT-продуктами и современных подходах к IT-архитектуре.
Как я помогаю компаниям:
1. Трансформирую культуру крупных компаний, организую цифровые трансформации.
2. Перевожу монолитные системы на микросервисную архитектуру.
3. Провожу тренинги для программистов и менеджеров.
4. Организую работу от сбора требований до запуска IT-продукта.
5. Консультирую как внешний IT-архитектор и личностный коуч.
Личный сайт https://byndyu.ru
Благодарности
Коллегам за поддержку и такую же сильную любовь к инженерному делу, как у меня. В особенности Андрею Шапиро – за его глубину и постоянное желание докопаться до сути.
Моей жене Яне Мильбергер за её любовь и мудрость.
Хочу поблагодарить за обратную связь по книге, подсказки, уточнения и помощь Антона Степанова, Алексея Пименова, Михаила Пуляевского, Николая Заостровцева и Влада Зелинского.
Структура книги
В разделе I – инструменты для управления IT-продуктами в условиях неопределённости. В разделе II – IT-архитектура и работа с IT-системами с точки зрения эффективности достижения бизнес-целей.
В конце книги есть два приложения с дополнительными материалами к каждому разделу. В приложениях я собрал ссылки на свои статьи, интервью и выступления, чтобы вы могли глубже погрузиться в затрагиваемые в книге темы.
Необязательно читать последовательно. Для начала можно выбрать наиболее актуальную для вас тему и возвращаться к книге по мере возникновения новых вопросов. Каждая тема – это ключ к большой области знаний. Я даю основы понимания и ви́дения этой темы плюс множество ссылок для самостоятельного изучения и дальнейшего движения в правильном направлении.
В сносках довольно много ссылок. Если вы читаете книгу в бумажном виде, то у меня для вас хорошая новость: не нужно набирать длинные ссылки вручную. Перейти по ссылке в сноске можно, написав в строке браузера https://byndyu.ru/footnote/<номер сноски>, и вы перейдёте к статье или видео, на которые я ссылаюсь. Кроме этого, полный список ссылок можно найти на сайте книги https://byndyu.ru/AntifragileIT.
Раздел I. Управление IT-продуктами
В этом разделе собраны подходы и принципы, которые помогут выстроить работу компании для создания IT-продуктов и пригодятся в цифровой трансформации.
Глава 1. Кнопочное мышление против целостного IT-продукта
Кнопочные решения портят жизнь разработчиков, пользователей и инвесторов
Когда мы общаемся с коллегами, заказчиками и пользователями, я использую фразу «кнопочное мышление». Что я имею в виду?
Синонимами кнопочного мышления можно назвать экранное мышление или преждевременную концептуализацию. Суть мышления кнопками можно раскрыть на десятке примеров из практики, но пока – история, которая наверняка случалась с каждым. Представьте: к вам приходит клиент и рассказывает о падении конверсии на сайте. А вы в ответ: «Давайте кнопку покупки сделаем побольше и поярче!» Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Это и есть кнопочное мышление.
Откуда берутся кнопочные идеи
Практика показала, что есть три типажа людей-генераторов кнопочных решений. Речь не о конкретных позициях в проекте, потому что лажать может каждый член команды. Программисты, QA, дизайнеры, заказчики, инвесторы и конечные пользователи – потенциальные создатели кнопок.
Торопыги
Представьте ситуацию, в которой Заказчик приносит проблему. Он делится этой проблемой с Торопыгой. Что делает Торопыга в ответ? Чувствует давление, как будто Заказчик ждёт ответа, причём мгновенно. Пауза затягивается, а ответа в голове не появилось – напряжение возрастает. В своём воображении Торопыга уже видит, как его, беднягу, обвиняют в некомпетентности, и выдаёт первое пришедшее в голову решение. В лучшем случае бесполезное, в худшем – вредное.
Как быть, если вы заметили за собой недуг торопыжничества? Во-первых, осознайте, что невозможно знать все ответы. Придумывание налету – не признак профессионализма. Во-вторых, брать паузы в переговорах и на совещаниях – норма. Берёте паузу, идёте думать. Приносите с собой варианты решений, риски по каждому, плюсы и минусы[1].
Решалы
Решалы – ребята-профи, которые в IT собаку съели. Спроси – сразу ответят. Хотя и не факт, что за плечами у них серьёзные проекты и десятки лет опыта.
Для Решалы входящие проблемы и задачи видятся типовыми, уже решёнными. По фреймворку Cynefin Framework[2] Решалы видят мир в квадратике Obvious, ну, максимум – в Complicated. Другими словами, у них всегда есть готовое решение, надо только выбрать категорию проблемы. Не понимая того, что они лишают себя шанса преподнести бизнесу проработанное решение и вырасти на новой задаче.
Бизнес-решала пострашнее Разработчика-решалы, потому что любит проталкивать Pet Features в продукт. Pet feature – это такие любимчики, как милые домашние питомцы, цель их существования в продукте неясна, но они почему-то по душе тому, кто платит за разработку.
Спасители
Неожиданно в голове у человека появляется чувство, что если он не поднимется с колен и не поведёт за собой команду, то конец проекту, продукту и даже компании. Он берёт на себя роль Спасителя, поднимает флаг и ведёт людей за собой. Спасители мыслят кнопочно с особым фанатизмом.
Если вы решили, что это ситуационное лидерство[3], о котором так много сказано в гибких подходах разработки, то будете правы. Только не всё ситуационное лидерство одинаково полезно. Проблема возникает, когда во время подъёма человек перестаёт слышать других и адекватно оценивать ситуацию. Его решения становятся ультимативными: он на войне, он Спаситель, он вершит судьбы.
Если вы заметили Спасителя в проекте, постарайтесь вывести человека из этого состояния. Медленно, но непреклонно и жёстко. Чем раньше, тем лучше. Впереди его ждут сожаления о решениях, принятых в состоянии аффекта.
Я – могучий генератор кнопок
Не знаю, к какой части себя присоединить, но и я тоже великий генератор кнопок и быстрых решений. 15 лет опыта и скорость мозга не дают мне усомниться в своей правоте. Я решаю со страшной скоростью и наслаждением.
Наверняка в мире живут айтишники со стальной волей. Они способны держать себя в жёстких рамках, не вываливаться в роль Решалы или Спасителя. Я к таким не отношусь и периодически скатываюсь в одну из ролей, а иногда в их комбинацию.
Когда я это осознаю, бью себя по щекам, колю булавкой и торможу подобное решательство. Не всегда успешно, но я всё равно стараюсь. Кажется, со временем становится лучше.
Мимикрирующие User Story и хитрые Product Owner'ы
С источниками кнопочного мышления разобрались. Теперь узнаем, что с ними делать. Почему мы даём Решалам порулить? Почему не отбрасываем поверхностные идеи? Как предотвратить собственное решательство?
User Story как фильтр
Когда я думал о фильтрах, не пропускающих кнопочные идеи, вспомнились User Story[4]. Мы используем истории для формирования задач проекта в повседневной практике. Сила User Story в том, что они заставляют описывать ценность. Нет ценности в истории – нет лишней кнопки в интерфейсе.
Работа строится следующим образом. Вносишь в работу идею → опиши в виде User Story. Ответь на вопрос «Чтобы что?».
Хочешь кнопку выгрузки отчёта в Excel. Ок, чтобы что? Чтобы было на всякий случай? В мусорку, не берём в работу.
Бухгалтер Оля сказала, что ей так нравится? В мусорку, не берём в работу.
Вы посовещались внутри отдела экономистов, нарисовали кнопку в интерфейс и теперь хотите, чтобы мы её добавили? Чтобы что? Потому что это ваша идея и она вам нравится? В мусорку.
Вы заказчик и вы так видите? Другого «чтобы что» нет? Увы, в работу не берём. Иногда можно сделать ставку на Pet Feature, но перед этим следует обозначить риски и чётко проговорить бесполезность затеи.
Хитрые Product Owner'ы
User Story отлично отсеивает кнопочные идеи. Проверено на практике. Однако здесь появляется оборотная сторона проблемы. Product Owner'ы и stakeholder'ы поняли, что через User Story не пройти, потому что приходится искать ответ на вопрос «Чтобы что?». А это сложно, если ты пришёл с Pet Feature. Сложно, но сильно хочется.
Product Owner'ы[5] подстроились под новую модель постановки задач. Они научились играть в эту игру.
Я, как корпоративный клиент,
Хочу скачивать отчёт о движениях денежных средств,
Чтобы видеть, что баланс стал отрицательным.
Неопытный разработчик или дизайнер примут такую историю за правильную. Но присмотритесь к ней внимательно. Перечитайте эту историю и попробуйте прикинуть, какие вопросы у вас возникнут к Product Owner'у.
Я бы для начала спросил о дальнейшей жизни скачанного отчёта. О жизни пользователя, который скачает этот отчёт. Что он найдёт в отчёте? С помощью чего найдёт нужное? Как он отделит нужное от ненужного?
Мимикрирующие User Story
Правило User Story соблюдено, но без погружения и дополнительных вопросов в работу оно не работает. Что делать? Копаем, ищем корни проблемы, задаём открытые вопросы, используем принцип 5 Why[6]. Со временем узнаём корень проблемы и записываем в User Story:
Я, как корпоративный клиент,
Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.
Хочу…
Чтобы…
Уже лучше, потому что мы поняли, откуда пришло кнопочное решение со скачиванием отчёта. Теперь мы знаем, что клиент теряет деньги, если оперативно не получает информацию о счёте.
Следующий шаг – понять, как мы поменяем жизнь корпоративного клиента. Gojko Adzic в книге Quick Ideas To Improve Your User Stories[7] указывает на то, что лучше прописывать в User Story дельту между тем, как пользователь жил до релиза, и тем, как он заживёт после. Получаем такую историю:
Я, как корпоративный клиент,
Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.
Хочу останавливать работу, если баланс стал критично низким,
Чтобы не терять деньги.
Мы остановим работу пользователя и трату денег, когда баланс станет отрицательным. Когда мы озвучиваем предложение пользователям, они не верят, что можно автоматически остановить работу. Для пользователя боль потери денег настолько сильна, что они сами придумали скачивание отчёта, они готовы смотреть в отчёт, искать в нём ответ на вопрос об отрицательном балансе.
В последней версии User Story кнопочное решение убрано. Раскопана корневая проблема. Предложено решение, которое закроет корневую проблему. Появился шанс принести пользу после релиза, а не добавить ещё одну кнопку для скачивания ещё одного отчёта.
Преждевременные решения
Некоторым людям неймётся выпалить решение. Они как будто играют в «Свою Игру» или «Брейнринг». Ждут вопрос и на скорость предлагают решение.
В спешке между проблемой и идеей возникает слепая зона. Цепочка рассуждений и выводов остаётся за кадром (рис. 1).
Рис. 1. Отсутствие связи между целью и решением
Мы не принимаем первое поспешное решение, копаем корень проблемы, определяем действующих лиц. После прокладывания пути из цели через действующих лиц до корня проблемы кнопочное решение теряет былую прочность (рис. 2).
Рис. 2. Прорисовка связи между целью и решением
Увидев корневую проблему или потребность, накидываем много возможных решений (рис. 3).
Рис. 3. Множество решений для одной цели
Обратите внимание, что теперь налицо выбор, но сделать его сложнее. У меня есть предположение, что люди намеренно останавливаются на первом решении, которое кажется подходящим. Ведь если идти дальше, то придётся выбирать, оценивать риски каждого решения, его плюсы и минусы. Работы прибавится. Кроме того, чем шире выбор, тем меньше будет радость от итогового решения.
Глубокое бурение проблемы затратно, никто не стремится в это болото. Но если мы хотим создать полезное решение, то нужно пересилить себя и раскрыть слепую зону.
Истории из жизни
Кейс: Сужение видения
Идёт планирование релиза. Product Owner заканчивает фразу словами: «…можно отправить почтой». Я сразу останавливаю обсуждение, потому что одной фразой произошло сужение проблематики до одного решения. Остановились и раскопали корень потребности. Почему отправлять? Почему почтой? В мире ведь придумано много способов донесения информации до пользователей. В итоге предложили пять способов рассказать клиентам об обновлениях. Совет: не сводите решение к одному варианту.
Кейс: Решения без проблемы
Новый заказчик обсуждает с нами модернизацию IT-продукта. Пока рассказывает о продукте, вспоминает о проблеме – клиенты уходят в минус и перерасходуют ресурсы без оплаты. Сервис берёт деньги по мере выполнения операции, но предсказать расходы заранее нельзя. По мере рассказа заказчика посещает идея: обрубать доступ и оставлять клиента без результата.
Обсуждение прервали, раскопали проблему пользователей. Выяснилось, что пользователи не понимают, сколько денег остаётся в каждый момент времени, поэтому не могут оперативно принимать решения. Мы предложили показывать им расходы и текущий баланс в режиме онлайн. Заказчик удивился и сказал: «А что, так можно?»
Сколько стоят 1000 строк кода?
Представьте сцену в магазине. Вы набрали продуктов в корзину и подошли к кассе. Кассир пробил товары, взвесил фрукты и овощи, назвал стоимость. Отлаженный механизм.
Та же история с созданием IT-продукта. Вы сидите на кассе, приходит бизнес с корзиной фич и решений. Вы оцениваете, взвешиваете, говорите ему стоимость.
Давайте вернёмся в магазин и переиграем ситуацию. Вы подходите к кассе, выкладываете покупки. Продавец вам говорит: «Зря вы взяли помидоры „шеди леди“ для рагу из кролика. Этот сорт слишком сладкий, для рагу не подойдёт. Возьмите сорт „маленький принц“, рагу с ними отменное».
Посмотрим, что изменилось. Почему вы благодарны кассиру и хотите его обнять? Он узнал вашу цель. После этого он предложил решение, которое двигает вас к цели, а не просто молча согласился с предложенным решением. Ценность покупки в этом магазине выросла, удовлетворение выросло, вы захотите приходить в этот магазин снова.
Теперь вернёмся к IT. Для выявления целей, понимания пути достижения целей, формирования выбора из решений я рекомендую Impact Mapping[8]:
Рис. 4. Разделение проблем и решений
Техника изучается за пару дней. С помощью Impact Mapping мы прокладываем путь от решений до цели, расставляем приоритеты, отсекаем Pet Feature, которые идут со стороны бизнеса и со стороны команды. Единственная сложность – процесс создания Impact Mapping: он требует навыков эффективной коммуникации.
Истории из жизни
Кейс: Требуется больше всплывающих окон
Представьте IT-отдел внутри компании. Руководители отдела маркетинга, финансов и прочих ставят ему задачи. Приходит начальник, который отвечает за точки продаж, и требует добавить всплывающее сообщение раз в 10 минут на рабочем месте. Работников на местах обяжут нажимать «ОК» в модальном окне каждые 10 минут, чтобы понять, на месте работник или нет. Задача как задача; IT-отдел взял да и сделал. Прошло время. Работники на местах ужились с новшеством.
В IT-отдел пришёл начальник маркетинга и попросил добавить всплывающее сообщение, чтобы работник выходил на улицу и раздавал листовки. Сообщение по задумке всплывает каждые 30 минут, в результате должны повыситься продажи. Задача как задача; IT-отдел взял да и сделал.
На местах это вылилось в противоречивый сценарий. Работник видит сообщение о том, что надо идти на улицу и раздавать листовки. Он выходит и раздаёт, а в это время всплывает сообщение: «Ты на месте?»
Почему так произошло? Никто не контролировал целостность системы. Многоголовый Product Owner приносил задачу, разработчики брали задачу, не создав целостной картинки поставки ценности, поэтому они не увидели противоречий.
Кейс: Зачем делаем?
Заказчик пришёл с идеей сделать приложение для курьеров. Заказчик – федеральная компания, сотни филиалов по стране. Цель продукта – оптимизация работы курьеров.
До работы с нами у проекта накопилась полугодовая история. Заказчику сделали ТЗ, реализовали часть мобильного клиента, но не сделали серверную часть. С этой историей заказчик пришёл к нам. Мы начали проект по нашему процессу[9], и уже к концу Customer Journey Mapping заказчика осенило. Они поменяли бизнес-модель, запустили ряд экспериментов в бизнесе и обещали вернуться к нам через три месяца. В итоге вернулись через полгода с перестроенной компанией, которая стала готова для создания нового продукта. Продукт мы сделали и успешно запустили. Мы считаем это успехом, так как не позволили потратить время на что-то бесполезное.