Kick off встреча что это

Старт напоминает спираль, этапы повторяются, но на новом понятийном уровне.

• Виток 1 — Цели и выбор
• Виток 2 — Новые смыслы в команде
• Виток 3 — Детальная подготовка.

Подготовка и наблюдение со стороны Scrum мастера

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

Стартовое целеполагание

• Определить цели бизнеса и как мы поймём что их достигли (OKR…)
• Определить рамки и сроки

При необходимости — провести мероприятие по выравниванию в понимании принципов Agile.

Не более чем на 2ч. Лёгкое знакомство с ценностями и принципами Agile, а также с подходом, который будет использовать команда. (например, Scrum, Kanban, DevSecOps и т. д.)

Kick-off workshop — установочная встреча с заказчиками. Активности, инструменты, лайфхаки.

Команда

• Представление Scrum мастера команде
• Совместимы ли ценности и культура с Agile?
• Решение острых HR проблем
• Собираем вопросы (ожидания) с людей
• Сформулировать рабочие соглашения внутри команды
• Определяемся с инструментами и хранилищами совместного владения ценностями (Git , системы документирования и т.п.)

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

Митинг: Обзор проекта, будущего продукта

• Цели / Введение в трудозатраты
• Видение проекта / Объем
• Практические результаты
• Критерий успеха
• Предположения
• Ожидания
• Риски
• Дизайн / Архитектурный обзор
• Тестовая среда
• Технические / бизнес-зависимости
• Спонсор
• Основные заинтересованные стороны
• Точки эскалации и масштабирования
• Lean Canvas

Цель: раскрыть Бизнес-контекст (рассказывает представитель компании) — Рассказываем о бизнес-целях проекта.

Сроки: до 4х часов, обычно 1 час.

Митинг: Формирование беклога

Формируем перечень приоритетных сквозных задач проекта

Цель: SMART беклог, без оценок трудоёмкости.

Сроки: до 1 рабочего дня, обычно уже есть наброски

Митинг: Подход к реализации

Agile, Kanban, Cynefin, Scrum, User Story Mapping. DevSecOpsи т.п.

Цель: Определиться с подходом и возможными компромиссами

Сроки: 2 часа

Митинг: Командные роли

• Владелец продукта
• Скрам Мастер
• Члены команды и их компетенции
• Карты — Heat Map и Star Map

Цель: Определить состав, роли и ответственности внутри команд.

Сроки: не более 3х часов.

Митинг: Командные нормы

• Трекер зададач(JIRA…)
• Артефакты и их хранение
• Определение слова Ready (DoR)
• Определение Done (DoD)
• Требования к качеству и SRE

Цель: Утвердить, как организована рабочая доска и как будут использоваться вспомогательные ресурсы. Установите командные нормы для потока информации / карточек рассказов. (например, столбцы состояния рабочей доски, что определяет готовые к работе и готовые к тестированию карточки историй и т. д.)

Как провести установочную встречу (kick-off meeting)

Сроки: до 2 часов.

Митинг: User Story Mapping приоритетных услуг

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

Цель: сформировать цель работы на блидайшие 1–2 месяца.

Сроки: 3–4 часа

Митинг: Оценка бэклога

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

Сроки: 1 час

Митинг: Следующие шаги

• RoadMap
• Планирование релизов
• Назначение первого планирования спринта и его длинны

Цели: Определите все элементы, которые требуют последующих действий. Планируем состав первого релиза новых услуг и определяем критерии успешности

Сроки: 4 часа

Источник: msklv.medium.com

kick-off meeting

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

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

. . Словарь экономических терминов .

Англо-русский экономический словарь .

Смотреть что такое «kick-off meeting» в других словарях:

• Kick-Off-Meeting — Kick off oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem… … Deutsch Wikipedia
• kick-off meeting — noun The first official meeting of a group of people who will be working together on a project. The agenda will usually include introductions, statement(s) of mission, and organization of teams or working groups. The implication is that there… … Wiktionary
• Kick-off-Meeting — Kịck ọff Mee|ting, Kịck|ọff|mee|ting, das (Jargon): Zusammenkunft aller Beteiligten zu Beginn der Arbeit an einem Projekt … Universal-Lexikon
• kick-off meeting — Riunione che avviene durante le prime fasi dell iter di quotazione, in cui viene presentato il progetto e vengono definite le responsabilità dei singoli soggetti coinvolti nel processo di quotazione. La preliminary timetable definisce i tempi e … Glossario di economia e finanza
• Kick-off-Meeting — D✓Kịck ọff Mee|ting, Kịck|ọff|mee|ting [. mi. ] … Die deutsche Rechtschreibung
• Kick-Off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem Softwareprojekt ein … Deutsch Wikipedia
• Kick Off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem Softwareprojekt ein … Deutsch Wikipedia
• Kick off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem Softwareprojekt ein … Deutsch Wikipedia
• Kick-off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football (Kickoff (American Football)) oder Rugby eine Auftaktveranstaltung zu Beginn eines Projektes in der Wirtschaft (auch „Kick[ ]off Meeting“ genannt) den Start der… … Deutsch Wikipedia
• kick|off — «KIHK F, OF», noun, adjective. –n. 1. a kick that puts a football in play at the beginning of each half and after a score has been made. It is made from the defending team s 40 yard line. 2. Informal, Figurative. any move made to begin: »At… … Useful english dictionary
• kick off something — ˌkick ˈoff sth derived to start a discussion, a meeting, an event, etc. Syn: ↑open Main entry: ↑kickderived … Useful english dictionary

