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

Интересная статья, но если пункт к пункту 2 вы относите только то, что процитировали:
"2. Непрофессионализм участников проектов
«Все компании, предоставляющие услуги в ИТ, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей…». Джоэл Спольски, «Джоэл о программировании»."
то я бы еще отметил тот факт, что сами заказчики иногда не знают, что хотят, и в этом я думаю заключается их непрофессионализм... И в последствии чего и получается пункт №4.
Если все так и подразумевалось, то беру слова обратно...
P.S.-хорошие советы, тем более от Исполнителя и для Заказчика.

"По оценкам некоторых экспертов, количество таких проектов доходит до 60%".
По личному опыту считаю что это процент на уровне 75-80%, а некоторые проекты только со 2 или 3 раза получаются.

Господину, автору статьи, следует пойти поработать в команду Исполнителя.

В любом проекте присутсвуют эти причины провала.
Иногда даже несколько одномоментно.
Главное в любом проекте это умение договариваться Исполнителя и Закакзчика.
Всем бы нам адекватных заказчиков.

Дискуссия здесь неуместна - автор статьи прав на все сто. За грамотную, непредвзятую статью (ведь ИТ-специалисты никогда открыто не признаются, что дурят народ, доверчивый к техническому прогрессу))) спасибо.

Цитата
Александр Власенко пишет: Господину, автору статьи, следует пойти поработать в команду Исполнителя.

От исполнителя статью и прочитали

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

Не жадность губит It-проекты. А недостаток жадности . Все, что происходит на обычном проекте описано правильно, с хорошим юмором, кое-где переходящим в добрый сарказм. И вывод хороший - выгнать некомпетентную команду как можно быстрее А вот дискуссию на тему, что же сделать, чтобы обычный проект получился при обычной команде, можно и продолжить. У меня простой рецепт. Нужно больше денег и времени! Риски - неизбежны. ТЗ будет кривым, хоть ты у...ся. Спецы исполнителя будут сопротивляться изменениям до последнего, так, как будто бьются с врагом Родины. Будут меняться и требования, и специалисты Заказчика. В жизни не увидите полностью компетентную команду Исполнителя. Ну и что? Все это решается простым увеличением бюджета по мере необходимости. Или закладыванием рисков в начальную цену простым увеличением ее в три раза. Готовность Заказчика платить, не жадничать - очень важна. А вот готовность Исполнителя браться за крупный проект за три копейки из-за недостатка жадности и конкуренции просто опасна.

Цитата
Александр Власенко пишет: Господину, автору статьи, следует пойти поработать в команду Исполнителя.

Нет, это будет лишним. Все что надо, он уже знает. Вы обратили внимание на сарказм в рекомендации по подбору проектой команды?

Цитата
Александр Посконный пишет: Считаю, что хороший Исполнитель с опытом способен узнать Заказчика с такими "недостатками" и вовремя отказаться от проекта, если не знает как им противостоять. Иначе - это жадность, из-за которой так низок процент успешных проектов.

Это точно жадность. Порой трудно его узнать на анчальном этапе.
Это как принимать человека на работу. На собеседовании это одно, а когда начинает работать это порой бывает нечтно другое.

Цитата
Александр Власенко пишет: Господину, автору статьи, следует пойти поработать в команду Исполнителя.

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

Елена Дегтярёва,

Цитата
ведь ИТ-специалисты никогда открыто не признаются, что дурят народ, доверчивый к техническому прогрессу)))

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

Чтобы преодолеть равнодушие людей к прогрессу, искоренить потребительское отношение (к ИТ, в частности) - что только ни приходится делать.

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

В условиях, когда Исполнитель не сторонняя компания (которая имеет возможность отказаться от проекта), а часть группы компаний (пусть и равная в Совете директоров с автоматизируемым Заказчиком), такие тезисы, как:

Цитата
- мнение Исполнителя всегда важнее мнения будущих пользователей, поэтому лучше вообще не спрашивать мнения пользователей

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

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

