Это серия из трёх постов предназначена для новичков, которые уже находятся в процессе перехода в IT или только планируют сменить нишу. Здесь будут собраны базовые термины из IT-индустрии, которые стоит знать начинающим Проджект и Продакт Менеджерам, Продукт-Овнерам, а также тем, кто ещё не определился со своей ролью.

В конце статьи я оставлю ссылку на свой Telegram-канал и ссылку на третью статью на Хабре из серии.

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

Также прикреплю PDF-файл, чтобы можно было скачать всё сразу.

Планирование и Управление

1. BurnDown Chart

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

• Применение: В Agile и Scrum бурндаун график используется для визуализации объема работы, оставшейся для завершения в рамках спринта, отображая оставшиеся задачи на вертикальной оси и время на горизонтальной. Регулярное обновление этого графика позволяет командам отслеживать прогресс, выявлять задержки на ранних стадиях и принимать оперативные меры для их устранения. Это не только повышает прозрачность внутри команды, но и среди заинтересованных сторон, наглядно демонстрируя, насколько команда приближается к выполнению своих целей и задач.

2. BurnUp Chart

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

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

3. Critical Path Method (CPM)

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

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

4. Fixed Price

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

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

5. Gantt Chart

• Определение: Гистограмма, которая иллюстрирует график проекта, показывая даты начала и окончания различных элементов проекта.

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

6. Project Deliverables

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

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

7. Project Schedule

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

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

8. Project Scope

• Определение: Определяет границы проекта, включая то, что будет доставлено (и что не будет), цели проекта и его ограничения.

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

9. RACI Matrix (Responsible, Accountable, Consulted, Informed)

• Определение: Матрица, которая уточняет роли и обязанности в проекте, определяя, кто несет ответственность (Responsible), кто подотчетен (Accountable), кто консультируется (Consulted) и кто информируется (Informed) по каждой задаче или результату.

• Применение: В управлении проектами матрица RACI (Responsible, Accountable, Consulted, Informed) используется для обеспечения ясности обязанностей и предотвращения путаницы относительно того, кто отвечает за выполнение задач. Эта матрица помогает четко определить, кто несет ответственность за каждую задачу, кто принимает окончательные решения, кто должен быть консультирован в процессе и кто должен быть проинформирован о прогрессе. Это не только упрощает коммуникацию в команде, но и способствует более эффективному управлению проектом, позволяя избежать дублирования усилий и недоразумений. Четкое распределение ролей и обязанностей повышает ответственность и способствует более слаженной работе команды, что в конечном итоге способствует успешному выполнению проекта.

10. Risk Management

• Определение: Процесс выявления, оценки и контроля рисков, которые могут потенциально повлиять на результаты проекта.

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

11. Status Report

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

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

12. Time & Material

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

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

13. Velocity Chart

• Определение: График, который отслеживает объем работы, выполненной командой в каждом спринте. Он помогает прогнозировать, сколько работы команда сможет выполнить в будущих спринтах на основе прошлых показателей.

• Применение: В Agile и Scrum график, отслеживающий объем выполненной работы в каждом спринте, служит важным инструментом для измерения продуктивности команды и прогнозирования ее будущей емкости. Этот график позволяет командам анализировать свои прошлые результаты, определяя, сколько работы они могли выполнить в течение предыдущих спринтов, что помогает делать более обоснованные прогнозы для будущих спринтов. Используя эти данные, команды могут лучше планировать объем задач, который они смогут взять на себя, а также выявлять тенденции и улучшения в своей работе. Регулярное обновление и анализ этого графика способствует повышению прозрачности и улучшению коммуникации как внутри команды, так и с заинтересованными сторонами, что в конечном итоге ведет к более эффективному управлению проектами.

14. Work Breakdown Structure (WBS)

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

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

Методологии, Спринты, Задачи

1. Agile

• Определение: Набор принципов и ценностей для разработки программного обеспечения, который подчеркивает итеративный прогресс, сотрудничество и адаптацию к изменяющимся требованиям. Agile способствует гибкости и обратной связи с клиентами.

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

2. Epic

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

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

3. User Story

• Определение: Пользовательская история — это краткое и простое описание функции с точки зрения пользователя или клиента, объясняющее желаемую функциональность и ее назначение.

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

4. Kanban

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

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

5. SCRUM

• Определение: Популярный Agile-фреймворк, который организует работу в фиксированные итерации, называемые спринтами (обычно 2–4 недели). Он включает в себя определенные роли (Scrum Master, Product Owner, команда разработки) и церемонии (ежедневные стендапы, обзоры спринтов и т. д.).

