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

С приходом в Evercode Lab первого наемного менеджера в моей рабочей жизни очень много всего изменилось. Еще бы, ведь огромное множество вещей по ведению проектов стало реально делегировать. Но сегодня не об этом. Одним из новшеств, которые Никита внедрил в нашей компании — проведение регулярных ретроспектив. Собираемся всей компанией и обсуждаем по пунктам: что хорошо, что плохо, что можно с этим делать и что удалось сделать с прошлой ретроспективы, все это, конечно, приправлено множественными «почему».

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

Начнем с понятий. «Воркфлоу» я понимаю как совокупность всех процессов как технических, так и коммуникативных, относящихся к той или иной деятельности. Это может быть крупномасштабный процесс работы фирмы, может быть работа с документами или кодом.

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

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

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

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

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

Какие же проблемы мы вскрыли в последнее время:

  • часто задачи в basecamp в итоге просто полностью дублируют задачи в github.issues. С одной стороны это последствие было очевидно, с другой — к сожалению, не сразу. Процесс можно автоматизировать, но при любом раскладе он требует мониторинга и человеческого контроля. Т.е. в целом получаем лишнюю работу.
  • клиент часто не видит часть задач, комментариев и обсуждений. Проще на примерах. Менеджер находит логическую нестыковку в функционале проекта, ставит задачу на github, разработчик делает. Все прошло мимо заказчика. Хорошо, если за период были сделаны задачи по договоренности в basecamp. Но если нет, то информация о том, на что было потрачено время дойдет до клиента только на регулярном созвоне/встрече.
  • разработчик не видит общей картины по своим задачам. Да github позволяет смотреть свои задачи по всем проектам, но из-за лагов в синхронизации что-то может быть упущено. Кстати, тут еще вступают в игру исключения: единичные проекты у нас ведутся, например, только на github (клиент достаточно компетентен) или вообще в asana заказчика (так как наша работа — лишь часть общего проекта).
  • плохо понятны приоритеты по задачам. Понятно, что приоритеты такая вещь, которая на постоянство не претендует, поэтому тут без части управления не обойтись. Но иметь возможность сквозной приоритизации задач между проектами хочется.
  • менеджер или управляющий всей фирмы иногда не видят всей картины по загрузке в целом, что затрудняет планирование. Да, мы используем дополнительные инструменты, отслеживаем, закладываем, предугадываем и рискуем, но опять же — могло бы быть лучше.

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

Я делал к проблеме уже не один подход, фантазируя, прикидывая разные схемы, изучая инструменты, их интеграции друг с другом. Вчера был еще один такой подход. Затяжные выходные — отличная возможность уединитьcя в новом офисе для стратегического планирования и просто неспешного обдумывания всего и вся. Если честно, то голова после дня за таким занятием пухнет еще больше, чем после дня активной работы по клиентским проектам.

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

Итак, попробую сформулировать свое видение того, как «оно должно быть» или, может, «как хочется, чтобы оно было» пока без оглядки на то, насколько это в принципе возможно.

Сначала общие принципы:

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

Теперь ближе к практике:

  • система ведения по крайней мере в рамках одного проекта должна быть одна, без разделения на «загончики» для клиента и разработчиков
  • маловероятно, что всем клиентам одинаково удобна будет одна система, что позволило бы использовать ее и для крупного планирования, но к этому можно стремиться
  • сам процесс вне зависимости от используемого инструмента для ведения задач более менее одинаков и как правило может быть понятно настроен
  • работа должна разбиваться на итерации. Идеально, если это будет одна неделя, максимум — две.
  • в рамках итерации есть обязательные точки коммуникации (созвон/встреча), в которых задействована все участники проекта:
    • планирование задач на неделю — команда формирует список задач на неделю
    • обзор результатов работы за неделю — исполнители отчитываются о результатах, команда обсуждает, отмечаются успехи, неудачи
    • ежедневные статусы — очень короткие встречи/созвоны/чаты, нацеленные на формирование плана на день и разрешения блокирующих вопросов
  • неделя как период для детального планирования является максимальным интервалом
  • при этом, конечно, планирование (roadmap) проекта на более долгосрочный период должно присутствовать
  • в течение итерации коммуникации не прекращаются, но концентрируются вокруг выбранных на неделю задач (комментарии, сообщения о готовности, обратная связь)
  • все задачи проекта изначально попадают в общий inbox/backlog (он может быть разбит на какие-то подсистемы, блоки, подпроекты)
  • крайне нежелательно в ходе итерации менять ее состав. Но эти случаи предусмотрены на данный момент в двух ситуациях:
    • критичный баг — должен быть поправлен как можно быстрее
    • критичный функционал, укладывающийся по времени в рамки итерации — таковой должен являться критичным именно с точки зрения бизнес-ценности в проекте. Решения об изменении состава итерации обязательно подкреплять обоснованием ценности, которое не должно состоять только из «потому что я так хочу»
  • задача в рамках итерации проходит несколько состояний (конкретный состав может отличаться от проекта к проекту, но принцип одинаков):
    • запланирована на неделю
    • в работе (in progress)
    • code review
    • тестирование на staging’е (демонстрация на тестовом сервере)
    • обратная связь (задействован менеджер со стороны исполнителя и представитель заказчика)
    • готова к релизу (либо заливается сразу в production, либо ожидает остальных запланированных на неделю)
    • залита в production (попала в релиз)
  • в зависимости от обратной связи статус задачи может перейти обратно на стадию «в работе»
  • со стороны заказчика обязательно должен быть один (это важно) человек с правом окончательного решения, который по результатам решает, пойдет задача в релиз или отправится на доработку (или даже на следующую итерацию)
  • задачи должны быть сформированы таким образом, чтобы всем было понятно условия ее готовности (definition of done, SMART)
  • задача считается окончательно выполненной только когда попадает в production
  • разработчик задействован на всех этапах жизни задачи
  • менеджер не должен выступать тестировщиком результатов разработчика
  • менеджер отвечает за соблюдение договоренностей, настройку коммуникаций, решение проблем, формулировку задач

Последствия:

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

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

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

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