что такое скоуп задач
Всё, что вы хотели знать об областях видимости в JavaScript (но боялись спросить)
У JS есть несколько концепций, связанных с областью видимости (scope), которые не всегда ясны начинающим разработчикам (и иногда даже опытным). Эта статья посвящена тем, кто стремится погрузиться в пучину областей видимости JS, услышав такие слова, как область видимости, замыкание, “this”, область имён, область видимости функции, глобальные переменные, лексическая область видимости, приватные и публичные области… Надеюсь, по прочтению материала вы сможете ответить на следующие вопросы:
— что такое область видимости?
— что есть глобальная/локальная ОВ?
— что есть пространство имён и чем оно отличается от ОВ?
— что обозначает ключевое слово this, и как оно относится с ОВ?
— что такое функциональная и лексическая ОВ?
— что такое замыкание?
— как мне всё это понять и сотворить?
Что такое область видимости?
В JS область видимости – это текущий контекст в коде. ОВ могут быть определены локально или глобально. Ключ к написанию пуленепробиваемого кода – понимание ОВ. Давайте разбираться, где переменные и функции доступны, как менять контекст в коде и писать более быстрый и поддерживаемый код (который и отлаживать быстрее). Разбираться с ОВ просто – задаём себе вопрос, в какой из ОВ мы сейчас находимся, в А или в Б?
Что есть глобальная/локальная ОВ?
Не написав ни строчки кода, мы уже находимся в глобальной ОВ. Если мы сразу определяем переменную, она находится в глобальной ОВ.
Глобальная ОВ – ваш лучший друг и худший кошмар. Обучаясь работе с разными ОВ, вы не встретите проблем с глобальной ОВ, разве что вы увидите пересечения имён. Часто можно услышать «глобальная ОВ – это плохо», но нечасто можно получить объяснение – почему. ГОВ – не плохо, вам нужно её использовать при создании модулей и API, которые будут доступны из разных ОВ, просто нужно использовать её на пользу и аккуратно.
Все мы использовали jQuery. Как только мы пишем
мы получаем доступ к jQuery в глобальной ОВ, и мы можем назвать этот доступ пространством имён. Иногда термин «пространство имён» используют вместо термина ОВ, однако обычно им обозначают ОВ самого уровня. В нашем случае jQuery находится в глобальной ОВ, и является нашим пространством имён. Пространство имён jQuery определено в глобальной ОВ, которая работает как ПИ для библиотеки jQuery, в то время как всё её содержимое наследуется от этого ПИ.
Что такое локальная ОВ?
Локальной ОВ называют любую ОВ, определённую после глобальной. Обычно у нас есть одна ГОВ, и каждая определяемая функция несёт в себе локальную ОВ. Каждая функция, определённая внутри другой функции, имеет своё локальное ОВ, связанное с ОВ внешней функции.
Если я определю функции и задам внутри переменные, они принадлежат локальной ОВ. Пример:
Все переменные из ЛОВ не видны в ГОВ. К ним нельзя получить доступ снаружи напрямую. Пример:
Переменная “name” относится к локальной ОВ, она не видна снаружи и поэтому не определена.
Функциональная ОВ.
Все локальные ОВ создаются только в функциональных ОВ, они не создаются циклами типа for или while или директивами типа if или switch. Новая функция – новая область видимости. Пример:
Так просто можно создать новую ОВ и локальные переменные, функции и объекты.
Лексическая ОВ
Если одна функция определена внутри другой, внутренняя имеет доступ к ОВ внешней. Это называется «лексической ОВ», или «замыканием», или ещё «статической ОВ».
С лексической ОВ довольно просто работать – всё, что определено в ОВ родителя, доступно в ОВ ребенка. К примеру:
В обратную сторону это не работает:
Всегда можно вернуть ссылку на “name”, но не саму переменную.
Последовательности ОВ
Последовательности ОВ определяют ОВ любой выбранной функции. У каждой определяемой функции есть своя ОВ, и каждая функция, определяемая внутри другой, имеет свой ОВ, связанный с ОВ внешней – это и есть последовательность, или цепочка. Позиция в коде определяет ОВ. Определяя значение переменной, JS идёт от самой глубоко вложенной ОВ наружу, пока не найдёт искомую функцию, объект или переменную.
Замыкания
Живут в тесном союзе с лексическими ОВ. Хорошим примером использования является возврат ссылки на функцию. Мы можем возвращать наружу разные ссылки, которые делают возможным доступ к тому, что было определено внутри.
Чтобы вывести на экран текст, недостаточно просто вызвать функцию sayHello:
Функция возвращает функцию, поэтому её надо сначала присвоить, а потом вызвать:
Можно конечно вызвать замыкание и напрямую:
Можно догадаться, что упрощённо их код выглядит примерно так:
Функция не обязана ничего возвращать, чтобы быть замыканием. Любой доступ к переменным извне текущей ОВ создаёт замыкание.
ОВ и ‘this’
Каждая ОВ назначает своё значение переменной “this”, в зависимости от способа вызова функции. Мы все использовали ключевое слово this, но не все понимают, как оно работает и какие есть отличия при вызовах. По умолчанию, оно относится к объекту самой внешней ОВ, текущему окну. Пример того, как разные вызовы меняют значения this:
Встречаются и проблемы со значением this. В следующем примере внутри одной и той же функции значение и ОВ могут меняться:
Здесь мы создали новую ОВ, которая вызывается не из обработчика событий, а значит, относится к объекту window. Можно, например, запоминать значение this в другой переменной, чтобы не возникало путаницы:
Иногда есть необходимость менять ОВ в зависимости от того, что вам нужно.
В примере:
Значение this не относится к перебираемым элементам, мы ничего не вызываем и не меняем ОВ. Давайте посмотрим, как мы можем менять ОВ (точнее, мы меняем контекст вызова функций).
.bind() не вызывает функцию, а просто привязывает значения переменных перед её вызовом. Как вы знаете, мы не можем передавать параметры в ссылки на функции:
Это можно исправить, создав новую вложенную функцию:
Приватные и публичные ОВ
В JavaScript, в отличии от многих других языков, нет понятий публичных и приватных ОВ, но мы можем их эмулировать при помощи замыканий. Для создания приватной ОВ мы можем обернуть наши функции в другие функции.
Но вызвать эту функцию напрямую нельзя:
Вот вам и приватная ОВ. Если вам нужна публичная ОВ, воспользуемся следующим трюком. Создаём пространство имён Module, которое содержит всё, относящееся к данному модулю:
Директива return возвращает методы, доступные публично, в глобальной ОВ. При этом они относятся к нужному пространству имён. Модуль Module может содержать столько методов, сколько нужно.
Не нужно стараться вываливать все методы в глобальную ОВ и загрязнять её. Вот так можно организовать приватную ОВ, не возвращая функции:
Мы можем вызвать publicMethod, но не можем privateMethod – он относится к приватной ОВ. В эти функции можно засунуть всё что угодно — addClass, removeClass, вызовы Ajax/XHR, Array, Object, и т.п.
Интересный поворот в том, что внутри одной ОВ все функции имеют доступ к любым другим, поэтому из публичных методов мы можем вызывать приватные, которые в глобальной ОВ недоступны:
Это повышает интерактивность и безопасность кода. Ради безопасности не стоит вываливать все функции в глобальную ОВ, чтобы функции, которые вызывать не нужно, не вызвали бы ненароком.
Пример возврата объекта с использованием приватных и публичных методов:
Удобно начинать название приватных методов с подчёркивания, чтобы визуально отличать их от публичных:
Удобно также возвращать методы списком, возвращая ссылки на функции:
Словарик айтишника или Что? Где? Куда? Часть 1
«Привет! Добро пожаловать! Спасибо, что приняла наш оффер. Пойдем знакомиться с твоей командой. У них как раз сейчас дейли. Ты вышла под конец спринта, поэтому пока работы для тебя не запланировали. Как стендап закончится, можешь почитать спеки, командные окиары и просмотреть бэклог на следующий спринт. По всем вопросам обращайся к своему пио.»
Язык айтишников
Каждый, кто работает в IT, непременно сталкивался с профессиональным жаргоном и компьютерным сленгом. Его можно любить или ненавидеть, принимать или терпеть, но непреложным остается факт — IT-жаргон существует и от него никуда не деться.
Когда приходишь в новую компанию, на тебя наваливается куча незнакомых слов. Кажется, их так много, что потребуется немало времени, чтобы понять и выучить их все. Многие слова ты уже знаешь, о смысле других догадываешься, часть из них является англицизмами, поэтому догадаться об их значении несложно Первая реакция — неприятие: «Зачем использовать английские слова в русский речи, когда есть достаточно русских альтернатив?» Потом ты пытаешься сохранить чистоту языка. В итоге, начинаешь говорить так же, как и все. Это неизбежно.
Профессиональный жаргон существует не для того, чтобы испортить русский язык. Он позволяет ускорить устное общение IT-специалистов и наладить их взаимопонимание. Обычно слова получаются короткими и емкими. Иногда одно слово заключает в себе целую фразу. Поэтому польза в них, на мой взгляд, есть.
Я послушала, как говорят разработчики в Wrike, и составила словарик из самых распространенных слов. Слова собраны по тематическим группам.
Scrum-терминология
Scrum — это методология по управлению проектами. Набор принципов, ценностей, политик, ритуалов для организации работы. В скраме полно терминов, но в ежедневный обиход попала и закрепилась только часть из них.
Бэклог
От англ. backlog (дословно — очередь работ) — еще не запланированный объем работы, который требуется выполнить команде. Каждая созданная задача вначале попадает в бэклог, а потом уже в спринт.
Как и в случае со спринтом, термин используется и в отрыве от скрама. Часто бэклогом называют отложенные задачи. Которые сделать нужно, но не сейчас.
Гол, голевой
От англ. goal (дословно — цель) — цель спринта (бывает одна или несколько), которую команда берется сделать. Цель состоит из ряда задач, которые нужно выполнить, чтобы его достигнуть.
Слово употребляется и как существительное, и как прилагательное. Может быть множественного числа.
Дейли
От англ. daily (дословно — ежедневно) — ежедневные короткие (от 5 до 30 минут) встречи команды с целью поделиться прогрессом по выполненным задачам за предыдущий день и озвучить план работ на текущий день. Также дейли могут называть стендапом (от daily standup), потому что обычно такие встречи происходят стоя — для большей эффективности.
Коммититься
Глагол от англ. существительного commitment (дословно — ответственность). Коммититься — значит обещать выполнить определенный объем работы в оговоренные сроки. Это не просто обещание, это сознательное обязательство перед собой и командой. Человек, который закоммитился, обязан сделать всё возможное, чтобы выполнить то, что сам и пообещал реализовать.
Спринт
От англ. sprint (дословно — бег на короткую дистанцию) — заданный отрезок времени, за который нужно выполнить запланированный объем работы, чтобы в конце этого отрезка был ожидаемый результат.
Термин используют не только те, кто работает по скраму, но и те, кто просто хочет организовать свою работу и сформировать ясные рамки, во время которых должны быть выполнены задачи.
Инструменты для работы
Технические, информационные и вспомогательные средства и приложения для работы.
Ветка
От англ. branch (дословно — ветка) — тот редкий случай, когда в ходу русский перевод термина. Веткой (термин git) называют полную копию проекта, в которой ведется разработка. В проекте может быть создано много веток, что позволяет работать одновременно с разными частями кода. Потом все ветки загружаются в мастер. Процесс «ответвления» иногда называют «бранчеванием», уже как раз от branch.
От англ. mock-up (дословно — эскиз) — макет с UX-дизайном для разработки. Несмотря на то, что слово дословно переводится как «эскиз» или «прототип», в Wrike моками называют готовые проработанные макеты с дизайном.
От англ. production (дословно — промышленная среда) — ветка с рабочей версией продукта, которую видят пользователи. Это окончательная точка куда попадает результат разработки. Иногда так же называют мастер.
От англ. reference (дословно — пример) — схожий функционал или внешний вид, который используется для ориентира. Он служит для сравнения.
Спека
От англ. specification (дословно — спецификация) — документ с подробным описанием требований, условий и технических характеристик, как должен работать разрабатываемый функционал.
Таска
От англ. task (дословно — задача) — задача, заведенная или планируемая на любого работника.
Разработка
Термины, употребляющиеся разработчиками при работе над задачами.
От англ. boost (дословно — ускорение) — процесс повышения производительности, ускорение загрузки.
Катить
Отправлять готовую работу в деплой, предпринимать шаги для подготовки ветки к мерджу в продуктовую ветку.
Комплитить
От англ. complete (дословно — заканчивать) — завершать задачу, закрывать задачу, когда она полностью готова.
Консистентность
От англ. consistency (дословно — системность) — общее единообразие во всех частях продукта.
Матчится
От англ. match (дословно — совпадать) — полное соответствие чего-либо с чем-либо. Процесс приведения к единообразию.
Пинать
Термин, подобный глаголу «пинать», который также имеет значение «делать» и «работать». Конкретное значение определяется по приставке. Подопнуть — сделать немного, допинать — доделать.
Ручка
От англ. handler (дословно — обработчик) — бэкэнд-термин, означающий ответ от сервера, в котором приходят данные.
Скоуп
От англ. scope (дословно — объем) — набор фич и частей продукта, закрепленных за отдельной командой.
От англ. feature (дословно — характеристика) — определенная часть или деталь от общего продукта, которая разрабатывается изолированно.
От англ. flow (дословно — течение) — порядок действий при работе над задачей. Например, вначале задача берётся в разработку, потом проходит ревью, далее тестируется и т.д.
Должности
Некоторые должности, названия которых вошли в обиход в виде сокращений с английского.
Девопс
От англ. DevOps, сокращенно от Developer Operations (дословно — интеграция разработки и эксплуатации) — специалист, занимающийся внедрением DevOps-методологии. Полное название должности — DevOps-инженер, но в речи вторую часть всегда отбрасывают.
От англ. PO, сокращенно от Product Owner (дословно — владелец продукта) — роль по скрам-методологии, человек, ответственный за проработку продукта и распределение бэклога. Он знает о требованиях пользователя и возможностях команды.
От англ. PM, сокращенно от Product Manager (дословно — менеджер продукта) — менеджер, который отвечает за продукт, его обязанности совпадают с обязанностями пио, отличие только в том, что это название должности, а не роли в скраме. Так же, как пио, пиэмов могут называть продакт.
Организационное
Термины, относящиеся к организации работы, а также термины, употребляющиеся в неформальной речи при обсуждении чего-либо.
Дейоф
От англ. day-off (дословно — выходной) — просто выходной.
Драйвер
От англ. driver (дословно — водитель) — человек, который берет на себя инициативу управления проектом/процессом/задачей. В его обязанности входит следить за тем, как протекает созданный им процесс, и руководить им. Он мотивирует других людей выполнять работу для достижения поставленных целей.
Консёрн
От англ. concern (дословно — тревога, участие) — в английском языке слово «консёрн» имеет много различных значений, при этом очень часто употребляется в русской речи. Какое именно значение вкладывает в него автор, известно только ему самому. Иногда — это смесь многих значений, таких как: особый интерес, беспокойство, цель, настороженность, опасение и т.д.
Окиары
От англ. OKR, сокращенно от Objectives and Key Results (дословно — цели и ключевые результаты) — система по постановке и достижению целей. Она нужна для синхронизации работы всех участников компании/отдела/команды, чтобы все двигались в одном направлении, с понятными приоритетами и постоянным ритмом. В отличие от KPI, это амбициозное целеполагание, достижение окиаров (окров) на 70-80% — отличный результат.
Оффер
От англ. offer (дословно — предложение) — предложение о работе / приглашение на работу.
Поинт
От англ. point (дословно — точка) — чаще всего употребляется в значении «точка зрения», сокращенно от point of view. Также в значениях: «суть», «смысл», «довод».
Основы управления проектами. Структура проекта. Часть 2
Управление содержанием проекта. Scope проекта
Scope проекта описывает границы проекта, то есть то, что включено в проект и, что не менее важно, что в него не включено. Scope-менеджмент – это комплекс действий, которые вам нужно предпринять, чтобы убедиться, что у вас есть все необходимое для завершения проекта. По сути, это контроль объема работ перед началом проекта.
Проектная команда должна справляться с объемом проекта, но многие переменные слишком велики, чтобы ими управлять. Разбивка объема и работа над небольшими частями облегчают управление этим объемом. Вот почему вы создаете структуру декомпозиции работ, чтобы показать ваш проект, разделенный на меньшие части.
Возможно, вы слышали термин Scope Creep. Это неконтролируемое разрастание объема и границ проекта. Объем проекта имеет тенденцию к расширению, поэтому контроль объема является важной частью Scope-менеджмента. Чтобы предотвратить Scope Creep, вы должны отслеживать состояние проекта и управлять запросами на изменение.
Когда работа над проектом завершена, необходимо проверить данные. Другими словами, просмотрите завершенные результаты, чтобы убедиться, что они были выполнены удовлетворительно. Кроме того, заказчик или спонсор проекта должен официально принять утвержденные результаты.
График проекта
Управление временем – это важный комплекс мер для обеспечения своевременного завершения проекта. Первым шагом в управлении временем является составление плана управления расписанием, который документирует, как вы собираетесь разрабатывать, управлять, выполнять и контролировать расписание проекта. В зависимости от потребностей вашего проекта, этот план может быть формальным и подробным, неформальным и многоуровневым, или где-то между этими двумя формами.
Вторым шагом является определение графика действий или задач. Помните структуру распределения работ, т.е. шаги, которые мы рассматривали в Scope проекта? Самые нижние уровни в структуре распределения работ называются рабочими пакетами, и они определяют конкретные результаты проекта. Здесь вы разбиваете каждый рабочий пакет на действия, в которых прописана работа, необходимая для его завершения.
После того как вы определили график мероприятий, пришло время упорядочить их. Последовательность действий основана на взаимодействии между задачами. Каждое действие, кроме самого первого и самого последнего, должно быть связано, по крайней мере, с одним предшествующим или одним последующим. Когда вы добавили все свои взаимосвязанные действия, результатом будет логическая последовательность порядка, в котором должна выполняться работа в проекте.
Затем вы должны оценить ресурсы, необходимые для выполнения каждого действия. Вы оцениваете количество и типы необходимых вам ресурсов, включая людей, оборудование и материалы. Далее, вы можете использовать свои оценки ресурсов и выяснить, сколько времени потребуется для завершения каждого действия. Есть несколько методов для составления расписания из последовательности ваших действий и оценок: метод критического пути, метод критической цепи и т.д. Все это мы рассмотрим в будущих главах.
Какой бы подход планирования вы ни использовали, конечным результатом является график, который отражает ранние и поздние даты начала и окончания каждого действия в вашем проекте. Хотя для разработки реалистичного графика обычно требуется несколько повторений, в конечном счете вы создадите базовый график для своего проекта.
Как только работа над вашим проектом начинается, вы отслеживаете ход выполнения работ, а также изменения в графике, чтобы вы могли определить любые отклонения от начального плана. Если это происходит, вы можете предпринять корректирующие действия, чтобы восстановить график.
Бюджет проекта
Поскольку у большинства проектов есть бюджет, управление затратами включает процессы, обеспечивающие соответствие вашего проекта этому бюджету. Во время планирования вы составляете план управления затратами. Вы собираете такую информацию, как структура работ, график и предполагаемые ресурсы, чтобы вы могли оценить затраты по проекту.
Существует множество методов оценки затрат, таких как экспертные оценки, параметрическая оценка и восходящая оценка. Методы, которые вы выбираете, зависят от проекта и вашей организации. Оценки стоимости со временем улучшаются, когда вы узнаете больше о проекте.
Для некоторых проектов смета становится бюджетом. Тем не менее для многих проектов разрабатывается собственный бюджет. В этом случае вам может понадобиться манипулировать областью действий, ресурсами и расписанием, пока смета не будет соответствовать бюджету.
Когда работа над вашим проектом начинается, вы отслеживаете состояние и отслеживаете фактические расходы. Если фактические затраты на выполнение работ превышают базовые затраты, вы можете предпринять корректирующие действия, чтобы уменьшить перерасход средств. Именно так управление затратами помогает вам завершить ваш проект в рамках бюджета.
Управление качеством проекта
Успех проекта означает достижение его целей. Управление качеством включает процессы, обеспечивающие соответствие проекта его целям и требованиям. Управление качеством начинается с планирования.
В плане управления качеством вы определяете стандарты качества, необходимые для проекта и конечных результатов. Такие вещи, как технические характеристики продукта, допустимые уровни ошибок, допустимые размеры и т.д. В плане также указывается, как вы продемонстрируете, что проект соответствует этим стандартам.
Обеспечение качества – это то, что вы делаете, чтобы убедиться, что ваш проект соответствует стандартам качества, которые вы определяете. Например, обзоры или создание прототипов. Вы анализируете результаты тестов, чтобы увидеть, соответствуют ли они установленным вами стандартам.
Другой областью обеспечения качества является оценка ваших процессов и процедур качества, чтобы увидеть, есть ли способы их улучшить. Контроль качества – это тестирование результатов и регистрация результатов этих тестов. Это те процессы, которые вы выполняете, чтобы гарантировать, что проект соответствует требуемому уровню качества.
Трудовые ресурсы проекта
Во время планирования вы определяете навыки и роли, необходимые для выполнения работ, предписанных проектом. После того как они определены, вы можете составить штатное расписание для вашего проекта. Следующим шагом является приобретение людей, которые вам необходимы. Это могут быть нанятые сотрудники или взятые внутри организации.
Коммуникации в проекте
Общение является ключом к успеху проекта. Как менеджер проекта, вы проводите большую часть своего времени, общаясь с людьми о проекте. Во время планирования вы разрабатываете план коммуникаций по вашему проекту. Здесь описывается информация, которую вы сообщаете, аудитория, которая получает информацию, методы, которые вы используете для ее отправки, и как часто вы должны оставаться на связи.
Когда начинается работа над проектом, вы должны следить, чтобы все получали необходимую информацию, и она вовремя доходила до нужных людей. Поскольку управление проектами в значительной степени связано с другими людьми, управление коммуникациями в проекте имеет решающее значение для его успеха.
Риски проекта
Риск представляет собой неопределенность. Управляя рисками проекта, вы не только уменьшаете вероятность и влияние негативных событий, но и пользуетесь преимуществами происходящих позитивных событий.
Первым шагом в управлении рисками проекта является составление плана. По сути, вы объясняете, как выполнять задачи по управлению рисками в вашем проекте. Планируя управление рисками, вы обеспечиваете достаточно времени и ресурсов для этих важных задач.
На втором этапе определяются риски, с которыми может столкнуться проект. Вам следует периодически повторять этот шаг, чтобы искать новые риски, которые могут возникнуть в процессе работы. Нет необходимости управлять каждым выявленным риском. Для этого есть третий шаг.
Третьим шагом является анализ вероятности возникновения каждого риска, а также его влияния на проект. Таким образом, вы можете расставить приоритеты по рискам, чтобы сосредоточиться на тех из них, которые имеют наибольшую вероятность и влияние.
Имеется множество способов справиться с рисками, например, избежать их, застраховаться от риска, уменьшить его влияние, разработать планы действий в чрезвычайных ситуациях и так далее. Для каждого риска, которым вы управляете, вы решаете, как вы будете реагировать на риск в случае его возникновения.
Последний шаг – мониторинг рисков. Вы анализируете ситуацию, чтобы оценить возникновение какого-либо риска в проекте и мгновенно запустить подготовленное решение. Затем вы отслеживаете результаты, чтобы убедиться, что решение работает. Управление рисками важно на протяжении всей работы над проектом. Это помогает уменьшить негативное воздействие вредных событий, поэтому мы еще остановимся более подробно на данной теме в будущих главах.
Управление закупками
Управление закупками включает в себя выбор поставщиков, которые предоставляют необходимые вам товары, и управление контрактами, которые вы заключаете. Первым шагом в управлении закупками является создание плана. В дополнение к созданию процедуры закупок данный план определяет, что вам нужно получить за пределами вашей организации.
Следующим этапом закупок является получение предложений от продавцов, выбор потенциального поставщика и заключение контрактов. Пока ведется работа над проектом, вы должны управлять этими контрактами, отслеживать производительность поставщиков и управлять любыми изменениями.
Заинтересованные стороны проекта
Привлечь внимание заинтересованных сторон является ключевой задачей в управлении проектом. Успех вашего проекта может зависеть от вашей способности управлять заинтересованными сторонами.
Первое, что вам нужно сделать в управлении заинтересованными сторонами, это определить их. Вам надо знать их имена, их ожидания от проекта, их вклад в проект, влияние, которым они обладают и многое другое. Вы должны хранить эту информацию и периодически добавлять новую.
После того как вы определите заинтересованные стороны, ваша следующая задача – придумать стратегии, позволяющие заинтересованным сторонам участвовать в жизни проекта. Другими словами, вам нужно выяснить, как построить хорошие отношения с заинтересованными сторонами и сделать их плодотворными.
Реализация стратегии – это следующий шаг. По мере развития проекта вы взаимодействуете с заинтересованными сторонами, чтобы заручиться их поддержкой, устранить любую оппозицию и сбалансировать противоречивые цели и ожидания.
На последнем этапе вы мониторите ситуацию и следите за тем, чтобы заинтересованные стороны не выбивались из проекта и были включены в процесс. Это краткий обзор того, как вы управляете заинтересованными сторонами проекта.
Интеграция проекта
Элементы проекта, такие как scope, график проекта, его стоимость, риск и качество являются взаимозависимыми. Небольшое изменение одного из них может оказать большое влияние на другие части вашего проекта.
Интеграция проекта – это действия по координации элементов проекта и их компромисс для достижения целей вашего проекта. Интеграция означает интегрировать части в одно целое. Ваша первая задача по управлению интеграцией возникает в самом начале проекта – разработка его устава.
Устав проекта содержит обзор проекта и его необходимость. Здесь можно увидеть уровень полномочий менеджера проекта. Устав проекта, как правило, включает начальный объем (scope), смету расходов, график реализации и список заинтересованных сторон проекта.
План проекта является воплощением интеграции проекта. Это дорожная карта, которую вы используете, чтобы направлять ваш проект по ходу его реализации, а также это тот базовый уровень, с которым вы сравниваете прогресс после начала работы над проектом.
Когда вы закончите планирование, приходит время воплотить этот план в жизнь, руководя реализацией проекта. Это тот этап, где все элементы начинают выполнять работу над проектом.
Говоря о мониторинге и контроле работы над проектом, здесь вы сравниваете прогресс с вашим планом. Таким образом, вы можете решить, что вам нужно сделать, чтобы ваш проект шел в нужное русло, как перераспределять ресурсы, идти на компромисс с целями и идти на компромиссы между объемом, временем, стоимостью и качеством.
Изменения могут оказать существенное влияние на проекты, поэтому вы хотите, чтобы изменения происходили контролируемым образом. Благодаря управлению изменениями у вас есть процессы, позволяющие просматривать запросы на изменения, утверждать или отклонять их и управлять ими до тех пор, пока они не будут выполнены.
Последнее, что вы делаете в управлении интеграцией – закрываете проект. То есть вы завершили все, что происходило в проекте, чтобы формально завершить его. Когда вы закрываете проект, вы просматриваете всю информацию, которую вы собрали о проекте, чтобы убедиться, что все работы по проекту завершены и цели достигнуты.
Перейти к следующей части «Инициация проекта «.