Цитата
Елена Дегтярёва пишет: Дискуссия здесь неуместна - автор статьи прав на все сто. За грамотную, непредвзятую статью (ведь ИТ-специалисты никогда открыто не признаются, что дурят народ, доверчивый к техническому прогрессу))) спасибо.

Согласен. Но проблема скрыта намного глубже.
Есть проекты которые инициируются только ради проектов.. Тогда они на 99% провалены ещё до начала.
Эту тему мне обсуждать не интересно, мне интересно, когда проект назрел и он не обходим.
1. Проблема которая возникает.
IT -компании как и обычные люди ленивы по своей натуре, и соответственно проще продать решение несколько раз с различными "доработками", чем каждый раз начинать работу с "0". Но для заказчика с финансовой точки зрения зачастую разработка продукта с "0", окажется дешевле, чем адаптация готового продукта.

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

Итак берём лучший Вариант, у меня как у заказчика есть потребность в продукте. Я смог найти IT компанию которая "гарантирует" предоставить мне "продукт".
Вся Мы встречаемся и обсуждаем функционал и другие технические параметры продукта, проектная группа ТЗ...
Вот тут кроется 1 подводный камень, приступает к работе на основании ТЗ,а потом уже начинает дополнительно наращивать продукт адаптируя его под предъявляемые требования.
Необходимо по факту получения ТЗ, провести предварительную "на бумаге" встройку продукта в компанию.. и задача проектной команды заказчика как раз и состоит в этом. т.е на этапе примерки они должны внести корректировки в ТЗ.. - назовём этот этап 1-я примерка.
2-этап (2-я примерка) необходим для того, чтобы понять возможно ли создание такого продукта силами исполнителя и выяснения какие возможности "роста" нужно заложить в продукт. Соответственно ТЗ опять изменяется и дополняется.
3-этап окончательная примерка "на бумаге", уточнение мелких (но очень важных) деталей и согласование сроков между заказчиком и исполнителем.
Только после этого исполнитель может приступать к разработке продукта и инсталляции его в компанию заказчика.
Да проблемы возникать будут, но положительный результат гарантирован в 95 случаях, при этом заказчик получает оптимальный (цена/качество) для него продукт, а исполнитель минимизирует любые" свои расходы при создании продукта.

Нужно не забывать, что заказчик имеет только потребность, но он сам ещё не знает какой именно продукт ему нужен сейчас и будет нужен завтра. Задача исполнителя как профессионала как раз и помочь получить заказчику нужный ему продукт.

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

Цитата
Денис Милованов пишет: IT -компании как и обычные люди ленивы по своей натуре, и соответственно проще продать решение несколько раз с различными "доработками", чем каждый раз начинать работу с "0". Но для заказчика с финансовой точки зрения зачастую разработка продукта с "0", окажется дешевле, чем адаптация готового продукта.

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

Статья мне категорически НЕ ПОНРАВИЛАСЬ!
Я бы назвал ее (статью) – «дурацкой». А как иначе…

Описывается взаимодействие ЗАКАЗЧИКА неизвестно зачем устанавливающего у себя систему и не в состоянии определить цель и требования к системе, для краткости назовём ЗАКАЗЧИК-дурак.

С другой стороны ИСПОЛНИТЕЛЬ, который не знает цели, требования заказчика, не понимает проблемы заказчика, и при этом, БЕРЁТСЯ делать ЧТО-ТО не зная что. Для краткости назовём ИСПОЛНИТЕЛЬ-дурак.

Так вот, автор описывает взаимодействие одного «дурака» с другим «дураком» и смакует их «дурацкие» проблемы.
Заканчивает автор статью «дурацкими» (в смысле для дураков) советами.

Ну как НЕ НАЗВАТЬ эту статью «дурацкой» и вредной как для НОРМАЛЬНЫХ исполнителей, так и для НОРМАЛЬНЫХ заказчиков???

