gifts2017

Безнадежные проекты: виды и причины.

Опубликовал MaxDavid (MaxDavid) в раздел Управление - Управление проектом

Недавно начал читать книгу Эдварда Йордона «Путь камикадзе (Смертельный марш)», посвященную безнадежным проектам. С самого начала я решил сделать для себя краткий конспект; потом в конспект добавились комментарии, связанные с моим видением прочитанного применительно к 1С; потом мне стало понятно, что из всего этого может получиться статья, которую неплохо было бы выложить на Инфостарт. Ведь кто знает, возможно, именно тот проект, в котором вы участвуете сейчас – безнадежен!

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

При чтении книги, прежде всего, следует учитывать следующие факторы:

1) Она написана в конце 90-х годов прошлого века, поэтому некоторые моменты (в основном технические) уже устарели; кроме того, иные из них прямо неверны применительно к 1С.

2) Автор рассматривает безнадежные проекты в основном с точки зрения крупного бизнеса, другими словами, рассматривает случай, когда в проекте занято сравнительно большое количество людей в течение длительного времени. В сфере 1С ситуация обычно противоположная: автоматизировать средний магазин могут 2-3 специалиста за пару месяцев; разработать и внедрить нетиповую конфигурацию под заказчика – от 1 до 20 человек за полгода-год в зависимости от сложности задачи и поставленных сроков.

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

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

 

Далее – собственно, конспект книги с комментариями.

В первых же строчках книги Эдвард Йордон высказывает следующую мысль: «Каким бы ни было объяснение этого феномена, я уже пришёл к следующему трезвому заключению: безнадёжные проекты являются нормой, а не исключением». Далее следует сверхзадача книги: создать руководство по выживанию в таких проектах. В ней (в книге, но не в настоящей статье) будут рассмотрены вопросы приоритетности при распределении ресурсов, кадровые вопросы, методы и средства выживания.

Определение безнадежного проекта: Йордон определяет как безнадежные такие проекты, в которых хотя бы один из следующих параметров отклоняется от нормальных значений по крайней мере на 50%.

1) Сроки выполнения.

2) Количество разработчиков.

3) Бюджет.

4) Требования к возможностям системы.

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

Еще один способ определить безнадежный проект: объективная оценка вероятности провала более 50%.

 

Опираясь на статистические исследования, Йордон утверждает, что «в среднем продолжительность проекта превышает плановую на 6-12 месяцев, а стоимость превышает бюджет на 50-100%». Подобное превышение сроков для случая 1С, полагаю, завышено (хотя очень крупные проекты, возможно, и достигают подобных задержек), но что касается бюджета – спорить трудно.

«Наиболее важной отличительной характеристикой безнадёжного проекта является его масштаб. В зависимости от масштаба можно выделить четыре категории проектов:

1) небольшие проекты – проектная команда включает менее 10 человек, работает в исключительно неблагоприятных условиях и должна завершить проект в срок от 3 до 6 месяцев;

2) средние проекты – проектная команда включает от 20 до 30 человек, протяжённость проекта составляет 1-2 года;

3) крупномасштабные проекты – проектная команда включает от 100 до 300 человек, протяжённость проекта составляет 3-5 лет;

4) гигантские проекты – в проекте участвует армия разработчиков от 1000 до 2000 человек и более (включающая, как правило, консультантов и соисполнителей), протяжённость проекта составляет от 7 до 10 лет».

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

«Может оказаться полезным помимо масштаба проекта использовать такой критерий, как количество организаций-пользователей, вовлечённых в проект. Достаточно трудно бывает удовлетворить и одного-единственного пользователя, или однородную группу пользователей из одного подразделения. Трудности, с которыми приходится сталкиваться в проектах масштаба предприятия, на порядок серьёзнее хотя бы из-за политических и коммуникационных проблем, связанных с коллективной деятельностью любого рода. В результате системные проекты, связанные с проектами реинжиниринга бизнес-процессов, часто вырождаются в безнадёжные». А вот этот критерий в случае 1С очень актуален.

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

