Технологии проектного управления – Scrum, Kanban, PRINCE2 и другие

Содержание

Современные технологии управления проектами

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

Компьютерные
программы управления проектами используют
для решения следующих основных задач:

  • структуризации
    и описания состава и характеристик
    работ, ресурсов, затрат и доходов
    проекта;

  • расчета
    расписания исполнения работ проекта
    с учетом всех имеющихся ограничений;

  • определения
    критических операций и резервов времени
    для исполнения других операций проекта;

  • расчета
    бюджета проекта и распределения
    запланированных затрат во времени;

• расчета
распределения во времени потребности
проекта

в
основных материалах и оборудовании;

  • определение
    оптимального состава ресурсов проекта
    и распределения во времени их плановой
    загрузки;

  • анализа
    рисков и определения необходимых
    резервов для надежной реализации
    проекта;

  • определения
    вероятности успешного исполнения
    директивных показателей;

  • ведения
    учета и анализа исполнения проекта;

• моделирования
последствий управленческих воздействий
с целью принятия оптимальных решений;

Программные
средства управления проектами установлены
во всем мире на миллионах компьютерах
— только пакет Microsoft Project установлен
более чем на двух миллионах компьютеров.

На
Российском рынке программных средств
управления проектами представлены
пакетами, сильно различающиеся своими
функциональными возможностями и ценой.
К недорогим программам (до 1000 долларов)
можно отнести американские пакеты
Microsoft
Project,
Time
Line,
CASuperProject,
SureTrak.
Разработчики этих программ особое
внимание уделяют легкости использования
и обучения.

Из
профессиональных пакетов (до 15 000
долларов) на отечественном рынке
представлен российский пакет Spider Project
и американские Artemis Schedule Publisher, Primavera
Project Planner, Open Plan, Artemis Project View. Эти пакеты
ориентированы на широту функциональных
возможностей управления2.

менеджер
проекта и принцип формирования команды
проекта

Менеджер
команды проекта это единственное лицо,
которое отвечает за все происходящее
в проекте.

Менеджер
команды проекта

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

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

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

Менеджер
команды проекта

Имеет
уникальную, четко поставленную цель в
каждом проекте Руководит проектом,
существование которого ограничено во
времени

Управляет
временной командой, причем ее состав
за время проекта

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

Может
не быть специалистом предметной области
проекта

По
окончании каждого проекта может оказаться
«временно безработным» Карьера в
основном «горизонтальная», рост состоит
в управлении все более сложными,
масштабными проектами

Главная
мотивация — бонус, зависящий от
результатов проекта

Значение
менеджера команды проекта для реализации
проекта

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