Почему считаю статью ВРЕДНОЙ?
1. Она не дает советы НОРМАЛЬНЫМ участникам процесса.
2. Она не указывает НОРМАЛЬНЫМ исполнителям и заказчикам на «подводные камни» и не показывает, как избежать неприятности.
3. Она ничему не учит!
Но если кто и прочел статью до конца, то мой (личный) совет – не будьте дураками!!

Денис, хотел бы я посмотреть сейчас, какая коммерческая компания (не госкомпания!), готова (перефразируя Вас) "потратить кучу денег, ради потратить кучу денег"... Не знаю, вообразить себе даже не готов...

Далее,

Цитата
когда проект назрел и он не обходим

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

Могу порекомендовать к чтению (есть в интернете):

Автор : Эдвард Йордон
Название книги : Путь камикадзе [Смертельный марш]
Аннотация :
Книга Эдварда Йордона «Путь камикадзе» представляет собой полное руководство по выживанию в безнадёжных проектах, предназначенное для разработчиков программного обеспечения. Практически каждому разработчику ПО и менеджеру приходится сталкиваться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом, т.е. проектами, обречёнными на неудачу. В условиях реинжиниринга корпораций безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордона является руководством по решению следующих проблем: выживание в проектах, обречённых на неудачу; достижение оптимальных соглашений во время переговоров; управление персоналом и расстановка приоритетов; выбор средств и технологий; определение момента, когда уже пора выйти изпроекта. Эдвард Йордон применяет свою уникальную технологию и интуицию менеджера к наихудшим вариантам софтверных проектов, показывая, как максимально повысить шансы на успех, или, по крайней мере, вывести вашу карьеру из-под удара. Шаг за шагом Йордон проходит все стадии жизненного цикла проекта, учит менеджеров и разработчиков правильно вести себя с заказчиками и оптимально использовать доступные ресурсы, включая людей, средства, процессы и технологию. Учитесь проявлять необходимую гибкость при проведении переговоров, расставлять осмысленные приоритеты и… вовремя выходить из проекта. Если вам когда-либо требовалось совершить невозможное, «Путь камикадзе» – ваша книга.


Дата : 1997

Денис Милованов,

Цитата
IT -компании как и обычные люди ленивы по своей натуре, и соответственно проще продать решение несколько раз с различными "доработками", чем каждый раз начинать работу с "0". Но для заказчика с финансовой точки зрения зачастую разработка продукта с "0", окажется дешевле, чем адаптация готового продукта

На чем основано это утверждение? Я с ним не согласен, это неправда.
Современные программные продукты давно имеют блочную архитектуру, стандартизированные процедуры. Это конструктор, иные модули которого можно запустить в работу в первую неделю. За модульными системами - будущее, ибо они уже в базе покрывают минимум 50% типовых бизнес-операций. Модульные системы во многих случаях являются для бизнеса даже носителем знаний, энциклопедией "как надо работать".

Утверждение ИТ-компаний: "наше конкурентное преимущество - это то, что мы разработаем систему с нуля под Вас, именно под Ваши потребности и структуру" - это чистой воды развод и некомпетентность.

Цитата
Александр Абрамов пишет: Я уж не говорю про такие утопичные вещи, как "структура", "вменяемые требования", "готовность аккуратно работать над ТЗ", "возможности роста", "штабная игра на бумаге".. Над каждым из этих слов я готов пролить слезу счастья, это где бывают такие Заказчики?

Как-то они существовали до Вас? Значит всё, что перечислено они могут (теоретически). Ваша задача получить в конечном итого деньги при этом минимально на это потратится.
Так решайте свою задачу.. тем более что мы не рассматриваем вопрос как Вам к ним попасть.. Вы уже у них, Вы пришли..
Так действуйте, ПОМНИТЕ ВЫ СПЕЦИАЛИСТ В СВОЕЙ ОБЛАСТИ!!!! И пока вы своими делами и поступками это не опровергните.. Вас будут СЛУШАТЬ и к Вам прислушиваться.
Мой способ всегда давать выбор заказчику, Всегда!!! Но всегда я даю ему выбрать из 2-х предложенных мною вариантов, при этом обсуждая и разбирая с ним каждый из них.. "фишка" как говорится, что 3-го варианта нет:0

