Как достигать результатов в IT-проектах в условиях
неопределённости
В моём понимании IT занимается обслуживанием бизнеса. Код пишется и макеты рисуются для того, чтобы компания быстрее и точнее конкурентов понимала и выполняла потребности своих клиентов. Для достижения этого результата следует понимать, какие инструменты работают, а какие мало применимы в мире постоянных перемен.
В своей книге я рассказываю, как можно выстроить внутреннее качество IT-систем и процессы разработки таким образом, чтобы успевать вовремя подстроиться под любые изменения внутренней и внешней среды, а также изменяющиеся по ходу реализации проекта нужды заказчика.
Одним из ключевых понятий данного исследования является понятие «Антихрупкости», введённое в научный оборот американским финансистом, профессором, трейдером с Уолл-стрита Нассимом Талебом. В бизнесе нам приходиться принимать решения под давлением, в условиях неопределенности, да ещё при ограниченном бюджете времени, средств и ресурсов. Это классическое определение проектного менеджмента.
Мой собственный предпринимательский опыт и опыт моих партнеров, клиентов и друзей убедил меня в том, что при создании IT-продуктов важное внимание следует уделять их «антихрупкости» – прочности, работоспособности предлагаемых клиенту решений в условиях меняющегося мира. Искренне надеюсь, что мои мысли, изложенные в этой книге, позволят читателям найти оптимальные решения в сложном мире IT–продуктов.
Где купить книгу Антихрупкость в IT
Шпаргалка — навигация по темам, которые стоит знать руководителю компании и топ-менеджеру, чтобы грамотно реализовать IT-проекты нового уровня сложности. По каждой теме будет много ссылок на статьи, интервью, обзоры и видео.
Продуктовый подход описан в книгах давно, но только недавно крупные российские компании начали на него переходить. При новом подходе IT-продукт создаётся внутренней кросс-функциональной командой, а процесс основывается на метриках, гибкой культуре, машинном обучении и постоянных поставках новых фич. Этот подход позволяет бизнесу не просто держаться на плаву, но и создавать инструменты для конкурентной борьбы за доли рынка. Обсудим, почему компании больше не хотят писать ТЗ для проекта, разбивать ТЗ на части, раздавать отделам и аутсорсерам. Расскажу, как создаются продуктовые команды в аутсорсе, какие качества отличают крутых Product Owner’ов от осредственных, и какие инструменты и подхо- ды стоит применять уже сейчас.
Подробно рассматриваю историю Lean Software Development и принципы, на которых построен этот подход.
Как меняется подход к стендап-митингам по утрам, если мы переходим от Scrum к Kanban.
Ничто не раздражает заказчика больше, чем неверная оценка сроков. Ничто не давит на разработчика сильнее, чем неправильно оценённая задача. Причём со временем развития IT-отрасли мало что меняется.
Как решается спор о том, насколько подробным должно быть ТЗ.
Почему написание подробного ТЗ — это потери для бизнеса.
Я собрал самые известные манифесты из мира IT. По ним интересно понаблюдать, чем живут айтишники.
Распаковываем трудоустройство в Byndyusoft: технический директор Руслан Сафин и основатель Byndyusoft Александр Бындю рассказывают о полном процессе трудоустройства, интернатуре, плоской структуре работы и многом другом.
InnerSourcing и микросервисы дополняют друг друга и одновременно повышают порог вхождения новичков в эту тему. Я расскажу с точки зрения IT-архитектора и организатора процесса разработки:
Язык программирования нужно выбирать под бизнес-цели. Я расскажу, на какие факторы обращать внимание, чтобы повысить шансы на успех.
Архитектура влияет на долгосрочный успех IT-продукта. Я расскажу, каким образом планировать работу над задачами архитектуры по мере создания продуктов.
Эволюция подходов к IT-архитектуре. Определите, где вы сейчас, чтобы понять, куда вы пойдёте дальше.
Тема перехода на микросервисную архитектуру стала одной из самых горячих на конференциях по архитектуре ПО. Заказчики и разработчики захотели раздробить монолитные приложения на множество маленьких сервисов, чтобы увеличить скорость доставки релизов до пользо- вателей, разделить ответственность команд, уменьшить взаимозависимость бизнес-функций приложения и использовать горизонтальное масштабирование вместо вертикального.
Описанные проблемы «монолитов» и способы решения проблем с ними не являются исчерпывающим руковод- ством по переходу к распределённой архитектуре. Скорее, это перечисление шагов и практик, которые пригодились на наших проектах и привели к нужным результатам.
Одной из целей применения CQRS тоже является переход к горизонтальному масштабированию. Однако кроме этого CQRS даёт ряд преимуществ на уровне дизайна кода и простоты поддержки.
Принципы проектирования классов облегчают работу программиста. Уметь их применять очень важно. Умелое использование этих принципов избавляет проект от тяжёлого бремени технических долгов, облегчая его поддержку и расширение.
Где купить книгу Антихрупкость в IT