Pull to refresh
0

Agile в заказной веб-разработке

Reading time 7 min
Views 19K
Если мы (веб-студия или частный разработчик) делаем веб-проект для себя, мы сами вольны выбирать метод разработки: гибкий (Agile) или каскадный («водопад»). Как правило, чем сложнее проект, тем меньше шансов у водопада. Но когда мы делаем сайт для заказчика, метод всегда один: каскадный. Эта статья о том, как (и зачем) убедить заказчика попробовать гибкую модель для сложных веб-проектов.

Agile и водопад глазами заказчика


Чтобы доказать что-то заказчику, нужно думать, как думает он. Не вдаваясь в детали гибкой методологии (несколько полезных ссылок я приведу в конце статьи), попробуем составить сравнительную таблицу.
Модель Каскадная Гибкая
Процесс разработки Непрерывный, с заранее определенными этапами Итерационный, количество итераций неизвестно
Проектирование Один раз, в начале проекта, подробное Многократное, детализация по мере необходимости
Вовлечение клиента 3-4 раза Постоянное
Сроки и бюджет Заранее определены и прописаны в договоре Неизвестны до самого конца проекта
Клиент платит за... Результат Процесс
Процесс разработки в каскадной модели разбивается на ограниченное количество этапов. Обычно они такие: предпроектное исследование (по итогам — смета на составление технического задания), проектирование (по итогам получается ТЗ и смета на проект), отрисовка дизайна, разработка (она может тоже делиться на этапы), наполнение, тестирование, сдача. В гибкой модели после каждой итерации мы имеем некий условно-законченный проект («предварительная структура сайта и черновой дизайн», «голый сайт с черновым дизайном», «то же с интерфейсом к базе заказчика»), который можно использовать как базу для продолжения работы, дальнейшей детализации или переосмысления предыдущих этапов.

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

В каскадной модели вовлечение клиента в проект как правило происходит 3-4 раза: при выборе подрядчика, в процессе проектирования, при утверждении ТЗ и дизайна, в конце проекта. В гибкой модели заказчик должен быть готов к тому, что его будут дергать для согласований и обсуждений раз в одну-две недели, отрывая тем самым от других не менее важных дел. Для «ленивых» заказчиков (они же «занятые») это может стать серьезной преградой.

Что касается сроков и стоимости проекта, то при работе по гибкой методике ни исполнитель, ни заказчик не знают, когда проект закончится и сколько денег он будет стоить. Впрочем, и при каскадной модели частенько получается так же :)

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

Сайт как изобретение


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

Вся разница в том, что мы создаем новый продукт, то, чего раньше не делали. Конечно, наверняка существуют проекты, сильно похожие на наш, но если проект делали не мы, то мы никак не можем судить об их трудоемкости. Да и свои-то наработки очень редко получается использовать повторно, по себе знаю (я больше 10 лет руководил веб-студией, специализирующейся как раз на сложных веб-проектах). Таким образом, предварительную оценку большого проекта мы можем взять либо с потолка, либо на основе предыдущего опыта «проектов-наиболее-похожих-на-этот», то есть тоже с потолка; и еще сверху накинем «за риск». Если нам повезет, мы сделаем проект быстрее и сэкономим (заказчик в минусе). Если не повезет — мы задержим проект, будем вынуждены экономить на тестировании, кросс-браузерности, документировании. Получается, заказчик опять в минусе.

Поэтому, если мы подходим к проекту как к инновации, изобретению, нам будет гораздо проще обосновать необходимость оплаты за процесс.

Ваши проблемы — это проблемы заказчика


При оплате «за результат» мы сталкиваемся с тем, что покупаем одно (время наших сотрудников), а продаем другое (макет дизайна, программный модуль). Выше я показал, что проблемы с неправильной конвертацией одного в другое мы в любом случае будем решать за счет заказчика, ведь других источников дохода, кроме клиентов, у нас нет. Каскадная модель может создать и другие проблемы разработчику. Например, проект будет задержан по вине заказчика, и мы не сможем вовремя получить оплату. А т.к. проект большой, отсутствие этой запланированной оплаты может создать брешь в бюджете. Мы не сможем вовремя заплатить зарплату или аренду, что вряд ли хорошо скажется на мотивации сотрудников. И это всё равно ударит по клиенту.

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

