В предыдущих статьях мы поднимали свой собственный Клуб на платформе Vas3k. Дело закончилось тем, что мы этот самый Клуб успешно запустили в продакшен и даже настроили автоматический бэкап!

Воно как это было: https://teletype.in/@toptuk/pmiclub6

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

Эту статью меня сподвигло написать фатальные изменения кода Vas3k Клуба, когда поменялась предметная область авторизации.

Синхронизация кодовой базы

При разработке Клуба мы договаривались, что у нас будет 3 ветки кода в репозитории форка Клуба Vas3k'а:

• dev - ветка для наших локальных доработок.
• master - ветка со стабильным кодом, который протестирован локально.
• deploy - ветка для деплоя Клуба в продакшен среду. Тут содержится именно та версия нашей кодовой базы, которую видят все пользователи.

Синхронизировать доработки мы будем с dev веткой 🐈 Приступим...

Наша задача интегрировать в наш репозиторий все закрыл Pull Request из репозитория Vas3k'а: ссылка

Чтобы перенести изменения из исходного репозитория в репозитарий форка, нам необходимо добавить исходный репозиторий git в качестве основного репозитория ("upstream"). Для этого, локально выполним следующие действия:

• Запускаем консоль (командную строку в Windows или термина в Linux/Mac)
• Переходим в директорию репозитария форка
• Выполняем следующие команды для получения списка настроенных удаленных репозитариев

git remote -v
    origin https://github.com/[Your UserName]/[Your Fork].git (fetch)
    origin https://github.com/[Your UserName]/[Your Fork].git (push)

• Добавляем репозитарий Vas3k'а в качестве базового репозитария

git remote add upstream https://github.com/vas3k/vas3k.club.git

• Если повторно выполнить команду для получения списка настроенных удаленных репозитариев, то получится следующая картина

$ git remote -v

origin https://github.com/[Your UserName]/[Your Fork].git (fetch)
origin https://github.com/[Your UserName]/[Your Fork].git (push)
upstream https://github.com/vas3k/vas3k.club.git (fetch)
upstream https://github.com/vas3k/vas3k.club.git (push)

Сейчас все готово для интеграции изменений из оригинального репозитория Vas3k'а в ваше репозиторий форка.

Слияние (merge) изменений из оригинального репозитария

Прежде всего, нужно получить все изменения из исходного репозитория. Обратите внимание, что фиксации в исходном репозитории будут храниться в локальной ветке с именем upstream/master.

$ git fetch upstream

 remote: Counting objects: 75, done.
 remote: Compressing objects: 100% (53/53), done.
 remote: Total 62 (delta 27), reused 44 (delta 9)
 Unpacking objects: 100% (62/62), done.
 From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY
  * [new branch]      master     -> upstream/master  

Переключимся или убедимся, что текущая рабочая ветка это dev ветка

$ git checkout dev

 Switched to branch 'dev'

Осуществим слияние изменений из оригинального репозитария Vas3k'а в свой репозитарий. Это приведет к синхронизации dev ветки вашего форка с оригинальным репозиторием Vas3k'а без потери локальных изменений.

Скорее всего в результате слияния изменений появятся множество конфликтов, которые нужно разрешить, прежде чем завершить слияние.

$ git merge upstream/master

 Updating a422352..5fdff0f
 Fast-forward
 .... 

В результате устранения конфликтов останется только залить изменения и запустить деплой нашего Клуба в продакшен

git push origin dev

ИТОГО

Для последующей синхронизации изменений из репозитария Vas3k Клуба нужно выполнить следующие команды:

$ git fetch upstream
$ git checkout dev
$ git merge upstream/master
$ git push

Поддержка изменений аунтентификации

Однажды, Vas3k решил переделать предметную область аутентификации. Добавили возможность аутентификации на внешних сайтах с помощью OpenID... И тут заверьте - все сломалось!

После деплоя форка Клуба с интегрированными изменениями он перестал запускаться.

Ошибки в Sentry выглядели следующим образом:

InconsistentMigrationHistory
Migration auth.0001_initial is applied before its dependency contenttypes.0001_initial on database 'default'.

❤️ MEOW! ❤️

Links

https://stackoverflow.com/questions/37099564/docker-how-can-run-the-psql-command-in-the-postgres-container

https://stackoverflow.com/questions/19674456/run-postgresql-queries-from-the-command-line

https://stackoverflow.com/questions/38996599/django-manage-py-migration-applied-before-its-dependency

https://stackoverflow.com/questions/58623291/how-to-restore-database-from-dump-or-sql-file-in-docker-using-volume

Привет, Олимпийский!

Писал статью треугольник талантов руководителей проектов — три опоры, на которых держится профессия: Ways of Working (хард-скиллы управления), Power Skills (лидерство и коммуникация) и Business Acumen (понимание бизнеса). Ы статье про TOP компетенций для резюме разбирал, какие четыре компетенции — коммуникации, планирование, контроль и мотивация — рекрутеры и PMO хотят видеть в первую очередь.

Эта статья - уже не абстрактная теория, а конкретный набор навыков, которые нужны PM, если вы работаете руководителем проекта в IT-продуктовой компании: там, где PM живёт на стыке бизнеса, продукта и разработки.

Понимание бизнеса и продукта

Это Business Acumen из треугольника талантов. Если PM не понимает, зачем компания вообще делает то, что делает, он превращается в диспетчера задач: ведёт спринты, закрывает тикеты, но не может ответить на вопрос "а зачем мы это делаем". В продуктовой компании это особенно критично — здесь решения принимаются не по ТЗ заказчика, а исходя из стратегии и данных о пользователях.

• Понимает бизнес-цели компании и умеет связывать задачи с результатом. Каждая задача в бэклоге должна быть объяснима через "зачем" — иначе это работа ради работы.
• Знает продуктовую стратегию и понимает, зачем делается каждая ключевая инициатива. PM должен уметь пересказать роадмап своими словами, а не просто скопировать его в план проекта.
• Разбирается в домене: рынке, пользователях, конкурентах, ограничениях и типовых сценариях. Без понимания контекста сложно отличить важный риск от несущественной детали.

