Как оценить крупный технический проект до утверждения бюджета

Крупное техническое предложение часто подают в убедительной форме. У него есть название. Есть схема. Оно может обещать более удобное будущее: новую платформу, замену системы, крупную интеграцию или полное переписывание.

Небольшие проблемы обычно проявляются совсем иначе. Кому-то приходится дважды обновлять страницу, прежде чем появится нужное действие. Сотрудники поддержки копируют одни и те же данные между двумя экранами. Клиент уже знает, на какую кнопку нельзя нажимать. Разработчик знает, что отчет нужно запускать в определенном порядке.

После достаточного количества повторений все это перестает выглядеть как проблема. Это превращается в «то, как работает система».

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

Почему обходные решения легко не заметить

Люди удивительно хорошо приспосабливаются к неудобным системам.

Представьте человека, который каждый день работает в продукте. Он знает, что после открытия странице нужно немного времени, чтобы прийти в стабильное состояние. Он ждет, прежде чем начать вводить текст. Он знает, что после определенного действия фильтр сбрасывается, поэтому применяет его снова. Он знает, какое поле нужно заполнить перед другим, даже если интерфейс никак на это не указывает.

Ничего из этого не нужно записывать. Это превращается в мышечную память.

Новый сотрудник, новый клиент или основатель, который снова посмотрел на продукт после долгого перерыва, видит другую систему. Они не знают последовательность действий. Они не знают скрытое правило. Они видят трения там, где постоянный пользователь видит обычную процедуру.

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

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

Одно обходное решение часто можно терпеть. Но продукт может накопить их множество.

Почему крупные проекты могут скрывать более простые варианты

О крупных проектах проще говорить, чем о списке небольших улучшений.

«Заменить модуль биллинга» звучит как стратегия. «Исправить 37 раздражающих вещей в биллинге» звучит как техническое обслуживание. У первого есть четкие границы и заметный бюджет. Второе требует внимания, расстановки приоритетов и повторяющихся решений.

Но это не причины считать, что крупный проект принесет больше пользы.

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

По отдельности такие изменения могут выглядеть не впечатляюще. Вместе они способны сделать существующий продукт более удобным для пользователей и более простым для поддержки.

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

Возможно также, что замена или переработка системы будет лучшим путем. Суть проще: размер предложения не доказывает, что оно является лучшим ответом на проблему.

Основатель должен иметь возможность спросить, какие еще пути рассматривались.

Практическая схема сравнения

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

Начните с четырех вопросов.

1. Какую проблему пользователя мы решаем?

Попросите описать проблему конкретно.

«Модернизировать платформу» не является проблемой пользователя. «Клиенты не могут завершить определенный процесс без обращения в поддержку» гораздо ближе к сути. «Команда каждую неделю тратит время на сверку данных из двух мест» тоже конкретно.

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

Если предложение не может ясно это объяснить, решение, возможно, опережает диагностику.

2. Какие обходные решения существуют сейчас?

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

Спросите команду, сотрудников поддержки и людей, которые ежедневно пользуются системой:

• Что вам приходится помнить, чтобы все работало?
• Какие шаги вы повторяете, потому что продукт вам не помогает?
• О чем вы предупреждаете нового человека?
• Что бы вы сделали иначе, если бы впервые увидели этот экран?

Ответы не становятся автоматически техническим заданием. Это карта трений. Некоторые пункты будут пустяковыми. Некоторые выявят более глубокую проблему. В любом случае теперь у вас есть что-то реальное, что можно сравнить с предлагаемой инициативой.

3. Какие есть варианты, кроме создания новой системы?

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

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

Вариант «минимальное изменение» важен даже тогда, когда его никто не рекомендует. Он заставляет задать полезный вопрос: какое самое небольшое изменение может заметно улучшить ситуацию и почему его недостаточно?

Команда, которая может на это ответить, не обязана выбирать самый маленький вариант. Она показывает, что крупный вариант был выбран осознанно.

4. Что каждый вариант изменит в дальнейшем?

Начальная стоимость разработки составляет только часть решения.

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

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

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

Как найти небольшие исправления, которые стоит сделать

Список раздражающих вещей еще не план. Нужен способ решить, что важнее всего.

Я предпочитаю смотреть на два измерения: насколько широко проблема влияет на значимую работу и насколько сложно безопасно ее устранить.

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

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

Вот простой способ просмотреть список:

Цель не в том, чтобы превратить решения по продукту в представление с таблицами. Цель в том, чтобы перестать считать привычные неудобства нейтральным фоновым шумом.

Когда крупная инициатива все же оправдана

Иногда сравнение указывает на более крупный объем работы.

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

Крупная инициатива также может быть оправдана, если небольшие исправления будут лишь сохранять процесс, которого больше не должно существовать.

Я хочу избежать утверждения инициативы только потому, что она звучит более стратегически, чем исправление текущего продукта. Стратегия должна выдерживать сравнение с альтернативами, в том числе с менее привлекательными.

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

С какой полезной просьбы начать разговор с командой

Если перед вами крупное техническое предложение, попросите его автора перед утверждением добавить еще один раздел:

Опишите самое небольшое изменение, которое может решить проблему пользователя. Объясните, что оно улучшит, что не улучшит и почему его недостаточно.

Эта просьба меняет разговор. Обсуждение уходит от вопроса, насколько технически впечатляет предпочитаемое командой решение. Оно возвращается к проблеме, вариантам и компромиссам для бизнеса.

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

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

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