В чем суть управления строительством

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

В чем суть процессного управления?

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

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

Управление строительством с помощью 4D ТИМ | BIM. Часть 3. Правовые предпосылки перехода к ТИМ

• планирование,
• организация,
• контроль,
• координация,
• мотивация (по классификации Анри Файоля).

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

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

Что нужно для внедрения процессного управления?

К типичным проблемам по внедрению процессного управления относятся:

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

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

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

Выделение бизнес-процессов верхнего уровня

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

Закупка –> Доставка –> Хранение –> Продажа

Именно эти процессы играют ключевую роль в торговом бизнесе.
Обеспечивающими бизнес-процессами в данном случае будут:

• административно-хозяйственное обеспечение,
• юридическое обеспечение,
• бухгалтерский учёт,
• управление маркетингом,
• управление персоналом.

Когда процессы верхнего уровня выделены, они уже могут быть расписаны более подробно, до входящих в их состав под процессов. Например, процесс “Закупка” в компании – оптовом дистрибьюторе был расписан до следующих входящих в него подпроцессов.

Под процесс бизнес-процесса “Закупка”

• Поиск поставщиков и товаров.
• Определение потребности в товаре.
• Формирование заказа.
• Заказ товара.
• Возврат товара поставщику.

При этом необходимо указывать входы и выходы каждого подпроцесса, а также ответственные подразделения за выполнение подпроцессов. Пример этого процесса “Закупка” приведен на рисунке 1.

Рис. 1. Фрагмент описания бизнес-процесса верхнего уровня “Закупка”

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

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

• Важность процесса с точки зрения реализации стратегии бизнеса: насколько велика роль того или иного процесса в выполнении стратегических планов?
• Проблемность: насколько далёк процесс от идеала?
• Возможность изменения процессов: насколько затратно или сложно изменить тот или иной процесс?

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

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

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

• Качественные строительные материалы.
• Качественные и быстрые строительные работы.
• Наличие бренда компании.
• Тесное взаимодействие с заказчиком при разработке проекта бизнес-центра.

В результате в качестве ключевых были определены такие бизнес-процессы, как:

• Закупка и контроль качества строительных материалов.
• Строительно-монтажные работы по европейскому стандарту.
• Управление маркетингом (в части формирования сильного бренда компании).
• Проектирование при активном взаимодействии с заказчиком.

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

• IT – обеспечение (из-за низкой квалификации и недостатка специалистов)/
• Строительно-монтажные работы (из-за длительности и недостаточного обеспечения квалифицированными кадрами)/

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

Совмещение цикла P-D-C-A и схемы процессного подхода

Улучшение бизнес- процессов с позиций современной системы управления должно осуществляться на основе требований процессного подхода с использованием цикла PDCA. Это такой управленческий цикл, который получил название «Цикл Деминга-Шухарта», который связан с постоянным совершенствованием процессов режиме:

планирование – выполнение – проверка – управление (улучшение) P-D-C-A (Plan –Do- Check- Act).

Совмещение цикла P-D-C-A и схемы процессного подхода в соответствии со стандартом ИСО серии 9000 изображено на рисунке 2.

Рис.2 Цикл Деминга-Шухарта в процессном управлении

Другими словами, владелец процесса в ходе управления планирует (Plan) распределение ресурсов для достижения поставленных целей. В ходе выполнения (Do) процесса исполнителями, владелец проверяет (Check) качество работ по информации, которая поступает с контрольных точек. Владелец процесса ведёт оперативное управление, активно (Act) вмешиваясь в ход бизнес-процесса, корректируя сроки и требования к результатам в соответствии с изменившейся ситуацией.

Деятельность владельца процесса носит плановый характер при нормальном ходе процесса или не плановый – в случае возникновения проблемных ситуаций, требующих немедленного вмешательства. Пример бизнес-процесса «Закупки», управляемого на основе PDCA, приведён на рисунке 3.

Рис.3. Пример бизнес-процесса Закупки» на основе цикла PDCA

Процесс, показанный на рис.3, соответствует циклу PDCA и базовым требованиям процессного подхода, сформулированным в МС ИСО 9001:2008. Особенности построения МС ИСО 9001:2008 позволяют применить его в любой сфере деятельности, при управлении практически любой организацией.

Базовые показатели оптимизации бизнес-процессов