Роли, полномочия и границы ответственности

Из "Треугольника талантов" я цитировал: работает команда, а оценивают менеджера. Но чтобы честно нести эту ответственность, PM должен точно понимать, где заканчиваются его полномочия и начинаются чужие. Размытые границы — источник большинства внутренних конфликтов в командах.

• Понимает роли в команде и зоны ответственности каждого участника. Иначе неизбежны дублирование работы и ситуации "я думал, это делаешь ты".
• Имеет полномочия принимать операционные решения в рамках своей зоны. PM без права решать хоть что-то самостоятельно — это не менеджер, а секретарь при команде.
• Может быстро эскалировать блокеры и получать помощь от нужных людей. Скорость эскалации часто важнее её "красоты" — застрявшая на неделю проблема стоит дороже, чем неловкий вопрос не по адресу.
• Понимает, где его зона ответственности заканчивается, а где начинается зона продуктового или функционального лидера. PM не подменяет продакт-менеджера в вопросах "что делать" и тимлида в вопросах "как делать" — он координирует, а не решает за них.

Планирование и управление исполнением

Это прямое продолжение "Планирования" и "Контролирования" из статьи про TOP компетенций. PM — интегратор, который объединяет планы и команду в одно целое. Но план без контроля исполнения — просто красивый документ, который никто не читает после первой недели проекта.

• Умеет приоритизировать задачи по ценности, рискам и срокам. В продуктовой разработке бэклог всегда больше, чем ресурсы команды — приоритизация это не разовое действие, а постоянный процесс.
• Ведёт план работ, сроки, зависимости и риски. Не ради самого плана, а чтобы видеть заранее, где команда упрётся в стену.
• Собирает и уточняет требования так, чтобы команда могла по ним работать. Требования должны быть переведены с языка бизнеса на язык, понятный разработке и дизайну.
• Фиксирует договорённости, чтобы не было разночтений. "Мы вроде так и договаривались" — самая дорогая фраза в проекте.
• Следит за выполнением и не допускает потери фокуса. Команды легко отвлекаются на срочное в ущерб важному — задача PM держать фокус на приоритетах.

Метрики и данные

Продуктовая компания живёт данными, а не мнениями. PM, который полагается только на ощущения команды или громкость голоса на встрече, рано или поздно приведёт проект не туда.

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

Коммуникация и лидерство

80% успеха проекта зависит именно от того, как выстроено общение в команде. В продуктовой компании PM коммуницирует не только с разработкой, но и с продажами, маркетингом и руководством одновременно — и везде на разном языке.

• Умеет коммуницировать с разработкой, дизайном, аналитикой, продажами и руководством. Каждой аудитории нужен свой уровень детализации и свой фокус.
• Может проводить встречи так, чтобы они давали конкретный результат. Встреча без результата — это не коммуникация, а трата времени всей команды одновременно.
• Умеет управлять конфликтами и снимать напряжение в команде. Конфликт, оставленный без внимания, не исчезает — он уходит в пассивное сопротивление и падение мотивации.
• Обеспечивает прозрачность статуса проекта для всех заинтересованных сторон. Никто не должен узнавать о проблемах проекта последним.

Качество и адаптивность

Последний блок — про баланс. PM легко скатывается в одну из крайностей: либо гонит скорость в ущерб качеству, либо цепляется за первоначальный план и теряет управляемость при первом же изменении.

• Контролирует качество, а не только скорость. Быстро сделанная, но некачественная работа почти всегда возвращается в виде более дорогой переделки.
• Умеет адаптироваться к изменениям без потери управляемости. В продуктовой разработке планы меняются постоянно — задача не в том, чтобы этого избежать, а в том, чтобы менять план управляемо, а не хаотично.

Критично важно: без этого чек-лист не работает

Все навыки выше — зона ответственности самого PM. Но есть вещи, которые PM обеспечить себе сам не может — это должна дать компания. Без них даже самый компетентный интегратор (вспоминая роль PM из "Треугольника талантов") физически не может интегрировать.

• Есть доступ к людям, которые принимают решения. Иначе любой сложный вопрос упирается в стену ожидания.
• Есть право синхронизировать команды и ставить приоритеты. Без этого права PM превращается в наблюдателя за чужими решениями.
• Есть возможность влиять на сроки, объём и порядок работ. Иначе PM отвечает за результат, на который не может повлиять — заведомо проигрышная позиция.
• Есть ясные границы ответственности. Мутные границы порождают либо перегрузку PM чужими задачами, либо пустоты, за которые никто не отвечает.
• Есть поддержка руководства, если нужно убрать блокеры. Эскалация без реакции сверху — это просто крик в пустоту.

Заключение

Этот чек-лист — не разовая проверка "подхожу я или нет", а рабочий инструмент: для самооценки, для найма и для роста внутри профессии. Он логично собирает то, о чём я писал раньше про треугольник талантов и топ компетенций, — но применительно к конкретной среде: IT-продуктовой компании, где руководитель проекта одновременно интегратор, коммуникатор и человек, который переводит бизнес-цели на язык задач для команды.

Предисловие

Как-то раз автор забыл продлить сервер в хостинге. Хостинг такой сервер удалил... Пришлось купить новый. Исходим из следующих допущений:

• Сервер под управлением Ubuntu (актуальной версии).
• Есть Root доступ к серверу через SSH и авторизацией с помощью пароля.

Что требуется сделать:

• Создать нового пользователя на сервере с правами Администратора.
• Настроить авторизацию к серверу от имени нового пользователя с авторизацией по сертификату.
• Установить Docker

Подключение к серверу и изменение пароля

У вас должны быть IP адрес сервера и пароль для Root

Подключение:

ssh root@<ip-адрес>

Смена пароля root:

passwd

Создание нового пользователя

Создать нового пользователя (например, "newuser"). При необходимости, установить пароль для этого пользователя.

sudo adduser newuser

Добавить пользователя в группу администраторов (sudo)

sudo usermod -aG sudo newuser

Настройка авторизации с помощью сертификатов

Сгенерировать сертификат на локальном компьютере.

ssh-keygen -t ed25519 -C "newuser@mypc"

