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

Previously on Evercode Lab Advent

К нам обратился клиент. Он понимает свой бизнес…

Допустим, все просто шикарно. Наши оценки приемлемы для клиента, наш подход его устраивает.

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

Мысли в слух

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

В описании нашей вакансии менеджера проектов одним из пунктов в глобальных целях является следующий: «Стыковка ожиданий клиентов с результатами работы фирмы». За этой туманной фразой на самом деле скрыто довольно много всего.

Я уже писал, что все, что мы делаем, это про людей. А люди от своих желаний и ожиданий не отделимы. Поэтому важно их согласовывать. Ожидания клиента с тем, как мы работаем и какой предоставляем результат. Ожидания менеджера с подходами и результатами разработчиков. Ожидания разработчиков с реальным поведением клиента или менеджера, предоставляемыми материалами, реакциями на вопросы. Через эту призму смотреть на процессы очень полезно. Если каждый знает, чего хочет сам и чего ожидают от него, шансы успешно реализовать проект возрастают многократно.

Роли

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

  • программист
  • менеджер проектов
  • клиент
  • управляющий фирмой

У каждой роли свои задачи и цели.

Разработчик:

  • видеть все свои задачи с учетом приоритетов
  • знать, какую задачу делать следующей
  • понимать, как сообщить о готовности задачи
  • иметь возможность уточнить задачу у менеджера или клиента

Менеджер проектов:

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

Клиент:

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

Управляющий фирмой:

  • видеть общую картину работы по проектам
  • понимать текущую и планируемую нагрузку на фирму
  • понимать, можно ли брать проект X в интервал времени Y

Принципы

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

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

Процесс

Итак, как же мы строим процесс.

Во-первых, инструменты:

  • basecamp – основное место для общения по предмету функционала и его деталей, может также служить для фиксирования общего и недельных планов работ в упрощенном виде
  • youtrack – хранилище готовых к выполнению задач (backlog), а также инструмент фиксации итераций (Agile Boards)
  • github – хранилище кода проекта и его истории, инструмент для совместной работы программистов
  • комната в hipchat, комната в skype — для решения оперативных вопросов

С самого старта проекта мы поднимаем для него тестовую версию, доступную команде и клиенту по логину-паролю. Тестовая версия может быть на поддомене project.evercodelab.com или на поддомене клиента.

  • работа должна разбивается на итерации, обычно это 1-2 недели
  • в рамках итерации есть обязательные точки коммуникации — созвон или встреча, в которых задействована все участники проекта. Цели этих точек:

    • планирование задач на неделю
    • обзор результатов работы за неделю — исполнители отчитываются о результатах, команда обсуждает, отмечаются успехи, неудачи
  • у встреч/созвонов желательно наличие повестки и набросков плана заранее, а также follow-up письмо (топик в basecamp) для фиксации договоренностей
  • в течение итерации коммуникации не прекращаются, а концентрируются вокруг выбранных на неделю задач (комментарии, сообщения о готовности, обратная связь)
  • задачи должны быть сформированы таким образом, чтобы всем было понятно условия ее готовности (definition of done, SMART)
  • крайне нежелательно в ходе итерации менять ее состав. Но это возможно, если:

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

    • запланирована на неделю
    • в работе (in progress)
    • code review
    • тестирование на staging’е (демонстрация на тестовом сервере)
    • обратная связь (задействован менеджер со стороны исполнителя и представитель заказчика)
    • готова к релизу (либо заливается сразу в production, либо ожидает остальных запланированных на неделю)
    • залита в production (попала в релиз)
    • в зависимости от обратной связи статус задачи может перейти обратно на стадию «в работе»
  • задача считается окончательно выполненной только когда попадает в production
  • менеджер не должен выступать тестировщиком результатов разработчика
  • менеджер отвечает за соблюдение договоренностей, настройку коммуникаций, решение проблем, формулировку задач

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

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

Завтра же расскажу, как во время работы над проектами мы обращаемся с кодом.

Эта статья является частью Evercode Lab Advent 2014 — цикла из 24 статей о том, как появилась, устроена и работает компания Evercode Lab. Полный список статей можно посмотреть в анонсе Evercode Lab Advent.