скачать книгу бесплатно
Антихрупкость в IT
Александр Васильевич Бындю
Код пишется и макеты рисуются для того, чтобы компания быстрее и точнее конкурентов понимала и выполняла потребности своих клиентов. Для достижения этого результата следует понимать, какие инструменты работают, а какие мало применимы в мире постоянных перемен. В своей книге я рассказываю, как можно выстроить внутреннее качество IT-систем и процессы разработки таким образом, чтобы успевать вовремя подстроиться под любые изменения внутренней и внешней среды, а также изменяющиеся по ходу реализации проекта нужды заказчика. Одним из ключевых понятий данного исследования является понятие «антихрупкость». Мой собственный предпринимательский опыт и опыт моих партнёров, клиентов и друзей убедил меня в том, что при создании IT-продуктов важное внимание следует уделять их «антихрупкости» – прочности, работоспособности предлагаемых клиенту решений в условиях меняющегося мира.
Александр Бындю
Антихрупкость в IT
Отзывы о книге
Александр – практик, создавший успешную ИТ-компанию, интересную своей культурой и решениями. Эта книга – результат жизненного опыта, пройденные грабли и ошибки. Позволяет с разных сторон посмотреть на задачи, решаемые с помощью ИТ. Послужит отличной точкой входа для понимания дальнейших направлений профессионального развития
Заостровцев Николай – коуч-консультант организаций и первых лиц
Книга является настольным руководством для заказчика, который решил воспользоваться услугами заказной разработки ПО, или для директора, который решил завести в своей компании айтишников. Книга вводит вас в необходимую терминологию и инструменты, необходимые для достижения успеха в 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 (https://byndyu.ru/)
Благодарности
Коллегам за поддержку и такую же сильную любовь к инженерному делу, как у меня. В особенности Андрею Шапиро – за его глубину и постоянное желание докопаться до сути.
Моей жене Яне Мильбергер за её любовь и мудрость.
Хочу поблагодарить за обратную связь по книге, подсказки, уточнения и помощь Антона Степанова, Алексея Пименова, Михаила Пуляевского, Николая Заостровцева и Влада Зелинского.
Структура книги
В разделе I – инструменты для управления IT-продуктами в условиях неопределённости. В разделе II – IT-архитектура и работа с IT-системами с точки зрения эффективности достижения бизнес-целей.
В конце книги есть два приложения с дополнительными материалами к каждому разделу. В приложениях я собрал ссылки на свои статьи, интервью и выступления, чтобы вы могли глубже погрузиться в затрагиваемые в книге темы.
Необязательно читать последовательно. Для начала можно выбрать наиболее актуальную для вас тему и возвращаться к книге по мере возникновения новых вопросов. Каждая тема – это ключ к большой области знаний. Я даю основы понимания и ви?дения этой темы плюс множество ссылок для самостоятельного изучения и дальнейшего движения в правильном направлении.
В сносках довольно много ссылок. Если вы читаете книгу в бумажном виде, то у меня для вас хорошая новость: не нужно набирать длинные ссылки вручную. Перейти по ссылке в сноске можно, написав в строке браузера https://byndyu.ru/footnote/<номер сноски>, и вы перейдёте к статье или видео, на которые я ссылаюсь. Кроме этого, полный список ссылок можно найти на сайте книги https://byndyu.ru/AntifragileIT (https://byndyu.ru/AntifragileIT).
Раздел I. Управление IT-продуктами
В этом разделе собраны подходы и принципы, которые помогут выстроить работу компании для создания IT-продуктов и пригодятся в цифровой трансформации.
Глава 1. Кнопочное мышление против целостного IT-продукта
Кнопочные решения портят жизнь разработчиков, пользователей и инвесторов
Когда мы общаемся с коллегами, заказчиками и пользователями, я использую фразу «кнопочное мышление». Что я имею в виду?
Синонимами кнопочного мышления можно назвать экранное мышление или преждевременную концептуализацию. Суть мышления кнопками можно раскрыть на десятке примеров из практики, но пока – история, которая наверняка случалась с каждым. Представьте: к вам приходит клиент и рассказывает о падении конверсии на сайте. А вы в ответ: «Давайте кнопку покупки сделаем побольше и поярче!» Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Это и есть кнопочное мышление.
Откуда берутся кнопочные идеи
Практика показала, что есть три типажа людей-генераторов кнопочных решений. Речь не о конкретных позициях в проекте, потому что лажать может каждый член команды. Программисты, QA, дизайнеры, заказчики, инвесторы и конечные пользователи – потенциальные создатели кнопок.
Торопыги
Представьте ситуацию, в которой Заказчик приносит проблему. Он делится этой проблемой с Торопыгой. Что делает Торопыга в ответ? Чувствует давление, как будто Заказчик ждёт ответа, причём мгновенно. Пауза затягивается, а ответа в голове не появилось – напряжение возрастает. В своём воображении Торопыга уже видит, как его, беднягу, обвиняют в некомпетентности, и выдаёт первое пришедшее в голову решение. В лучшем случае бесполезное, в худшем – вредное.
Как быть, если вы заметили за собой недуг торопыжничества? Во-первых, осознайте, что невозможно знать все ответы. Придумывание налету – не признак профессионализма. Во-вторых, брать паузы в переговорах и на совещаниях – норма. Берёте паузу, идёте думать. Приносите с собой варианты решений, риски по каждому, плюсы и минусы[1 - Александр Бындю. Проблем быть не должно, https://byndyu.ru/footnote/1 (https://byndyu.ru/footnote/1)].
Решалы
Решалы – ребята-профи, которые в IT собаку съели. Спроси – сразу ответят. Хотя и не факт, что за плечами у них серьёзные проекты и десятки лет опыта.
Для Решалы входящие проблемы и задачи видятся типовыми, уже решёнными. По фреймворку Cynefin Framework[2 - Cynefin framework, https://byndyu.ru/footnote/2 (https://byndyu.ru/footnote/2)] Решалы видят мир в квадратике Obvious, ну, максимум – в Complicated. Другими словами, у них всегда есть готовое решение, надо только выбрать категорию проблемы. Не понимая того, что они лишают себя шанса преподнести бизнесу проработанное решение и вырасти на новой задаче.
Бизнес-решала пострашнее Разработчика-решалы, потому что любит проталкивать Pet Features в продукт. Pet feature – это такие любимчики, как милые домашние питомцы, цель их существования в продукте неясна, но они почему-то по душе тому, кто платит за разработку.
Спасители
Неожиданно в голове у человека появляется чувство, что если он не поднимется с колен и не поведёт за собой команду, то конец проекту, продукту и даже компании. Он берёт на себя роль Спасителя, поднимает флаг и ведёт людей за собой. Спасители мыслят кнопочно с особым фанатизмом.
Если вы решили, что это ситуационное лидерство[3 - Situational leadership theory, https://byndyu.ru/footnote/3 (https://byndyu.ru/footnote/3)], о котором так много сказано в гибких подходах разработки, то будете правы. Только не всё ситуационное лидерство одинаково полезно. Проблема возникает, когда во время подъёма человек перестаёт слышать других и адекватно оценивать ситуацию. Его решения становятся ультимативными: он на войне, он Спаситель, он вершит судьбы.
Если вы заметили Спасителя в проекте, постарайтесь вывести человека из этого состояния. Медленно, но непреклонно и жёстко. Чем раньше, тем лучше. Впереди его ждут сожаления о решениях, принятых в состоянии аффекта.
Я – могучий генератор кнопок
Не знаю, к какой части себя присоединить, но и я тоже великий генератор кнопок и быстрых решений. 15 лет опыта и скорость мозга не дают мне усомниться в своей правоте. Я решаю со страшной скоростью и наслаждением.
Наверняка в мире живут айтишники со стальной волей. Они способны держать себя в жёстких рамках, не вываливаться в роль Решалы или Спасителя. Я к таким не отношусь и периодически скатываюсь в одну из ролей, а иногда в их комбинацию.
Когда я это осознаю, бью себя по щекам, колю булавкой и торможу подобное решательство. Не всегда успешно, но я всё равно стараюсь. Кажется, со временем становится лучше.
Мимикрирующие User Story и хитрые Product Owner'ы
С источниками кнопочного мышления разобрались. Теперь узнаем, что с ними делать. Почему мы даём Решалам порулить? Почему не отбрасываем поверхностные идеи? Как предотвратить собственное решательство?
User Story как фильтр
Когда я думал о фильтрах, не пропускающих кнопочные идеи, вспомнились User Story[4 - Андрей Шапиро. Руководство по сбору требований в формате User Story Mapping, https://byndyu.ru/footnote/4 (https://byndyu.ru/footnote/4)]. Мы используем истории для формирования задач проекта в повседневной практике. Сила User Story в том, что они заставляют описывать ценность. Нет ценности в истории – нет лишней кнопки в интерфейсе.
Работа строится следующим образом. Вносишь в работу идею ? опиши в виде User Story. Ответь на вопрос «Чтобы что?».
Хочешь кнопку выгрузки отчёта в Excel. Ок, чтобы что? Чтобы было на всякий случай? В мусорку, не берём в работу.
Бухгалтер Оля сказала, что ей так нравится? В мусорку, не берём в работу.
Вы посовещались внутри отдела экономистов, нарисовали кнопку в интерфейс и теперь хотите, чтобы мы её добавили? Чтобы что? Потому что это ваша идея и она вам нравится? В мусорку.
Вы заказчик и вы так видите? Другого «чтобы что» нет? Увы, в работу не берём. Иногда можно сделать ставку на Pet Feature, но перед этим следует обозначить риски и чётко проговорить бесполезность затеи.
Хитрые Product Owner'ы
User Story отлично отсеивает кнопочные идеи. Проверено на практике. Однако здесь появляется оборотная сторона проблемы. Product Owner'ы и stakeholder'ы поняли, что через User Story не пройти, потому что приходится искать ответ на вопрос «Чтобы что?». А это сложно, если ты пришёл с Pet Feature. Сложно, но сильно хочется.
Product Owner'ы[5 - Product Owner по сути – это предприниматель внутри компании. Он ещё не вырос до создания своей компании либо не хочет рисковать созданием собственного бизнеса, при этом он уже мыслит и действует как предприниматель.] подстроились под новую модель постановки задач. Они научились играть в эту игру.
Я, как корпоративный клиент,
Хочу скачивать отчёт о движениях денежных средств,
Чтобы видеть, что баланс стал отрицательным.
Неопытный разработчик или дизайнер примут такую историю за правильную. Но присмотритесь к ней внимательно. Перечитайте эту историю и попробуйте прикинуть, какие вопросы у вас возникнут к Product Owner'у.
Я бы для начала спросил о дальнейшей жизни скачанного отчёта. О жизни пользователя, который скачает этот отчёт. Что он найдёт в отчёте? С помощью чего найдёт нужное? Как он отделит нужное от ненужного?
Мимикрирующие User Story
Правило User Story соблюдено, но без погружения и дополнительных вопросов в работу оно не работает. Что делать? Копаем, ищем корни проблемы, задаём открытые вопросы, используем принцип 5 Why[6 - Five whys, https://byndyu.ru/footnote/6 (https://byndyu.ru/footnote/6)]. Со временем узнаём корень проблемы и записываем в User Story:
Я, как корпоративный клиент,
Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.
Хочу…
Чтобы…
Уже лучше, потому что мы поняли, откуда пришло кнопочное решение со скачиванием отчёта. Теперь мы знаем, что клиент теряет деньги, если оперативно не получает информацию о счёте.
Следующий шаг – понять, как мы поменяем жизнь корпоративного клиента. Gojko Adzic в книге Quick Ideas To Improve Your User Stories[7 - Gojko Adzic. Fifty Quick Ideas To Improve Your User Stories, https://byndyu.ru/footnote/7 (https://byndyu.ru/footnote/7)] указывает на то, что лучше прописывать в User Story дельту между тем, как пользователь жил до релиза, и тем, как он заживёт после. Получаем такую историю:
Я, как корпоративный клиент,
Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.