Как говорил Форд, Вы можете любить любую машину, любого цвета, но это точно будет черный Форд-Т..

Все остальные крики и жалобы я считаю проявлением непрофессионализма.

Цитата
Александр Абрамов пишет: Денис, хотел бы я посмотреть сейчас, какая коммерческая компания (не госкомпания!), готова (перефразируя Вас) "потратить кучу денег, ради потратить кучу денег"... Не знаю, вообразить себе даже не готов...

О уважаемый Вы ошибаетесь...
1. компании в состоянии "агонии" хватаются за всё..
2. компании с верой в технологический прогресс который их спасёт
3. холдинги с "отсутствующей" "системой управления" (Грибы дождя 2005-2007 года).
Я из Ростова-на-Дону не выходя с десяток на память Вам назову, и это только с численностью персонала до 600 человек.
А так берите любое предприятие с персоналом от 100 человек и желательно живущее на "остатках СССР", вот Вам "такой клиент".
А Ваша задача,в итоге прийти к результату описываемому в моём предыдущем посте.

Цитата

Александр Абрамов пишет: На чем основано это утверждение? Я с ним не согласен, это неправда. Современные программные продукты давно имеют блочную архитектуру, стандартизированные процедуры. Это конструктор, иные модули которого можно запустить в работу в первую неделю. За модульными системами - будущее, ибо они уже в базе покрывают минимум 50% типовых бизнес-операций. Модульные системы во многих случаях являются для бизнеса даже носителем знаний, энциклопедией "как надо работать". Я выше писал, что внедрение потребует изменения компании заказчика и породит "эффект отторжения" Это Россия уважаемый Александр, ну не типовые мы, не типовые.. Согласен, что есть компании которые... (ну скажем так более или менее используют "типовые процессы", но все остальные изобрели их сами, придумали, модифицировали и используют. Но раз они живут, у них есть деньги, значит это имеет право жить. Утверждение ИТ-компаний: "наше конкурентное преимущество - это то, что мы разработаем систему с нуля под Вас, именно под Ваши потребности и структуру" - это чистой воды развод и некомпетентность.

Если это только утверждение - согласен,
если это факт - то это профессионализм.

Может я немного неправильно расставил акценты в своих высказываниях, но я имел ввиду, что продавать голый продукт (коробочное решение) нельзя.. К продукту должно идти РЕШЕНИЕ как его применять!!! Не инструкция а именно решение..

Цитата
Как-то они существовали до Вас? Значит всё, что перечислено они могут (теоретически). Ваша задача получить в конечном итого деньги при этом минимально на это потратится.

Кто существовали? :) Непуганый жирный потребительский рынок, госконтракты, правительственное лобби, что еще там..? это всё существовало, да. Зачем думать об оргструктуре, процессах, операционной эффективности?

Цитата

О уважаемый Вы ошибаетесь... 1. компании в состоянии "агонии" хватаются за всё.. 2. компании с верой в технологический прогресс который их спасёт 3. холдинги с "отсутствующей" "системой управления" (Грибы дождя 2005-2007 года). Я из Ростова-на-Дону не выходя с десяток на память Вам назову, и это только с численностью персонала до 600 человек. А так берите любое предприятие с персоналом от 100 человек и желательно живущее на "остатках СССР", вот Вам "такой клиент".

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

Цитата
Денис Милованов пишет: О уважаемый Вы ошибаетесь... 1. компании в состоянии "агонии" хватаются за всё.. 2. компании с верой в технологический прогресс который их спасёт 3. холдинги с "отсутствующей" "системой управления" (Грибы дождя 2005-2007 года).

При этом цель проекта- Сделайте так чтобы все было хорошо.

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

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

Мне статья понравилась, материал лаконичен и доступен. Спасибо автору за описание признаков и этапов провальных проектов. Ужасная статистика по поводу провальности проектов: 60, 70, 80%. Уважаемые Заказчики, Менеджеры и Исполнители проектов будьте бдительнее...