За много лет работы в iWink я руководил множеством ИТ-проектов. Правда, честного числа не получилось. Я ошибался, напортачил и напортачил больше раз, чем мне хочется сосчитать, что стоило многих лет напряженной работы преданных делу разработчиков, включая меня самого. Но, эй, мы живем и учимся, верно? Теперь я хочу передать уроки из моих спотыканий и оплошностей. Моя цель? Убедитесь, что ваши проекты действительно будут успешными.

Как это началось

Когда iWink начинался, я был единственным разработчиком. Но по мере того, как росла наша клиентская база, росла и команда. Больше разработчиков означало больше неудач. И, как оказалось, большая команда разработчиков может потратить значительно больше времени, чем волк-одиночка. Даже экспоненциально, как я покажу ниже.

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

Неудача в масштабе

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

Со временем я изучил несколько крупных ИТ-проектов, реализуемых государством и в частном секторе. Во многих проектах, которые я исследовал, миллионы евро и сотни лет разработки были потрачены впустую. Экстраполируя, мы могли бы тратить от 3% до 4% нашего валового внутреннего продукта на неудачные ИТ-проекты. Каждый год. Очевидно, это намного больше, чем общая стоимость глобального сокращения выбросов CO2.

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

6 причин, почему IT-проекты терпят неудачу

Это шесть сил, из-за которых ИТ-проекты терпят неудачу.

Причина 1: размер проекта

Размер проекта — едва ли не самая важная причина, по которой ИТ-проекты терпят неудачу. Он усиливает остальные пять сил, но также имеет свою собственную динамику.

В большом проекте одному человеку сложно контролировать объем проекта. По мере того, как в проект добавляется больше людей, сложность возрастает. Больше людей также означает больше линий связи и больше места для ошибок. Думайте о команде разработчиков как о точках на листе бумаги. Для соединения двух точек требуется только одна линия. Добавьте третью точку, и внезапно появятся три линии. Четвертая точка требует трех дополнительных линий, поэтому общее количество линий (мы все еще говорим здесь о линиях связи) теперь равно шести. После того, как вы наберете десять разработчиков, у вас будет сорок пять (45) линий связи.

