Более 90% экспертов-web-разработчиков не готовы вносить серьезные изменения в проект по ходу работы. И cчитают подобных клиентов — «[censored], которые сами не знают чего хотят». Не, не так. С самого начала!
В пятницу я слетал в Москву на денек, на партнерскую конференцию 1С-Битрикс. Отмечу прекрасную организацию мероприятия. Ребятам удалось создать дружескую, непринужденную атмосферу. В рамках конференции прошло несколько круглых столов, на которых обсуждались острейшие проблемы студий: риски, организация производства, рост, диверсификация бизнеса. На одном из круглых столов был поднят вопрос — приемлемы ли существенные изменения в проекте уже по ходу его работ. Итак!
Cубъективное
Озвученная общая экспертная позиция: «мелкие (незначительные) хотелки — сделаем по ходу работ, а любые существенные — заворачиваем» («нужен новый лосось»). Меня несколько пугает сказочное единодушие экспертов по этому вопросу. Лезть на трибуну и стучать тапком — не входило в мои планы. Поэтому очень кратенько расскажу про то, чего лишаетесь вы (и чего лишаете клиента), не применяя гибкие методологии (наш любимый scrum). Особенно при разработке тяжеловесных проектов.
Для клиентов
Гибкий контроль бюджета и сроковСостав функций можно менять по ходу работы.
Быстрый стартМожно реализовать только самые важные функции (например, организовать продажи), запустить проект в свет и сразу начать на нем зарабатывать, а все менее важные функции реализовать в будущем.
Не нужно тратить много времени на техническое заданиеДостаточно четко представлять задачи 1-2 ближайших этапов. Не нужно тратить полгода на сбор всех требований в один талмуд, который все равно будет неактуальным через 2-3этапа после начала работ.
Получить «то, что нужно», а не «то, что просили»Это самое главное. Никакое детальное техническое задание и прототипы не заменять возможность улучшать и подстраивать уже готовый продукт под меняющийся мир.
Для студий
Ежедневный «пульс» проектов. Раннее выявление проблемПожалуй, в scrum сейчас самая ненапряжная, но очень эффективная методика контроля (всего три вопроса: «Что было сделано вчера?», «Какие планы на сегодня?», «Какие есть проблемы?»).
Самообучающиеся командыScrum предполагает проведение ретроспектив и постоянное улучшение процессов работы.
Снижение рисковИтеративный подход снижает риск не попасть в ожидания клиента, а применение методик, типа Planning Poker минимизирует риск неправильных оценок.
Стандартизация потока работСуществует множество способов сделать что-то через жопу. Обратная сторона — правильные процессы дают правильные результаты.
Другая производительностьПара человек, работающих в команде, с высокой вероятностью будут работать продуктивнее, чем если бы они трудились каждый над своим проектом.
Я понимаю, что это все — нафик не надо на проектах за 70.000р, (а-ля «натянуть шаблон на Битрикс»). И не считаю scrum панацеей, которая спасет мир (cм. «Культ Карго в IT»). Но я почему-то уверен, что web-разработчики должны были слышать что-то о гибких методологиях и уже хоть что-то начать применять у себя. Хотя бы потому, что это работает, гарантирую. А если не работает — значит, что-то не так делаете.
зызызы
Битрикс, спасибо вам, вы клёвые. Ждем няшную версию API, с блекджеком и плюшками!
Как вы боретесь с тем, что 1С-Битрикс продвигается как готовый продукт с четкой ценой и даже в этом смысле противопоставляется сайтам на самописных движках, которые по сути - услуга. А разработка по scrum - это не то что услуга, это вообще ПРОЦЕСС. Клиентам страшно.
А зачем с этим бороться? Битрикс прекрасно продается, как удачная админка к, порой, причудливым инкарнациям, например. Совсем технически тяжелые вещи, где админка нафик не нужна — порой запиливаются на ZendFramework или Node.JS. Зависит от задач.
Клиентов лучше не пугать терминологией, это да. Скрам, Бэклог, Стэндап...— применять только для тех, кто реально интересуется технологическим процессом (а есть такие, т.к. иногда проект на стороне клиента курируют технари). По человечески и на понятном языке рассказать, как пойдет работа. Обосновать, почему так будет в итоге дешевле. Не прятать прогнозируемую "финальную" цену, но предупредить, что она может поменяться, если будут изменения в проекте. Это принимают все адекватные.
А потом запилить нормальный scrum, прикалывая каждую итерацию — как допсоглашение к основному договору .
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».