Работы - это Альфа области интересов "Деятельность". Конкретную работу следует считать субальфой Альфы "Работы". Работа должна быть выполнена. В работе следует руководствоваться практиками, из которых состоит технология работы инженерной группы. Инженерная группа планирует и выполняет работу, необходимую для создания продукта. По мере продвижения работы инженерная группа непрерывно анализирует технологию и адаптирует ее к текущему контексту по мере необходимости.
Работа – это то, что делает инженерная группа для достижения результата при создании продукта проекта, предоставляющего пользу для потребителя. Следует думать о работе как о совокупности действий, выполняемых на рабочем центре для преобразования предмета труда.
Далее будем придерживаться следующего соотнесения понятий:
1. Альфа (Заинтересованное лицо, Ценность, Продукт, Требования) в ходе деятельности инженерной группы должна последовательно сменять свои состояния. Достижение Альфой следующего состояния оценивается по соответствующему чек-листу. Событие – это смена состояния Альфы.
Например: Продукт демонстрируем – Продукт готов.
2. Необходимость перевести Альфу из достигнутого в следующие состояние будем называть Задачей.
Например: Задача инженерной группы – достигнуть готовности продукта после того, как разработан его прототип.
3. Для выполнения задачи инженерной группой планируются и реализуются работы. Работа может быть разделена на процедуры и операции, но это деление ничего нового не привнесет в обсуждение и производиться не будет. Преднамеренное отсутствие действий – это тоже работа.
Важно также определить, чем работа должна завершиться – результат работы. Оценить, завешена ли задача, не составляет труда – должны быть положительно заполнены чек-листы оценки достижения Альфой требуемого состояния. Результат выполнения задачи – достижение Альфой требуемого состояния.
Для работы результатом будет ее Выход. Под Выходом будем понимать совокупность рабочих (выходных) продуктов, создаваемых в ходе работы, выполненных с приемлемым качеством. В дальнейшем наименования "Результат работы" и "Выход работы" будем использовать как синонимы.
Например: Работа – электронное согласование проекта договора должностным лицом. Выходной рабочий продукт - электронная карточка договора в системе электронного документооборота с отметкой о согласовании (не согласовании). Качество выполнения данной работы может быть оценено по степени соответствия рабочего продукта требованиям. Так, если проект документа не будет согласован, то в карточке должно быть указана причина. При этом Альфа "Договорной документ" сменит свое состояние только при согласовании проекта документа всеми предусмотренными в процедуре должностными лицами.
Рабочие продукты могут различаться по типу.
- Конструкт – физический, либо информационный объект, создание или преобразование которого является целью выполнения работы.
- Артефакт – информационный, абстрактный объект, сопутствующий работе (описание).
Инженерная команда должна выполнять два типа действий по отношению к работам:
- Спроектировать структуру работ. Нужно определить, какие конкретные шаги, и с какими результатами приведут к созданию готового продукта, отвечающего требованиям и ожиданиям потребителя. По сути, это задача создания.
- Эффективно выполнить эти работы (управление работами). Речь идет об операционном управлении: нужно сделать всё запланированное с требуемым качеством, уложившись в сроки и бюджет. Управление работами, это практики распределения ресурсов и обеспечения их продуктивного использования.
Проектирование структуры работ
Результатом проектирования структуры работ должен явиться достаточно полный и подробный список работ – "контрольный список работ". Контрольный список не содержит календарных дат или указания ответственных. Это только список действий. На основе контрольного списка может быть составлен календарный план. В календарных планах уже указывается и срок исполнения, и ответственный за исполнение. Если контрольный список по выполнению проекта составлен с необходимой степенью подробности и полноты, то успех проекта обеспечен с высокой вероятностью.
Во многих случаях для практик, которые должны быть применены инженерной группой, уже существуют достаточно подробные контрольные списки. В качестве примера такого контрольного списка следует привести модель, представленную в РД 107.15.0006-88 "Классификатор планово-учетных единиц, выполняемых в составе НИР и ОКР ".
В соответствии с данным классификатором все работы, выполняемые в рамках НИР и ОКР, в зависимости от их сложности и трудоемкости разбиваются на несколько групп, каждая из которых объединяет планово-учетные единицы, одинаковые по сложности и близкие по трудоемкости. Эти группы образуют уровни агрегирования планово-учетных единиц. Определено шесть уровней агрегирования: 1 – стадия; 2 – этап; 3 – подэтап: 4 – работа; 5 – процедура; 6 – операция. Планово-учетные единицы, одинаковые по специфике, образуют вид работ.
Обобщенная технологическая модель, описанная в РД 107.15.0006, позволяет систематизировать все планово-учетные единицы, выполняемые в рамках ОКР, по уровням агрегирования и является основой для разработки типового и детального перечня работ.
Во многих инженерных коллективах существует опыт и практика решения типовых задач, который сопровождается пониманием перечня и связи работ, позволяющих достичь необходимых результатов – это еще одна возможность получить проект контрольного списка для реализации работ проекта.
Если подходящего контрольного списка нет, то Инженерная группа может воспользоваться известными методологиями его получения.
Структурное разбиение работ (Work Breakdown Structure, WBS)
В руководствах по управлению проектами также встречается наименование "Структура декомпозиции работ (СДР)" или "Иерархическая структура работ (ИСР)".
Суть метода проста. Планировщики поэтапно разбивают задачи проекта на все более мелкие составные части, пока не будет достигнут требуемый уровень детализации. Самые малые элементы называются работами проекта. Работы, приводящие к достижению одного частного результата (деталь, сборочный узел, модуль программы и т.д.), могут объединяться в пакеты работ.
Структурному разбиению работ может предшествовать структурная декомпозиция продукта (PBS). Это вносит вклад в создание ИСР, которая определяет действия, необходимые для предоставления этих результатов. Использование результатов структурной декомпозиции продукта позволяет преодолеть трудности, возникающие из-за неопределенности предположений о том, что и как делать, поддерживая сосредоточенность на целях и задачах проекта.
Эмпирические правила, которым необходимо следовать при разбиении работ.
- Разбиения необходимо производить на примерно равнообъемные работы.
- Логично предположить, что чем подробнее детализация работ, тем точнее экономические расчеты и прогноз сроков. Однако управление проектом на основе излишне детализированного плана неоправданно трудоёмко, особенно в условиях существенной изменчивости.
- Целесообразно единичную работу (пакет работ), выполняемую по единой технологии, назначать одной оргроли (оргзвену).
- При выполнении декомпозиции нужно учесть все критические работы независимо от их трудоемкости, стоимости или длительности. Некоторые работы могут иметь определяющее значение. Например: получение разрешение на строительство в строительных проектах. Прямые затраты на получение разрешения минимальны, но без разрешения успешное завершение проекта невозможно.
Не столь важно, как точно и детально управляются отдельные элементы проекта, важно, чтобы управление осуществлялось всеми элементами проекта.
В практике управления проектами считается нормой итерационный подход к разработке ИСР. Версии ИСР могут меняться по мере углубления в предметную область проекта и изучения новых деталей, явлений и зависимостей. Происходит это не только при подготовке проекта, но и на стадии его исполнения.
При особо изменчивом и неопределенном контексте ИСР и контрольный список могут быть разработаны на короткий промежуток времени и в последующем часто уточняться.
Обеспечение качества
Обеспечение качества при разработке продукта осуществляется с помощью двух методологических направлений: прикладного и организационного.
Методы прикладного обеспечения качества специфичны для конкретной предметной области, реализуемых практик и типа продукта. Они являются основным инструментом для повышения качества при разработке.
Методы организационного обеспечения качества создают общие условия и предпосылки "не снижения" качества. Они являются во многом общими и обязательными для всех областей деятельности.
Так, например, важное значение в обеспечении качества придается контролю качества полученных результатов на уровне задач проекта, т.е. Альфа, достигнув очередного состояния, должна соответствовать установленным требованиям, зафиксированных в чек-листах.
Качество продукта проекта и его составляющих проверяется посредством приемочного контроля (верификация, тестирование). Помимо проверки качество продукта проекта, являющегося системой, должно быть подтверждено приемкой (валидация) – это испытания того, что потребитель, используя продукт в своей системе деятельности, удовлетворит свои потребности и получит ожидаемую ценность.
Приемочный контроль с последующей выбраковкой и коррекцией принятых решений не единственный подход к обеспечению качества. Существует еще и контроль самого процесса выполнения работы. Безусловно, приемочный контроль лучший способ подтверждения результата, но в разы проще и дешевле проверять саму работу, а не результат выполнения задачи. Метод обеспечения качества через обоснование на основе процесса, был закреплен в стандартах "СМК" серии ISO 9000. Суть этого подхода заключается в предположении о том, что соблюдение документированного процесса даст требуемое качество выходного рабочего продукта этого процесса. Для этого надо документировать рабочие процессы и требовать их выполнения в том виде, в каком они были документированы.
В настоящее время уже понятно, что использование "стандартов качества" серии ISO 9000 не гарантирует обеспечение качества. Проверка и приемка (испытания) остаются необходимыми практиками обеспечения качества. Для их удешевления и ускорения используются множественные симуляции – моделирование. Более того, безошибочность проектирования в последнее время стала все более основываться на многочисленных проверках моделей продукта – разнообразных прототипов.
Как правило, качество работ достигается следующими методами:
- контроль качества выходов - результатов Работ и операционный контроль;
- поддержание достаточной квалификации и вовлеченности исполнителей;
- регулирование рабочей нагрузки;
- должная обеспеченность рабочих центров;
- применение соответствующих технологий, и т.п.
Обеспечение производительности процесса разработки
Операционные менеджеры обеспечивают всё "в срок, в рамках бюджета" и добиваются чтобы общий "Проход" всех выходных рабочих продуктов в ходе выполнения работ был максимален. Это и есть задача операционного управления – управления работами.
Проход – это скорость, с которой система генерирует "единицы цели“.
Управление работами (work/operations management, операционное управление) сводится к тому, чтобы оптимально распорядиться ресурсами: выполнить максимальное количество работ с минимальными ресурсами.
Вот некоторые эвристические правила операционного менеджера для увеличения скорости движения рабочих продуктов.
- Сокращение лимитов незавершенной работы.
- Расстановка приоритетов и принудительное ранжирование.
- Максимизация пропускной способности за счет определения приоритета работ с самыми высокими альтернативными издержками, которые могут быть выполнены быстро.
- Устранение работ, которые можно не делать.
- Обеспечение управления конфигурацией и повышение качества, т.к. конфигурационные коллизии и дефекты ведут к появлению необходимости исправлений уже сделанного.
- Устранение простоев в работе.
- Уменьшение времени обработки рабочих продуктов на рабочих центрах, находящихся на местах ограничений в потоке работ.
Применяются также и иные инструменты максимзации прохода:
- системный подход и поток (Systems Thinking and Flow);
- одна задача в единицу времени (One-Piece Flow);
- визуализация задач (Kanban);
- быстрое устранение препятствий (Andon, Stand-Up Meetings);
- поток создания ценности (Value Stream);
- минимальный рабочий продукт (Minimum Viable Product);
- вытягивающая система (Pull System);
- ранняя обратная связь (Early Feedback Loops);
- сдвиг влево (Left Shift);
- непрерывное тестирование (Continuous Testing);
- определение завершения (Definition of Done);
- поиск и устранение потерь (Lean, Muda, Elimination of Waste);
- постоянное обучение и экспериментирование;
- отказ от поиска крайних (Blamelessness Culture);
- непрерывное улучшение.
Состояния Альфы "Работа"
- Работа инициирована: Определен требуемый Выход, и созданы необходимые и достаточные условия для выполнения Работы.
- Работа подготовлена: Все предварительные условия для начала Работы выполнены.
- Работа начата: Инженерная группа собрана, и Работа выполняется.
- Работа под контролем: Работа продвигается хорошо, риски под контролем, уровень производительности достаточен для достижения удовлетворительного Выхода.
- Работа закончена: Работа, нацеленная на достижение результатов, закончена.
- Работа закрыта: Все оставшиеся служебные задачи завершены, и Работа официально закрыта.
Также в ГОСТ Р 57195-2016 приведен и чек-лист с условиями, относительно которых можно составить представление о достижении Альфой "Работа" указанного состояния.
Отношения между Альфами
Альфа "Работы" находится в отношениях с другими альфами областей интересов "Решение" и "Деятельность".
- Работы выполняются инженерной группой.
- Работы изменяют продукт.
- Работы ограничиваются и направляются требованиями.
- Работы осуществляются по технологии.