ИТ-проект нужно успеть запустить, пока не закрылось "окно возможностей" |
Том де Марко, глава компании The Atlantic Systems Guild.
Большинство неудачных проектов провалились не из-за ошибок исполнителей, а из-за неверной оценки сроков выполнения. Никто не осознает, что проект важно выполнить до тех пор, пока «окно возможностей» не закрылось.
В то время представлялось удивительным: как это может быть, чтобы работа над программным обеспечением оказалась сложнее, чем над самими устройствами? Понадобилось некоторое время, чтобы осознать это, но все, что мы делали, подчинялось неявной цели перебросить персонал, занятый аппаратной частью, на разработку софта. В скором времени оказалось, что именно в разработке ПО заключается вся сложность. Я пытался объяснить это менеджерам проектов, которые постоянно сетовали: «Сотрудники, занятые работой над „железом", никогда не доставляют проблем. Так что же происходит с разработчиками ПО?» Этот вопрос не терял актуальности до конца двадцатого века. Несмотря на наши очевидные успехи, нас преследовали и неудачи. Да и вообще вся литература того времени пестрит историями о многочисленных провалах.
Сегодняшнее поколение читателей вряд ли догадывается о том, что выставляемые «деревенскими валенками» разработчики того времени на самом деле принимали активное участие в укреплении мировой экономики, коммуникациях между людьми и организациями по всему миру. И вряд ли кто отдает себе отчет в том, что именно эти люди коренным образом изменили сущность фактически любого бизнеса на Земле.
В 90-х значительную часть моей практики заняла работа по оказанию помощи в судебных процессах. Конечно, все тяжбы касались неудачных проектов, поэтому я имел возможность получить представление о гораздо большем количестве таких проектов, нежели тех, в которых я сам принимал участие. Удивительно, но оказалось, что все провальные проекты в значительной степени напоминали друг друга. Представьте: по условиям контракта компания А разрабатывает систему ПО для компании B, но не успевает завершить проект или завершает его в сроки, которые выходят за рамки, оговоренные контрактом, — и контракт разрывается. Компания B подает в суд на компанию А (или наоборот), одна из сторон нанимает меня. В конце концов А и В теряют крупную сумму, а я и юристы, напротив, получаем приличное вознаграждение, но ничего при этом не меняется. На своем опыте я ни разу не сталкивался с разбирательствами из-за плохого качества выполнения работ, медленной реакции системы или неприемлемого пользовательского интерфейса. Причиной всему были просрочки. И хотя вопрос «Что происходит с разработчиками ПО?» сложен, ответ на него прост: мы периодически опаздываем.
К этому времени я начал рассказывать всем, кто только готов был меня слушать, о том, что запоздавшие проекты похожи друг на друга. Думаю, в целом я был прав, хотя объяснение на тот момент было несколько неточным. Я видел одинаковость этих проектов в том, что они потерпели неудачу из-за неверной оценки сроков выполнения, а не из-за ошибок исполнителей. Но если быть ближе к истине, то у многих проектов вообще отсутствовала какая-либо оценка сроков исполнения. Готовность продукта в январе следующего года? Почему бы и нет? Как ни странно это звучит, но столь много отличных софтверных продуктов было выпущено именно таким образом, что я в конце концов устал напоминать о важности заблаговременной оценки сроков выполнения проекта.
Я до сих пор убежден, что все сорванные по срокам проекты похожи, но — по совершенно иной причине... Вот общее, что объединяет все просроченные проекты: они слишком поздно начались. Работа над проектом, который должен быть выполнен за два года и сдан 31 декабря 2011-го, обязана начаться 1 января 2010-го. Но если проект стартует в начале 2011-го, то он обречен на провал.
«CОЗДАНИЕ ШУМИХИ ВОКРУГ РАЗРАБОТЧИКОВ, НЕ СУМЕВШИХ ВОВРЕМЯ ПРЕДСТАВИТЬ ДОСТОЙНЫЙ ПРОДУКТ, — ВСЕГО ЛИШЬ ПОПЫТКА ОТВЛЕЧЬ ВНИМАНИЕ ОТ ТЕХ, КТО НА САМОМ ДЕЛЕ НЕСЕТ ОТВЕТСТВЕННОСТЬ ЗА ПРОВАЛ»
На мой взгляд, есть три причины затянувшегося старта.
Вначале никому не хватает мужества начать проект, пока в результате конкурсного отбора не станет ясно, что он все же запускается. А когда это наконец выясняется, приходится наверстывать упущенное время и выполнять работу в авральном режиме.
Если бы проект начинался за весьма значительное время до срока сдачи, то всем участникам пришлось бы столкнуться с тем, что бюджет окажется гораздо больше, чем предполагалось изначально.
Никто не осознает, что проект важно выполнить до тех пор, пока «окно возможностей» не закрылось. Концепция «окна возможностей» объясняет, почему компания Google должна была стать первым создателем движка поисковой системы: в противном случае ее поглотили бы конкуренты. Вы скажете, что Google не является первопроходцем в этом деле, что она занялась им на 15 лет позже других? Я допускаю, что аргумент «окно возможностей» может быть несколько искусственным, но третья причина — это на самом деле замаскированная суть первой или второй.
Причина же одна, и заключается она в отсутствии конкуренции — а это верный путь к провалу дела. И обратите внимание: это не является неудачей разработчиков, вовлеченных в данный проект. Это неудача маркетинговой команды, которую обошли более сильные маркетологи из другой компании. Создание шумихи вокруг разработчиков, не сумевших вовремя представить достойный продукт, — всего лишь попытка отвлечь внимание от тех, кто на самом деле несет ответственность за провал.
В результате мы получаем проекты, которые стартовали поздно, потому что не обладали той значимостью, которая могла бы оправдать их истинную стоимость. На мой взгляд, существует много разновидностей провалов, и случаются они очень часто. Если проект приносит десятикратную ценность от расчетной стоимости, никого не будет волновать, что действительная стоимость его оказалась в два раза выше расчетной. С другой стороны, если ожидаемая выгода превышает ожидаемые затраты всего на 10%, то нарушение сроков проекта — это катастрофа. Однако вместо того, чтобы обвинять разработчиков ПО, не успевших сдать проект в срок, правильнее было бы задаться вопросом: «Почему мы беремся за проект с такой незначительной ожидаемой выгодой?» Чем громче жалобы на просроченный проект, тем больше вероятность того, что он должен был принести минимальную выгоду и был запущен с ошибочным предположением, что его можно реализовать дешево. Действительно плохо для разработчиков софта то, что они слишком часто берут на себя чужую вину.
Впервые опубликовано в журнале "CIO: руководитель информационной службы" № 1-2 за 2012 год.
Источник: Инфобизнес
Назад в раздел
