Профессиональная конференция по управлению интернет-проектами

19 и 20 сентября 2011

О вреде проектного управления

Доклад принят в Программу конференции
Олег Сапрыкин («Флант» — лидеры DevOps в России. Российский вендор ПО и сервисная компания по построению DevOps-решений под ключ, лидер российского рынка. На рынке с 2008 года — более 15 лет опыта в Open Source, Linux, DevOps. Работаем с Kubernetes с момента его появления. №1 контрибьютор Kubernetes из России и Единственный в России сертифицированный CNCF поставщик услуг по Kubernetes (KCSP). Делаем DevOps as Service — запускаем и поддерживаем инфраструктуру бизнеса, создаем комфортную и эффективную среду разработки, выстраиваем CI/CD-процессы с нуля, проводим аудит. 15 лет опыта. Пилим Open Source — авторы grafana-statusmap, ovpn-admin, shell-operator, addon-operator. Мы — №1 контрибьютор в Kubernetes из России и один из основных разработчиков Dex. В 2023 году наша утилита werf официально стала проектом CNCF.)
Олег Сапрыкин

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

  1. Ловушка избыточного управления. В большинстве организаций, занимающихся поточным производством сайтов, существует класс (или даже классы) проектов, в которых проектное управление должно быть минимизировано, а то и вовсе сведено к нулю. Для них больше подходят принципы серийного производства, нежели проектный подход. Я планирую на примерах показать, что в такого рода проектах введение человеческого управленческого ресурса ведет к снижению эффективности, а иногда и вовсе "убивает" проекты. Зачастую целесообразно идти по пути тотальной автоматизации производственного процесса, максимально сводя уникальные проектные задачи к типовым, а ручное управление искоренять.
  2. Ловушка предпочитаемой методологии. Если проекту все же требуется проектный подход к управлению, зачастую для его ведения выбирается "модная" на данный момент, либо привычная методология, без учета специфики проекта. В то же время, каждому проекту в зависимости от состава команды, бюджета, требований и специфики заказчика требуется уникальная методология. Я расскажу о том, как уйти от мышления в терминах методологий к мышлению в терминах методов и артефактов, необходимых и достаточных для конкретного проекта. В этой части будут затронуты проблемы "формальных методов" и "артефактов в себе", рассмотрены способы избежать управленческой деятельности, не продвигающей проект к успешному завершению.
  3. Ловушка безусловной веры в метод. Выбирая методы и артефакты, мы имеем право на ошибку, важно лишь вовремя ее заметить и прекратить использование неуместных практик. Кроме того, для нужд конкретного проекта метод может (и, зачастую, должен) модифицироваться. Следование букве описанного в литературе метода может приводить к ситуации "Мы все делали по книге, что мы делали не так?". Избавиться от страха изменять метод на лету, не боясь отходить от канона - важнейшее умение в динамичных проектах.

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

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

Целевая аудитория

Менеджеры web проектов, начинающие и не только; технические руководители компаний.

Комментарии