«Нужно различать очень сложные и принципиально невыполнимые проекты». Тут Йордон цитирует John Boddie: «Наиболее нереальные проекты могут быть квалифицированы как таковые на самой ранней стадии. По-видимому, существует два основных типа таких проектов: “системы с нечёткими целями” и “очень сложные системы”».

 

Далее в книге идет перечисление причин безнадежных проектов и их краткое описание. Собственно, сами причины актуальны до сих пор, но некоторые описания устарели или неактуальны для 1С, поэтому, оставив для причин исходные названия, я слегка актуализировал описания.

Итак, причины безнадежных проектов:

1. Политика, политика, политика.

Эту причину Йордон считает основной для большинства случаев безнадежных проектов.

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

В сфере 1С такая причина довольно актуальна, правда, в основном в крупных фирмах. В мелких конторах подобный сознательный саботаж проекта скрыть трудно; кроме того, зачастую на подобных проектах зиждется благополучие всей фирмы, и отрицательный результат скажется на всех.

Рекомендации: Йордон советует отстаивать собственные приоритеты, цели и моральные ценности и пытаться все-таки вытащить проект.

2. Наивные представления маркетинговых служб, высшего руководства, менеджеров проекта и др.

«Наивность часто связана с неопытностью» - меланхолично замечает Йордон и продолжает: «люди, не имеющие представления о трудоёмкости и длительности создания нужной им системы, принимают нереалистичные решения». Случаи, когда нереалистичные решения принимаются сознательно, рассмотрены в пп.1, 6, 7.

Рекомендации: если есть вероятность того, что руководство может пересмотреть выделяемые ресурсы после того, как станет ясно, что проект нереален – как можно быстрее произвести реальную оценку проекта (Йордон рекомендует для этого применять подход RAD вместо каскадного подхода). Иначе следует всерьез подумать о необходимости своего участия в этом проекте.

3. Наивный оптимизм юности: «Мы сможем сделать это за выходные!»

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

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

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

4. Менталитет первопроходцев у неопытных предпринимателей

Эта причина проявляется у вновь открывающихся фирм, которые «недоукомплектованы специалистами и менеджерами, не имеют достаточного финансирования и слепо верят в свои шансы на успех». Для случая 1С это особенно актуально, т.к. бизнес имеет сравнительно низкий порог вхождения. Отличие от других случаев – напористость и безудержный оптимизм. Отметим, что Йордон считает в некоторых случаях такую причину положительным фактором, о чем рассуждает далее в тексте книги (суть рассуждений вкратце – подобный менталитет помогает безболезненно пережить участие в безнадежном проекте).

Рекомендации: Йордон советует трезво оценивать шансы на успех и в зависимости от этого принимать решение о своем дальнейшем участии в проекте.

5. Менталитет «Морского Корпуса» (Marine Corps): Настоящие программисты не нуждаются во сне!

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

Рекомендации: каждый решает сам для себя, устраивает ли его подобный подход. Йордон, по крайней мере, на этот случай советов никаких не дает.

6. Высокая конкуренция из-за глобализации рынка.

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

Рекомендации: тут сложно что-либо рекомендовать, каждый случай индивидуален и вряд ли удастся выделить какие-то общие закономерности.

7. Высокая конкуренция из-за появления новых технологий.

Йордон при описании разделяет два случая. Первый – компании, использующие старые технологии, вынуждены браться за безнадежные проекты, дабы не отстать от возможностей конкурентов; второй – компании берутся за внедрение новых технологий только потому, что они новые, и в результате, не имея опыта внедрения и поддержки (а иногда прямо ошибаясь в возможностях этих технологий), быстро доводят проект до стадии безнадежного. Для 1С второй случай гораздо актуальнее - вспомним появление восьмерочной платформы – сколько надежд на нее возлагалось и сколько заняло вылизывание косяков, вплоть до появления версии 8.1, сделавшей платформу более-менее работоспособной.

