Блог

Ms project требования

Оглавление:

Администратор MS Project Server

Требования:
• Высшее техническое образование.
• Продвинутый уровень использования продуктов MS Office (Word, Excel, Outlook, Project);
• Опыт работе с системами управления проектами;
• Опыт администрирования MS Project Server (2010)
• Знание порядка настройки Share Point Services;
• Знание основ Active Directory.
• Английский — чтение тех документации.
Желательно:
• Знание основ MS SQL Server;
• Создание и настройка отчетов Project;
• Написание скриптов.

Обязанности:
• Администрирование MS Project Server от 1 года;
• Настройка корпоративного календаря;
• Работа с пулом ресурсов;
• Настройка прав и ролей пользователей в соответствии с их ролями;
• Общий контроль работы ИСУП (открытие и закрытие изменений, корректность и полнота данных, архивирование информации);
• Обеспечение доступности MS Project Server в соответсвии с требованиями бизнеса;
• Обучение сотрудников компании работе с MS Project;
• Подготовка отчетности по проектам.

Интеграция 3SL Cradle с MS Project

Начиная с релиза 6.6. в Cradle реализована двунаправленная интеграция с Microsoft Project. Это позволяет связать каждый проект Cradle с любым количеством планов (проектов, программ) MS Project. При этом:

  • Задачи каждого плана MS Project отражаются проекте Cradle как иерархия связанных элементов.
  • Поддерживается двусторонняя синхронизация между проектом Cradle и планом MS Project.
  • Задачи Cradle могут быть назначены на пользователей Cradle, на основе чего формируются списки задач для каждого пользователя.
  • Каждый пользователь Cradle может видеть свой список задач, подсвеченный в соответствии с ходом выполнения каждой задачи, не выходя из среды проектирования — Cradle.

Какие задачи позволяет решить интеграция 3SL Cradle с MS Project?
Прежде всего — обеспечить трассировку (прослеживаемость) между проектными данными — требованиями, проектными решениями, рисками, тестами и задачами плана работ.

Такая трассировка позволяет:

  • отслеживать изменения в реальном времени,
  • быстро определять область влияния изменений,
  • вовремя проводить перепланирование,
  • более точно прогнозировать трудозатраты.

Таким образом, реализуется здравый подход к управлению — план перестает быть оторванным от реальной проектной деятельности и имеет прямые связи с артефактами проекта.

Два профессиональных инструмента за счет использования встроенного «моста» значительно повышают качество управления проектами по разработке программно-технических систем.

Как вернуть надежность MS Project Server? Устоит ли он против Облака?

Анекдот про спецов по MS Project Server с нашей группы на Facebook

— Ты кто?
— Я добрая фея.
— А почему с напильником и кувалдой?
— Вот видите как вы мало знаете про добрых фей!

Владимир Иванов
Featured Microsoft Valuable Professional

PM Consulting Services
Microsoft Cloud Acceleration Partner
Microsoft Gold Project and Portfolio Management Competency
Microsoft Gold ISV Competency

Облака создали новый стандарт надежности

Думаю многие заметили кардинальное изменение на рынке систем управления проектами в России в последние месяцы. Внедренцы и клиенты ушли в поиск альтернатив традиционным решениям. Это общемировая тенденция, по отчетам Gartner хорошо видно, что рынок меняется и изменится еще больше. Облака вошли на рынок предложив не только решения в 4 раза дешевле традиционных решений и не только небывалую совместимость с мобильными устройствами, но и главное небывалую надежность 99,8%-99,9% недостижимую на традиционных решениях.

Сам Microsoft не собирается быть Дон Кихотом воюющим против Облачной Ветряной Мельницы, фактически Microsoft предлагает заменить все семейство технологий SharePoint на их облачный аналог SharePoint Online в облаке Microsoft Office 365. Надо понимать, что Microsoft занимается бизнесом и его не волнует судьба старых партнеров и экспертов, которые отстали от развития и не освоили новые технологии. То что Microsoft завел отдельную партнерскую программу для облачных партнеров и не признает в ней даже «золотые» заслуги, и сертификаты экспертов по старым технологиям, показывает, что старых партнеров (и даже «золотых»!) в будущее он брать собирается только после кардинального обновления экспертной команды.

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

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

C одной стороны MS Project Server добился в России впечатляющих успехов. Таких кейсов как Газпром-Нефть или Кубок UEFA нет у Primavera. С другой стороны, если вдруг с подачи продавца нарушается клиентом технология установки и обслуживания MS Project Server, все может превратиться в ночной кошмар. Даже в таком случае надежность вернуть можно, однако стоимость обеспечения надежности становиться в ряде случаев запредельной. Если клиент лишь немного отклониться от технологии, то до 40% бюджета и до 50% срока внедрения может уйти только на решение проблем MS Project Server, а не на бизнес-процессы и их автоматизацию. Если проблема надежности честно обсуждалась с клиентом, то устранение ее стоит незначительных ресурсов. Но признание серьезных дефектов может повредить продажам. Сейчас для всех экспертов по MS Project Server стоит выбор как строить продажи: либо пытаться скрывать проблемы, либо их признавать и предлагать пути решения.

