Наша компания занимается разработкой web-приложений на заказ. Не сайтов-визиток, а именно приложений. Чаще всего — для внутрикорпоративного использования.

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

Сначала придется рассказать о пути, которым мы к этому пришли.

Классический аутсорсинг — продажа часов или фиксед прайс

Продажа часов: клиент подсаживается на “бесконечный” контракт, постепенно увеличивается команда, а возможно и рейты. Часто работу распределяет кто-то со стороны заказчика, в команде разработки нет своих аналитиков, Минусы: рейты поднять удается редко, иногда оказывается, что проект не взлетает и все деморализованы, людям надоедает и приходится часто ротировать команду. Выгодно при наличии средненьких программистов, без звезд, но по-настоящему интересные и сложные проекты с такой командой не сделать.

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

Фиксед прайс: сделать проект по ТЗ за оговоренный срок командой, в которой есть разные роли. Древняя классика — все проанализировать, оценить, запрограммировать, протестировать, внедрить и… вылететь из бюджета.
Методы борьбы:

1. разбиение на короткие итерации,
2. оценка рисков, вероятностные методы, умножения оценок на “пи” и т.д.,
3. комбинация обоих вариантов — короткие итерации, каждая из которых использует оценки скорости разработки и использует управление рисками при помощи вероятностных методов, т.е., например, SCRUM.

Долой культ карго — почему SCRUM в чистом виде не сработал в нашей команде

Пробовали на нескольких проектах, даже писали в критериях для отбора проектов — готовность заказчика работать по SCRUM. Минусы: сложно объяснить заказчику, зачем ему все это надо, довольно сложно нормально наладить процесс в команде, оценка velocity в условиях меняющихся команд неадекватна, у многих заказчиков предубеждение. Не смогли найти ответ на главный вопрос заказчика: “А сколько потребуется спринтов до завершения проекта?”

Что взяли на вооружение из SCRUM: процесс постоянного улучшения через ретроспективы — вплоть до смены процесса; критерии приемки для фич, составленные вместе с заказчиком; приоритезация фич; planning pocker для оценки.

Производство счастья промышленными методами — почему мы не хотим просто писать код за деньги

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

А когда умный человек — особенно developer в самом широком смысле этого слова — хочет получать удовольствие от своей работы, прежде всего он хочет понимать, что то, что он делает имеет смысл и кому-то нужно. (Бывает вырожденный случай — ультра-гик закапывается в технологии по уши, технологии ради технологий, и все это нужно только ему и узкой группе единомышленников).

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

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

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

Чтобы была счастлива команда — они должны знать, что все это кому-то нужно, чем более живыми будут пользователи, тем лучше. Команда должна видеть заказчика, у которого горят глаза от продукта, который адекватно воспринимает разумные доводы, а не меряет все в терминах “это на 100 баксов больше, убираем”. И немаловажный момент — команда не должна работать в режиме постоянного дедлайна и срыва сроков, должны быть нормальные выходные и вечера. Но если кто-то увлечен настолько, что даже дома берется за проект — это нормально, значит нравится. Но лучше объяснять, что так можно далеко зайти и стараться ограничить всех рабочим временем.

Если мы говорим о счастье заказчика, немаловажен навык “укладываться в срок и в бюджет”. Из всего вышесказанного у нас складывается некий способ работы с проектом, который мы стараемся применять последнее время. И это не есть какая-то методология — это здравый смысл + понимание бизнеса заказчика, которые заставляют подбирать комбинацию методологий либо просто нарушать все правила, когда это оправдано. В какой-то момент накопленные знания по 1-му закону диалектики привели к смене парадигмы. Мы стали относиться к продукту заказчика как к своему.

Практики, которые мы применяем сейчас

1. FFF — fixed price, fixed budget, flexible scope

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

Одним из основных принципов здесь является уже упомянутый YAGNI. По каждой фиче и пожеланию происходит выяснение приоритетов, важности для продукта в-целом и т.д. В этот момент любой человек в команде имеет право задавать вопросы “Зачем нужна эта фича?”, “Почему важно выпустить ее именно в этом релизе?” и “Что потеряет продукт, если этой фичи не будет/будет позже?”

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

2. MVP — только нужное и ничего лишнего

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

