Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

Несколько лет назад мы с Дмитрием «Goblin» Пучковым записали ролик о тендере Почты России на разработку мобильных приложений. Мы подробно разобрали не только конкретную историю, но и общую ситуацию с процедурой заказа программного обеспечения в коммерческих и государственных компаниях. Прошло много времени, но ситуация не изменилась. Это было бы простительно 20–30 лет назад, когда создание цифровых продуктов для бизнеса только начиналось. Теперь, когда слово «цифровизация» уже неприлично произносить, это выглядит странно.

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

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

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

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

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

Теперь вернемся к основной теме – людям, которые работают над проектом. Выбор специалистов должен определяться объективными потребностями, вытекающими из целей и типа проекта, а также технологическими особенностями создаваемого продукта. На практике это становится ясно далеко не сразу. Формат процедуры выбора подрядчика требует определиться с требованиями к составу проектной команды в самом начале, когда происходит оценка. От количества специалистов, компетенций и профессионального уровня зависит стоимость работ и принципиальная возможность подобрать подходящих кандидатов к началу проекта. В результате судьбу проекта определяют не только преждевременные технические решения, но и люди, выбранные на ранней стадии. Каждый из них может быть отличным профессионалом, но не подходить для решения задач конкретного проекта. Универсальных специалистов не существует.

Критерии выбора исполнителей для управления неопределенностью

Какими же критериями тогда должен руководствоваться бизнес при выборе специалистов для проекта? Прежде всего необходимо перестать считать всех работников IT-отрасли «программистами». Это все равно что считать всех, кто занимается строительством «строителями». Также необходимо отказаться от мысли, что «программисты» отличаются друг от друга «сообразительностью» и при достаточном уровне способны решить любые задачи. И, наконец, не стоит рассчитывать, что «программистам» можно поставить задачу, просто «объяснив на пальцах». Но об этом мы поговорим позже.