В любом случае, необходимо вынести в бюджет внедрений трудозатраты на техническое обслуживание MS Project Server отдельной строкой. Признание наличия серьезных технологических рисков позволяет их минимизировать и сократить бюджет технической поддержки до приемлемого. Надо перестать менеджерам терроризировать разработчиков и администраторов вопросами в стиле «почему опять висит очередь MS Project Server?«, а нужно выделить специалистам время на того, чтобы они сделали свою работу по стабилизации сервера управления проектами Microsoft. Если кому-то нужно независимое экспертное обоснование для выделения ресурсов на обеспечение надежности, перешлите спонсору проекта эту статью.

Если мы хотим работающие системы, а не игрушки, нужно перестать играть в игры утверждая, что «ошибки есть в любом программном обеспечении» и дело решается только звонками в техподдержку Microsoft. Вопрос в том, что MS Project Server далеко не «любое программное обеспечение», а уникальное, с уникальной бизнес-моделью нацеленной на заказные и отраслевые решения. Такого класса ПО больше на рынке нет. Однако бизнес-модель MS Project Server предполагающая вмешательство программистов для создания решения под заказ, перешла в другую стадию. Фактически Microsoft уже рассчитывает, что программисты исправят (обойдут) и ошибки в его продукте. Возьмем к примеру вот эту «таблетку». Если несколько снизить политкорректность и назвать проблемы своими словами эту «таблетку» нам пришлось сделать в связи с тем, что MS Project Server был не способен не просто сохранять проекты, а еще при этом разрушал базы данных клиентов. Сейчас MS Project Server 2010 зависает на публикации проекта более 4000 задач, если опять же не использовать разные «таблетки». Приключение с Service Pack1, который должен исправлять ошибки Microsoft, а на деле разрушил множество серверов заказчиков показывает, что одними только ресурсами Microsoft проблема надежности MS Project Server не решается. Все это звучит страшно для тех кто решил купить «коробку+обучение», но абсолютна не проблема если MS Project Server внедряется по правилам эко-системы SharePoint, где программист с «напильником и кувалдой» неотъемлемая часть внедрения. Однако клиент должен четко понимать что за продукт он купил, для каких целей и как обеспечивается его надежность. MS Project Server и MS SharePoint это не продукты в коробке, это полуфабрикаты для разработчиков решений под заказ.

Не конечные пользователи, а партнеры Microsoft реальные клиенты MS Project Server, фактически для партнеров Microsoft поставщик запчастей («платформы») из которых они могут собрать решение под вашу отрасль. Так получится конечный продукт. Если нарушить эту бизнес-модель, будут проблемы не только со стабильностью, но и с функциональностью. Причем если у «сборщиков решений» возникают проблемы с качеством запчастей поставщика, то они имеют варианты и другие кроме ремонта. Можно заменить запчасти с дефектами на другие без дефектов, например заменить MS Project Server целиком на решения на базе Microsoft Office 365, где это возможно. Если проблемы большие, то рассматриваются уже варианты поставок запчастей от других вендоров. Это мы тоже рассмотрим в данной статье как варианты получения стабильных решений на MS Project путем использования технологий Oracle или Clarizen.

И тем не менее, как купить и внедрить MS Project Server не попав в катастрофическую ситуацию с надежностью и добиться невероятной полноты функционала? Начнем с культуры продаж.

Повышение культуры продаж MS Project Server — главное организационное условие технологии обеспечения надежности

Вернемся к MS Project Server. Зачем Вам покупать продукт, который без специального главного шамана, достаточно просто может зависнуть, перестать отображать что-то на Web-страницах или выкинуть еще что-то поинтересней местами совершенно непредсказумым образом? Ответ прост — вы купили платформу для отраслевых решений или решений под заказ со всеми плюсами и минусами такой сделки.

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

Уникальность бизнес-модели MS Project Server, как платформы для заказных или отраслевых решений

Если у Вас ограниченный бюджет и задачи ваши просты типа «только портфель проектов и табелирование», то вопрос экономической целесообразности покупки MS Project Server открытый. Есть масса других продуктов, которые это делают и даже легче настраиваются. Именно на такой сегмент и нацелились Облачные вендоры типа Clarizen и Gartner не рассматривает MS Project Server для таких задач.

Однако Gartner ставит MS Project Server рейтинг лидера в тяжелом классе, причем выше Oracle Primavera. Неправильное предположение, что эксперты Gartner не знают о проблемах надежности MS Project Server, просто надо внимательно читать для какого класса решений они поставили рейтинг. Для этого класса проблемы надежности MS Project Server нивелируются.