Источник: economy_en_ru.academic.ru

Перед началом проекта: 8 секретов стартовой встречи

Kick-off митинг — это стартовая встреча перед началом проекта. Такие собрания помогают познакомить участников команды, обозначить цели и сделать сотрудничество прозрачным. Конечно, при условии, что встреча проведена правильно.

Перевели советы французского портала Manager GO о том, как организовать kick-off митинг.

Для чего нужна стартовая встреча

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

Как и любую другую встречу, kick-off митинг нужно тщательно продумать и спланировать. Составьте план встречи и разошлите приглашенным, чтобы они подготовили вопросы и предложения.

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

#1. Знакомство

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

# 2. Повестка встречи

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

# 3. Суть проекта и цели команды

Обязательно ответьте на вопрос: «Какие проблемы решает проект?» Сотрудникам важно понимать, почему они будут делать ту или иную работу.

Бизнес и управление

«Проджект-менеджмент в ІТ»

Тарас Федорук
Senior Delivery Manager в Mobiquity Inc.

Узнать больше

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

# 4. Описание этапов проекта

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

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

# 5. Роль и ответственность каждого

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

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

Источник: l-a-b-a.com

Как не набить шишек на старте проекта

Меня зовут Настя, я Unit Manager международной команды в компании Itransition и тренер по управлению проектами в IT-Academy. За почти 10 лет опыта в менеджменте мне довелось поработать с разными заказчиками, продуктами, командами. На старте карьеры меня удивляло, что, согласно статистике PMI, из года в год более половины проектов заканчиваются крахом.

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

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

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

О чем мало говорят, но было бы полезно использовать

Team Charter или манифест команды

Было ли у вас когда-нибудь ощущение, что вы работаете в коллективе, но не команде? У меня было много раз, к сожалению. Первым шагом на пути создания команды я чаще всего выбираю Team Charter. Мне очень нравится этот инструмент, так как он решает сразу несколько задач. При этом важен не только процесс создания манифеста/устава команды, но и получившийся артефакт.

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

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

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

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

Onboarding Guide или руководство для новичков

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

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

Communication plan или план коммуникации

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

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

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

Реестр юридических документов

Здесь все просто: чтобы ничего важного не потерять и не забыть, лучше сразу все хранить в одном месте, будь то папка на Sharepoint или страничка на Confluence. Важно помечать «срок годности», чтобы вовремя обновлять необходимые документы.

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

О чем многие знают, но часто забывают

Договор

Что является отправной точкой для старта проекта? В сервисных IT-компаниях, как правило, – подписание контракта. Но почему-то этот самый контракт менеджеры не считают нужным прочитать. Постараюсь кратко описать, что полезного там можно найти, помимо всем известных сроков и стоимости поставки:

Deliverables или объем поставляемых услуг

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

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

Assumptions или допущения

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

Например, в допущениях указано, что заказчик предоставит готовые API для разработки front-end. Соответственно, есть риск того, что это допущение окажется ошибочным. В таком случае команде придется, как минимум, приложить дополнительные усилия на интеграцию с серверной частью приложения. Задача менеджера – определить, насколько сильным будет влияние на проект риска, что допущение окажется ошибочным, и составить план «Б».

Процедура приемки

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

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

Я указала только три пункта, но договор нужно и важно читать полностью, вдумчиво! На моей практике были примеры, когда менеджер обещал клиенту гарантию, руководствуясь своим опытом работы с контрактами в другой компании, хотя в текущем контракте она не была прописана. Бывало, что осуществляли замену членов команды, не соблюдая условия договора, что влекло за собой праведный гнев заказчика. А ведь можно было этого легко избежать.

Устав проекта

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

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

Kick-off Meeting или встреча по инициации проекта

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

• Подготовьтесь и проведите внутренний kick-off. Это позволит вам отрепетировать звонок с заказчиком, пообщаться с командой, с pre-sales, собрать всю возможную информацию и создать список открытых вопросов. Как результат, вы будете более подготовленными и менее тревожными.
• Подготовьте презентацию. Она сильно облегчит вам задачу как докладчику и позволит всем участникам встречи легче улавливать информацию, быть всегда в одном контексте. Инструментов для этого достаточно: Microsoft PowerPoint, Miro, Prezi – выбор на любой вкус.
• Убедитесь, что у всех участников с вашей стороны включены камеры, налажен звук микрофона, всех хорошо видно, у всех надлежащий внешний вид. Созвонитесь за 30 минут до звонка с клиентом, чтобы все проверить. Все уже привыкли к условиям удаленки, поэтому если вдруг на заднем плане у кого-то появится кот или ребенок – это не страшно. Страшно, если вы начнете вести себя неадекватно и кричать на ребенка или кота.
• Предупредите клиента о формате звонка. Обычно я высылаю презентацию заранее, чтобы он смог подготовиться, а также внести дополнения или правки при необходимости.
• Вышлите follow-up и приглашения на последующие встречи. Если вы не задокументируете ваши договоренности – будьте уверены: о них забудут или, что хуже, в момент наступления проблем будут использовать не в вашу пользу.

Я видела проекты, на которых не было ни внутреннего, ни внешнего kick-off. Также видела проекты, где kick-off проходил без презентаций и качественной подготовки. Они не закрывались, но, помимо налета безразличия со стороны менеджмента, появлялись другие, более серьезные проблемы.

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

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

Источник: habr.com