SIMBA: Simplified Management By Artifacts

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

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

Каждая группа имеет Координатора Команды (КК), который обычно не является самым компетентным экспертом, но обладает хорошими организационными навыками и сильной самодисциплиной. КК отвечает за четыре основных элемента нашей системы управления: 1) Планирование, 2) Ежедневные отчеты, 3) Еженедельные звонки и 4) Демонстрации.

Наш План - это очень простой текстовый документ, видимый каждому в команде, обычно в Google Документах, и редактируемый только TC. Это примитивная версия структуры разбивки работ (WBS), сочетающаяся с диаграммой Ганта, где каждая строка является конкретным артефактом, таким как файл, документ, программный модуль, PDF-отчет и т. д. Задачи не приветствуются в Плане, только артефакты. Пример:

Каждый артефакт имеет 1) владельца и 2) рецензента. В первом артефакте “Требования v1” владельцем является Джефф, а рецензентом - Билл. Джефф будет следить за доставкой требований, а Билл будет проверять их и подтверждать. Владельцы не обязательно являются основными участниками своих артефактов, но они несут ответственность за контроль за статусом доставки. Проще говоря, когда артефакт доставляется в срок, мы вознаграждаем владельца; когда доставка задерживается, мы также винимаем (я знаю, что большинству из вас не нравится это слово) владельца.

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

Каждый артефакт имеет субъективно определенный статус завершенности, например, “80%” для первого артефакта выше. Эта информация собирается ТС от рецензентов, а не от владельцев.

Один человек может владеть не более трех артефактов, и рецензировать не более четырех. Таким образом, никто не может контролировать более семи артефактов.

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

Тема электронной почты начинается с WEEK13, где 13 - это номер предыдущей календарной недели в текущем году. Кстати, в почти каждом году есть 52 недели. Часть WEEK облегчает поиск отчетных писем во входящих. Также есть список, разделенный запятыми, наиболее важных тем отчета, чтобы дать читателю быстрое представление о представляемых результатов.

Каждое достижение прошлой недели начинается с глагола или глагола в прошедшем времени, например “исправил”, “добавил”, “уточнил” и т.д. После глагола упоминается объект, к которому мы внесли вклад. В конце каждой строки указан статус выполнения, субъективно оцененный автором отчета. В списке достижений не должно быть больше семи пунктов, независимо от размера команды или детализации плана. Отчет не должен рассказывать всю историю, а только подчеркивать наиболее важные моменты.

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

Каждая задача для новой недели начинается с глагола в инфинитивной форме, например “опубликовать” или “проверить”, и, конечно, упоминается объект. В списке не должно быть больше семи задач.

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

Каждую неделю в одно и то же время и день мы проводим 30-минутный звонок через Zoom: все участвуют. Мы смотрим на План и обсуждаем, находится ли наша работа по-прежнему на правильном пути. Мы задаем друг другу вопрос:

  • Мы правильно разбили область задачи?

  • Что мы упустили в нашем плане?

  • Все владельцы обязаны придерживаться своих сроков и областей работы?

  • Есть ли какие-либо пропущенные риски?

Мы не используем телефонные звонки для отчетности. Для этого у нас есть понедельные отчеты.

Все решения, которые мы принимаем на телефонных звонках, мы называем протоколом встречи и отправляем по электронной почте всем (или публикуем в нашей групповом чате в Telegram).

Почти каждую неделю мы просим владельца артефакта продемонстрировать свои результаты на одном часе звонка в Zoom под названием “демо”. Обычно это происходит, когда приближается дата доставки и владелец готов показать что-то готовое. Однако демонстрационные звонки также очень полезны для сбора мнений, когда артефакт все еще находится в процессе разработки.

Обязанностью ТС является проведение регулярных демонстрационных звонков еженедельно, приглашая владельцев самых важных артефактов.

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

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:29

sixnines availability badge   GitHub stars