Интересно, что этот растущий уровень сложности частично объясняет, почему добавление дополнительных разработчиков в проект, работающий с отставанием от графика, обычно не помогает. На самом деле, это может задержать его еще больше. (Если вы хотите узнать об этом больше, введите в поиск закон Брука.

Если вы запомните только один урок из этой истории, пусть это будет следующий: «Держите свои проекты как можно меньше». Если вы не можете сократить свой проект, разбейте его на небольшие части и выполняйте шаг за шагом. Не приступайте к следующему шагу, пока вы полностью не предоставите конечным пользователям результаты первого шага.

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

Причина 2: недооценка затрат

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

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

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

Но на этот раз новый мост будет построен в Австрии. Фактически, он должен быть километровой длины и более 200 метров высотой, пересекая долину между двумя очень крутыми горами. Кроме того, до строительных площадок можно добраться только на вертолете, а погода может быть довольно сложной. Что вы делаете? Удвоить предыдущую оценку? Утроить? Попробуйте подсчитать необходимое количество полетов на вертолете? Посмотреть местные прогнозы погоды? Есть так много неизвестных, вы обречены на провал.

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

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

Так что делать?

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

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

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

Причина 3: переоценка преимуществ

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

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

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

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

Существует два основных типа ценности, связанной с ИТ-проектами.

Ценность первого типа заключается в том, что ИТ может сэкономить время. Чтобы оценить время, сэкономленное новым инструментом управления персоналом, вы можете оценить количество часов, которое отдел кадров тратит на расчет сверхурочной работы для каждого сотрудника. Вы можете сделать обоснованное предположение или (гораздо лучше) поговорить с кем-нибудь, работающим в отделе кадров. Может быть, вы даже можете измерить время, затраченное напрямую. Это ваше базовое измерение. Теперь оцените, сколько времени отделу кадров придется потратить на выполнение той же работы с использованием нового инструмента. Разница во времени, умноженная на некоторую оценку затрат в час, является разумным преимуществом.

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

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

После того, как вы оценили выгоды за период времени (скажем, за год), вам нужно умножить их на срок полезного использования разрабатываемого программного обеспечения. Я видел, как использовались кратные x10, подразумевая, что разработанное программное обеспечение будет продолжать генерировать оценочное значение по крайней мере десять лет подряд. По моему опыту, десять лет — это очень большой срок. Хотя через десять лет после запуска многие программы все еще будут использоваться, во многих случаях созданная ценность будет утеряна гораздо раньше. Мир технологий движется очень быстро. Программное обеспечение может стать бесполезным из-за новых и других способов ведения дел. Бизнес-процессы и перспективы рынка могут быстро меняться. Количество пользователей может внезапно уменьшиться. Возможно, потребуется переписать программное обеспечение, потому что среда, в которой оно работает, внезапно перестала поддерживаться. В качестве общего эмпирического правила я использую предполагаемую продолжительность жизни в три года для выгод, получаемых от любого программного проекта.

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

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

Как только вы решите начать свой проект, начните его и продолжайте. Самое главное, сосредоточьтесь на завершении и не позволяйте вашему клиенту (или команде разработчиков) расширять масштаб. Может показаться разумным срывать низко висящие плоды, когда вы их видите, но вы обнаружите, что слишком легко поддаетесь следующей темной силе, которая приводит к провалу ИТ-проекта: расползанию масштаба.

Причина 4: Ползучесть области

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

Логика, вызывающая расширение области действия, часто кажется разумной и обычно следует следующему формату: «если мы собираемся обновить X, мы также должны исправить проблему Y, пока мы ее решаем». Например, «если мы переходим на Zungla для нашего хранилища, мы также должны использовать его функции резервирования, чтобы заменить нашу нынешнюю дорогостоящую инфраструктуру резервного копирования». Или: «Если мы передаем наш стек хостинга на аутсорсинг, нам также следует перейти на CI/CD».

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

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

Для большинства проектов, которые я наблюдал в iWink, дедлайн за дедлайном отставал, главным виновником был расползание масштаба. Ему подвержены все, кто участвует в ИТ-проектах. Конечные пользователи, например, приходят в восторг, когда им представляют прототип, и видят новые возможности. Точно так же разработчики натыкаются на незнакомый фрагмент кода и решают исправить не связанную с этим проблему «пока они это делают». Менеджеры, зная, что серверы будут временно отключены для установки нового программного обеспечения, предпочитают объединять функции в пакеты, чтобы максимизировать ценность.

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

Несмотря на кажущиеся рациональными оправдания расползания масштаба, выход есть. Чтобы утверждать это, нужен сильный руководитель проекта, но для успеха каждого ИТ-проекта решающее значение имеет простое утверждение: «Мы можем добавить эту функцию позже». Очень важно заморозить масштаб и как можно быстрее доставить то, над чем вы сейчас работаете. Добавьте новые возможности в список возможных будущих шагов, а затем повторите процесс выбора следующего шага вашего проекта, сравнивая затраты и выгоды. Стратегия должна быть такой: выпускать раньше, выпускать часто.

Интересно, что иногда ИТ-подрядчики намеренно не контролируют расширение масштабов. Хотите знать, почему? Я объясню в следующем разделе…

Причина 5: несогласованные стимулы

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

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

Прямое уравнение «время равно деньгам» применимо здесь напрямую. Чем дольше продолжается проект, тем больше зарабатывает подрядчик. Это создает финансовый стимул для подрядчика максимально продлить проект, не рискуя контрактом. Следовательно, меньше срочности для быстрого выполнения задач. Между тем, спешка и срезание углов для экономии времени могут увеличить риск ошибок. Если подрядчик несет ответственность за эти ошибки, у него теперь есть дополнительный стимул не торопиться.

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

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

Причина 6: невозвратные затраты

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

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

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

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

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

Однако это может привести к выбрасыванию хороших денег после плохих. Продолжение неудачного проекта не возмещает невозвратные затраты; вместо этого это часто приводит к еще более высоким затратам и трате большего количества ресурсов. Как говорится, «Когда ты в яме, перестань копать».

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

Краткое содержание

Я потратил годы на провальные ИТ-проекты. Обещал поделиться, как не повторять ошибок. Крупные ИТ-проекты всегда будут сложными, но если вы будете внимательно следить за этими шестью основными рисками, вы сможете преодолеть препятствия, подготовив почву для успешных результатов проекта.

1. Держите проекты небольшими, а крупные разбивайте на управляемые сегменты. Чем больше проект, тем больше туман непонимания и недопонимания.

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

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

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

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

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

Не будь мной. Не теряйте годы. Сделайте ваши проекты успешными. Спасти планету.