Дело в том, что «лидеры» — это самые дорогие продукты по Gartner, которые могут с лучшим качеством освоить самые большие бюджеты примерно за 3 года внедрения. На поверхностный взгляд проигрывающий в надежности и функциональности MS Project Server той же Oracle Primavera вроде бы плохой выбор. Однако все наоборот и Gartner прав, Primavera — плохой выбор, а MS Project Sever таит в себе очень важную магию. Магию «кастомизаций».

Дело в том, что только Microsoft предлагает на рынок платформу программирования для создания систем управления проектами под заказ и отраслевых решений. Вы можете заставить MS Project Server адаптироваться под ваш бизнес или купить партнерское решение для вашей отрасли. Программисты применив те самые «напильник и кувалду» могут придать MS Project Server практически любую форму и удовлетворить самые безумные желания клиента. Как говорится: «Любой каприз за ваши деньги». Primavera и все остальные системы не имеют таких мощных средств разработки дополнений и программной доработки. Что выросло в Oracle — то выросло, изменению не подлежит. Ваш бизнес должен подстроится под Primavera, даже если заложенные в ней сценарии не оптимальны для него и даже если аналитики Oracle не эксперты в Вашем бизнесе. Сравнив эти два подхода Gartner справедливо посчитал, что Microsoft с его проблемами надежности меньшее зло, чем негибкий Oracle.

Gartner дважды прав, расширяемость MS Project путем программирования просто феноменальная по степени гибкости. Например наш Turbo Project фактически внедрен в ядро Microsoft Project Professional. Технологии Microsoft позволяют это сделать, поэтому кроме возможности перепрограммировать MS Project Server под себя, вам еще доступен богатый набор «готовых кубиков» из которых быстро можно складывать решения. Если заметили, программисты могут починить сам MS Project Server, если даже сам Microsoft не знает, что с этим делать. Партнеры Microsoft почти всегда могут с помощью программирования его починить, если заказчик дает на это ресурсы. Пример «таблеток» выше.

Отметим, что MS Project Server стал действительно членом семейства SharePoint, т.к. ключевым партнерам по MS Project Server пришлось пойти недавно еще дальше повторяя дорогу партнеров SharePoint. Ст. 1280 ГК РФ по-сути разрешает производить декомпиляцию продуктов в целях запуска интегрированного решения. Нам пришлось также декомпилировать 100% MS Project Server, чтобы получить весь исходный текст написанный программистами Microsoft, т.к. в ряде случаев MS Project Server не может предоставить диагностической информации о том, что с ним произошло. Приходится искать ошибки прямо в тексте программ Microsoft, вероятно следующий шаг их исправлять как это делают партнеры по SharePoint. Анализ проблем по исходным текстам Microsoft в топовых внедрениях становиться необходимостью, т.к. Microsoft Premier Support не может помочь клиентам, которые не готовы отдать ему свою базу данных для воспроизведения ошибок.

Другие публикации:  Органы государственного финансового контроля их полномочия

Проблема надежности в крупных внедрениях развилась дальше. Фактически мне приходилось в проектах Microsoft Consulting Services отключать модули MS Project Server и создавать свои собственные, т.к. местами «починка» начинала стоить дороже, чем просто переписать функциональность заново. Отметим, что в архитектуре MS Project замена родного модуля на партнерский заложена в очень многих местах. Это позволяет не только заменить модуль страдающий проблемами надежности, но и фактически снимает всякие рамки для развития MS Project Server. Недавно мы создали собственный ресурсный модуль, например, т.к. стандартные ресурсные механизмы MS Project органичены для ряда промышленных решений.

Анализируя все это надо понимать, что нет реальных альтернатив Microsoft. В 2003м году я сам выбирал платформенного вендора между Microsoft и Oracle. Для профессионала было очевидно, что технологии Microsoft тут во многих местах недостаточно функциональные и недостаточно надежные. Однако Primavera надежная как скала, но и гладкая как скала, нет ни одной ручки, за которую можно было бы ухватится, чтобы начать создавать отраслевые решения. Только интеграция с «рядом стоящими» системами, а это слишком примитивно для большинства отраслевых решений. То что сейчас как «отраслевые решения» для Primavera по-сути продаются системы на базе 1С:Предприятия показывает всю глубину проблемы с отсутствием собственной платформы. Разработка собственных механизмов табелирования рабочего времени или встроенных систем ресурсного нормирования в Primavera это невозможная задача.

Если вглядеться в этот сценарий внедрения MS Project, где он перепрограммируется, то можно отметить, что проблемы его надежности нивелируются. Если клиент достает MS Project Server из коробки для решения простейших задач, то он безусловно испытает культурный шок в первый раз столкнувшись с зависанием очереди. Однако если решение под заказ, клиент понимает, что фаза тестирования и пуско-наладок это необходимость. Поэтому клиент и внедренец всегда планируют мероприятия для обеспечения надежности и такими счастливым образом обходят проблемы продукта. В кратком изложении правильный бизнес-процесс внедрения с разрешением проблем надежности MS Project Server приведен в этом учебном фильме. У каждого партнера Microsoft свой «парашют».