• Применение: Scrum, как Agile-фреймворк, в первую очередь используется в разработке программного обеспечения для управления сложностью проектов и улучшения процесса доставки продукта. С помощью фиксированных итераций, называемых спринтами, команды могут разбивать сложные задачи на более мелкие, управляемые части, что упрощает планирование и выполнение. Определенные роли, такие как Scrum Master и Product Owner, помогают организовать процесс, управлять требованиями и устранять препятствия. Церемонии, такие как ежедневные стендапы и обзоры спринтов, способствуют эффективной коммуникации внутри команды, обеспечивая регулярный обмен информацией о прогрессе и выявлении проблем. Это позволяет командам быстрее адаптироваться к изменениям и обеспечивать высокое качество конечного продукта, что в итоге повышает удовлетворенность клиентов и сокращает время вывода на рынок.

6. Waterfall

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

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

7. Change Request

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

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

8. Sprint

• Определение: Фиксированный период времени, обычно от 1 до 4 недель, в течение которого команда разработки выполняет определенный объем работы. Спринты являются ключевым компонентом фреймворка Scrum.

• Применение: В Agile и Scrum методологиях спринты используются для организации задач разработки в управляемые блоки, что позволяет командам сосредоточиться на выполнении конкретного объема работы за фиксированный период времени. Каждый спринт начинается с планирования, на котором команда выбирает набор задач из бэклога продукта, которые они намерены завершить в течение спринта. Это помогает разбить сложные проекты на более мелкие, управляемые части, что облегчает управление и мониторинг прогресса. В конце каждого спринта проводится обзор, на котором команда демонстрирует выполненные задачи, а также собирает обратную связь от заинтересованных сторон. Такой подход способствует быстрой адаптации к изменениям, повышает вовлеченность команды и позволяет регулярно поставлять рабочие функции или улучшения, что в итоге способствует успешной реализации продукта и удовлетворению потребностей пользователей.

9. Sprint Daily Standup

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

• Применение: В Scrum и Agile командах ежедневная встреча, известная как "ежедневный стендап" или "daily stand-up", проводится для синхронизации усилий команды и содействия коммуникации. На этой встрече, которая обычно длится около 15 минут, каждый участник делится информацией о том, что он сделал накануне, что планирует сделать сегодня и какие препятствия или проблемы мешают ему выполнять работу. Это позволяет всей команде быстро получить обновленную информацию о прогрессе, выявить потенциальные проблемы на ранних стадиях и оперативно находить решения. Регулярные стендапы способствуют укреплению командной сплоченности, повышению ответственности и поддержанию фокуса на целях спринта, что в конечном итоге способствует более эффективному выполнению задач и успешной реализации проекта.

10. Sprint Demo

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

• Применение: В Scrum встреча, проводимая в конце спринта и известная как "обзор спринта" или "sprint demo", служит для демонстрации прогресса команды и сбора обратной связи от заинтересованных сторон. На этой встрече команда презентует выполненные задачи, демонстрируя новые функции или улучшения, которые были реализованы в течение спринта. Это позволяет заинтересованным сторонам увидеть, как проект развивается, и оценить соответствие продукта их ожиданиям.

11. Sprint Planning

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

• Применение: В методологии Scrum встреча, проводимая в начале спринта и называемая "планирование спринта" (sprint planning), предназначена для определения объема работы, который команда планирует выполнить в течение следующего спринта. На этой встрече владелец продукта представляет приоритетные задачи из бэклога, а команда разработки оценивает, какие из них они смогут выполнить, учитывая свои ресурсы и текущие возможности. Команда обсуждает каждую задачу, уточняет требования и делит их на более мелкие задачи, если это необходимо. В результате на этой встрече создается четкий план работы на спринт, который помогает всем участникам понимать цели и задачи, а также способствует более эффективной организации труда. Такой подход не только обеспечивает прозрачность, но и позволяет команде лучше управлять своими усилиями и достигать более высоких результатов в рамках спринта.

12. Sprint Retrospective

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

• Применение: В Scrum встреча, проводимая после обзора спринта и известная как "ретроспектива спринта" (sprint retrospective), служит для того, чтобы команда могла обсудить, что прошло хорошо, что не получилось и как можно улучшить процессы для следующего спринта. На этой встрече участники открыто делятся своими мнениями и предложениями, создавая безопасное пространство для обсуждений. Это помогает выявить успешные практики, которые стоит продолжать, а также определить проблемы или препятствия, с которыми столкнулась команда, и выработать стратегии их решения. Ретроспектива способствует формированию культуры непрерывного улучшения, позволяя команде адаптироваться и развиваться с каждым спринтом. Путем обсуждения и внедрения улучшений команда может повысить свою продуктивность, качество работы и удовлетворенность от работы, что в конечном итоге приводит к более успешным проектам.

Мой телеграмм канал: t.me/mr_ponder

Ссылка на статью 1/3: https://habr.com/ru/articles/847250/

Ссылка на статью 3/3: https://habr.com/ru/articles/847256/