Базовые показатели определяют эффективность и конкурентоспособность организации, уровень её процессного управления. Они сгруппированы и представлены в виде пяти групп:

• показатели Результативности бизнес-процесса – R$
• показатели Стоимости бизнес-процесса – C$
• показатели Времени бизнес-процесса – t
• показатели Качества бизнес-процесса – Q
• показатели Фрагментации бизнес-процесса – FRAG

1. Показатели Результативности бизнес-процесса характеризуют его экономическую эффективность. Если бизнес-процесс приносит деньги или, другими словами, имеет доходную составляющую, то в качестве одного из показателей используется доход. Для производственных процессов в качестве показателя результативности может использоваться объем производства продукции. Для бизнес-процесса “Управление персоналом” в качестве показателя результативности используется показатель текучести кадров и т.д.
2. Показатели Стоимости бизнес-процесса характеризуют величину потребляемых процессами издержек. Стоимость бизнес-процесса прямым или косвенным способом определяет цены на продукцию и возможность более широкого охвата различных групп клиентов. Снижение издержек бизнес-процессов позволяет компании снизить свои операционные и финансовые риски и приобрести большую маневренность в конкурентной борьбе.
3. Показатели Времени бизнес-процесса являются одним из основных факторов, определяющих конкурентоспособность организации. В современной динамичной среде, на рынке с большой конкуренцией и требовательными клиентами конкурентно способными оказываются те компании, бизнес-процессы которых имеют наиболее короткие сроки исполнения. Если у предприятия срок обработки заказа и отгрузки продукции хотя бы на 5-20% меньше, чем у конкурента, то конкурентная позиция данной компании является очень высокой.
4. Показатели Качества бизнес-процесса для каждого процесса индивидуальны. Например, качество производственных бизнес-процессов может измеряться как процент брака. Качество складских бизнес-процессов может измеряться, как процент пересортицы или ошибок при формировании заказов. Качество бизнес-процесса продаж может измеряться такими показателями как процент рекламаций, процент повторных клиентов, степень удовлетворённости клиентов и т.д.
5. Показатель Фрагментации бизнес-процесса является универсальным, может использоваться для измерения любых процессов и характеризует их организационную сложность. Чем больше количество различных структурных подразделений и сотрудников компании участвуют в бизнес-процессе, тем сложнее процесс и выше фрагментарность. В настоящее время в большинстве случаев степень фрагментарности бизнес-процессов целесообразно уменьшать.Смешанные показатели бизнес-процесса создаются на основе базовых показателей результативности, стоимости, времени, качества и фрагментарности, рассмотренных выше. Примером смешанных показателей являются показатель, рассчитываемый как отношение результативности к стоимости бизнес-процесса.

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

Практическое задание

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

Ответьте честно себе на вопросы:

1. Как сейчас Вы им управляете?
2. Используете ли показатели эффективности бизнес-процессов?
3. Если да, то выпишите основные показатели, которые используете в своей управленческой работе.
4. Вы регулярно получаете по ним отчёты?
5. Анализируете отчёты и показатели?
6. Делаете выводы, внедряете принятые по бизнес-процессам решения их в жизнь?
7. Насколько удобна и эффективна ваша действующая система процессного управления?
8. Хотите ли вы что-то изменить?

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

Шаблоны и примеры процессного управления приводятся нами в Приложении.

Источник: rr52.ru

IT-технологии: современное управление строительством

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

Владимир Александрович, когда началось внедрение IT-технологий в строительство и чем это было обусловлено?

— Этот процесс был начат, когда создавался Мосстройкомитет, — еще в начале 90-х, и у его истоков стояли такие люди, как С. Бачурина и Е. Мамышева, а организованная тогда структура известна сегодня как «Интус». Конечно, за счет колоссального прорыва в области компьютерных технологий сейчас компьютеризация стройкомплекса приобрела совершенно иные формы и масштабы, что обусловлено и внутренними потребностями строительной отрасли.