В процессе выполнить:

• Задать пароль для сертификата.
• Задать название файла. Например "newuser"

Подключиться к серверу от имени root. Далее выполнить:

• Перейти в директорию нового пользователя

cd ~newuser/

• Создать директорию .ssh

mkdir .ssh

• Создать и открыть файл

nano authorized_keys

• Вставить содержимое файла newuser.pub в файл authorized_keys на отдельной строке
• Настроить права

sudo chown -R newuser:newuser /home/newuser/.ssh
sudo chmod 700 /home/newuser/.ssh
sudo chmod 600 /home/newuser/.ssh/authorized_keys

Авторизация нового пользователя

В директории, где сгенерирован сертификат для нового пользователя выполнить подключение к серверу

ssh newuser@<ip-адрес> -i ./newuser

Настройка SSH

Изменение порта ssh

Открыть файл sshd_config

sudo nano /etc/ssh/sshd_config

Отредактировать и изменить порт для ssh. Например,

Выполнить "sudo systemctl edit ssh.socket" и добавить:

[Socket]
  ListenStream=
  ListenStream=0.0.0.0:45654
  ListenStream=[::]:45654  

Выполнить команды

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo systemctl status ssh.socket

Проверить, что все хорошо: "sudo ss -tlnp | grep 45654"

Настроить ufw (если применимо)

Выполнить

sudo ufw allow 45654/tcp
sudo ufw allow 443/tcp
sudo ufw reload

Дополнительно

• Установка: sudo apt install ufw -y
• Включение: sudo ufw enable
• Обязательно: sudo systemctl enable ufw
• sudo ufw delete allow 22/tcp - удаление

Теперь подключение будет следующим (ВАЖНО!):

ssh newuser@<IP-адрес> -i ./newuser -p 45654

Отключение IPv6

Открыть файл sysctl.conf

sudo nano /etc/sysctl.conf 

В конец файла добавить

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Выполнить

sudo sysctl -p

Отключить авторизацию через пароль и авторизацию Root

Открыть файл sshd_config

sudo nano /etc/ssh/sshd_config

В файле отредактировать следующие поля:

• PubkeyAuthentication yes
• PasswordAuthentication no
• PermitEmptyPasswords no
• PermitRootLogin no

В конец файла добавить

Match User newuser
  PasswordAuthentication no

Перезапуск sshd

Выполнить:

sudo systemctl restart sshd

Установка Docker

Выполнить шаги инструкции "Install using the apt repository", см: https://docs.docker.com/engine/install/ubuntu/

Добавить нового пользователя в группу docker

Выполнить

sudo usermod -aG docker newuser

Проверить группы для нового пользователя

groups newuser

Перезагрузка

Выполнить

sudo reboot

Подключение

ssh newuser@<IP-адрес> -i ./newuser -p 45654

Заключение

На этом всё. Всем добра! См. комментарии.

Добрый день, коллеги!

Попадая в проект любому человеку нужно разобраться, а в чем же смысл и цель проекта? С какими вызовами приходится сталкиваться команде проекта для достижения намеченных конечных результатов? Как новому PM принять проект и сделать это максимально быстро?

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

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

Определение

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

Состав устава проекта

Устав - это 3-5 страничный документ, который пишет руководитель проекта, а подписывает спонсор. Очень важно, чтобы спонсор или инициатор проекта (может быть группа лиц) видели и согласились с содержанием устава.

Название

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

Цель проекта

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

Конечность проекта

Устав обязан содержать информацию о конечности проекта - ограничениях по срокам, стоимости и содержанию работ.

Тезисы:

• То, до чего договорились, то и спросят в конце.
• То, что просили в уставе, то и дадут.

В составлении устава главные помощники PM:

• Команда экспертов
• Базы знаний (корпоративная и/или личная).

Сроки проекта

Сроки в уставе проекта указываются в виде дедлайнов. Точность оценок +50%, если фаза инициации - короткая. Если для проекта характерен риск невозвратных потерь, то в этом случае устав создается продолжительное время, но и точность оценок повышается в разы.

Если проект содержит фазы/вехи, то такие даты ("вороты фаз" или майлстоны) должны быть указаны в уставе.

Стоимость и ресурсы проекта

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

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

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

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

Содержание в уставе

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

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

Веб-сервис для обслуживания конечного продукта X и поддержки пользователей, выполняющий следующие функции:
- Периодическое резервирование пользовательских данных;
- Мониторинг состояния продукта Х;
- Позволяющий выполнять произвольные операции обслуживания на конечных ресурсах продукта Х;
- Позволяющий выполнять операции обновления ресурсов продукта Х;

Дополнительные разделы устава проекта

Заинтересованные стороны

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

Если в проекте меняется PM или спонсор, то проект "перезапускается", а устав - переписывается и согласуется заново.

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

Терминирующие риски

Устав может содержать терминирующие риски - это те, которые если срабатывают, то если срабатывают, то хоронят проект. Данные риски являются неснижаемыми.

Поставки проекта

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

Ключевые показатели эффективности

Показатели если есть, то включаются в устав. Должны быть выражены численно.

Неизменность устава

Главным свойством устава является его неизменность в течение жизни проекта. Желательно, чтобы устав был в печатном виде, и его точно видел спонсор или инициатор проекта. Если меняется устав, то такой проект перезапускается.

Изменение устава проекта - это означает, что проект провален!

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

❤️ Meow! ❤️

Проект

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

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

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

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

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

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

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

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

Устав создает руководитель проекта, а согласует и подписывает - спонсор.

Жизненные циклы

Методологи проектного управления выделяют следующие виды подходов к реализации проектов:

• Предиктивный - планирование реализации проекта осуществляется от начала и до конца. В процессе реализации проекта изменения практически невозможны.
• Адаптивный - выделяют следующие подвиды:
• Итерационный - поставки реализации осуществляются регулярно с определенной частотой. Например, классический CI/CD процесс;
• Инкрементальный - поставки осуществляются порционно, когда реализован ценный инкремент;
• Инкрементально-итерационный - обобщение двух подвидов выше. Классический пример - SCRUM.
• Гибридный - совокупность предиктивного и адаптивного жизненного цикла. Осуществляется первоначальное планирование проекта, а в процессе реализации гибкие планы постоянно уточняются.

