Поздний выпуск продукта – это не смертельно

Как ни странно, поздний выпуск продукта чаще всего не является таким уж фатальным для него событием. Если опоздавший продукт обладает качеством ниже среднего, то он, безусловно, имеет все шансы провалиться, но если продукт несет ценность потребителю, нарушение графика выпуска с большой долей вероятности не вызовет продолжительный негативный эффект. Для настоящего хита не важно, вышел он на месяц или даже на год позже. Microsoft Access вышел с опозданием на несколько лет, тем не менее он все еще занимает значительную долю рынка. И обратная ситуация – окажись продукт отвратительным, кто вспомнит, что он был выпущен точно в срок?

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

Так, компьютеру PenPoint, разработанному компанией GO в 1990 году, пророчили славу прародителя поколения носимых карманных компьютеров и основоположника революции в этом направлении. Однако в 1992 году PenPoint потерпел крах, и эстафету по перевороту индустрии носимых устройств перехватил компьютер Apple Newton. После того как и Newton не смог воодушевить пользователей, на горизонте эры карманных компьютеров забрезжила новая надежда – Magic Link от General Magic. На календаре был 1994 год. Когда продажи Magic Link также провалились, на рынке карманных компьютеров наступила мертвая тишина. Инвесторы провозгласили этот сегмент рынка бесперспективным. А потом, словно из ниоткуда, в 1996 году на рынке возник PalmPilot и в мгновение ока снискал всеобщее признание. Его создатели вступили на никем не захваченную территорию с опозданием на шесть лет. Рынок всегда готов принять качественный продукт, доносящий ценность и удовлетворяющий потребности клиентов.

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

Выторговывание опций

Следствием процесса управления дедлайнами стал феномен, который я называю «выторговывание опций». Много лет назад программистов обвиняли во всех грехах из-за их привычки запутанно описывать свойства программного продукта на салфетках во время вечеринок, что, по мнению пользователей, нередко влекло за собой появление неудачного ПО. Пытаясь защититься, программисты начали выдвигать требования, чтобы руководители и маркетологи были более точными в своих запросах. Компьютерные программы работают на основе процедур, а эти процедуры с легкостью приводят к появлению новых опций продукта, так что вполне естественно, что программисты соотнесли понятие точности в запросах со списком опций. Этот список опций позволял программистам сваливать всю вину на руководителей, если продукт оказывался провальным. У них всегда находился такой ответ: «Мы здесь ни при чем. Мы добавили все опции, которых требовало от нас руководство».

Как следствие, жизненный цикл большинства продуктов начинается с документа, который имеет разные названия: «маркетинговая спецификация», «техническая спецификация» или «маркетинговые требования». Другими словами, этот документ представляет собой список желаемых опций, что-то вроде списка ингредиентов в рецепте торта. Как правило, такой документ рождается в ходе множества продолжительных мозговых штурмов, на которых руководство, специалисты по маркетингу и программисты выдумывают, какие опции сразят всех наповал, и делают краткие тезисные наброски. Излюбленным инструментом для создания списков опций обычно являются электронные таблицы, одна такая таблица может быть длиной в десяток экранов. (Одна из строк этой таблицы неизменно содержит опцию «хороший пользовательский интерфейс».) Предложения по новым опциям могут также исходить от фокус-групп, появляться в ходе исследований рынка и анализа конкурентов.

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

Программисты проводят черту в середине списка. Все, что выше этой черты, будет реализовано, говорят они, а все, что ниже «линии смерти», откладывается на потом или вовсе игнорируется. Они ставят руководство перед выбором: дать больше времени на разработку или урезать количество опций. Несмотря на то что на разработку продукта неизбежно потребуется больше времени, чем было запланировано, руководство не хочет разыгрывать этот козырь уже в самом начале проекта, потому начинается обсуждение функциональных возможностей. На этом этапе возникает множество споров и моментов, не лишенных драматизма. Опции вымениваются на время, а время падает жертвой опций. Эта примитивная словесная борьба за выгоды так естественна для природы человека, что ни одна из сторон не испытывает неудобств. Придумываются сложные параллельные стратегии. Как отмечает Ройял Фаррос из компании Т/Maker: «Стоит обвинить какую-нибудь одну опцию в срыве дедлайна, как в список незаметно прокрадется еще с десяток других запоздалых опций». В этой битве теряется видение перспективы, столь необходимое для успешности продукта.

По рассказу Фарроса, флагманским продуктом компании T/Maker был текстовый процессор WriteNow – «идеальный программный продукт для университетов. В 1987 году количество продаж копий WriteNow университетам было больше, чем количество продаж копий Word компанией Microsoft. Тем не менее мы не смогли удержать лидерские позиции, потому что не учли одной функции, крайне необходимой текстовым процессорам для университетов, – концевые сноски, чем сильно разозлили наших самых лояльных потребителей в этом рыночном сегменте. В попытках не сорвать дедлайн мы так и не смогли включить ее в спецификацию. В результате продукт вышел точно в срок, но при этом мы потеряли целый сегмент рынка».

Программисты правят бал

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

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