Рекомендации: к сожалению, на этот интересный случай Йордон опять не дал никаких советов. Собственно, в среде 1С этот случай, скорее всего, может встретиться на этапе, когда заказчик делает свой выбор, а не на этапе внедрения; соответственно, к безнадежным проектам как таковым имеет весьма слабое отношение. Как один из методов противодействия – выяснить плюсы и минусы предложения соперника, чтобы в полемике аргументировано отстоять свой вариант.

8. Сильное воздействие неожиданных правительственных решений.

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

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

9. Неожиданный незапланированный кризис.

Это может быть что угодно – уход ведущих программистов, резкое изменение условий работы (например, изначально продукт затачивался под использование какого-либо сервиса, а поставщик, предоставляющий этот сервис, обанкротился). Йордон сетует на то, что, даже если нам точно известно, когда разразится кризис, мы склонны его игнорировать, и в качестве примера приводит «проблему 2000 года», о которой все знали заранее, и все равно она стала для многих неожиданностью.

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

 

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

И напоследок – никакой пересказ не заменит оригинала. Рекомендую все-таки ознакомиться с самой книгой. Полезно.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Андрей Суханцов (&rew) 27.02.12 08:42
Жизненная статья, сталкивался со всеми причинами сам, только вот проекты не стали безнадежными, и каким-то "чудом" успешно завершались.
Особенно часто сталкивался с ситуацией 2+6 и поначалу шел на поводу у руководства, в результате заработал пару болячек. Теперь либо приходим к общему знаменателю, либо ... не приходим)))
2. popal (popal_al@mail.ru) 27.02.12 15:44
человек говорит включайте голову. И разложил по полочкам. сжато, но эффектно.
правда кроме замены каскадного ведения проекта можно использовать не только RAD, для начала согласен.
у меня тоже ситуации от 2 до 6 и кажется они всегда упираются в непомерную жадность руководства.
И ситуации становятся видны со временем, а ты уже влип. кажется пора читать маркетингово - психологические книги, похожие темой на "как определить по жестам кто лжет" ведь на словах часто все гладко
3. Дмитрий Утенков (automatizator) 29.02.12 04:30
4. Владимир G (laduk) 29.02.12 04:35
5. Анна Денисова (aimerlive) 29.02.12 15:36
Спасибо за статью, интересно прочесть.
6. Ирина Волкова (ir-ish-ka) 01.03.12 05:51
А меня 5 пункт порадовал.
Работала с такой организацией. Сначала даже тонизирует, но потом... сбежала, в общем.
Интересная статья, спасибо!
7. Сергей Алферов (SunShinne) 02.03.12 22:30
Хорошая статья. Политика, политика, политика... и еще все врут, даже сами себе.
8. Александр Рытов (Арчибальд) 07.03.12 08:30
Второй раз сижу в безнадежном политиканчком проекте...
9. Роман (AzzZ) 11.03.12 15:44
(8) Арчибальд, не устал ? ;) Приезжай к нам в Москву. Здесь даже бездельничая можно получать денюжку, а уж если работать так просто сказка.
10. Александр Рытов (Арчибальд) 13.03.12 07:48
(9) Не, не хочу. Лучше быть большой лягушкой в маленькой речке, чем маленькой лягушкой в большом болоте.
frc; Spartan; awk; +3 Ответить
11. Ирина Павленко (PAVI) 04.07.12 15:17
шансы на успешное завершение обратно пропорциональны масштабу проекта