Любим мы или ненавидим Microsoft, но если нам нужно решение «под себя» или отраслевое, то альтернатив MS Project Server никаких нет. Это все равно что можно любить или ненавидеть Windows — все равно купить придется.

Но если наше решение не подразумевает перепрограммирование системы и нам нужно быстро решить типовые задачи, а также воспользоваться генильным по юзабилити (интерфейсу пользователя) MS Project? Как нам получить портфель проектов и отметки об исполнении, если не через MS Project Server?

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

Какое еще ПО может быть сервером для десктопов MS Project?

Если MS Project Server со всеми его недостатками фактически не имеет разумных альтернатив для заказных решений, то десктоп MS Project в реальности практически не имеет конкурентов вообще.

Часто мы серьезно рассматриваем конкуренцию MS Project с Primavera или HP PPM. Однако стоить помнить, что десктопы MS Project — это более миллиарда долларов в год, а остальные игроки порядка 100 миллионов. Поэтому в масштабах всего бизнеса систем управления проектами для Microsoft сражение с Primavera или HP PPM это как битва великана с боевыми гномами.

Надо сказать, что если можно долго с аргументами в руках критиковать качество MS Project Server, то качество десктопов MS Project превосходное и на уровне стандартов Microsoft Office. Также много функций, также все удобно, также надежно.

Неудивительно, что после внедрения Primavera или HP PPM внедренцы Oracle и HP, которые победили MS Project Server, никак не могут избавиться от десктопов MS Project, которые так прилипают к пользователям, которые не хотят расставаться с самым удобным в мире инструментом планирования. Но решение само на поверхности — можно просто итегрировать лучшее, что делают вендоры.

Primavera Project Planner как сервер для клиентов MS Project

Primavera сама экспериментировала с тем, чтобы создать даже эмулятор MS Project Server для подключения к ней клиентов MS Project. Но высокая цена такого решения сделала его непопулярным.

Можно сделать другой вариант интеграции отказавшись от сервера Oracle и воспользовавшись скрытым потенциалом Primaver Project Planner. Конечно это Oracle не понравиться (он теряет на лицензиях в 10 раз), но это его проблемы. Главное, чтобы клиентам нравилось.

В Primavera Project Planner очень хорошие средства управления портфелем проектов, контрольными точками и бюджетированием сверху-вниз. Это исторически все встроено в сам клиент Primavera Project Planner.

Для энергетиков мы несколько раз делали решение, где портфель проектов из десктопов MS Project консолидировался именно Primavera Project Planner. Причем мы добились выполнения требований Федеральной Сетевой Компании для таких интегрированных решений.

В плане управления портфелем проектом (если говорить о готовом решении без доработок и компонент) Primavera Project Planner функционально превосходит MS Project Server, но стоит всего $2,500 против $10.000.

Недостаток в отчетности Primavera исправим путем создания заказного пакета OLAP-отчетов с выводом их в виде сводных таблиц Excel. Сама Primavera Project Planner использует SQL-сервер для хранения данных, в случае MS SQL Standard, даже не требуется отдельно покупать OLAP-сервер, Microsoft его просто подарит.

Получается решение очень дешевое, функциональное и главное надежное. Для строительных и промышленных проектов очень хорошее решение еще в плане того, что на Primavera не сделать производственный модуль с нормированием, а на базе MS Project Professional это возможно, через такие компоненты как Turbo Project.

Облако как сервер для клиентов MS Project

Другой вариант это использовать облачные сервисы для организации документооборота и табелирования. Тут кандидат понятный — Облако Clarizen.

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

Пользуясь случаем дам ссылку на новый мультфильм про Clarizen.

Решение очень привлекательное по цене/качество, т.к. стоимость Clarizen в 4 раза ниже чем MS Project Server, то что делает в MS Project Server/SharePoint программист, в Clarizen делает бизнес-консультант настройками, и главное облако никогда не падает и за это наконец отвечает вендор.

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

Но вернемся к MS Project Server, как нам его привести в чувство, если он нам нужен? Первый совет уже был — избавиться от безответственных продавцов, которые нарушают технологию. Будем теперь конкретней.

Не гонись поп за дешевизной, когда покупаешь оборудование для MS Project Server

В принципе Microsoft довольно неплохо описал как правильно установить MS Project Server в TechNet, вопрос в том, что многие IT-специалисты и продавцы считают ниже своего достоинства читать документацию к продукту.

Если читать внимательно, то можно обнаружить, что желание запихать MS Project Server со всеми компонентами в один сервер это нарушение технологии установки. Как говориться, читайте что написано мелким шрифтом для односерверной инсталляции:The guideline requirements for SharePoint Server 2010 are also valid for a Project Server 2010 installation with a small data set and light usage [Выделено Microsoft]«. Если перевести прямолинейно — ничего хорошего в односерверной инсталляции у вас не получится.

