Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

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

Хотелось бы остановиться подробнее на том, что я имею в виду под «как угодно» и «когда угодно».

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

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

Интересы бизнеса

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

Николай сказал, что аргументация идёт больше со стороны IT, чем со стороны заказчика. Например, я пишу «донести мысль, что технические долги = финансовые долги». Но тогда у бизнеса будет резонный вопрос – а почему вы не построили свой процесс так, чтобы нам вообще не пришлось думать об этом техническом долге? Это же проблема вашего процесса.

Или, например, про модели финансов Николай заметил, что я исхожу из опыта своей компании, когда мои команды ответственны и нацелены на бизнес-результат. Но многим заказчикам приходится сталкиваться с другим: заключаешь договор на T&M – и исполнитель завышает часы, чтобы обеспечить себя стабильным неторопливым заработком. Идёшь на FFF, но если команды слабые, то делают мало, постоянно приходится жертвовать объёмом работ, и получается игра в одни ворота. Заказчик снова в проигрыше. Что делать, чтобы для сохранения сроков и бюджета не пришлось резать объём работ в 4 раза?

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

Книга должна вам помочь отследить слабые сигналы, которые покажут вам, что что-то идёт не так. В нужный момент это должно сработать, и вы вовремя заметите изъян, который может погубить всё дело. Я описал, по сути, то, как должно быть, чтобы вы использовали логику рассуждения книги как ориентир в разговорах с техническими директорами и IT-специалистами.

Границы применимости

В книге описаны подходы, которые помогают достигать бизнес-результатов в IT-проектах в условиях неопределённости. Соответственно, если ваша предметная область консервативна, в ней нет изменений, ваш бизнес и бизнес конкурентов пребывает в полном штиле, то описанное в книге будет для вас слишком большими затратами, потому что вложения не окупятся.

Аналогично вам не пригодятся подходы из книги, если вы делаете очень маленькие проекты или проекты, которые не особо влияют на бизнес-цели.

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

Дополнительные материалы и сноски

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

Вопросы и пожелания

Спасибо вам, что прочитали эту книгу! Я буду рад услышать ваше мнение о подходах, которые я описал. Пишите мне, буду рад пообщаться. Все мои контакты вы можете найти на сайте книги по адресу https://byndyu.ru/AntifragileIT.

Приложение 1. Дополнительные материалы к разделу I

Шпаргалка для предпринимателя по IT-миру

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

https://blog.byndyu.ru/2017/09/it.html

Как перейти от проектного мышления к продуктовому [видео и слайды]

Продуктовый подход описан в книгах давно, но только недавно крупные российские компании начали на него переходить.

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

Обсудим, почему компании больше не хотят писать ТЗ для проекта, разбивать ТЗ на части, раздавать отделам и аутсорсерам. Расскажу, как создаются продуктовые команды в аутсорсе, какие качества отличают крутых Product Owner'ов от посредственных, и какие инструменты и подходы стоит применять уже сейчас.

https://blog.byndyu.ru/2018/08/blog-post.html

История и принципы Бережливого производства ПО [видео и слайды]

Подробно рассматриваю историю Lean Software Development и принципы, на которых построен этот подход.

https://blog.byndyu.ru/2016/12/lean-software-development.html

Стендапы в стиле Kanban

Как меняется подход к стендап-митингам по утрам, если мы переходим от Scrum к Kanban.

https://blog.byndyu.ru/2015/05/kanban.html

Все программисты – оптимисты

Ничто не раздражает заказчика больше, чем неверная оценка сроков. Ничто не давит на разработчика сильнее, чем неправильно оценённая задача. Причём со временем развития IT-отрасли мало что меняется.

https://blog.byndyu.ru/2015/02/customer-satisfaction_24.html

Откровенное общение с заказчиком

Как решается спор о том, насколько подробным должно быть ТЗ.

http://blog.byndyu.ru/2017/05/blog-post.html

Техническое задание как база знаний о