* Данная статья будет полезна начинающим project-менеджерам, а также Заказчикам, которые хотят получить от своего сотрудничества с веб-студией положительный результат.

Почему Scrum?
Рабочий процесс и как продавать свою работу
клиенту
Итоги

Почему Scrum?

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

В ходе работы обязательно возникает если не технический, то человеческий фактор, после чего проект не заканчивается в изначально запланированные сроки и продолжает тянуться и после всех сожженных дедлайнов и последующих передоговоров (это не опечатка — да, это слово «передоговоров»).

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

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

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

Раньше мы как работали?
Есть клиент со своей «хотелкой», с ним вместе составляется ТЗ, оговариваются детали, составляется смета работ, примерные сроки, дата старта, предоплата и.. в путь. Проект отдается в производство.
До первой демонстрации прототипа клиенту, вот тут начинаются танцы. Или пляски. Шаманские пляски с песнопениями. Не, ну как. Конечно в договоре мы оговариваем и количество правок. И то, что будет сделано. Согласно первоначальному прототипу и т.д.

Только клиенты вдруг решают добавить «ещё вот это сюда, после мы примем проект» – а это работа специалиста ещё на двадцать часов и т.д., с отклонением от первоначального плана проекта. Изначально «вот тут вот так» не хотели и вдруг стало надо. Короче, нетвердая тема, все это дело. Нам надоело. Клиентам надоело.

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

И он нашёлся. В детстве я читал книгу Ли Яккока — Карьера менеджера. Там было много всего и что-то вскользь про Тойоту. Про их производственный процесс. Гугл мне подсказал, что это канбан-методика. Далее, Гугл подсказал, как по ней работать в IT-сфере. Что методологии называются Scrum и Kanban, имеют много общего и в целом из одной среды. Вселенная услышала мой зов и в тот же день ко мне обратился клиент, который хотел строить свой продукт по Scrum-методике. Все, как по книжке, которую я за день до этого приобрел. И началось. Составление бэклога, подбор команды под проект, утренние собрания, спринты и выгрузка продукта, канбан-доска..

В общем, мы делали все по скраму с применением канбана и у нас.. получилось. Сделать продукт в срок и небольшой командой. Продукт, который клиент принял сразу и без просьб о доработке.
Не в меньшей мере благодаря лояльности, вовлечённости заказчика в работу, в том числе. Т.к. методологии (что Scrum, что Kanban) подразумевают вовлечённость заказчика, без этого проект не начать.
Закончив проект, я взял паузу, чтобы осознать и обдумать происходящее.

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

Если говорить о технической стороне, то мы взяли все полезное (в контексте реальной, практической пользы) из Scrum и взяли за методическую основу построения работы Kanban. Из скрама мы взяли составление бэклога (Бэклог – хотелки Заказчика, список из того, что должен содержать в себе проект, функционал и всё, что по мнению Заказчика, должен уметь разрабатываемый нами продукт), разделение работы на спринты (но после сами спринты стали формальностью, т.к. иногда карточка с задачей возвращалась из «Готово» в «Процесс» и некоторая часть задач тянулась, как один непрерывный спринт – вообще, тут многое зависит от специфики проекта и задачи), утренние митинги, выгрузку рабочих частей сразу, для демонстрации Заказчику. Канбан-доска позволила нам структурировано подойти ко всей работе, а реализация её в Trello – иметь всю историю работы над проектом благодаря разделу «Комментарии» в карточке задачи.

Подробнее обо всём в разделе «Рабочий процесс и как продавать свою работу клиенту».

Рабочий процесс и как продавать свою работу
клиенту

Все начинается с брифа. Вернее, все начинается с ТЗ. С ТЗ, поступившего от клиента. Часто, именно с выявлением того, что ТЗ составлено неконкретно, мы отправляем Заказчика заполнить бриф. Вдумчиво и не торопясь.

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

Далее, после согласования всех административных моментов, мы раскидываем проект на итерации и раскладываем его карточками задач на Kanban-доске в списке «Бэклог проекта». Берем в активный спринт (спринт – это отрезок времени, обычно состоящий из 3-7 дней) пару-тройку задач в работу, перемещая из столбца «Бэклог» на доске, в столбец «В процессе» и после выполнения задачи, в столбец «Готово».

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

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

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

А раньше было так – мы делали полностью проект, основываясь на ТЗ, показывали итог, клиент такой – о, здорово. А потом «а давайте вот тут переделаем или я не забираю». И возня, возня, возня. Хорошо, что мы от этого ушли и пришли к текущему построению работы.

Итоги

Адаптировав под свою работу методологии Scrum/Kanban, мы получили следующее:
1) ускорили себя в 4 раза в производстве.
2) построили эффективную систему аккаунт-менеджмента и сократили сроки сдачи проекта практически на 90%, т.к. работу теперь забирают, как только выгружена финальная итерация – сразу подписываем акт сдачи-приёмки и получаем вторую часть оплаты за сделанную работу.


Материал подготовил Артур Бурханов,
основатель и руководитель агентства Бурханов Digital