Я имею в виду, что основной причиной необходимости внедрения IT-технологий является то, что за последние годы объемы строительства выросли настолько, что контроль над ними уже невозможно осуществлять на бумаге, как это было еще в 80-90-е годы. Сейчас, когда Москва строит в общей сложности порядка 10 млн. кв. метров площадей в год, полностью быть в курсе происходящего возможно только при условии использования информационных ресурсов, портальных решений, некой интеграционной оболочки, увязывающей все аспекты строительства. Информационные технологии — это инструмент, который повышает эффективность деятельности и позволяет, сидя в кресле на рабочем месте, не тратя время на поездки и разбор бумаг, управлять процессом. Сегодня IT-технологии усовершенствованы до такого уровня, что не просто являются информационными системами, а предоставляют возможность настроить управленческий учет по отрасли, отслеживать функционирование отдельных бизнес-процессов, связать администрирование строительной области в единую систему.

— Внедрение информационных технологий было революцией сверху или снизу? Инициатива исходила от руководства отрасли или родилась «на местах»?

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

— Какие задачи вы решаете сегодня?

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

— Какие уже есть достижения в этой сфере?

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

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

— Как это примерно выглядит?

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

Мы можем в развитии посмотреть, как мы движемся, как выполняется утвержденный правительством города план, какие задачи поставлены, и какие уже назрели. Нажимаем нужную кнопку — и видим, например, Москву 2005 года со всеми построенными объектами. Нажимаем другую — перед нами 2010 год с пунктирными линиями, которыми обозначены запланированные к строительству объекты.

— А можно ли сравнить план и его реальное выполнение?

-Да, система позволяет и это.

— Какие основные проблемы вам приходится решать при внедрении 1Т-техноло-гий в строительной отрасли?

— Я не вижу здесь особых проблем. Было бы у руководства желание этим заниматься.

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

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

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

— С какими фирмами вы сотрудничаете?

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

Из IT-фирм мы тесно сотрудничаем с «Информационно-Технологической Группой» (ITG), которая сейчас работает над видеоархивом, с НПЦ «Развитие города», ОАО «УРСиП» — это головная организация, являющаяся системным интегратором нашего комплекса и увязывающая все информационные ресурсы, которые созданы и создаются. Нельзя не сказать о «Гекторе», который ведет систему строительных отходов, вносит научный вклад в разработку нормативной базы и переводит ее в формат информационного ресурса. Он же занимается разработкой каталога строительных материалов.

— Всеобщая компьютеризация многократно облегчает работу, но многих волнует, не вытеснится ли в связи с этим реальное человеческое общение?

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

Источник: www.wikistroi.ru

ОСНОВЫ УПРАВЛЕНИЕ СТРОИТЕЛЬСТВОМ.

— шаг 2. Декомпозиция целей, построение иерархической структуры работ.

— шаг 3. Построение структурной схемы организации проекта.

— шаг 4. Разработка стратегии реализации проекта. Построение плана по вехам.

— шаг 5. Разработка тактики реализации проекта. Построение сетевых моделей.

— шаг 6. Планирование ресурсов. Разработка реального календарного графика работ.

— шаг 7. Оценка затрат. Разработка бюджета проекта.

— шаг 8. Разработка и принятие плана проекта.

2.1. Сети предшествования. Диаграмма Ганта (Гантта). Ресурсная гистограмма.

1. Управляемые параметры проекта.

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

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

— объемы и виды работ, их этапы, структура работ, а также исполнители;

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

— ресурсы для осуществления проекта, в том числе материально-технические, трудовые, финансовые, а также ограничения по ресурсам: общие и по этапам;

— качество проектных решений, строительно-монтажных работ, материально-технических ресурсов;

— риск,как мера неопределенности и вероятности потерь и убытков.

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

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

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

1.2. Календарный план строительства предприятий, комплекса зданий и сооружений (комплексный укрупненный сетевой график КУСГ). Разрабатывается в составе ПОС, увязывает выполнение проектных, строительно-монтажных и пусконаладочных работ, а также поставок оборудования, строительных материалов и конструкций;

1.3. Календарный план производства работ по объекту (комплексный сетевой график). Разрабатывается в составе ППР и устанавливает последовательность и сроки выполнения строительно-монтажных работ и их взаимную увязку во времени при возведении отдельного здания (сооружения). Является основным документом производственного назначения, на основе которого осуществляют оперативное планирование и управление работами на объекте, составляют годовые, квартальные, месячные и недельно-суточные графики производства работ, а также графики поступления на объект оборудования, строительных материалов и конструкций;

1.4. Календарный план производства отдельных видов работ (локальный график). Разрабатывается на отдельные этапы строительства, отдельные виды сложных строительно-монтажных работ, а также на работы субподрядных организаций;

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

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

