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

27.02.12

Управление проектом

Недавно начал читать книгу Эдварда Йордона «Путь камикадзе (Смертельный марш)», посвященную безнадежным проектам. С самого начала я решил сделать для себя краткий конспект; потом в конспект добавились комментарии, связанные с моим видением прочитанного применительно к 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 года», о которой все знали заранее, и все равно она стала для многих неожиданностью.

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

 

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

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

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2770    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14297    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5852    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4699    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2746    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4184    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

09.09.2022    10664    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13087    0    Evil Beaver    17    

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

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

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