Читаем рекомендованные требования. Обратите внимание, что даже если вы ставите MS Project Server для двух с половиной пользователей все равно требования такие и не меньше. Грубейшая ошибка думать, что требования к MS Project Server просто линейно зависят от числа пользователей. Ниже рекомендуемой конфигурации по «железу» MS Project Server не просто начинает работать медленней, в нем срабатывают внутри таймауты и чаще всего просто зависает очередь сервера. Если вы поставили на меньшем по мощности оборудования и вам просто показалось, что MS Project Server работает, вы будете жестоко наказаны в дальнейшем нестабильной работой за пренебрежение требованиями инструкции.

И так минимальные требования:

  • Отдельный сервер для MS Project Sever: 4 процессорных ядра на частоте 2,5 Гц, 8 гигабайта памяти
  • Отдельный сервер для MS SQL Server. В интрукции прямо намекают, что нужно 8 процессорных ядер и 16 гигабайт памяти.

Если вы ищите решения для управления проектами для рабочей группы, симпатичные требования к оборудованию, неправда ли?:)

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

8 ядер для MS SQL Server нужны из тех соображений, что для MS SQL «бутылочное горло» в архитектуре MS Project Server и ему нужно по 2 процессорных ядра на каждый конвейер очереди. Такая мощность нужна потому, что программисты Microsoft не смогли внутри MS SQL Server реализовать множество алгоритмов на «чистом» языке SQL-запросов. Очень интенсивно используются «курсоры», профессионалы знают, что такая техника программирования способна убить даже мощный SQL-сервер, т.к. вынуждает его быть не сервером баз данных, который за одну операцию перерабатывает сотни записей, а просто медленным итерпритатором, который их перебирает по одной.

Ядро MS Project Server так устроено, что в случае если не хватает ресурсов, оно не начинает работать медленней. Поскольку ядро «многопоточное» и нужно решать задачу как синхронизировать параллельно обрабатываемые потоки данных, то разработчики Microsoft не смогли найти другого решения как поставить таймауты. Проще говоря, если не хватает ресурсов начинают внутри MS Project Server каскадом срабатывать тайм ауты и типичное следствие зависание очереди MS Project Server с фактическим блокированием его работы.

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

Отметим, что Microsoft не описал в инструкции требования к дисковым массивам и это создает у многих проблемы. По опыту могу сказать, что в большинстве случаев RAID 10 из 8 дисков достаточен.

Но особенно жестоко чувствуется отсутствие описания к дисковой системе в случае виртуализации.

Виртуализация и VMWare как фактор критических рисков для надежной работы MS Project Server

Виртуализация официально поддерживается MS Project Server, но опять же читайте, что написано мелким шрифтом. Нигде не сказано, что поддерживается виртуализация VMWare, более того передаю вам из первых рук от разработчиков MS Project Server по их просьбе, что VMWare официально не поддерживаемая платформа. Почему VMware работает плохо расскажу подробней дальше, но отмечу, что протестирована только виртуализация на Microsoft Hyper-V.

И читаем мелкий шрифт: «We do not recommend running SQL Server on a virtualized machine. The competition for resources on a virtualized machine can substantially decrease the performance of the SQL Server«. Какой интересный документ! Ранее Microsoft и VMware показывали множество тестов по «успешной» виртуализации SQL-серверов. Ведь признание того, что есть приложения практически несовместимые с виртуализацией ставит под сомнение стратегию продажи «кочующих продавцов» виртуальных систем. Однако опытные администраторы давно знают, что виртуализация SQL-серверов это просто обман некомпетентных покупателей. Microsoft даже указал не только на несовместимость с виртуализацией, но правильно указал на ее основную причину — конкуренция за ресурсы.

SQL-серверы очень сложные системы, сопоставимые по сложности с операционными системами. Внутри промышленного SQL-сервера живет система искусственного интеллекта, которая за 0.01 сек может сотворить чудо. Если просите SQL-сервер сделать операцию. Искусственный интеллект взвешивает «стоимость» работы с памятью, процессорами и жесткими дисками. Это очень тонкая система, она учитывает малейшие накладные расходы оборудования такие как лишние перемещения головок в жестких дисках и т.п. Система виртуализации живет своей жизнью и может просто отобрать какой-то ресурс «на время», если это нужно другой виртуальной машине. Придуманный SQL-сервером план (query plan) выполнения становится неоптимальным и происходит деградация до 10 раз, дальше таймауты и как мы помним MS Project Server после этого висит.

Все тесты по виртуализации SQL-серверов фикция и обман от продавцов виртуализации, т.к. они сделаны в нереальных условиях без конкуренции за ресурсы.

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

