Промежуточная проверка

Промежуточная проверка

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

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

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

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

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