Программы и портфели

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

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

Координатор и экспедитор

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

Экспедитор проекта - это роль, которая выступает помощником руководителя проекта в части коммуникаций и не обладает какой-либо властью в принятии решений по проекту.

Роли в проекте

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

А на сегодня - все. ❤️ Meow! ❤️

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

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

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

Важно напомнить, что самые важные заинтересованные стороны указываются в Уставе проекта.

Главная задача

Главная задача управления заинтересованными сторонами - это идентифицировать и адекватно вовлечь их в проект.

Идентификация ЗС осуществляется в процессе инициации или запуска проекта. Еще до момента создания устава начинает формироваться соответствующий реестр.

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

Область знаний

Прежде чем приступим к описанию процессов, сформулируем вопросы к области знаний управления ЗС:

• Где искать заинтересованные стороны?
• Как фиксировать выявленные ЗС?
• Что делать весь проект с ЗС?

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

• Идентификация заинтересованных сторон - относится к группе процессов инициации проекта.
• Планирование управление заинтересованными сторонами - относится к группе процессов планирования.
• Управление вовлечением заинтересованных сторон - относится к группе процессов выполнения.
• Мониторинг вовлечения заинтересованных сторон - относится к группе процессов мониторинга и управления.

Любопытной особенностью области знаний управления ЗС является то, что процесс идентификации относится к инициации проекта. К инициации проекта еще относится только процессы интеграции проекта, см. https://blog.s-sidorov.ru/WFPxXYin3Rj

Идентификация заинтересованных сторон

Для идентификации заинтересованных сторон применяется "здравый смысл" (как, собственно, и везде). Где их можно поискать?

• Применить анализ документов: возможно для проекта есть контракт или бизнес кейс?
• Задаться вопросами:
• Кто просил о запуске проекта?
• Кто будет использовать результаты проекта?
• Кто изменит свою работу в результате реализации проекта?
• Кто принимает решения относительно проекта?
• Кто может выделять / забирать ресурсы проекта?
• Кто влияет на тех, кто влияет на проект?

Минимально в реестре заинтересованных лиц должны быть Спонсор, Руководитель проекта и Команда проекта. Последнюю в реестре не указывают, но подразумевают.

Реестр заинтересованных сторон

Идентифицированные заинтересованные стороны фиксируются в реестре. Реестр ЗС - это центральный артефакт области знаний, и он состоит из следующих столбцов таблицы:

• ФИО или семантическая роль. Если есть, то указываются должность, отдел и/или департамент;
• Опционально: непосредственный начальник;
• Контактная информация и предпочитаемый вид связи;
• Если для обращения к ЗС требуются выполнить некоторые ритуалы, то их также необходимо зафиксировать;
• Главные ожидания и главные требования;
• Влияние на проект:
• Отношение к проекту;
• Интерес к проекту;

Дополнительно можно указать роль в проекте. При этом, значения ролей могут быть своими, например, "обеспокоенный лоббист".

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

Техники идентификации заинтересованных сторон

Основные техники идентификации - стандартные:

• Экспертные оценки;
• Мозговой штурм;
• Письменный мозговой штурм - группе раздается листок, где каждый указывает 2-3 свои идеи, кто является ЗС. Далее листки передаются по кругу, куда каждый вписывает новую идею, но без повторений. И так до тех пор, пока листки не завершат круг. Осуществляется молча;
• Анализ документов;
• Опросники и анкеты;

Влияние, отношение и интерес заинтересованных сторон

В процессе идентификации заинтересованных сторон необходимо определить следующие свойства:

• Влияние - то, насколько сильно ЗС может повлиять на проект.
• Отношение - является ли ЗС другом, врагом, нейтроном или т.п.
• Интерес - насколько ЗС следит за проектом.

Стремимся к тому, чтобы "враги" были в неведении, а "лоббисты" - наоборот.

Планирование вовлечения заинтересованных сторон

Перед планирование вовлечения ЗС требуется определить тактики вовлечения. Для этого используются матрицы Влияния-Интерес, куб Влияние-Интерес-Власть, модель особенностей и т.д.

Матрица Влияние-Интерес

Рассмотрим пример матрицы Влияния-Интереса. Чтобы создать матрицу, нужно построить график, где:

• ось Y — влияние;
• ось X — интерес.

Шкалы осей не обязательно должны быть цифровыми. Достаточно определить низкие и высокие показатели для дальнейшей классификации.

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

• Закрыть потребности / Keep satisfied - поддерживать уровень удовлетворенности:
• Следить, что требования удовлетворено достаточно;
• Противников не злить, а сторонников - переводить в другой квадрант.
• Активно вовлекать / Manage closely - уделять максимальное время, привлекать к планированию, демо и т.п.
• Оказывать внимание / Keep Informed - информировать о работах проекта:
• Делать рассылку писем со статусом;
• Создать ящик, куда можно направлять пожелания.
• Наблюдать / Monitor - следить, что ничего не изменилось со временем.

Куб заинтересованных сторон

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

Модель особенностей заинтересованных сторон

Для каждого типа идентифицированной заинтересованной стороны определяется тактика работы с ней.

Типы влияния заинтересованных сторон

Влияние на работы проекта делятся на следующие виды влияния:

• Влияние на нижнем уровне - обычно, это команда проекта.
• Влияние сбоку - это другие менеджеры, средние начальники.
• Влияние снаружи - это те ЗС, которые находятся снаружи проекта.
• Влияние на верхнем уровне - это высшее руководство.

На проекте может формироваться карта заинтересованных сторон с указанием тактик работы с ними.

Цель планирования вовлечения заинтересованных сторон

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

Управление вовлечением заинтересованных сторон

На протяжении проекта требуется отслеживать и актуализировать записи в реестре ЗС. Для этого применяются различные инструменты, такие как:

• Проводить совещания;
• Вести переговоры;
• Управлять конфликтами;
• Формировать базовые правила вместе с командой;
• Предпринимать действия, которые диктует культура и "политическая" осведомленность.

Мониторинг вовлечения заинтересованных сторон

В процессе реализации проекта PM и команда проверяют:

• Вовлекаются ли ЗС так, как планировали?
• Не изменилось ли отношение ЗС к проекту?
• Не пора ли скорректировать план вовлечения ЗС?

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

Заключение

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

❤️ Meow! ❤️

Привет, Мир!

Среди трёх граней талантов руководителя проектов (Ways of Working, Power Skills, Business Acumen) сегодня поговорим о Power Skills. Он же Soft Skill - про то, как слышать, слушать и быть услышанным.

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

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

Процессы управления коммуникациями

Управление коммуникациями состоит из следующих процессов:

• Планирование управления коммуникациями. Осуществляется в два этапа:
• После инициации проекта.
• После определения команды проекта
• Управление коммуникациями - управления каналами коммуникаций.
• Мониторинг коммуникаций - проверяем исполнение плана коммуникаций.

Область знаний относится к "другим" планам управления проекта и не включается в проектный треугольник/семиугольник. Суть области знаний - убедиться, что все заинтересованные лица вовремя получают всю необходимую информацию.

Виды коммуникаций

Различаются следующие виды коммуникаций:

• Устные ИЛИ письменные
• Официальные ИЛИ неофициальные
• Толкающие ИЛИ тянущие ИЛИ интерактивные
• Толкающие (Push) - отправить коммуникацию без проверок успешности доставки.
• Тянущие (Pull) - любой запрос информации.

Отчёты

Любые отчёты в проекте - это способ коммуникации. Отчет должен быть полным, четким и кратким (по возможности).

Выделяют следующие виды отчетов:

• Отчет о статусе
• Отчет о прогрессе
• Отчет о тенденциях (есть ли улучшения или ухудшения со временем)
• Отчет о прогнозах (единственный вид отчёта про будущее)
• Отчет о расхождениях
• Отчёт о выполненном объеме (относится к EVM, Earned Value Management).

Каналы коммуникаций

Если коммуникация происходит между двумя людьми, то получаем один канал коммуникации. Если между тремя, то два канала, а между четырьмя - 6.

Формула:

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

Шум, канцелярит и жаргонизм

Шум в коммуникациях - это всё то, что мешае коммуникациям. В т.ч. физический шум соседа с перфоратором при удаленной работе.

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

Техники коммуникаций

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

Итого

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

После формирования команды (этап Forming) первоначальный план надо превратить в базовый план управления коммуникациями:

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

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

Если же этого не сделать, то такой ПМ резко увеличивает шанс задержек или даже провала проекта.

На этом всё. ❤️ Meow! ❤️

В процессе повышения квалификации студенты часто спрашивают наставника о ежедневных операциях руководителя проектов? Эти вопросы для меня стали мотивацией освежить, что же делает PM, когда проект уже в ходу.

Итак, где мы находимся? Все планы созданы и утверждены, команда заряжена на реализацию проекта. Настало время соединять потенциал людей с планами -> интеграция.

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

Процессы интеграции

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

• Инициация проекта: разработать Устав проекта
• Планирование: разработать план управления проектом (ПУП)
• Исполнение проекта:
• Направлять и управлять работами проекта
• Управлять знаниями проекта
• Контроль проекта:
• Мониторинг и контроль работ проекта
• Осуществлять интегрированный контроль изменениями проекта
• Закрытие: закрытие проекта или фазы.

Разработка Устава проекта

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

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

Разработка плана управления проектом

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

Перед разработкой такого плана осуществляются следующие шаги:

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

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

• Жизненный цикл проекта (описание типа и подхода)
• Все базовые планы (Содержание, Расписание, Стоимость)
• Другие планы управления областями знаний (Качество, Риски, Закупки, Заинтересованные лица. Коммуникации, Ресурсы и др).
• План управления изменениями
• План управления конфигурацией

Направлять и управлять работами проекта

Данный процесс относится к области знаний выполнения проекта. Руководитель проекта организует ежедневные операции команды проекта -> дает импульсы команде, вдохновляет команду сделать работу (Performing).

Выходами данного проекта является:

• Поставки проекта.
• Данные об исполнении.
• Актуализация журнала проблем (Issue Log)
• Запросы на изменения (corrective action, prevention action, defect repair, updates и тп).

Управление знаниями проекта

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

Хорошей практикой является установка правила для команды: не смотрел Базу Знаний - не спрашивай!

Мониторинг и контроль работ проекта

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

Выходами данного процесса являются:

• Отчет об исполнении.
• Обновление планов и документов проекта
• Создание запросов на изменения в результате осознанной реакции (т.е. реактивной, а не проактивной).

Интегрированный контроль изменений

Данный процесс необходимо для обработки новых запросов на изменения. Алгоритм обработки следующий:

• Не противоречит ли Уставу? Если противоречит, то запрос отклоняется.
• Осуществляется анализ влияния на планы. Если применимо, то принимается в работу. Если влияет на планы, то в дело вступает совет по контролю изменений (Change Control Board - группа лиц в проекте, которая рассматривает запросы и принимает решение о включении или отклонении запроса.

В результате - запрос на изменение либо принимается, либо отклоняется, а о решении сообщается заинтересованным сторонам/лицам.

Закрытие проекта или фазы

Каждый проекта должен обязательно завершаться:

• Передаются конечные результаты. Подписываются акты приемо-передачи.
• Формируется финальные отчет (анализ и оценка успешности.
• Высвобождается команда.
• Финализируются усвоенные уроки.

Финал

Следуя шагам выше каждый ПМ повышает вероятность успешного завершения проекта. Отсутствие процессов интеграции порождает хаос - а это губительно плохо. Наша задача - побороть хаос и неопределенность. Сделать это возможно с помощью управления интеграцией :)

Meow!

Сколько ролей в проектном менеджменте в IT вы знаете? Project Manager, Agile Project Manager (Scrum Master), Delivery Manager (и не только Kanban), Program Manager, Technical Project Manager, Technical Program Manager, Portfolio Manager, Team Lead - все это сорта менеджмента отличаются друг от друга. Давайте разберемся в сути и принципах.

Сертификаты вам нужны в двух случаях: PMP после 5 лет лет работы чтобы снять гигиенические вопросы на собесах и PSM-I, если нужно работать в Agile. Можно обладать сертификатами по бизнес-знаниям, по мере надобности - LESS / Nexus / SAFe.

Project Manager

Это именно та средняя по больнице роль, на которую рассчитывают соискатели вакансий после прохождения обучения. Обычно требуется опыт от 1 до 5 лет работы в проектах. У такого PM, обычно, среднего размера проекты в количестве до 3-х штук и управление парой командой численностью до 20 человек. Иногда, встречаются PMы, которые работают с внешними подрядчиками (команда на аутсорсе). Заказчиков у такого проекта не особо много и вряд ли ведет проекты полного цикла со средней ответственностью. В дальнейшем растет до Senior Project, где делает всё тоже самое, только больше и с большей ответственностью.

Стандартная девиация для роли - это PM уровня супер-мега-бог человек, который держит на себе всё. Это редкость, и таких с рынка не ищут.

Agile Project Manager

Всё тоже самое, что и Project Manager только в Agile. Обладает массой примесей Product Owner, Scrum Master, Agile Coach, Dev Team Lead и тп. Основная разница с обычным PM: есть 1-2 команды, которые необходимо вести итеративно и/или инкрементально.

В зависимости от контекста, скорее всего это будет/была ваша стартовая роль в управлении проектами. Желательно иметь PSM-I иди CSM.

Delivery Manager

Становится хуже... Service Delivery Manager в KANBAN это тот, кто настраивает систему поставки ценности и обладает полномочиями устранять препятствия в потоке доставки ценности.
В известных RU-банках это те, кто следит за релизами, подбивает статусы и организует встречи, но не планирует и не контролирует.
Примесей от продактов и аналитиков не имеет.
Иногда DM подразумевает управление бюджетами и контрактами - тогда почти наверняка работа с внешними заказчиками. В этом случае, опыт работы в проектах от 5 лет, а сама роль повыше и побольше, чем PM + должен уметь вести проекты полного цикла

Program Manager

Это "мета"-прожект. Обычно, у него нет "своей" команды, но бываю исключения, когда Program совмещает работу с Project одного проекта. В целом, управляет программой и через него проходят несколько команд. Руководит PMами направляя их деятельность в верное русло.
Длительность проектов (программ) от года и больше. Проекты могут быть и без deadline'ов. В компаниях до 1000 сотрудников таких ребят нет.

Логичная ступенька эволюции из проджекта: Project —> Senior Project —> Program. Ну или горизонтальный переход из Delivery Manager.
В реальности происходит всё что угодно, цепочка написана для умозрительно.

Technical (Project / Program) Manager

Technical (Project / Program) Manager это все то же самое, что и PM/PrgM, но с добавлением понимания о чем говорят DEV, DevOps, Test и т.д. Может что-нибудь да накодировать сам, разобраться в дефекте и принять решение в одно лицо (в зависимости от компании, либо писал код ранее, либо нахватался пока работал в другой роли).
Разница с обычным PM в том, что обычный PM на проекте миграции из OnPrem в Cloud будет многозначительно молчать, хлопать глазами, но в случае проекта открытия филиала, организации крупного события успешно поможет конторе.
Кстати, технические менеджеры проекты без инженерной части часто проваливают из-за непривычного контекста.

Portfolio Manager

Это мета-Program Manager. Уровень директора, Vice-President или типа того. Напрямую проектами не управляет, но имеет большой опыт работы именно в проектах. Умеет решать конфликты.
В русскоязычном пространстве названия могут отличаться — это специфика структуры организации, которая тянется из культурных отличий. Могут встречаться роли программный директор, проектный директор, руководитель стратегических проектов и тд.

Карьерный рост

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

Логичным видится переход из прожектов в продакты, если интересно отвечать на вопрос "что и зачем", а не "как и когда".

PM может вырасти до CTO/COO - ветка тупиковая, в какой-то момент придется расти в ширь. Либо переходить в другую роль. Вырасти можно до руководителя PMO, если нравится драться за ресурсы и оптимизировать процессы.

PM в продуктовых компаниях

Ну и чтобы два раза не вставать, поговорим о PM в продуктовых компаниях.

Наверняка вы часто слышали, что в продуктовых компаниях, где внедрен Agile, менеджеры как бы не нужны. Нужны продакты, которые будут ответственны за вопрос "как и когда". Ну и старшие менеджеры, а команда будет самоорганизована и мотивирована.

Стереотипы менеджмента

Стереотипная порочная практика проектного менеджера - бегать за исполнителем с палкой с вопросом в стиле попугая "когда-будет-готово, когда-будет-готово"? Знакомо? Практика неэффективна - команда будет считать такого PM чужеродным объектом, чувствовать постоянное давление, а очков неформального лидера это не прибавляет. Да и радости работать с таким PM как-то маловато.

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

• Объясните команде смысл проекта (или задачи), почему он нужен, кому он нужен и почему он нужен именно в те сроки, которые хочет заказчик. То есть что будет, если не сделать в эти даты.
• Спросите команду, когда они будут готовы вернуться со сроками. Дайте команде время чтобы они изучили проект, основные требования и придумали как они в общих чертах будут делать проект.
• Исходя из даты предыдущего пункта, попросите команду к некоторой дате сказать, что они могут сделать, скажем, за квартал.
• Попросите команду дать не оценки по задачам, а список штук, которые они за этот квартал готовы поставить (deliverables).

"Ну вы же Agile, сделайте как мне надо пораньше. Без договора с поставщиком и мимо процесса. Очень надо!".

Agile - философия и mindset, а не методология. Быть Agile это про человечность. Сотрудничать, помогать друг другу, ценить результат и строить отношения. Но процессы-то тоже нужны, иначе вас легко продавить, а вы не понимаете ограничений окружающих. Что же делать? Установить нескольких (2-5) принципиальных ограничения и дать свободу в действиях в остальном. Свобода это хорошо, но без рамок будет хаос!

"Одно слово, которое лучше всего отражает суть роли менеджера проектов - интегратор”. - Rita Mulcahy

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

Ссылка с подробностями от Ивана Селиховкина

❤️ Meow! ❤️

Сегодня представляю вам статью, которая целиком написана с помощью искусственного интеллекта.

ПОЕХАЛИ!

В современном мире разработки программного обеспечения измерение продуктивности разработчиков становится все более сложной задачей. Традиционные метрики, такие как количество строк кода или завершенных задач, уже не могут полноценно отражать вклад и эффективность команды. Именно поэтому на помощь приходит SPACE framework — методология, разработанная исследователями из GitHub, Microsoft и Университета Виктории (Канада).

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

SPACE Framework решает несколько ключевых проблем, связанных с измерением и улучшением продуктивности разработчиков:

1. Ограниченность традиционных метрик: Традиционные метрики, такие как количество строк кода или завершенных задач, не учитывают сложность и качество работы. SPACE Framework предлагает более комплексный подход, который охватывает различные аспекты продуктивности.
2. Фокус на качестве, а не на количестве: Вместо того чтобы просто измерять объем выполненной работы, SPACE Framework помогает оценивать качество кода, что в конечном итоге ведет к более стабильным и надежным продуктам.
3. Учет невидимой работы: Многие аспекты работы разработчиков, такие как рефакторинг кода или участие в командных обсуждениях, часто остаются незамеченными. SPACE Framework помогает учитывать и эти важные, но невидимые элементы работы.
4. Балансировка метрик: Использование только одной метрики может привести к искажению реальной картины продуктивности. SPACE Framework предлагает сбалансированный набор метрик, который помогает избежать перекосов и учитывать различные аспекты работы команды.
5. Улучшение командной работы: Применение SPACE Framework способствует лучшему пониманию и улучшению командной динамики, что в конечном итоге ведет к более эффективной и слаженной работе.
6. Адаптация к изменениям: В условиях быстрого технологического прогресса и изменения требований, SPACE Framework помогает командам адаптироваться и оставаться продуктивными, несмотря на внешние изменения.

Эти проблемы делают SPACE Framework незаменимым инструментом для современных команд разработки, стремящихся к высокому уровню продуктивности и качества.

Внедрение SPACE Framework

Для успешного внедрения SPACE Framework в вашу команду разработки, следует применять следующие практики:

1. Определение метрик для каждой из пяти измерений:
• Satisfaction and well-being (Удовлетворенность и благополучие): Оцените удовлетворенность команды через опросы и регулярные обратные связи.
• Performance (Производительность): Измеряйте производительность через метрики, такие как время выполнения задач и количество завершенных задач.
• Activity (Активность): Следите за количеством коммитов, временем, проведенным за кодированием, и количеством завершенных код-ревью.
• Communication and collaboration (Коммуникация и сотрудничество): Оценивайте взаимодействие внутри команды через количество и качество командных встреч, обсуждений и совместных проектов.
• Efficiency and flow (Эффективность и поток): Измеряйте время, затраченное на выполнение задач, и количество прерываний в работе.
2. Регулярный сбор и анализ данных:
• Установите инструменты для автоматического сбора данных, такие как системы контроля версий, трекеры задач и платформы для код-ревью.
• Проводите регулярные анализы собранных данных, чтобы выявлять тенденции и области для улучшения.
3. Проведение регулярных ретроспектив:
• Организуйте регулярные ретроспективы, чтобы обсудить результаты метрик и определить, что работает хорошо, а что требует улучшения.
• Вовлекайте всю команду в обсуждение и принятие решений на основе данных.
4. Фокус на непрерывном улучшении:
• Используйте результаты анализа для внедрения изменений и улучшений в процессах разработки.
• Постоянно адаптируйте и корректируйте метрики и подходы в зависимости от изменений в команде и проекте.
5. Обучение и развитие команды:
• Обеспечьте обучение команды принципам и методам SPACE Framework.
• Поощряйте развитие навыков и знаний, которые помогут команде работать более эффективно и продуктивно.
6. Прозрачность и открытость:
• Делитесь результатами метрик и анализов с командой, чтобы все участники были в курсе текущего состояния и могли внести свой вклад в улучшение процессов.
• Создайте культуру открытости, где каждый член команды может предложить идеи и решения для повышения продуктивности.

Практики SPACE Framework

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

1. Еженедельные или двухнедельные ретроспективы:
• Цель: Обсуждение текущих метрик и выявление областей для улучшения.
• Формат: Команда собирается для обсуждения того, что сработало хорошо, что можно улучшить и какие действия предпринять для повышения продуктивности.
2. Ежемесячные обзоры метрик:
• Цель: Глубокий анализ метрик по всем пяти измерениям SPACE Framework.
• Формат: Презентация данных, обсуждение тенденций и определение стратегий для улучшения.
3. Ежедневные стендапы:
• Цель: Обсуждение текущих задач, выявление блокеров и координация работы.
• Формат: Краткие встречи (обычно 15 минут), где каждый член команды делится своим прогрессом и планами на день.
4. Код-ревью сессии:
• Цель: Обеспечение качества кода и обмен знаниями внутри команды.
• Формат: Регулярные встречи для совместного просмотра и обсуждения кода, что помогает улучшить качество и обучить менее опытных разработчиков.
5. Опросы удовлетворенности и благополучия:
• Цель: Оценка уровня удовлетворенности и благополучия команды.
• Формат: Периодические анонимные опросы, результаты которых обсуждаются на ретроспективах или специальных встречах.
6. Обучающие сессии и воркшопы:
• Цель: Повышение квалификации и обмен знаниями.
• Формат: Регулярные обучающие мероприятия, где команда может изучать новые технологии, методы и лучшие практики.
7. Планирование спринтов:
• Цель: Определение задач и целей на следующий спринт.
• Формат: Встречи для обсуждения и планирования задач, распределения ролей и установления приоритетов.
8. Демо-сессии:
• Цель: Демонстрация достигнутых результатов и получение обратной связи.
• Формат: Периодические презентации, где команда показывает, что было сделано за определенный период, и получает обратную связь от заинтересованных сторон.

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

Аналоги SPACE Framework

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

1. DORA Metrics (DevOps Research and Assessment):
• Описание: Набор метрик, разработанный для оценки эффективности DevOps-практик. Включает в себя такие метрики, как частота деплоя, время выполнения изменений, время восстановления после инцидентов и процент неудачных изменений.
• Цель: Помочь организациям улучшить свои DevOps-процессы и ускорить доставку программного обеспечения.
2. Accelerate Metrics:
• Описание: Основаны на исследованиях, представленных в книге "Accelerate" авторов Николь Форсгрен, Джез Хамбл и Джин Ким. Эти метрики включают в себя показатели, связанные с производительностью и стабильностью.
• Цель: Предоставить организациям инструменты для измерения и улучшения их производительности в разработке и доставке ПО.
3. OKR (Objectives and Key Results):
• Описание: Методология постановки целей и ключевых результатов, которая помогает командам и организациям фокусироваться на достижении конкретных, измеримых целей.
• Цель: Обеспечить прозрачность и согласованность целей на всех уровнях организации.
4. SMART Goals:
• Описание: Метод постановки целей, который акцентирует внимание на том, чтобы цели были конкретными (Specific), измеримыми (Measurable), достижимыми (Achievable), релевантными (Relevant) и ограниченными по времени (Time-bound).
• Цель: Помочь командам и индивидуальным разработчикам ставить четкие и достижимые цели.
5. Balanced Scorecard:
• Описание: Стратегический инструмент управления, который помогает организациям отслеживать и управлять своей деятельностью с помощью набора финансовых и нефинансовых показателей.
• Цель: Обеспечить сбалансированный подход к оценке производительности, учитывая различные аспекты деятельности организации.
6. GQM (Goal Question Metric):
• Описание: Методология, которая помогает организациям определить цели, сформулировать вопросы для оценки достижения этих целей и выбрать соответствующие метрики.
• Цель: Обеспечить структурированный подход к измерению и улучшению процессов разработки ПО.

Эти фреймворки и методологии могут быть использованы как альтернативы или дополнения к SPACE Framework, в зависимости от конкретных потребностей и контекста вашей команды или организации.

Метрики SPACE

1. Satisfaction and Well-Being (Удовлетворенность и благополучие):
• Опросы удовлетворенности: Регулярные опросы для оценки уровня удовлетворенности и благополучия команды.
• Индекс счастья: Ежедневные или еженедельные опросы, где члены команды оценивают свое текущее состояние.
• Текучесть кадров: Уровень удержания сотрудников и причины увольнений.
2. Performance (Производительность):
• Время выполнения задач: Среднее время, затраченное на выполнение задач или пользовательских историй.
• Частота деплоя: Количество развертываний в продакшн за определенный период.
• Время восстановления после инцидентов: Среднее время, необходимое для восстановления системы после сбоя.
3. Activity (Активность):
• Количество коммитов: Общее количество коммитов в репозитории за определенный период.
• Время, проведенное за кодированием: Общее время, затраченное на написание кода.
• Количество завершенных код-ревью: Число завершенных код-ревью за определенный период.
4. Communication and Collaboration (Коммуникация и сотрудничество):
• Количество командных встреч: Число встреч, проведенных командой за определенный период.
• Участие в обсуждениях: Количество и качество участия в обсуждениях и планировании.
• Оценка сотрудничества: Опросы, оценивающие уровень сотрудничества и взаимодействия внутри команды.
5. Efficiency and Flow (Эффективность и поток):
• Время выполнения задач: Среднее время, затраченное на выполнение задач без прерываний.
• Количество прерываний: Число прерываний в работе, таких как переключение контекста или неожиданные задачи.
• Процент времени в потоке: Доля времени, когда разработчики находятся в состоянии потока, то есть работают без прерываний.

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

Внедрение

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

1. Определение целей и метрик:
• Шаг: Совместно с командой определите цели, которые вы хотите достичь с помощью SPACE Framework.
• Пример: Если цель — улучшить удовлетворенность команды, можно провести опросы для оценки текущего уровня удовлетворенности и благополучия.
2. Сбор данных и выбор инструментов:
• Шаг: Выберите инструменты для автоматического сбора данных по выбранным метрикам.
• Пример: Используйте системы контроля версий (например, GitHub) для отслеживания количества коммитов и времени, проведенного за кодированием. Для опросов удовлетворенности можно использовать Google Forms или специализированные инструменты, такие как Officevibe.
3. Регулярные ретроспективы и обзоры метрик:
• Шаг: Проводите регулярные ретроспективы и обзоры метрик, чтобы анализировать данные и выявлять области для улучшения.
• Пример: На еженедельных ретроспективах обсуждайте результаты опросов удовлетворенности и метрики активности, такие как количество завершенных код-ревью.
4. Внедрение изменений на основе данных:
• Шаг: На основе анализа данных внедряйте изменения в процессы и практики команды.
• Пример: Если метрики показывают, что время выполнения задач слишком велико из-за частых прерываний, можно ввести практику "тихих часов", когда разработчики могут работать без отвлечений.
5. Обучение и развитие команды:
• Шаг: Обеспечьте обучение команды принципам и методам SPACE Framework.
• Пример: Проведите воркшопы и обучающие сессии, чтобы команда понимала, как использовать метрики для улучшения своей работы.
6. Прозрачность и открытость:
• Шаг: Делитесь результатами метрик и анализов с командой, чтобы все участники были в курсе текущего состояния и могли внести свой вклад в улучшение процессов.
• Пример: Создайте дашборд с ключевыми метриками, доступный для всей команды, и регулярно обновляйте его.
7. Постоянное улучшение:
• Шаг: Постоянно адаптируйте и корректируйте метрики и подходы в зависимости от изменений в команде и проекте.
• Пример: Если команда начинает работать над новым проектом, пересмотрите и обновите метрики, чтобы они соответствовали новым целям и задачам.

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

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

Заключение

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

Начните с малого, постепенно внедряя элементы SPACE Framework, и вы увидите, как ваша команда становится более продуктивной, слаженной и мотивированной.