2. Основные этапы процесса планирования проекта.

Как происходит на практике планирование строительства объектов?

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

Процесс планирования проекта можно представить в виде цепочки шагов:

Шаг 1. Планирование целей.

Шаг 2. Декомпозиция целей, построение иерархической структуры работ

Шаг 3. Построение структурной схемы организации проекта

Шаг 4. Разработка стратегии реализации проекта. Построение плана по вехам.

Шаг 5. Разработка тактики реализации проекта. Построение сетевых моделей.

Шаг 6. Планирование ресурсов. Разработка реального календарного графика работ.

Шаг 7. Оценка затрат. Разработка бюджета проекта.

Шаг 8. Разработка и принятие плана проекта.

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

Таблица 1. Основные этапы процесса планирования проекта.

№	Шаг	Результат
1.	Разработка концепции и планирование целей проекта.	Почему?
2.	Декомпозиция целей проекта, построение иерархической структуры работ (ИСР).	Что?
3.	Назначение ответственных. Построение структурной схемы организации (ССО) проекта.	Кто?
4.	Разработка стратегии реализации проекта, построение плана по вехам.	Как?
5.	Разработка тактики проекта, построение сетевых моделей, разработка идеального календарного графика работ.	Подробно как?
6.	Планирование ресурсов, разработка реального календарного графика работ с учетом ограничений на ресурсы.	Реально когда?
7.	Оценка затрат, разработка бюджета.	Сколько?
8.	Разработка и принятие плана проекта.	Все учтено?

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

Шаг 1. Планирование целей.

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

Сформулированные цели должны соответствовать принципу SMART, согласно которому они должны быть:

ясными и точными (S — Specific);

измеримыми (M — Measurable),

достижимыми (A — Achievable);

непротиворечивыми как между собой так и со стратегическими целями организации (R — Related);

определены по срокам их достижения (T — Times-bound).

К формулированию целей нужно отнестись внимательно по ряду причин:

— разное понимание целей участниками проекта приведет к ненужной трате ресурсов, цели достигнуты не будут;

— незначительные сдвиги границ целей вызывают значительные изменения сроков и бюджета проекта;

— что в целях не прописано (забыли прописать или неправильно поняли), то обязательно выпадет из рассмотрения и выполнено не будет).

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

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

Шаг 2. Декомпозиция целей, построение иерархической структуры работ (ИСР) или построение структуры разбиения работ (СРР), что представляет собой разные названия одного и того же процесса.

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

Критерием выбора количества уровней иерархии и степени детализации ИСР являются:

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

— уровень, на котором руководитель проекта хотел бы контролировать бюджет и получать данные о затратах на выполнение работ.

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

Шаг 3. Построение структурной схемы организации проекта (ССО).

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

Шаг 4. Разработка стратегии реализации проекта. Построение плана по вехам.

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

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

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

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

Шаг 5. Разработка тактики реализации проекта. Построение сетевых моделей.

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

Возможно два подхода к построению сетевых моделей. При первом — стрелками на графике изображаются работы, а вершинами — события. Такие модели относят к типу «Работа-стрелка» и называют сетевыми графиками. При втором подходе, наоборот, стрелкам соответствуют события, а вершинам — работы. Такие модели относят к типу «Работа-вершина» и называют сетями предшествования.

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

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

Наиболее часто для расчета и анализа сетевого графика используется набор сетевых процедур, известных под названием процедуры метода критического пути (МКП).

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

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

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

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

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

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

МКП (метод критического пути) требует определенных входных данных:

— комплекс выполняемых работ;

— взаимосвязь между всеми работами;

— расчетная или технологическая продолжительность каждой работы;

— дата начала проекта.

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

— общую продолжительность проекта и дату его окончания;

— комплекс работ критического пути;

— ранние и поздние даты начала и окончания каждой работы.

С использованием компьютерных средств расчет по МКП проводится очень быстро.

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

Рис. 1. Диаграмма Ганта — один из видов сетей предшествования.

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

Шаг 6. Планирование ресурсов. Разработка реального календарного графика работ.

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

При планировании вводят два основных типа ресурсов: возобновляемые и невозобновляемые. Вопрос классификации ресурсов по типам будет рассматриваться в Теме № 7 «Обеспечение строительного производства материалами, изделиями и конструкциями».

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

1. Определение ресурсов (описание ресурса и определение максимально доступного количества);

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

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