Приведем
ряд определений, дающих представление
о функциях и ответственности:

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

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

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

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

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

    Удовлетворить
    потребности участников проекта (в том
    числе команды проекта).
    Менеджер
    команды проекта должен выявить всех
    участников
    проекта, определить роли, которые они
    будут играть в этом проекте, выявить
    влияние каждой из сторон на успех
    реализации проекта и удовлетворить
    ожидания всех участников проекта.

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

    Основные
    обязанности менеджера команды проекта:

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

    2. обеспечивает
      исполнение плана проекта;

    3. решает
      вопросы привлечения ресурсов в проект;

    4. координирует
      и принимает участие в работах по
      заключению контрактов в проекте и
      контролирует их своевременное исполнение

  • закрытие;

    1. подбирает,
      подготавливает, мотивирует членов
      команды проекта,

    2. формирует
      организационную структуру проекта;

    3. определяет
      ответственность, содержание работ и
      цели для каждого участника команды;

    4. руководит
      командой проекта;

    5. отвечает
      за постоянный поиск совместно с командой
      оптимальных для проекта решений по
      соотношению прибыли и затрат;

    6. способствует
      формированию благоприятной атмосферы
      в команде проекта;

    7. способствует
      разрешению конфликтов;

    8. устанавливает
      все необходимые коммуникационные
      связи;

    9. обеспечивает
      формирование эффективных информационных
      потоков в проекте, составление и
      предоставление отчетности;

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

    11. контролирует
      и анализирует текущее состояние работ
      по проекту,­ прогнозирует возможные
      проблемы и предпринимает корректирующие
      действия;

    12. координирует
      деятельность всех участников и
      контролирует изменения;

    13. обеспечивает
      полное и своевременное закрытие проекта

  • другие
    обязанности.

  • studfile.net

    Управление проектной организацией / Habr

    Agile подходы набирают популярность из-за хорошей реализации работы с неопределенностью за счет постоянной поставки результата. Однако, почти любой Agile-процесс требует выделенной команды на проект и почти ничего не предоставляет для стратегического планирования. Реальность организацией такова, что им нужно выполнять все свои обязательства вовремя и в полном объеме имеющимися ресурсами. А с другой стороны, программно-портфельное управление — это отдельные книжки-приложения к PMBoK и до них мало кто добирается, хотя почти в любой организации есть «направления» и ограниченные ресурсы.

    Поэтому, я создал Метод управления проектной организацией «Pulse management» — Метод Пульса (далее Метод). Это набор рекомендаций и Правил на основе Теории Ограничений, Agile-подходов и проектного управления обеспечивающий выполнение обязательств Организацией вовремя и в полном объеме в условиях ограниченных ресурсов и высокой неопределенности содержания проектов.

    История

    Так получилось, что я создавал системы реального времени, постоянно работая в компаниях с высокой научной составляющей. Когда нужно делать одновременно много НИОКР (научно-исследовательских опытно-конструкторских работ), НИР и ИТ-проектов, но при этом ты не можешь нанять выделенную команду на каждый проект. При этом, каждое подразделение — это отдельный Продукт который нужно развивать участвуя в нескольких НИОКР. Иными словами, есть высокий уровень связности проектов и каждый проект выполняется для разных Заказчиков.

    С 2002 я внедряю Agile в варианте eXtreme Programming в ИТ-компаниях, как инженер, как менеджер, с 2016 года как консультант. В попытках найти лучший способ управления инженерами я перечитал всё, что есть. Но я так и не нашел ответа на вопрос «Что делать в условиях жестких сроков?». Поэтому, когда я в 2011 году занялся Теорией Ограничений я получил ответ на этот вопрос. И описанный Метод — это обобщение личного опыта и лучших практик, которые дополняют друг друга.

    Цель этой статьи познакомить вас с границами применения Метода и основной концепцией. А также пригласить к обсуждению и внедрению описанного подхода в своих организациях. Пилотное применение Метода в полном объеме (ранее я применял только отдельные элементы) за последние полгода показало очень хорошие результаты.

    Границы применения

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

    Метод Пульса предназначен для организаций базирующихся на человеческом капитале

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

    Как проверить, что вы находитесь в такой ситуации:

    1. Генеральный директор регулярно общается с Клиентами извиняясь за непопадания в ожидания (“держит оборону”).
    2. В компании «рваный» ритм поставки, Клиенты не получают обещанное и неизвестно когда получат.
    3. Руководители проектов находятся в постоянном стрессе
    4. Необходимо ручное управление задачами руководителем.
    5. У инженеров постоянно не хватает времени на выполнение задач.

    Узнали себя? Тогда идём дальше!

    Что определяет Метод

    Раз мы разобрались с границами применения, то сразу рассажу что Метод определяет, а чего нет.

    Метод определяет основные правила игры:

    1. Метод определяет Правила планирования проектов и работ в спринте
    2. Метод определяет Правила выставления приоритетов в портфеле проектов
    3. Метод определяет Правила контроля выполнения работ
    4. Метод определяет Правила проведения совещаний и других необходимых мероприятий

    И некоторые другие Правила. Правила — программируют Организацию.

    Концепция метода

    Организация в трёх измерениях

    Метод построен на трёхмерной модели организации. Организация должна расти в трёх направлениях одновременно. Если будет перекос в какую-либо сторону, то появляются дисфункции Организации.
    Три измерения организации

    Метод Пульса охватывает все 3 вершины треугольника:

    1. Цели — В организации должны непрерывно ставится цели для того, чтобы выполнять обещания и искать новые возможности для роста на рынке. Это направление коммерческого роста, иными словами «про деньги и развитие».
    2. Процессы и Правила — Необходимо непрерывно совершен­ствовать бизнес-процессы и договариваться о правилах.
    3. Технологии и профессионализм — необходимо непрерывно повышать квалификацию специалистов и улучшать технологии проектирования и производства.

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

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

    Потоки принятия решений

    Все принимаемые решения в Организации можно разделить на Потоки принятия решений. Каждое решение принятое на своём уровне приводит к большим изменениям в Потоке следующего уровня.


    Потоки принятия решений

    Поток реализации

    Поток реализации — это поток работ, которые нужно выполнить для получения результатов. Именно результаты Потока Реализации приносят доход и удовлетворённость Клиента.

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

    Поток управления — поток управленческих решений влияющих на качество Потока Реализации. Поток управления может, как ускорить Поток Реализации, так и замедлить его. Поток управления ставит Цели в поток Реализации. Поток Управления “программирует” Поток Реализации.

    Поток улучшений

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

    Применение

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

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

    Заключение части

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

    Продолжение следует.

    PS: Но, если хочется всё и сразу, то есть методичка «Pulse Management: Управление проектной организацией».

    habr.com

    Технологии управления проектами фирмы «1С»

    Технологии > Технологии управления проектами

    Технологии управления проектами фирмы «1С»

    Фирмой «1С» разработаны технологии управления проектами, которые удовлетворяют большинство потребностей в организации эффективного и результативного процесса запуска информационной системы в зависимости от масштабов проекта, размера объекта автоматизации, внедряемого программного продукта, количества заинтересованных сторон, объемов доработок типового или отраслевого решения и ряда других факторов.

    Заявка на услуги
    ЦКТП

    Назначение технологий управления проектами

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

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

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

    Основная задача управления проектами создания ИС — снизить негативное влияние этих факторов на проект и постараться воспользоваться благоприятными возможностями. Для решения этих задач фирмой «1С» разработаны технологии управления проектами.

    Валерия Шлеенкова, руководитель подразделения фирмы «1С», бизнес-форум 1С:ERP 2015, секция для ИТ-директоров

    Технологии управления проектами фирмы «1С»

    Фирмой «1С» разработаны технологии управления, направленные на эффективную организацию проектов внедрения информационных систем на базе платформы «1С:Предприятие 8». Индустриальные подходы к управлению проектами позволяют в значительной степени сэкономить время и ресурсы в проектах внедрения за счет проработанных типовых базовых элементов жизненного цикла проекта: выходной продукции по проекту, описания выполнения ключевых процессов, шаблонов проектной документации и т. д.

    В настоящее время разработаны и применяются следующие технологии:

    Технологии управления проектами фирмы «1С» позволяют удовлетворить большинство потребностей в организации эффективного и результативного процесса запуска информационной системы в зависимости от масштабов проекта, размера объекта автоматизации, внедряемого программного продукта, количества заинтересованных сторон, объемов доработок типового или отраслевого решения и ряда других факторов, которые необходимо учитывать при выборе технологии управления проектом для конкретного проекта.

    Позиционирование технологий управления проектами, разработанными фирмой «1С», показано ниже.

    Для того чтобы успешно работать с рисками в проектах, в технологиях управления проектами фирмы «1С» определено следующее:

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

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

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

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

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

    Результаты применения технологий управления проектами фирмы «1С»

    Перечисленные выше, а также другие элементы технологий управления проектами, которые предоставляются фирмой «1С», позволяют:

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

    Соответствие стандартам и рекомендациям

    Технологии управления проектами внедрения, предлагаемые фирмой «1С», разработаны в соответствии с рекомендациями и требованиями мировых и отечественных стандартов, таких как:

    • «Руководство к своду знаний по управлению проектами PMI PMBOK»;
    • рекомендации по использованию agile-подходов к организации разработки программного обеспечения, такие как eXtreme Programming (XP) и SCRUM;
    • стандарты ISO 9001 и ГОСТ Р ИСО 9001 «Системы менеджмента качества. Требования»;
    • других рекомендаций выдающихся практиков в области разработки и внедрения информационных систем.

    Поиск по разделу

    технологии

    Отзывы заказчиков

    07.11.2019

    1С:ITIL — новая редакция 1.2

    Вышла редакция 1.2 продукта 1С:ITIL с использованием машинного обучения для интеллектуальной классификации обращений и подбора ответа из базы знаний.

    consulting.1c.ru

    Технологии проектного управления: курсы по управлению проектами

    Управление проектами — ряд последовательных действий, которые направлены на достижение единой (заданной) цели, действия эти согласованы, взаимосвязаны, при выполнении действий команда оперирует ресурсами (время, труд, деньги, материалы, пространство, энергия), работами, объемами, качеством и рисками. На действия наложены ограничения по ресурсам. Широкому кругу специалистов (специалистам по контролю качества, IT-менеджерам, руководителям отделов, разработчикам программных продуктов, сотрудникам проектных и сервисных отделов) необходимо познать науку управления проектами.

    Технологии проектного управления

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

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

    На курсах «Управления проектами» Вы сможете:

    • узнать, как происходит управление проектами в соответствии с международными стандартами;
    • познакомиться с методологией управления проектами;
    • познакомиться с практическим применением международных стандартов управления проектами;
    • проанализировать свою деятельность по управлению проектами;
    • найти пути решения проблем своего управления проектами;
    • получить помощь в подготовке к сертификации PMI;
    • поучаствовать в ролевых играх на тему «Управления проектами», тем самым попробовать применить полученные знания по курсу.

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

    www.prostoy.ru

    Управление проектированием — Википедия

    Управление проектированием — это организационно-техническая деятельность, которая в рамках условий поставленной задачи позволяет наилучшим образом разработать проектную документацию на новую продукцию[1].

    Понятие проекта и проектирования[править | править код]

    Работа любого предприятия состоит из постоянного решения разных производственных задач[2]. Часто ответственные внутрипроизводственные задачи и задачи по разработке сложной научно-технической продукции называют проектами. Продуктами проекта могут быть продукция предприятия (результаты научных и маркетинговых исследований, проектно-конструкторская и технологическая документация на новое изделие, программное обеспечение и т. д., разработанные для заказчика) и решение внутренних производственных задач (повышение качества продукции и эффективности организации труда, оптимизация финансовых потоков и т. д.).

    Проект — это работы, планы, мероприятия и другие задачи, направленные на создание нового продукта (устройства, работы, услуги). Выполнение проекта составляет проектную деятельность.
    Применительно к разработке проектно-конструкторской документации проектная деятельность включает:

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

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

    Стороны проектной деятельности[править | править код]

    В соответствии с Гражданским кодексом, проектирование — это один из видов подрядных работ, результатом которых является продукция (проект), то есть комплект документации на другой продукт (объект проектирования, то есть материальное устройство, или выполнение работы, или оказание услуги).

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

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

    Понятие управления проектированием[править | править код]

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

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

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

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

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

    Методология управления проектированием[править | править код]

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

    Принципы проектной деятельности[править | править код]

    Рис.1. Основные части проектирования

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

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

    • Практическая полезность:
      • деятельность должна быть целенаправленной, устремленной на удовлетворение действительных потребностей реального потребителя или определенной социальной, возрастной или иной группы людей, а также на удовлетворение действительных целей предприятия;
      • деятельность должна быть целесообразной. Важно вскрыть причины, препятствующие использованию существующих объектов для удовлетворения новых потребностей, выявить вызывающие их ключевые противоречия и сконцентрировать усилия на их разрешении;
      • деятельность должна быть обоснованной и эффективной. Разумным будет использование не любого решения задачи, а поиск оптимального варианта;
    • Единство составных частей:
      • целесообразно любой объект и процесс, сложный ли он или простой, рассматривать как систему, внутри которой можно выделить логически связанные более простые части — подсистемы, единство частных свойств которых и образует качественно новые свойства системы;
      • разрабатываемые объекты предназначены для людей, ими создаются и эксплуатируются. Поэтому человек также обязан рассматриваться в качестве одной из взаимодействующих систем. При этом должно приниматься во внимание не только физическое взаимодействие, но и духовно-эстетическое воздействие;
      • внешняя, или как её ещё называют — жизненная среда, также должна рассматриваться в качестве системы, взаимосвязанной с проектируемым объектом, а процесс проектирования — как часть системы функционирования предприятия;
    • Изменяемость во времени:
      • учёт этапов жизненного цикла объекта и процесса разработки;
      • учёт истории и перспектив развития и применения разрабатываемого объекта, а также областей науки и техники, на достижениях которых базируются соответствующие разработки[4].

    Методы и модели проектной деятельности[править | править код]

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

    Эвристические методы оперируют понятиями и категориями (абстрактными, отвлеченными). Формализованные — конкретными параметрами или их группами. Экспериментальные — физическими (реальными) объектами и процессами и их характеристиками.

    Среди эвристических методов отметим следующие универсальные методы:

    • Метод декомпозиции. Лежит в основе системного подхода. Метод позволяет разложить сложную задачу на ряд простых, но взаимосвязанных задач, представить её в виде иерархической структуры. Применим к исследованию как устройств, так и процессов. С его помощью, например, уточняют цель работы (построение дерева целей), расчленяют периоды на этапы (например, понятие жизненного цикла изделия). При декомпозиции следует руководствоваться определёнными правилами;
    • Метод мозговой атаки. Служит основой коллективного решения проблем, возникших в процессе проектирования, а также подготовки и проведения продуктивного совещания;
    • Метод последовательных приближений (метод итераций). Проектирование ведется в условиях информационного дефицита, то есть в начале проекта сведения о виде конечного решения минимальны, и они пополняются и уточняются в процессе проектирования. Такая неопределенность устраняется посредством выполнения итерационных процедур;
    • Теория решения изобретательских задач (ТРИЗ). Помогает выявить истинные причины (противоречия), мешающие разработке системы, и выбрать средства для их устранения. ТРИЗ также помогает найти компромисс (разрешить противоречия) в случае возникновения конфликтов интересов.

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

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

    Хотя объектом проектирования является продукция в виде устройства, работы, услуги, в действительности в процессе проектирования работа ведётся с их моделями, вид которых постепенно уточняется от первоначальных словесных описаний до опытных образцов. И результат проектирования — проектная документация, тоже является одним из видов моделей (чертежи, полигональная модель, информационная модель), промежуточных на пути создания продукта.

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

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

    Если принять за 1 стоимость исправления проектной ошибки, обнаруженной после завершения проектирования и допущенной на этапе расчёта параметров (параметрического синтеза), то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах синтеза структуры, принципа действия, подготовки технического задания.

    Структура проектной деятельности (план управления)[править | править код]

    Рис.2. Структура проектной деятельности

    Проектирование как целенаправленная деятельность обладает определённой структурой.
    Структура проектной деятельности — это целенаправленная последовательность выполнения процедур на основе взаимодействия участников проектного процесса. Структура задаёт алгоритм (план) управления, ведущий к достижению целей проектирования, и представляет собой модель управления процессом проектирования[5].

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

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

    На каждом этапе проектирования выполняются следующие процедуры:

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

    Составление технического задания[править | править код]

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

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

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

    Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование. Специалисты считают, что грамотное ТЗ — это более 50 % успеха в решении задачи, а время, затраченное на подготовку ТЗ, — одно из лучших вложений, которые фирма может сделать в период проектирования. Недаром составление ТЗ поручается ведущим специалистам — главным конструкторам, руководителям проектов и работ и т. п.

    С другой стороны, стоит принимать во внимание слова Ли Якокки: «… беда в том, что ты учился в Гарварде, где тебе вбили в голову, что нельзя предпринимать никаких действий, пока не соберёшь все факты. У тебя 95 % информации, а для того, чтобы собрать недостающие 5 %, тебе понадобится еще шесть месяцев. За это время все факты устареют, потому что рынок развивается гораздо быстрее. Самое главное в жизни — всё делать вовремя.
    … главная задача состоит в том, чтобы собрать все важные факты и точки зрения, которые вам доступны. Но в какой-то момент надо начинать действовать решительно. Во-первых, потому, что даже самое правильное решение оказывается неверным, если оно принято слишком поздно. Во-вторых, потому, что в большинстве случаев не существует такой вещи, как полная уверенность. Вам никогда не удастся собрать все 100 % информации. К сожалению, жизнь не будет ждать, пока вы оцените все возможные просчеты и потери. Иногда надо просто двинуться вперед наудачу и исправлять ошибки по ходу движения».[7]

    В итоге ТЗ должно включать перечень целей проектирования и список предъявляемых требований:

    • Функциональная постановка целей. Изделие является лишь материальным носителем определенных функций, выполнение которых и позволяет достигать заданные цели (удовлетворять потребности). Но одну и ту же функцию могут выполнять разные устройства. Поэтому функциональное, а не предметное указание цели расширяет область возможных решений, что необходимо для поиска наилучшего. Также, функция — более четкий термин для описания сути назначения устройства. Уточнение целей и назначение соответствующих им функций — наиболее важная часть работы по составлению ТЗ;
    • Выполнение функций, реализующих заданные потребности, всегда увязывается с удовлетворением определенных требований (см. перечень типовых требований к техническим устройствам), которые делают изделия более привлекательными, учитывают и конкретизируют особенности производства и эксплуатации и т. п. Для удобства требования по виду подразделяют на три группы:
      • условия, характеризуются конкретными значениями данных (формально их можно представить в виде равенств). Например, масса изделия должна составлять 10 кг, применять сталь 40Х, место эксплуатации — тундра. Важную часть условий формирует оценка доступных ресурсов;
      • ограничения, задают допустимую область данных (формально их можно представить в виде односторонних или двусторонних неравенств). Например, вес изделия не должен превышать 10 кг, применять углеродистые стали;
      • показатели качества (которые преобразуются в критерии оптимизации), задают только перечень характеристик и направление поиска предпочтительного значения (максимальное или минимальное значение, например, вес изделия должен быть минимальным, а удобство обслуживания — максимальным). Конкретное значение показателя становится известным только в конце этапа или всего цикла проектных работ и служит мерой предпочтения в процессе поиска оптимального варианта (основой выбора окончательного варианта).

    Как и процесс проектирования, работа с требованиями также подлежит управлению. Эти процедуры хорошо отработаны в управлении требованиями к программному обеспечению.

    Стоит отметить, что приведённые в условии данные — это номинальные параметры, но было бы более правильно приводить нормированные значения этих параметров, задаваемые предельными допустимыми значениями (например, масса изделия 9,8…10,1 кг). То есть то, что считают условиями, на практике являются ограничениями в виде двусторонних неравенств. Ширина диапазона является следствием величины допуска на этот параметр.

    Для конкретизации целей и требований, заданных нечётко либо качественно, применяют метод декомпозиции.

    Синтез принципа действия[править | править код]

    Функция — цель, физический (или иной) принцип — основа её достижения. Задача синтеза принципа действия — отыскать принципиальные положения, физические, социальные и т. п. эффекты, которые составят основу функционирования будущего изделия. Это могут быть основополагающие нормы, фундаментальные законы и правила, их частные случаи или следствия. Работа ведется с принципиальными моделями и их графическим представлением — блок-схемами. Результатом этапа будет принципиальная (функционально-физическая) схема разрабатываемого устройства, причем такая, которая наилучшим образом удовлетворит требованиям ТЗ.
    Этому этапу соответствует заключительная стадия ТЗ и стадия технического предложения структуры проектирования по ГОСТ 2.103.[8]

    Оригинальность функционально-физической схемы является основой патентоспособности найденного технического решения (как правило, это — способ). С другой стороны, проведение патентных исследований[9] даёт возможность определить патентную чистоту полученного решения и подтвердить отсутствие на него права собственности.

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

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

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

    Структурный синтез[править | править код]

    На этапе структурного синтеза на основе выбранного принципа действия создаются варианты начального графического представления устройства — структуры, схемы, алгоритмы, упрощённые эскизы. Начинается процесс конструирования. Появляются параметры, характеризующие основную геометрию устройства, предложения по стандартным и готовым (покупным) узлам и агрегатам, возможным поставщикам. В соответствии с ГОСТ 2.103 этот этап включает стадию эскизного проектирования.

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

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

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

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

    Параметрический синтез[править | править код]

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

    Численное решение связано с расчетными моделями. Это могут быть известные модели (нормативные методы расчета и готовое программное обеспечение с хорошо отработанными алгоритмами решения) или разрабатываемые применительно к конкретной задаче. Выполнение технических расчетов — наиболее формализованная часть проектной деятельности.

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

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

    Действия по завершении цикла работ[править | править код]

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

    • о завершении проектирования устройства и оформлении проектной документации со сдачей её заказчику. При завершении проектирования подсистемы переходят к проектированию других подсистем, предварительно дополняя ТЗ условиями сопряжения частей;
    • о прекращении разработки данного устройства, поскольку его возможные варианты оказываются неспособными удовлетворить требованиям заказчика. Такое решение может быть принято на любом из этапов проектирования и обуславливается, прежде всего, экономическими и социально-политическими обстоятельствами. Заказчику представляется отчет о проделанной работе и объяснение причин её прекращения. Согласуются вопросы о разделении ответственности и понесенных расходов;
    • о неудовлетворительности полученных результатов (несоответствие конструкции реальным технологическим возможностям, недостаточная эффективность устройства) и возвращении на один из предыдущих этапов проектирования. В исходные данные вносятся коррективы (уточнения и дополнения), намечают план последующих действий и повторяют этапы проектных работ.

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

    В ряде случаев (важное задание, высокие требования к решению) по завершении работ проводят экспертизу проекта: внутреннюю или внешнюю (независимую). Приемка работы оформляется актами, причем проверяется не только качество результата разработки, но и комплектность документации.

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

    Инженер-менеджер Рон Дифтлер в лаборатории НАСА

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

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

    Понятие «инженерный менеджмент» иногда употребляется как синоним управления проектированием.

    История возникновения[править | править код]

    Истореографы считают, что самой старой кафедрой инженерного менеджмента является кафедра Технологического института Стивенса (штат Нью-Джерси). В 1908 году была основана Школа инженерного менеджмента. Позже в Европе появились бакалавриаты инженерного менеджмента. В 1959 году в Университете Дрексел тоже была начата программа по изучению инженерного менеджмента. Университет науки и технологии Миссури (ранее — университет Миссури-Ролла) основал кафедру инженерного менеджмента в 1967 году. Итальянская университетская система инженерного менеджмента появилась в начале 21 века. Обучение составляет 5 лет: 3 года на бакалавра и 2 — на магистра.

    Германия занимается изучением инженерного менеджмента с 1927 года в Берлине. Интересно, что в университетах и инженерных школах ГДР подобный курс обучения был создан как инженерная экономика. Стамбульский технический университет имеет отделы инженерного менеджмента (управления проектированием) с 1982 года. В Великобритании такая кафедра появилась в университете Варвик в 1980 году. В России программа инженерного менеджмента имеется с 2014 года и предлагает степень бакалавра и магистра. Во Франции она появилась в 2018 году и предлагает магистерское образование и 4-5 лет обучения. В большинстве стран Европы магистерские программы по подготовке специалистов инженерного менеджмента рассчитаны на два года обучения.

    Развитие[править | править код]

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

    Интересные факты[править | править код]

    Немало тех ученых, кого принято считать авторитетами в области инженерного менеджмента. Примером в этом отношении могут быть Тейлор, Анри Файоль, Генри Гант. Именно поэтому ранние школы инженерного менеджмента (школа научного управления, административная школа) содержали ярко выраженную инженерную составляющую.

    ru.wikipedia.org

    Проектный менеджмент в IT — как это?

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

    Из множества методологий нужна одна оптимальная и настроенная лично под нас и наш проект. Одно дело выполнять шаблонные задачи строго по скриптам из книги, другое — методом проб и ошибок вырабатывать свои специальные инструменты для учета приоритетов компании. Поэтому проектный менеджмент (PM), то есть методология управления компанией с делением всей работы на проекты, становится популярным во всех отраслях.

    Что такое проектный менеджмент

    Многие компании только сейчас переходят от классической (отработанная, часто бюрократическая схема) к проектной (каждая задача отдельно, делегирование ответственности) модели управления. Общий менеджмент для предпринимателя сводился к тому, что есть руководитель и исполнитель задачи. Дисциплина взаимодействия зависела от того, как прописано в шаблоне. Шаблон же был вбит в разумы всех одинаково лет этак 20-30 назад. Только этот шаблон уже не применить к новым условиями мирового рынка.

    Исторически все началось с того, что в период перестройки 90-х годов сама логика ведения бизнеса была нарушена настолько, что попытки построить новую рабочую концепцию управления в миллениум создали термин «компания-однодневка». Концепции таких компаний проверялись на прочность и только одна из 10 компаний существовала больше полугода в 2000-х. Параллельно оставались многолетние предприятия, кардинально меняясь каждые лет 5 чтобы выжить в период перемен.
    В 2010-х информационный взрыв интернета сделал доступной всю разрозненную базу наработок европейского и американского бизнеса. Из тонн полезной и мусорной информации вроде «что такое управление проектами и современный менеджмент», «как распределять обязанности, правильно предугадывать и сокращать риски» предприниматели до сих пор выбирают крупицы знаний, применимых именно в их компаниях.

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

    В IT project management (PM) — это дисциплина, что объединяет процедуры, принципы и политику ведения бизнеса. Она руководит проектом от разработки концепции до завершения проекта.

    Общий (функциональный) и проектный менеджмент отличается тем, что:
    • функциональный стабилен. Цель: поддержать и преумножить. Есть отработанный шаблон, он работает постоянно.
    • проектный изменчив. Цель: результат любой ценой. Есть deadline.

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

    Международная Ассоциация Управления Проектами (IPMA) провела исследование, по результатам которого новый подход сэкономит вам около 20-30% времени и 15-20% ресурсов.

    Управление IT проектами vs другие сферы бизнеса

    Чем отличаются Информационные Технологии от других отраслей? Судя по ИТ-форумам, зависимостью программистов от гаджетов, дорогого сыра и возможности поехать на Бали. Виртуальностью всей работы и ее результатов, невозможностью использования программы без электричества в городе. Важностью для будущих поколений всех научных достижений, что возможны только благодаря компьютерным инновациям.

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

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

    В IT проектный менеджмент может идти по трем жизненным циклам проекта:
    • Прогнозируемый, он же waterfall. Традиционный подход, даже в 2010-х применяется на порядок чаще других. Поэтапный линейный алгоритм.
    • Итерационный. Современный подход, в котором расширение функционала разрабатываемого программного обеспечения с каждым новым выпуском в рамках проекта.
    • Адаптивный. Agile, Scrum и другие методы. Цели компании и стратегия развития может меняться независимо от первоначального плана.

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

    Составлять собственную систему или применять существующую методику к руководству проектами — решать вам.

    Для начала опишите свой проект по 10 функциям управления проектами:
    1. Интеграция структуры проекта. Ключевая проблема, которую решает проект. Его результат и этапы (сгруппируйте их по смыслу). Разделяй, объединяй и властвуй.
    2. Масштаб и объем работ. Количество планируемых задач, потоков и приоритеты.
    3. Время. Сроки и хронология зависимых задач, ключевые этапы.
    4. Стоимость. Себестоимость проекта (ресурсы и человеко-часы).
    5. Качество. Критерии и оценка.
    6. Закупки. Ресурсы, логистика.
    7. HR. Люди. Навыки, потенциал и продуктивность.
    8. Коммуникация. Отчет руководству, взаимодействие между персоналом.
    9. Риски и потери. Предусмотри и предотврати.
    10. Заинтересованные стороны. Инвесторы, акционеры, директора и клиенты.

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

    Методологии управления IT проектами

    Главный выбор предпринимателя при разработке программ и приложений — это подходящая методология управления. Их действительно много, на 2017-й год существуют:

    Традиционные методики:

    PMI / PMBOK «Метод». Инициирование, планирование, исполнение, контроль и закрытие. Инструкция, не метод по сути.

    Гибкая методология:
    Методики по управлению изменениями:
    Процессно-ориентированные методики:
    Другие индивидуальные методики и гибридные подходы:

    Все названные методы управления проектами мы детально опишем в последующих статьях.

    Процесс управления проектами в IT

    Разрабатывать и внедрять PM в компании стоит постепенно, проверяя на практике каждый этап и взаимодействие.

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

    Все процессы управления проектами также происходят постепенно и проходят 5 этапов:
    1. Разработка концепции, инициирование.
    2. Определение и планирование.
    3. Запуск работы и воплощение задуманного.
    4. Контроль и наблюдение.
    5. Закрытие проекта.

    Организация управления IT-проектом

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

    Самое грубое деление классической модели ролей:
    • Владельцы.
    • Исполнители.
    • Потребители.

    В коммерческих компаниях выделяют такое понятие как заинтересованная сторона. Все, кто влияет на результат и прибыль. Это стейкхолдеры (stakeholders).

    Внутренние:
    • Учредители.
    • Инвесторы.
    • Персонал.
    Внешние:
    • Поставщики.
    • Посредники.
    • Потребитель (клиенты).

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

    Все участники проекта, причастные к его созданию и потреблению, разделяются на:
    • Заказчик. Главный. Принимает все ключевые решения.
    • Собственник. Владелец всех прав собственности на продукт проекта. Часто — заказчик.
    • Инициатор. Его идея становится проектом. Любой участник проекта может им быть. Права у заказчика.
    • Родительская (головная, материнская, постоянная) организация. Организация, в которой возник и будет проект.
    • Спонсор. Предоставляет финансирование. Обеспечивает материальные ресурсы.
    • Инвестор. Вкладывает финансирование ради личной прибыли от реализации проекта.
    • Управляющий (менеджер проекта). Лично ответственный за проект перед заказчиком. Имеет право принимать решения сам.
    • Команда управления. Руководители среднего звена.
    • Команда. Исполнители. Создают продукт.
    • Контрактор, Субконтрактор, Подрядчик. Исполнитель по контракту.
    • Клиент. Потребитель продукта.

    Инструменты для управления IT проектами

    В Америке сервисы для ведения бизнеса существуют с 1987 года, у нас же заветная 1С появилась лишь в 1991 году. Развитие технологий от автоматизированного бухгалтерского учета и CRM для call-центров до полноценной виртуальной среды централизованного контроля и взаимодействия в компании было долгим, но плодотворным.

    На 2017 год инструменты управления проектами стали распространенным явлением. Развился очень разнообразный рынок сервисов, что отличаются отраслевым софтом, функциями и наличием интеграции с другими программами. Теперь они могут быть с расширениями и мобильными версиями.

    Самые популярные конкуренты среди сервисов в странах СНГ Bitrix24, Trello, Asana, Basecamp и Worksection.

    Изюминка разных технологий в том, что в них можно найти:
    1. Диаграмму Ганта для определения дедлайнов и связанных временем задач, как реализовано в Worksection.
    2. PERT диаграмму для оценки и анализа алгоритмов и способов реализации проекта.
    3. Автоматические отчеты, канбан-доски, встроенные файловые системы и многое другое.

    Отдельно рекомендуем для комфортного управления ИТ-проектом использовать структурную декомпозицию работ в виде блок-схем.

    Вердикт

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

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

    Внешние — форс-мажоры.

    Принятый невыгодный закон в стране, стихийное бедствие или закрытие границ со страной-поставщиком сырья.

    Внутренние — поломки внутри компании, которые на уровне управления сводятся к трем выводам:
    1. Никто не знает, чего хочет, пока не попробует это. Даже самое точное ТЗ не отразит все ожидания. Даже лучший продукт найдет недовольного пользователя.
    2. Попробовав, мы хотим изменить. Многие идеи возникают только в процессе личного опыта и экспериментов. Помните: если мишень движется, стоит сдвигать прицел.
    3. Даже самому большому проекту будет брошен вызов конкурентом. Чем крупнее проект, тем легче ему провалиться. Сегментируйте, дробите, детализируйте.

    Короткие итерации с фиксированным дедлайном легче контролировать, выполнить и исправить.

    worksection.com

    ТОП-4 Методологии управления проектами

    26 Мар 2015

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

    Традиционная (Каскадная) методология управления проектами

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

    1. Определение требований
    2. Проектирование
    3. Реализация (строительство, производство…)
    4. Внедрение
    5. Тестирование и отладка
    6. Установка
    7. Эксплуатация и сопровождение

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

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

    Методология управления проектами PRINCE2

    PRINCE2 (Projects in Controlled Environments) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 – это процессно-ориентированная проектная методология, которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков). Методология PRINCE2 базируется на семи принципах, семи темах и семи процессах. Принципы являются центральным элементом методологии: если хотя бы один из них не выполняется, то нельзя говорить о том, что проект выполняется в рамках PRINCE2.

    Принципы методологии PRINCE2:

    1. Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта
    2. Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов
    3. Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач
    4. Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;
    5. Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности
    6. Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта)
    7. Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска

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

    Аспекты методологии управления проектами PRINCE2:

    1. Обоснование проекта: какую ценность проект принесёт организации?
    2. Организация: каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом
    3. Качество: какие имеются требования и критерии к качеству и каким образом можно их обеспечить
    4. Планы: шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию
    5. Риски: каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде
    6. Изменение: как руководство проекта будет оценивать влияние непредвиденных задач и изменений и реагировать на них
    7. Прогресс: реализуемость проекта, выполнение планов и дальнейшее развитие проекта

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

    PRINCE2 подразумевает следующие процессы управления проектом:

    1. запуск проекта
    2. руководство проектом
    3. инициация проекта
    4. контроль этапов
    5. управление созданием продукта
    6. управление границами этапов
    7. закрытие проекта

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

    Гибкая методология управления проектом (Agile Project Management)

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

    В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:

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

    Методология Agile является гибкой и позволяет легко изменить параметры проекта, что является значимым для таких сервисно-ориентированных проектов, как разработка программного обеспечения или графический дизайн. Но это методология не подходит для проектов со строго заданными параметрами и требованиями.

    Методология быстрой разработки приложений (Rapid Application Development — RAD)

    Быстрая разработка приложений (RAD) – это проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения. Данная методология управления проектами выделяет 4 стадии проекта:

    • Планирование
    • Пользовательское проектирование
    • Быстрое конструирование
    • Переключение

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

    Рекомендации:

    • Не существует универсальной «наилучшей» методологии управления проектом – выбор определяется типом проекта и спецификой окружающей среды
    • Если вы работаете над проектом с возможными небольшими изменениями содержания работ, например, в области строительства, выбирайте каскадную модель
    • Для разработки программного обеспечения, графического дизайна и других сервисно-ориентированных проектов выбирайте Agile методологию
    • Используйте методологию быстрой разработки приложений для небольших IT проектов с сжатыми сроками
    • Если вам необходимо минимизировать риски и требуются структурированный подход в исполнении крупного или среднего масштаба проекта, выбирайте PRINCE2
    • Не бойтесь использовать другие, менее популярные методологии, если они в большей степени подходят к вашему проекту

    Как получить международный сертификат по Agile?

    Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «ICAgile Certified Professional»

    Смотрите также:

    Источник: http://www.devx.com/enterprise/explore-the-top-4-project-management-methodologies.html

    www.pmservices.ru

    Отправить ответ

    avatar
      Подписаться  
    Уведомление о