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

Инженерная гордость

Такие проекты – самообман разработчиков. Они уверены, что лучше сделать невозможно. Создатели «фасадных» проектов говорят заказчику: «Мы построили масштабируемую систему, она может хорошо расширяться под любой нагрузкой». Надо понимать, что ни одни действительно опытный разработчик так не скажет. Он сделает множество оговорок про реальную масштабируемость, загонит её в рамки ограничений и опишет возможные риски.

Заявления о надёжности в 146% характерны для программистов, которые находятся в квадрате неосознанной некомпетентности (рис. 35).

Рис. 35. Матрица Осознанность – Компетентность

Не смотрите на количество отработанных лет на должности программиста (кто-то считает это показателем опыта), от них ничего не зависит. Плохо, когда такие «ведущие» программисты имеют дар убеждения заказчика или являются техлидами с его стороны, потому что заказчик остаётся совсем один в этой неравной битве за истину. В таких ситуациях нужно звать внешних консультантов, которым доверяют. Обращайте внимание на реализованные проекты, на роль этих людей в проектах, давайте им небольшие тестовые приложения, которые надо сделать от начала и до конца. При этом обязательно приглашайте консультантов, которые смогут оценить качество. Я сам частенько выполняю эту задачу, например, меня зовут устраивать публичные слушания[46] по проекту.

Инструмент для заказчиков

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

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

Второй шанс – вовремя отлавливать слабые сигналы, которые возникают во время работы:

1. Разработчики не разговаривают в терминах бизнеса, то есть создают свою реальность, далёкую от бизнеса.

2. Скорость разработки со временем замедляется – значит, в коде много технических долгов.

3. Перестаёт работать то, что раньше работало. Это показатель плохого внутреннего качества системы и низкого уровня тестирования.

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

Глава 10. Управление проектом по Fix Time, Fix Budget, Flex Scope (FFF)

В проектном треугольнике объём работ может быть плавающим при определённых условиях

Не мечта ли любого владельца компании управлять IT-продуктом так, чтобы поставлять продукт в срок, обгоняя конкурентов, и делать это с высоким качеством, радуя пользователей? Хотелось бы найти серебряную пулю для управления, и, кажется, она есть. Не такая уж серебряная и не такая уж пуля, но довольно надёжный и обкатанный годами подход к управлению, который можно назвать FFF: Fix Time and Budget, Flex Scope.

Почему и когда стоит выбрать FFF? Давайте посмотрим.

Три комбинации

Каждый из подходов к управлению проектом по сути отличается тем, что фиксирует или не фиксирует следующие величины: бюджет, объём работ, срок и внутреннее качество системы (рис. 36).

Рис. 36. Проектный треугольник с обозначением Внутреннего качества системы

Конкретная комбинация с определёнными условиями работы имеет плюсы и минусы:

Fixed price

1. Зафиксированы три точки проектного треугольника: срок, деньги и объём работы.

2. Основные риски берёт на себя исполнитель, и, как следствие, эти риски отражаются на оценке. Кроме этого, создаются риски и для заказчика (раздел l, глава 7).

3. Большим плюсом этого подхода является предопределённые до начала работ параметры проекта. Очень часто бизнесу/государству нужно прописать в договоре срок, деньги и объём работы.

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

5. Оплата происходит в конце проекта с возможной предоплатой в начале.

Time and Materials (T&M)[47]

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

2. Заказчик берёт в аренду ресурсы исполнителя по фиксированной ставке и управляет ими по своему усмотрению.

3. Исполнитель отвечает за максимально качественный продукт за счёт своей компетенции.

4. Оплачивается при этом время, которое сотрудники исполнителя были заняты на проектах заказчика. Это происходит в конце отчётного периода, например, раз в месяц.

5. Основные риски берёт на себя заказчик.

6. Если у заказчика есть чёткое понимание задач и организован контроль работы (в том числе собственных ресурсов, особенно Product Owner'а), то это самый оптимальный и быстрый вариант управления, потому что он наименее бюрократизирован: все заняты только разработкой без лишних отвлечений на ритуалы согласований.

Fix Time and Budget, Flex Scope (FFF)[48]

1. Зафиксированы три точки проектного треугольника: срок, деньги и внутреннее качество системы.

2. Оплата происходит в конце проекта с возможной предоплатой.

3. В контракте описываются задачи, но достаточно масштабно, чтобы можно было флексить объём работы без переписывания контракта.

4. Объём работы оговаривается в начале проекта, но является предметом дискуссии.

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

6. Риски делятся поровну: разработчики обязуются поставить ценность в срок и в рамках бюджета, а заказчик старается выбрать/урезать задачи, исходя из приоритетов бизнеса и текущей ситуации.

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

Внутреннее качество системы – это то, как ПО устроено внутри. Внешне софт может выглядеть хорошо и даже неплохо работать, но состоять при этом из одних «костылей», макаронного кода, хрупких интеграций, разрабатываться без тестов и работать без должного уровня мониторинга. Низкое качество грозит замедлением разработки и повышением стоимости поддержки. Высоким качеством можно считать, например, отсутствие технического долга (раздел II, глава 6) и успешное прохождение кода через метрики SonarQube[49].