Поэтому я временно отложил в сторону книгу и привел в удобочитаемый вид часть своих записей, которые предоставляю вашему вниманию. Разумеется, вся книга, да еще с комментариями, в одну публикацию не влезла. Тема, рассмотренная в данной статье – определение безнадежного проекта и его причины. Если подобный вид статьи – адаптация положений классического труда для 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 года», о которой все знали заранее, и все равно она стала для многих неожиданностью.
Рекомендации: автор книги их не дает, но, вне зависимости от степени ожидаемости кризиса, понятно, что для его успешного преодоления потребуется некоторая избыточность ресурсов фирмы. Только в этом случае можно манипулировать ими, снимая с одних проектов и перебрасывая на другие. Если же фирма ведет несколько проектов, и каждый из них – на пределе ресурсных возможностей, то рано или поздно какой-то из них с весьма высокой вероятностью станет безнадежным из-за подобных привходящих обстоятельств.
Таковы, согласно классификации Эдварда Йордана, виды и причины безнадежных проектов. Буду признателен, если в обсуждении статьи прозвучат дополнения и интересные случаи. Буду рад, если статья поможет кому-то в формулировке своих мыслей. Буду счастлив, если она поможет кому-нибудь определить безнадежные проекты и избежать участия в них.
И напоследок – никакой пересказ не заменит оригинала. Рекомендую все-таки ознакомиться с самой книгой. Полезно.