— Что это такое? Мне надо совершенно не это!
— Так мы все по ТЗ делали, вы его подписывали.
— Вы издеваетесь? Там 100 страниц вашим птичьим языком, я его не осилил, понадеялся на ваш профессионализм.
— Окей, переделаем, платите деньги.
— Вот еще, я столько денег заплатил, переделывайте бесплатно.
— Не будем.
— А мы не заплатим, пока не переделаете.

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

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

Ленивый заказчик — враг Agile


Под словом «ленивый» я подразумеваю не только и не столько природную леность. Идеальный заказчик — это тот, который:
  • имеет достаточно времени и желания, чтобы плотно работать с вами в течение проекта
  • обладает (или стремится обладать) навыками в Интернете хотя бы на уровне advanced user-а
  • не боится экспериментов и своей ответственности за участие в них
  • действительно заинтересован в том, чтобы сделать очень хороший проект
Если заказчик не отвечает этим требованиям, он «ленивый», с ним у вас вряд ли получится работать по гибкой методологии. Положа руку на сердце, ответьте на вопрос: сколько «неленивых» заказчиков вам попадалось в последнее время? По себе знаю, что это большая удача. Если очередной заказчик именно такой, то нужно предлагать Agile. А если вы заранее знаете, что заказчика «не хватит» на то, чтобы довести agile-проект до конца, то лучше, наверное, не рисковать.

Помимо всего прочего ленивые заказчики очень пугливы. На собственном опыте я убедился в том, что:
  • жестко планировать сроки выхода большого проекта нельзя, т.к. программисты срывают сроки всегда
  • в процессе работы очень часто в голову приходят новые интересные идеи, противоречащие изначальному ТЗ
  • за несколько месяцев, что длится разработка проекта, видение задач клиента может поменяться, а до разработчика эта информация может не дойти
  • самый продуманный интерфейс на реальных данных далеко не всегда так же красив и удобен, как на прототипах
  • дизайнеры очень редко «попадают в задачу» так, как ее видит клиент (и это не всегда вина дизайнера), и вынуждены переделывать макеты
  • большие спецификации не читают полностью не только клиенты, но и разработчики
Согласны с этим? А представьте, что вы всё это говорите заказчику, и посмотрите на этот список с его позиции. Вывод, который вы сделаете: в этой компании работают очень непрофессиональные люди. Заказчик просто испугается работать с вашей компанией и уйдет к той, где «такого нет», хотя там всё то же самое, только Agile не предлагают.

Наш опыт


С тех пор, как NetCat отделился от веб-интегратора АИСТ (юридически год назад, фактически больше двух), мы из поставщика услуг заказной веб-разработки превратились в их получателя (заказная веб-разработка очень сильно отличается от разработки тиражного ПО). Мы — небольшая компания, и мы стараемся аутсорсить всю ту работу, которая является для нас не очень профильной: верстка, дизайн, аудит, работы по сайту; а иногда даже и профильную работу тоже. Везде, где это имеет смысл, мы стараемся применять гибкие методы.

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

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

Тонкие места гибкого подхода


Чтобы статья не получилась однобокой, стоит перечислить и отрицательные стороны Agile с точки зрения заказчика. Во-первых, есть целый класс заказчиков, которые просто не могут не работать по каскадной модели: государственные организации, крупные фирмы, которые обязаны планировать и заранее утверждать сметы. А ведь именно они в первую очередь заказывают крупные проекты.

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

Но самое важное в работе по Agile – взаимное доверие, как на межличностном, так и на профессиональном уровне. Для того, чтобы получился хороший «гибкий» проект, вы должны не только сами поверить заказчику, но и добиться того, чтобы он доверял вам: вашей честности, профессионализму ваших сотрудников, вашей мотивации. В этом случае заказчик сможет получить тот проект, который ему нужен (не путать с тем, который он хочет), а вы сделаете интересный проект (большие проекты всегда интересны), помимо заслуженных денег получив еще и удовольствие от процесса.

Ссылки по теме

Tags:
Hubs:
+31
Comments 23
Comments Comments 23

Articles

Information

Website
www.netcat.ru
Registered
Founded
Employees
11–30 employees
Location
Россия