Прямой обратной связи для 1С скорее нет.
Автор Эдвард Йордон не упомянул еще один главный признак безнадежного проекта: адекватная система управления проектом, причем как со стороны Исполнителя, так и со стороны Заказчика. И не важно, маленький Заказчик или большой (как и Исполнитель).
Пример 1. Неадекватность руководства со стороны Заказчика. Руководителем проекта со стороны Заказчика назначают директора по общим вопросам, который в обычной жизни ведает столовыми и АХЧ.
Руководитель со стороны Заказчика должен отвечать следующим требованиям:
1. Иметь административнй ресурс, достаточный для управления сотрудниками Заказчика, вовлеченными в проект.
2. Иметь возможность отвечать за последствия принятых им на проекте решений, вплоть до оплаты подписанных актов о приемке работ.
3. ЛИЧНО иметь заинтересованность в проекте, в его результатах.
4. Иметь опыт в ведении проектной работы или опираться на мнение профессионального консультанта.
Пример 2. Неадекватность руководства со стороны Исполнителя. Руководителем проекта со стороны Исполнителя назначается бывший офицер Генерального штаба. О проектах 1С на тот момент он ничего не знал, но имел большие амбиции. Он позволял себе обещать клиенту то, что выполнить было невозможно, а потом требовал решения этих проблем с исполнителей. Обращался по принципу: упал-отжался.
P.S. Если руководство адекватное, то о прочих проблемах (сроки, бюджет, требования к ИС и количеству разработчиков) договориться можно и найти компромиссное решение.

P.P.S. А тема - замечательная. Спасибо.
12. Александр Рытов (Арчибальд) 04.07.12 15:23
(11) Это упомянуто под номером 2.
13. Денис Краснов (Neco) 05.07.12 22:37
Давно читал эту книгу, даже до того как занялся 1С. Помнится у Йордана есть хорошая мысль, что "безнадежные" проекты нужно планировать и управлять, потому-что это норма и есть существенные отличия от "безнадежного" проекта и "отвратительного".
14. sbv2005 (sbv2005) 09.07.12 12:34
Да, что-то делать с безнадежными проектами еще можно. А что делать с безнадежно выбранной системой учета? Это уровень выше ... Ведь и тут бывают косяки (( В России скорее не про RAD будут думать, а о выделяемом бюджете. И вот от него и будут планировать и систему, ресурсы, и кадры и т.д. А это - неправильно.
15. Ak A (frc) 12.07.12 14:37
Считаю, что статья - желание ворошить то, что ближе лежит. В данном случае - автор занимается 1С, вот и ворошит все применительно к 1С.
А к 1С вообще ничего нельзя применить. Никакие методики или опыт.
Единственно, что может пригодиться - опыт управления людьми в проекте. Но это как-бы не 1С.
А 1С не применима в 70% проектов, где её пытаются использовать. Потому как несприпособлена в первую очередь сама.
А там, подо что она заточена - так и разговаривать нечего, делает любой левой ногой.
Бухгалтерия есть - выше головы 1С никогда уже не прыгнет.
Разве что руководство сменится.
16. Кирилл (kiros) 13.07.12 12:11
Спасибо за статейку. Только ощущение незаконченности после прочтения. Т.ч. требуем продолжения!
17. MaxDavid (MaxDavid) 13.07.12 13:41
(15)
Считаю, что статья - желание ворошить то, что ближе лежит. В данном случае - автор занимается 1С, вот и ворошит все применительно к 1С.
Ну, это довольно естественно - читая, применять прочитанное к своему опыту.
А к 1С вообще ничего нельзя применить. Никакие методики или опыт.
Это весьма спорно.
(16) Вторая часть почти дописана, на днях причешу и выложу.
18. beigka (beigka) 24.04.13 15:42
Эта книжка была первой книгой по менеджменту проектов, которую я прочитала по этой теме. Приехала разруливать тяжелую ситуацию на одном проекте, ведущим аналитиком, мне сказали - читай, чтобы понимать наши шутки)
В книге изложен негативный опыт, который всячески систематизируется и изучается и с юмором излагается.
Призываю читать книги с позитивным опытом внедрения, например "Deadline. Роман об управлении проектами" Том ДеМарко, самое оно для начала)
19. Михаил Ражиков (tango) 24.04.13 15:47
(18) beigka, было бы очень интересно, как вы попали в ведущие разруливатели, не имея понятия о тематике сабжа.
Блат?
20. beigka (beigka) 25.04.13 10:41
(19) tango, наивный оптимизм юности вместе с порядочностью и упорством, а также предыдущий ведущий специалист, который решил создать собственный джаз бенд, сделали свое дело)
21. Иван Титков (ivannn) 27.03.14 22:03
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа