Предисловие

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

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

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

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

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

Алгоритм:

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

   sudo adduser newuser

• Выдать для нового пользователя права администратора.

   sudo usermod -aG sudo newuser

Настройка авторизации

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

• На локальном компьютере (прим.: делал на Mac'е) - сгенерировать сертификат

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

- При создании требуется задать название файла. Например: idnewuser.
- Опционально, можно задать пароль для сертификата. // Прим.: лучше создать.

• На удаленном сервере зайти в директорию .ssh для newuser:

   cd ~newuser/.ssh/

• Скопировать pub-ключ сертификата в файл "authorized_keys"

   nano authorized_keys
   <вставить содержимое idnewuser.pub на отдельной строке>

• Убедиться, что директория .ssh и файл authorized_keys обладают корректными правами

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

Установка Docker

Используя Root авторизацию выполнить шаги инструкции "Install using the apt repository" тут: https://docs.docker.com/engine/install/ubuntu/

После установки выполнить шаги:

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

   <sudo> usermod -aG docker newuser

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

   groups newuser

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

Требуется авторизоваться с помощью сертификата и проверить, что у newuser есть права на выполнение команд docker без sudo.

• Авторизоваться на сервере с помощью сертификата (файл "idnewuser")

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

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

   docker ps

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

Для отключения авторизации с помощью пароля для newuser требуется выполнить следующие шаги на сервере

• Открыть конфиг ssh

   <sudo> nano /etc/ssh/sshd_config

• В конфиг ssh в конец файла дописать (newuser - это имя нового пользователя)

     Match User newuser
         PasswordAuthentication no

• Сохранить изменения. Протестировать конфиг на ошибки:

     sudo sshd -t

• Если всё ок, то применить настройки

     sudo systemctl restart sshd

Заключение

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

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

Попадая в проект любому человеку нужно разобраться, а в чем же смысл и цель проекта? С какими вызовами приходится сталкиваться команде проекта для достижения намеченных конечных результатов? Как новому 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, и вы увидите, как ваша команда становится более продуктивной, слаженной и мотивированной.

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

Основная статья про принципы управления проектами находится в Клубе: https://pmi.moscow/post/52/ Пожалуйста, присоединяйтесь для обсуждения!

ПРЕДЕЛЕНИЕ

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

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

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

Принципы Agile

Agile - как же много о нём слышно! Agile был придуман инженерами по разработке программного обеспечения, и является реакцией снизу для улучшения процессов разработки ПО и сам по себе является не каким-то фреймворком, а скорее "набор мыслей" (mindset в прямом смысле этого слова). Давайте же ознакомимся, что же написано в Библии Agile?

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

Принципы Agile-manifesto

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

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Вчитавшись в принципы Agile Manifesto трудно не обратить внимание, что все описанные принципы логичные и соответствуют "здравому смыслу", и трудно с ними не согласиться в принципе. На мой взгляд, все IT-компании по всему миру, независимо от используемого подхода, соответствуют этим принципам. Даже в случае использования Водопадного подхода (в реальной жизни чистый Водопадный подход никто не использует) всегда возможны изменения с помощью дополнительных актов, изменения нормативов и всему такому.

Принципы Agile (и с ними все просто и сложно одновременно)

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

Четкое следование принципам Agile - сродни искусству, да и не всегда возможно в принципе.

• Представьте, что конечный продукт - это бэкенд-сервис, который выполняется на сервере. Как же можно обеспечить раннюю поставку уже полезного сервиса? Что это может означать? Ну вот, допустим, разработали каркас сервиса, который умеет запускаться, выполнять одну функцию и писать логи - такой сервис полезен ли для заказчика? Разве можно такой сервис отдавать пользователям? А готов ли заказчик принимать активное участие на первых этапах разработки сервиса?
• Другой пример, где найти команду высокомотивированных профессионалов, которые таковыми останутся на протяжении всей разработки? Если конечный продукт достаточно большой (а не стартап, или маленькое приложение), то он разрабатывается большим количеством людей с разной квалификацией и целями.

Подробнее про недостатки Agile принципов и SCRUM Framework можно почитать в "Черной Книге Скрам" от И. Селиховкина.

Фундаментальные принципы проектного управления

Если у проекта существуют ограничения по срокам, стоимости и/или содержанию, то применение принципов Agile основанных на тех или иных реализаций, таких, как SCRUM, Kanban, Lean не всегда оправдано по причине отсутствия гарантий по получению конечных результатов, соответствующих заданным ограничениям. Тот же SCRUM не может предиктивно оценить срок завершения разработки проекта, пока не вычислит истинную среднюю мощность команды.

<картинка здесь>

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

Информация взята из источника: https://infostart.ru/1c/articles/889250/

Принцип неизменности границ

Как ответ на вызовы конечности и неопределенности, родилось проектное управление. Появился принцип "яйца". Что символизирует куриное яйцо? Представьте, курица снесла яйцо и садится его высиживать. Яйцо сразу конечного размера, то есть скорлупа уже больше не увеличивается. И скорлупа – это аналог того, что называется «устав проекта». В каждом проекте обязательно есть такая вещь, как устав. В уставе фиксируются неизменные ограничения проекта - стоимость, сроки и кратко его суть (содержание). И сколько бы курица ни сидела, яйцо больше не растёт. Это жесткие рамки, в которые проект должен уложиться, и мы обязаны уложить его в эти рамки любой ценой

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

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

Задача менеджера проекта – обеспечить, чтобы внутреннее содержимое не переросло ограничения, чтобы белок и желток не стали больше самого яйца. Если скорлупа лопнет, проект тоже не получится. И PMBoK – это пособие о том, как впихнуть то, что не вмещается, как яйцо удержать в скорлупе.

Принцип завершенности и цикличности

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

Внутренний клубок процессов - это ни что иное, как цикл Деминга.

PDCA циклически повторяющийся процесс принятия решения, используемый в управлении качеством. Также известен как Deming Cycle, Shewhart cycle, Deming Wheel или Plan-Do-Study-Act. Также известен как принцип Деминга-Шухарта, но Деминг предпочитал PDSA у Шухарта.

• Планирование (P) - установления целей и процессов, необходимых для достижения целей, планирования работ по достижению целей процесса и удовлетворения потребителя, планирования выделения и распределения необходимых ресурсов;
• Выполнение (D) - выполнение запланированных работ;
• Проверка (C) - сбора информации и контроль результата на основе ключевых показателей эффективности, получившегося в ходе выполнения процесса, выявления и анализа отклонений, установления причин отклонений;
• Воздействие (A; управления, корректировки) - принятия мер по устранению причин отклонений от запланированного результата, изменений в планировании и распределении ресурсов.

Принцип проактивности

Проактивность – это антоним реактивности. Что такое реактивность? Когда что-то загорелось, побежали – потушили. А проактивность – это мы сидим и думаем, как бы так сделать, чтобы не загорелось никогда, а если загорится, чтобы мы быстро справились. Фактически, проактивность - это управление рисками. Превентивное.

Принцип командности

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

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

Набор почти универсальных проектных принципов

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

• NUP1: выбирай результаты и истину, а не привязанности
• NUP2: береги и оптимизируй энергию и ресурсы
• NUP3: всегда будь проактивен
• NUP4: помни, что прочность цепи определяется по самому слабому звену
• NUP5: не делай ничего без четкой цели
• NUP6: используй воспроизводимые элементы

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

Шесть принципов высокого качества обслуживания

Нашел тут статью: https://www.prostoy.ru/642.html - любопытно. Хорошая мысль - начинать с конца.

• ВИДЕНИЕ И МИССИЯ ПРОЕКТА
• БИЗНЕС ЦЕЛИ
• СТРАТЕГИЯ ВМЕШАТЕЛЬСТВА И ВЫПОЛНЕНИЯ ПРОЕКТА
• ОРГАНИЗАЦИОННОЕ ВЫРАВНИВАНИЕ
• ИЗМЕРЕНИЕ И ОТСЛЕЖИВАЕМОСТЬ

ЗАКЛЮЧЕНИЕ

Следовать принципам - важно. Надеюсь, что вам понравилась статья, увидимся в будущих сериях.

❤️Meow! ❤️

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

3 ключевых принципа бережливого производства (Lean в Toyota): клиентоориентированность, вытягивание, самосовершенствование.

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

• Фаза реализации: это текущая доминантная работа.
• Программирование: это создание нового по принуждению.

Что такое KANBAN-метод

Канбан-метод – это метод улучшения работы. Существует гипотеза, что практики Канбан-метода позволят вам делать работу еще лучше. С позиции Канбана это значит, что вы будете лучше попадать в ожидания заказчика. Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.

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

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

• Эволюционный метод развития.
• Катализатор изменений.

Канбан-метод и Канбан Тойоты – это одно и то же?

Канбан на заводах Тойоты – это бережливое производство, определяющим принципом которого является понятие “точно в срок”. Канбан, как термин в управлении, действительно пошел от Тойоты. В переводе с японского это слово означает “сигнал” или “карточка”. На автомобильных заводах такие карточки использовались, чтобы передать информацию с одного этапа на следующий о том, сколько и каких деталей потребуется.

Давайте разберем короткий пример. Нам нужно сделать три автомобиля “точно в срок”. Это значит, что мы точно заранее можем определить, сколько нам потребуется деталей на определенных этапах, и начинаем с конца вытягивать необходимое количество деталей для создания этого автомобиля, отвечая на вопросы: “Сколько литров краски нам потребуется?”, “Сколько колес?”, “Сколько двигателей?” и так далее. Таким образом, мы не создаем излишки запасных частей в виде остатков и экономим на складах, логистике и прочих издержках.

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

Канбан – это как Скрам?

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

Ценности KANBAN

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

Все ценности Канбана можно свести к одному слову — «уважение».

• Прозрачность: Убеждение в том, что открытый обмен информацией улучшает поток создания бизнесценности. В рамках данного типа ценности также используются простые и понятные термины.
• Баланс: Понимание того, что в целях повышения эффективности необходимо обеспечить баланс между различными аспектами, точками зрения и возможностями. Отсутствие баланса между некоторыми аспектами (например, нагрузкой и возможностями) в течение продолжительного периода времени может привести к нарушению нормальной работы.
• Сотрудничество: Совместная работа. Одна из задач Канбан-метода - совершенствование того, как люди делают работу совместно, поэтому сотрудничество представляет одну из его основных ценностей.
• Клиентоориентированность: Понимание того, в чем заключается предназначение системы. Конечная точка каждой Канбан-системы - создание ценности, то есть получение заказчиком требуемого продукта или сервиса. При этом заказчик остается внешним фактором по отношению к сервису, но может являться как внутренним, так и внешним фактором по отношению к организации. Заказчики и ценность, которую они получают, естественным образом находятся в центре внимания в Канбане.
• Поток: Понимание того факта, что работа представляет собой поток создания ценности (непрерывный или эпизодический). Способность видеть этот поток — ключевая отправная точка в использовании Канбан-метода.
• Лидерство: Способность вдохновлять окружающих на действия своим примером, словами и идеями. В большинстве организаций предусмотрена иерархическая структура, но при применении Канбан метода необходимо обеспечить лидерство на всех уровнях в целях создания ценности и совершенствования подхода к работе.
• Понимание: Главным образом, знание (и индивидуальное и организационное) о себе самом в целях дальнейшего развития. Канбан представляет собой метод совершенствования, и потому понимание того, какая точка является отправной, будет основополагающим.
• Согласие: Обязательство совместного движения в сторону достижения целей с учетом (а если возможно, урегулированием) расхождений во мнениях и различий в подходах. Здесь речь идет не о консенсусном управлении, а о принятии совместного стремления к совершенствованию.
• Уважение: Высокая оценка и понимание окружающих. Располагается в конце списка, поскольку представляет собой основу, на которой базируются остальные ценности.

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

Повестки Канбан / Призывы к действию!

Канбан принимает во внимание три повестки, три типа призыва к действию на основе потребностей организации:

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

Устойчивость направлена внутрь организации -> повышается эффективность. Это отправная точка для изменений :)

Принципы Kanban

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

Принципы управления изменениями:

Начните с того, что есть сейчас

• поймите текущий процесс и практики;
• соблюдайте текущие роли, обязанности и должностные инструкции.

Договоритесь об эволюционном развитии

• Что мы будем добиваться улучшений путём эволюционных изменений.

Поощряйте развитие лидерства на всех уровнях.

Принципы предоставления сервисов

Каждая организация представляет из себя экосистему взаимозависимых сервисов :)

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

Все эти принципы тесно связаны с ориентацией на оказание услуг (повестка) и клиенториентированностью (ценность).

Если рабочий процесс и соответствующий поток создания ценности не прослеживается для заказчика, то в центр внимания организации попадает то, что явно - это люди. Все ли они загружены? Достаточно ли квалифицированы? Могут ли работать усерднее? Обзор CI&CD. Акцент должен быть на приносимой ценности и потребителей сервиса (пользователей).

Поставка ценности, обязательства и доска

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

• Должно быть ограничено количество незавершенной работы (WIP-лимиты).
• Должны быть определены точка принятия обязательств и точка поставки.

Обязательство - это четко сформулированное негласное соглашение между заказчиком и сервисом о следующем:

• Заказчик желает получить рабочий элемент и согласен получить его поставку.
• Сервис готов обеспечить производство и выполнить поставку обязательств заказчику.

Lead Time - время производства, т..е. это время, которое элемент проводит в процессе между точкой принятия обязательств и точкой поставки
Customer Lead Time - время с момента поступления элемента в систему до момента поставки.

Закон Литтла и всё такое от М. Фролова (Cartman): ссылка

Практики KANBAN

Шесть практик:

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

Практика визуализации

Доска - это только из методов визуализации. Принципы визуализации:

• Определена точка принятия обязательств.
• Определена точка поставки.
• Определены этапы или фазы.
• На каждом этапе или фазе определены WIP-лимиты.

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

Ограничение количества незавершенной работы

Введение и соблюдение WIP-лимитов заменяет систему проталкивания (PUSH) на вытягивающую систему (PULL).

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

Введение WIP-лимитов приводит к:

• сокращению времени производства;
• увеличению скорости поставки.

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

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

Поток задач в Канбан-системе должен способствовать увеличению ценности и сведению времени производства к минимуму. Поток задач должен быть предсказуем.
Требуется обеспечить:

• Прозрачность;
• Проверку;
• Совершенствование;
• Регулирование узких мест;
• Контроль блокеров.

Классы обслуживания

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

Рассмотрим влияние стоимости задержки и соответствующий класс обслуживания на примерах:

• Expedite, Ускоренный класс – неотложная скорая помощь-реанимация. Едет по выделенной полосе. Нет времени откладывать решение проблемы. Нужно как можно скорее.
• FixedDate, Класс с фиксированной датой – стоимость задержки резко возрастает после определенного периода. Пример: проект в виде ФЗ с фиксированной датой начала действия. Не успеем вовремя, есть риск потерять лицензию.
• Standard, Стандартный класс – стоимость задержки растет пропорционально времени. Если делаем сразу, получаем прибыль сразу. Если делаем долго, получаем прибыль долго.
• Maintenance, Нематериальный класс – делаем, но явной прибыли эта работа не несет, стоимость задержки растет медленно. Например, уборка в доме. Можно и не убираться регулярно, но через пол года придется делать генеральную уборку.