1. Lean canvas помогает понять основную целевую аудиторию, ее проблемы и ожидания, предлагаемые решения, затраты и доходы. Хорошо, когда заказчик уже все это сделал. Если нет — мы делаем с ним вместе. Цель: понять, нужно ли вообще заниматься этим проектом. Инструменты: листы формата А0, стикеры, ручки, маркеры.
2. Персоны — это собирательные образы целевой аудитории, одушевляемые персонажи, выполняющие определенные роли при использовании продукта. Цель: при планировании новых фич или улучшении старых, ориентироваться на их “мнение”, представлять, как они будут реагировать. Инструменты: листы А4, карандаши, ручки.
3. Impact mapping — это mind-map бизнес-целей, где мы пытаемся представить, как наши персоны и каким образом помогут бизнесу достигнуть этих целей. Цель: определить основные действия и функционал продукта. Инструменты: доска и маркер, либо онлайн-сервис.
4. Story mapping — это аналог impact mapping, только со стороны пользователей. Берутся уже существующие персоны, из которых выбираем самых важных, согласно Impact mapping, записываем высокоуровневый функционал для каждой из них. Затем описываем минимально необходимый набор атрибутов фичи, который позволит сделать продукт ценным для персоны. И дополняем картину вариантами развития, какие только придут в голову за ограниченное время. Цель: определить скоуп первого релиза, он же — минимально ценный продукт или MVP. Инструменты: доска, листы А0, стикеры, ручки, маркеры; подойдут так же любые электронные таблицы.

Почему стикеры и доска лучше? Все собираются вместе, вовлечены в процесс.

3. Customer journey — роли, контексты, настроения

Делаем черновой вариант навигации по страницам (если web) или переходов клиента между этапами в других случаях. Берем всех персон, которых определили как важных, и проделываем для каждой. Перед каждой страницей мы пытаемся понять контекст, в котором пользователь пришел сюда.

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

4. Прототипирование интерфейсов — быстрая проверка гипотез

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

Почему мы не работаем с дизайнером с первого дня работы над проектом? Дизайнеры очень любят углубляться в мелочи и прорабатывать макеты до конца, в цвете, со всеми тенями и градиентами. Они художники, но у нас другая цель — нам надо понять, быстро нарисовав 5 вариантов расположения блоков на странице, соответствует ли макет бизнес-потребностям. Несмотря на то, что метод прогрессивного Jpeg продвигает одна из известнейших дизайн-студий — Бюро Артема Горбунова — не каждый дизайнер готов сменить парадигму. Два известных мне дизайнера Бюро, которые отлично понимают это, используют и обучают других, имеют высшее техническое или физико-математическое образование.

Суть метода — постепенное добавление детализации. Применительно к web-разработке: сначала только общая канва страниц и схема навигации, затем детальные макеты и верстка, затем реализация. Важно: процесс постепенного улучшения и детализации проходят все страницы вместе, а не по одной. Если есть возможность и время — можно поиграть с командой, командами других проектов, заказчиком в интерактивную игру с бумажными прототипами.

Цель: согласование высокоуровневого понимания интерфейса, вовлечение заказчика в творческий процесс — вложив в макеты частичку души, он уже не может сказать, что они никуда не годятся. Инструменты: бумага, ножницы, стикеры, карандаши, ручки, клей; либо продукты типа Balsamiq

5. Оптимизация процесса разработки

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

До сих пор мы требовали уступок только со стороны заказчика — мы ждем от него согласия на урезание функционала, лояльного отношения к нашим вопросам о целях и смысле, понимания объективных причин, по которым что-то может быть не сделано. А что мы сами делаем для того, чтобы успеть как можно больше, не жертвуя качеством?

Мы стараемся использовать теорию ограничений Голдратта для оптимизации процесса разработки. Определяем критический путь, закладываем буферы везде, где требуется. На диаграмме показываются и те места, где нужно участие заказчика — ответы на вопросы, предоставление материалов и т.д. Цель: в каждый момент видно, за какую задачу браться, заказчик видит, где от него напрямую зависит сдвиг дедлайна, помогает использовать страховочные буферы более грамотно, чем просто умножать срок на пи. Инструменты: любая электронная таблица либо специальный софт (мне не известен).

6. Готовность к изменениям

Мы не приветствуем составление ТЗ. Иногда заказчик уже с ним приходит, но мы знаем, что оно может дожить до конца разработки в неизменном виде только в одном случае: все сопротивляются изменениям до последнего, даже если понимают, что то, что записано в ТЗ, уже не актуально.

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

Резюме

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

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

P.S. В статье нет возможности рассказать о каждой из методик подробно. Поможет Google и просмотр видео-выступлений автора, где все это было рассказано чуть подробнее — вдруг кому-то не надоело читать :-)

Выступление на эту же тему, включая ответы на вопросы аудитории, есть поясняющие картинки и некоторые подробности по методикам:

Подробнее о практиках типа Story mapping, бумажном прототипировании и т.д.

Автор: AnnieOmsk

Источник