Это видно вот по какому фактору. Опытному специалисту продающему систему виртуализации хорошо известно об проблемах выше и он может их очень сильно минимизировать. Microsoft пишет как: «For the virtual machine that you are running SQL Server on, we recommend that you select the “pass through” option for the disk type (rather than dynamic, or fixed). If this is not an option, you should utilize a fixed disk size rather than a dynamically sized virtual disk«. Проще говоря, нужно отключить виртуализацию жестких дисков и создать дисковый отдельный массив для SQL-сервера. Однако если продавец виртуализации это признает начнется рушится миф об универсальности виртуализации и ее тотальной совместимости, это может быть причиной почему клиент откажется от сделки. Поэтому клиентам поставляются дорогие системы виртуализации, которые не имеют выделенных массивов для SQL-серверов. Причем делается это умышленно и зная о проблемах, которые будут от этого у клиента.

Если сравнивать Hyper-V и VMware, то в целом надо признать, что работает лучше Hyper-V при соблюдении всех инструкций, т.к. виртуализируется только MS Project Server, а не MS SQL. В среднем по империческим тестам MS Project Server быстрее на Microsoft Hyper-V, чем на VMware на 20%, но возможно именно эти 20% разделяют вас от «границы смерти», где вас ждут таймауты.

Опять же проблема не в технологии VMware, а в продавцах. Сама VMWare имеет более совершенные средства по динамическому перераспределению ресурсов процессоров и памяти между виртуальными машинами. Однако продавец не может сказать клиенту правду, что такие сложные технологии требуют серьезного сертифицированного специалиста для ее настройки. Причем именно сертифицированного и обученого самим вендором, а не «бывалого». Для MS SQL динамическое исчезновение памяти и процессоров создает также проблемы адекватности его алгоритмов такой ситуации. Влияет это не так сильно как проблема с жесткими дисками, но потерять 10% производительности можно. Опять же этого может хватить, чтобы поймать «таймауты» MS Project Server. Продавец виртуализации не может сказать клиенту правду о дорогом обслуживании редкими специалистами, т.к. клиента это может испугать. С Hyper-V ситуация лучше именно потому, что он лучше рассчитан на непрофессиональное администрирования. Ресурсы в Hyper-V чаще всего администраторы прост фиксируют и не включают динамическую балансировку.

Другие публикации:  Осаго 311

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

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

Заключительные рекомендации по надежности MS Project Server

  • Не верьте ни одному продавцу, которые не готовы вам назвать основные технологические риски и методы их разрешения.
  • Помните, если вы купили MS Project Server, то значит хотите его дорабатывать или ставить к нему компоненты, иначе ваши затраты на техническую поддержку не окупятся
  • Доработки под заказ и готовые отраслевые решения — это повод смириться со стабильностью MS Project Server, т.к. тестирование в таком внедрении это норма
  • Десктоп MS Project на порядок более надежен и стабилен, чем MS Project Server, принимая решения учитывайте это
  • Если вам не нужны доработки SharePoint для MS Project Server, изучите альтернативные сервера для консолидации планов из настольных MS Project
  • Внимательно читайте инструкции Microsoft по установке и не отступайте от них.
  • Не экономьте на оборудовании
  • Остерегайтесь виртуализации без продуманной архитектуры, предпочитайте Hyper-V вместо VMware
  • Почти всегда для внедрения MS Project Server нужен «шаман», но он может быть также бессилен, если вы кардинально нарушили технологию

Список честных шаманов по MS Project Server

Но мы не единственные на рынке, кто принципиально не строит бизнес на обмане. Вот список проверенных внедренцев.

  • Microsoft Consulting Services (звоните прямо в MCS консультантам)
  • Acceleration
  • ICS
  • Conteq
  • Bi to be
  • PMCS

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

Ms project требования

Сервис бесплатной оценки стоимости работы

  1. Заполните заявку. Специалисты рассчитают стоимость вашей работы
  2. Расчет стоимости придет на почту и по СМС

Номер вашей заявки

Прямо сейчас на почту придет автоматическое письмо-подтверждение с информацией о заявке.

Практика составления графика проекта в MS Project

Статья предоставлена редакцией информационно-аналитического журнала «Управление Проектами» в рамках совместного проекта с Финансовой академией “Актив”.

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

Для кого эта статья

Существует масса пособий по работе в MS Project. Почти все они рассказывают о технике: как пользоваться приложением, какие сущности в нем существуют, какие связи между задачами используются и т.д. Однако когда доходит до практики, руководитель проекта сталкивается с необходимостью принимать решения другого характера – какие задачи должны входить в график, как найти золотую середину между детальностью графика и удобством работы с ним, какие приемы лучше использовать, чтобы минимизировать трудозатраты на планирование? Как, в конце концов, обеспечить выполнение сроков проекта?

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

Планирование проекта

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

Если говорить об управлении сроками, то можно сформулировать следующие требования. Хороший график проекта:

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