После определения перечня ресурсов строят матрицу распределения ресурсов по работам проекта, изображенную на Рис. 2.

Рис. 2 Матрица распределения ресурсов по работам проекта.

После построения матрицы распределения ресурсов по работам строится профиль доступности ресурсов, который показан на Рис.3.

Рис. 3 Профиль доступности ресурсов.

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

После построения профиля доступности строят ресурсные гистограммы, показывающие перегрузку / недогрузку ресурсов — Рис. 4.

Рис. 4 Ресурсная гистограмма.

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

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

— разнесение параллельных работ (приводит к увеличению времени проекта);

— увеличение длительности работ (приводит к увеличению времени проекта);

— разрыв работ (приводит к увеличению времени проекта);

— назначение дополнительных ресурсов и (или) изменение их профиля (приводит к

увеличению стоимости проекта);

-смешанный подход (приводит к увеличению времени и стоимости проекта).

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

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

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

Шаг 7. Оценка затрат. Разработка бюджета проекта.

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

Рис. 5 Стоимостная гистограмма.

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

Шаг 8. Разработка и принятие плана проекта.

Результаты планирования проекта должны быть задокументированы и представлены для утверждения.

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

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

— обеспечение назначения требуемых ресурсов (времени, денег, штата) на проект;

— обеспечение основания для оценки и отображения прогресса достижения целей и результатов проекта;

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

На основе выполненного плана проекта разрабатывают графики потребности в ресурсах.

ОСНОВНЫЕ ПОНЯТИЯ В ОБЛАСТИ МЕНЕДЖМЕНТА КАЧЕСТВА СЕРТИФИКАЦИИ, СЕРТИФИКАЦИЯ ПРОДУКЦИИ И, ТЕРМИНОЛОГИЯ, СТРУКТУРА ГОСТ Р ИСО 9001-2001

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры.

ЧТО ТАКОЕ УВЕРЕННОЕ ПОВЕДЕНИЕ В МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЯХ? Исторически существует три основных модели различий, существующих между.

Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычис­лить, когда этот.

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала.

Источник: zdamsam.ru

AGILE – гибкая система управления проектами

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

• В 1991 году появился метод быстрой разработки приложений RAD
• В 1994 году появился метод разработки динамических систем DSDM
• В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
• В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
• В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

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

1. Люди и их взаимодействие важнее, чем процессы и инструменты
2. Рабочее ПО важнее, чем документация
3. Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
4. Готовность к внесению изменений важнее, чем первоначальный план

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

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

Чтобы реально осуществить на практике вышеизложенные идеи и принципы, необходимо придерживаться нескольких правил. Только тогда Agile-менеджмент проекта может быть эффективен.

Ключевые моменты в применении Agile

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

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

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

Особое внимание нужно уделить руководителю проекта. Его нельзя назвать человеком, раздающим указания налево и направо. Руководитель здесь выступает скорее в роли лидера, который задает направление и определяет правила сотрудничества и работы. Другими словами, Agile-управление является адаптируемым.

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

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

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

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

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

• Что я делал вчера?
• Чем я буду занят сегодня?
• Что мешает мне работать?

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

1. Четко обозначается значение проекта
2. В процессе реализации активно участвует клиент
3. Общий объем работ выполняется пошагово
4. Ориентироваться следует на конкретный результат
5. Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

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

Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).

Метод Scrum

Среди всех методов системы Agile Scrum отличается тем, что делает основной упор на качественный контроль рабочего процесса. Впервые описавшие его японские специалисты по стратегическому менеджменту Хиротака Такуэти и профессор в области научно-технических знаний Икуджиро Нонака называют метод «подходом в рэгби», где Scrum является «борьбой за мяч».

Метод заключается в том, что разработка проекта разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени, и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте включает в себя несколько стадий:

• Определяются объемы работы
• Каждый день проводятся 15-минутные встречи, чтобы члены команды могли скорректировать свою работу и подвести промежуточные итоги
• Демонстрируются полученные результаты
• Спринты обсуждаются для поиска удачных и неудачных решений и действий

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

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

Метод Kanban

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

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

В отличие от Скрам, Канбан обрел популярность намного позже, но это ни в коей мере не умаляет его достоинств и не делает менее эффективным. Метод полезен как в IT-области, так и в бизнес-сфере.

Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Источник: 4brain.ru