Делай правила работы явными

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

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

Правила должны быть:

• Минимальны
• Простые
• Наглядные
• Четко сформулированные
• Применимы в любых обстоятельствах
• Гибкими для изменений!

Применение практик вовлекают в:

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

Каденции в Канбане

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

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

• Канбан-митинг (ежедневная). Здесь обсуждаем статус задач, ежедневная каденция для актуализации статусов задач.
• Встреча по наполнению очереди (обычно раз в две недели). Берем на себя обязательства, что будет делать, как сервис. Stage Workflow для User Story.
• Встреча по планированию поставки (обычно раз в две недели). Возвращаем выполненные обязательства обратно, планирование поставки: выпуск релизов.
• Встреча по обзору сервиса (обычно раз в две недели). С метриками обсуждаем качество сервиса и как его улучшить, если нужно.
• Операционная встреча (обычно раз в месяц). С метриками обсуждаем качество взаимодействия связанных сервисов.
• Встреча по обзору рисков (обычно раз в месяц). С метрикам обсуждаем влияние заблокированных задач на работу сервиса.
• Встреча по обзору стратегии (обычно раз в квартал). С метриками обсуждаем изменения в стратегии.

Метрики в KANBAN и улучшения

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

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

❤️Meow!❤️ Всё есть сервис!