Блог студии itworks

Пишем про сайты, веб-дизайн, маркетинг в интернете

Как мы внедряли ФФФ и как из этого ничего не получилось

23 августа 2017

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


Я не критикую подход ФФФ, а пытаюсь лучше понять его суть и конкретные приёмы. Поймать то, что не плавает на поверхности. А заодно выяснить, почему именно у нас не получилось и как лучше (и стоит ли?) к этому прийти. Здесь будет подробный и честный разбор наших ошибок. Без увиливаний и отмазок. Мы не идеальны и часто ошибаемся. Но хотим это исправить.



Что это за зверь?


ФФФ — это метод управления проектами, практикуемый в Бюро Горбунова. Если кратко, метод заключается в том, что на этапе предпроектной подготовки с клиентом оговариваются сроки, бюджет и список функций. Сроки и бюджет фиксируются, то есть Бюро гарантирует, что в заданный «день Икс» проект будет запущен без потери качества. Запомните эти слова, они нам ещё пригодятся.


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


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


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


Я не очень силён в автомобилестроении, но надеюсь, что суть подхода объяснить смог. И кажется, что всё здесь вполне понятно и логично, но остаётся один вопрос — а что об этом думает покупатель нашей машины, который заплатил за «полный фарш»? Разберём детально.



Всё обязательно пойдёт не по плану


В первом же предложении в рассказе об ФФФ Бюро говорит: «Самая большая ошибка — предполагать, что проект пойдёт, как задумано». И мы раз за разом продолжаем составлять фиксированные планы и технические задания с огромным списком функционала. Почему мы это делаем?


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


Твоё лицо, когда всё идёт по плану



Мы, как и Бюро, разбиваем проект на отдельные этапы. Результат каждого этапа — это работающий и выполняющий своё полезное действие продукт. Но часто бывает так, что даже минимально достаточного функционала к заданной дате достичь не удаётся.


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


В этой истории главное — доверие. Мы гарантируем, что работаем честно и тратим максимум возможного времени на решение задачи проекта. Если не получилось, значит не получилось. Дизайн и разработка сайта — это не вышивание крестиком. Очень много процессов могут пойти не по плану. На практике может случиться что угодно. Самые сложные моменты, которые не укладываются в модель ФФФ, в моей практике — технический и человеческий факторы.


       1. Команда столкнулась с форс-мажорной ситуацией (сгорел компьютер, упали сервера, обнаружилась техническая несовместимость компонентов)


       2. Клиент затянул согласование


       3. Команда неправильно оценила свои силы и рассчитала сроки


       4. Клиент не предоставил вовремя необходимые материалы


       5. Мы забыли учесть часть функций в ТЗ, а в процессе работы вспомнили что это необходимо



Проблема №1. Всё сломалось


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


Никто не застрахован



Проект-менеджер звонит клиенту и объясняет ситуацию. Клиент недоволен. Дизайнер делает себе кофеиновую клизму и трое суток без сна и отдыха восстанавливает проект. В результате к дедлайну он успевает закончить 70% работы, но описанного в ТЗ результата получить не удаётся. Клиент недоволен. Ему плевать, что у вас там сломалось, он платит вам за результат. Студия забирает несколько дней, заложенных на согласование, чтобы доделать этап. Клиент присылает кучу правок. Этап затягивается, дедлайн по взаимной договорённости сдвигается.


Как нужно по ФФФ?


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


Как поступили мы?


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


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



Проблема №2. Не удалось согласовать флекс


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


Процесс согласования флекса. В роли рядового Кучи — наш проект-менеджер



Например, мы утвердили дизайн и передали макет в вёрстку. Верстальщик увидел макет и нашёл технические ошибки. Дизайнер сел их исправлять. Это заняло два дня. Дедлайн не сдвигается, но у верстальщика на два дня меньше. Менеджер проекта звонит клиенту и говорит, что в первой версии продукта не будет нижнего блока с формой обратной связи. Клиент недоволен. Кто виноват?


Как должно быть по ФФФ?


Клиент соглашается, что в первой версии не будет блока с обратной связью. Он не так уж и нужен, судя по карте скроллинга до него досматривают только 10% посетителей сайта.


Как происходит на самом деле?


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


Так случается не всегда. Часто удаётся договориться с клиентом и мы запускаем проект вовремя, но с урезанным функционалом. Проблема в другом — нам приходилось доделывать урезанный функционал после запуска бесплатно. Сейчас мы осознали эту ошибку и постепенно отходим от такой практики, становясь жёстче. Мы заранее обговариваем, что от каких-то элементов дизайна придётся отказаться, чтобы запустить вёрстку в срок. Это больно и для нас и для клиента. Но этот путь оберегает нас обоих от лишних затрат времени и денег.



Проблема № 3. Мы сработали плохо


Реакция проект-менеджера на нелепые отговорки



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


Как нужно?


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


Выстроить систему мотивации с коллективным KPI? Учитывая многократные пробы и ошибки, сейчас приходим к этому. Не всем это нравится, но в большинстве своём такая система приживается неплохо. Посмотрим что будет дальше.


Вот только и то и другое нужно было сделать до старта проекта, а не в середине.


Как было на самом деле?


Бесконечные уговоры, призывы к совести и «завтраки». К сожалению, одного профессионализма мало. Очень часто классный профессионал не может учесть кучу нюансов на предпроектной части. В ТЗ всего не опишешь. Верстальщику нужно видеть макет чтобы оценить свои сроки. Программисту нужно видеть макеты чтобы адаптировать базу данных, подготовить фильтры и поиск. А иногда исполнитель просто оказывается конченым мудаком. Такое тоже бывало.


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



Выводы


       1. Внедрять ФФФ тяжело. Это требует предельной честности и отдачи от команды. Это требует достаточно жёсткой авторитарной модели управления, продуманной организации процесса и системы мотивации. Если вы не уверены в своих силах — лучше не пробуйте, потеряете немного.


       2. ФФФ — не панацея. Есть множество других моделей работы над проектами, и многие из них вполне жизнеспособны. Некоторые, например, позволяют параллельно вести несколько проектов и всё успевать. Если чувствуете что не получается — попробуйте другую модель. Нервные клетки не восстанавливаются.


       3. Главная ошибка — это завышенные ожидания. Клиент пробегает договор глазами, не вникая в принципы совместной работы. Он видит дату и ожидает результат, который мы покажем к этой дате. Задача проект-менеджера — добиться от клиента понимания и принятия принципов ФФФ.


       4. Мы вряд ли когда-нибудь придём к ФФФ в том виде, как оно работает в Бюро. Но мы успешно используем некоторые приёмы этой модели управления. Например, дизайнерское управление разработкой.


       5. Качество остаётся на первом месте. Иногда мы готовы жертвовать сроками (и своими бюджетами) для достижения качественного результата. Главным постулатом было и остаётся «Не сдавать говна».






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

Поделиться
Запинить

Ваш комментарий

Ваше имя
Текст