Для того, чтобы составить такой график предлагаем следующий план действий:

1. Принять решения о способе планирования

1.1. Планирование от начала

Более привычный для большинства способ. Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.

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

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

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

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

Чтобы избежать раннего начала задач и распределить задачи во времени, можно использовать ограничения на задачи типа «Не ранее чем», «Фиксированная дата начала».

Иногда используют задержки и сдвиги между задачами.

Однако пользоваться задержками лучше по возможности меньше.

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

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

1.2. Планирование от конца

Если конечная дата проекта жестко определена, то правильнее планировать «от конца». Устанавливается дата окончания проекта, и во всех новых задачах автоматически устанавливается тип ограничения «Как можно позже».

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

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

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

2. Избавиться от лишнего и упростить план

Лишним считается все, что не помогает планировать сроки проекта.

2.1. Примеры задач, от которых можно избавиться

Рассмотрим группу задач «Управление проектом». Понятно, что задача управления проекта необходима, но она не определяет длительность проекта, а проект определяет ее длительность. Если мы сосредоточены на планировании сроков, можно ее убрать.

Задача «Поддержка». Как правило, это задача, которая начинается после запуска в эксплуатацию и имеет, как правило, фиксированную длительность (по договору), либо привязана к некоторым контрольным точкам. Можно включить ее в план проекта, но минимизировать ее детализацию. Эта задача может быть спокойно заменена в плане на две контрольные точки: Начало эксплуатации и Окончание поддержки.

План, в конечном итоге, нужен чтобы ставить задачи и проверять факт и качество исполнения. Это очень хороший критерий, чтобы определить, с какой степенью детализации его делать. В план должны попадать только те задачи, которые РП собирается ставить и проверять их исполнения. Более мелкие задачи переносятся за пределы плана — в Excel, в JIRA или в связанный план рабочей группы в MS Project.

2.2. Пример излишней детализации

Расписать задачи до отдельных шагов и действий можно, но что это дает? С точки зрения оценки длительности — ничего. Скорее, приводит к ошибке, т.к. в каждой задаче заложена значительная погрешность.

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

3. Установить взаимосвязи между задачами

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

Можем дать следующие рекомендации для выстраивания графика.

3.1. Используйте минимум видов связей

В MS Project вы можете использовать разные виды связей между задачами «Окончание-начало», «Начало-начало» и т.д. По возможности, избегайте разнообразия использования разных типов связей. Читать график с разными видами связей сложно. Его поведение графика при модификации становится трудно предсказуемым. Чем проще, чем однообразнее — тем лучше.

3.2. Не используйте связи с суммарными задачами

Рассмотрим упрощенный пример проекта, состоящего из двух этапов. Иногда план выглядит так:

В результате мы имеем неоптимальный план. Иванов и Петров будут простаивать, ожидая завершения работы Сидорова по Этапу 1. Если у нас есть задача максимально сжать график проекта, мы начнем работы по Этапу 2, не дожидаясь завершения всех работ по Этапу 1. И тогда график будет выглядеть следующим образом. Связи между задачами, в данном случае отражают последовательность работ каждого из ресурсов.

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

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

3.3. Используйте Сетевую диаграмму

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

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

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

4. Оценить длительность задач

В литературе описано много специальных и общих методик (PERT, мозговые штурмы, Дельфи и проч.). В реальности вы либо делаете оценку из собственного опыта, либо запрашиваете у экспертов или непосредственных исполнителей.

При оценке исполнителями нужно делать поправку. Учитывайте следующие факторы:

  • О достоверности оценки лучше судить, если известны предположения, их которых исходил оценщик.
  • Учитывайте психологические особенность каждого исполнителя
  • Сделать поправку длительности. Для некоторых исполнителей, исходя из опыта работы с ними, нужно делить оценку на два, для других — умножать на три.

Задачи не должны включать запас «на всякий случай». Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок. Реальность такова, что все опоздания накапливаются, а опережения съедаются. Почему так? Причины могут быть следующие:

  • «Студенческий синдром» — выучить курс в ночь перед экзаменом. И в проекте начинаем задачу когда до ее сдачи осталось минимум времени.
  • Перфекционизм — если осталось время, надо работу довести до совершенства.
  • Отсутствие доверия — «если сегодня я сделал быстрее, то в следующий раз моим оценкам не поверят, и урежут запрашиваемой мной время».
  • Возможность работать менее интенсивно — «зачем напрягаться, если есть запас по времени?»
Другие публикации:  Средства местного бюджета это собственность

Поэтому придерживайтесь следующих правил при планировании работ:

  • Вероятность выполнения в указанный срок установите в 50%. Это сократит оценку длительности по сравнению с 90% оценкой вероятности примерно вдвое. Сокращение времени позволит добавить в график временные буферы, которые вы будете расходовать из-за неизбежного опоздания по задачам. О добавлении буферов смотрите ниже.
  • Ресурсы не должны быть перегружены. Люди не должны выполнять несколько задач одновременно. В этом случае их производительность будет максимально возможной.

