Le kick-off de projet chez OVH

Как только я прибыл в OVH в команде Service Delivery, которая является гарантом производства, я хотел реализовать гибкую технику, известную как запуск в управлении проектами. В качестве менеджера PaaS одной из моих миссий является создание и продвижение методов технологии надежности сайта 1 (SRE), которые я использую в течение нескольких лет, в рамках моего предыдущего профессионального опыта. Сегодня эта дисциплина хорошо известна в индустрии программного обеспечения, для которой она была разработана. Одним из его основных вкладов является возможность внедрения программного обеспечения или платформы, которая с самого начала интегрирует и гибкость, и надежность. Но применение принципов SRE для OVH было отчасти проблемой. Поскольку компания в первую очередь является поставщиком ИТ-инфраструктур, необходимо адаптировать методы к этой конкретной деятельности.

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

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

Цели включают
Мы раскрываем здесь цели и ожидания, которые будут включены в проект, всегда в маркированном списке. Например: «Проект решает проблему Y.»

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

дизайн
Мы находим все технические элементы проекта: диаграмму архитектуры, список используемых технологий, цели, которые необходимо выполнить, или факторы успеха. В этом разделе основное внимание уделяется: «Как технически проектировать проект? "

Рассматриваемые альтернативы
В этой части перечислены альтернативы, рассматриваемые при исследовании проекта.

риски
Мы раскрываем здесь финансовые и технические риски, а также зависимости, которые создаст проект, как человеческий, так и технический.

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

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

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


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

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

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

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

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

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

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

Этот список, очевидно, не является исчерпывающим.


1. Инженерная надежность сайта (SRE) — это дисциплина, объединяющая аспекты разработки программного обеспечения и применяющая ее к проблемам компьютерной работы. Основными задачами являются создание сверхмасштабируемых и надежных программных систем. Эта дисциплина присуждается Бенджамину Трейнору Слосу, вице-президенту компании Google и его команде. Он присоединился к этой компании в 2003 году и отвечал за создание команды для обеспечения здоровья крупномасштабных производственных систем Google.