5. Избавиться от распараллеливания задач

Часто можно увидеть в планах параллельные задачи, назначенные на одних и тех же исполнителей. Например,

Очевидно, РП отдает управление последовательностью и приоритетом задач консультантам. Тогда, с точки зрения планирования, достаточно было бы одной задачи «Функциональный блок Контроль», назначенной на Емельянову и Тену. Наличие пяти параллельных задач не имеет смысла. Все ресурсы перегружены, трудоемкость и длительность задачи не оценена, приоритеты не понятны.

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

6. Выровнять ресурсы

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

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

В MS Project имеется функция выравнивания ресурсов. Эта функция расставляет задачи с учетом связей между задачами и ограничения по максимальной загрузке каждого ресурса и приоритета (поле «Приоритет»). Не всегда это приводит к нужному результату. План становится слишком длинным, а ресурсы недогружены. Задачи привязываются в плане к конкретным датам, что мешает их перепланировать. Можно добиться более адекватного плана в ходе автоматического выравнивания с помощью пересмотра зависимостей и расстановкой приоритетов, но это очень кропотливый и трудоемкий процесс.

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

Например, модифицируем предыдущий пример:

В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова. Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней. Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.

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

7. Исключить жесткую привязку задач к датам

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

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

8. Выявить критический путь

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

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

  • Уделять задачам критического пути ежедневное внимание, контролировать готовность всех необходимых ресурсов для их выполнения.
  • Мотивировать участников на сокращение длительности выполнения задач критического пути, не допускать отвлечения на другие задачи.
  • Использовать временные буферы, страхующие отклонение по срокам.

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

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

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

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

Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».

9. Добавить временные буферы в график

Добавление буферов в план позволяет избежать нарушений конечной даты проекта или этапа при неизбежном изменении сроков по задачам.

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

В результате, опоздания всегда накапливаются, а опережения — практически никогда.

Выход следующий – избавиться от резервов в задаче и вынести их в общий буфер проекта. Установить целевую вероятность выполнения задачи в срок в 50% Это значительно сокращает оценку сроков по каждой задаче, согласно статистике – вдвое. В половине случаев он будет нарушен. И это может быт не вина исполнителя, а влияние обстоятельств и неправильной оценки. При таком подходе вы не будете наказывать исполнителей за нарушение сроков, а относиться к этому как к неизбежному.

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

Различаются буферы проекта (этапа) — запас создаваемый в конце критической цепочки. И питающие буферы — временные резервы на входе в критическую цепочку, страхующие поток задач вне критического пути.

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

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

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

10. Проанализировать график

Далее мы переходим к тому, для чего, собственно мы проделывали все предыдущие шаги, непосредственно к работе с графиком.

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

10.1. Сокращение сроков

Посмотрим, нельзя ли сократить этот график. Самые длинные задачи — номер 17 и 21. 18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.

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

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

10.2. Риски, связанные с графиком

Интересно посмотреть на график проекта с точки зрения управления рисками. Какие риски может обнаружить график проекта?

  • Параллельное выполнение множества блоков работ или функциональных направлений. Необходимо решить, влечет ли опоздание одного из них серьезные последствия для всего проекта? Сложные проекты включают в себя до десятка направлений. Внедряется одновременно финансы, бюджетирование, HR, логистика и т.д. Если не предусмотрены работы по интеграции и координации направлений, не заложены резервы на отклонения по каждому из направлений, нет этапа интеграционного тестирования, велика вероятность неуспеха проекта в целом, а не только срыва сроков.
  • Отсутствие периода опытной эксплуатации. Если ОПЭ невозможна, то нужно рассматривать возможность поэтапного запуска, по функциональным областям или организационным единицам.
  • Излишне агрессивный график, отсутствие или недостаточный размер резервов. Об этом уже говорили. Такой проект вероятнее всего опоздает.
  • Этапы проекта или ключевые работы идут внахлест, с перекрытием. Во многих случаях это увеличивает риск переделки по уже выполненным задачам.
  • Если в графике отсутствуют работы и вехи, закрепленные за заказчиком, то возможно, мы плохо контролируем работы со стороны заказчика. Необходимо обратить внимание на то, что некоторые работы могут быть некорректно отнесены к зоне ответственности исполнителя.
  • Отсутствие в графике вех, означающих формальную приемку работ, может означать, что мы не до конца понимаем, какие промежуточные результаты и в какой момент должны подтвердить. А это чревато проблемами при сдаче результатов в конце проекта.

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

График проекта становится реальным инструментом управления в руках руководителя проекта, если график составлен с умом и следуя определенным стандартам. Владение инструментом и методами позволяет управлять сроками проекта гораздо эффективнее, с меньшими трудозатратами времени.

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