Наша компания занимается разработкой индивидуальных веб-приложений.
Не сайты-визитки, а приложения.
Чаще всего – для внутрикорпоративного использования.
Одним из наиболее актуальных вопросов заказной разработки является правильная оценка сроков и бюджета проекта, чтобы работа была выполнена, заказчик остался доволен, а прибыль — адекватной.
На протяжении 3 лет мы пробовали разные способы работы и подходы к решению проблемы сроков и бюджета.
Мы прочитали кучу книг, посетили десятки конференций, вебинаров и т. д. Ниже под катом описание решения, которое мы сейчас нашли, чтобы принести максимальную выгоду заказчику за интересный для нас бюджет. Сначала нам нужно поговорить о том, как мы к этому пришли.
Классический аутсорсинг – продажа часов или фиксированная цена.
Продажа часов: клиент подсаживается на «бесконечный» контракт, постепенно увеличивается команда, а возможно и ставки.
Часто работу распределяет кто-то со стороны заказчика, в команде разработчиков нет своих аналитиков, Минусы: редко удается поднять ставки, иногда получается, что проект не взлетает и все деморализованы, люди получают скучно и приходится часто менять команду.
Выгодно, если у вас есть посредственные программисты, без звезд, но по-настоящему интересные и сложные проекты с такой командой сделать невозможно.
Небольшая фиксированная цена на oDesk: небольшая работа за короткое время, подходит для рок-звезд, которые могут работать в одиночку и быстро.
Минусы: звезды быстро понимают, что так можно работать и сами, и уходят на фриланс.
Фиксированная цена: выполнение проекта по техническому заданию в течение определенного периода времени командой, в которой есть разные роли.
Древняя классика — все анализировать, оценивать, программировать, тестировать, внедрять и… исчерпать бюджет. Методы борьбы:
- разбиение на короткие итерации,
- оценка рисков, вероятностные методы, умножение оценок на «пи» и т. д.,
- сочетание обоих вариантов — короткие итерации, каждая из которых использует оценки скорости разработки и использует управление рисками с использованием вероятностных методов, т.е.
, например, SCRUM.
Долой культ карго — почему SCRUM в чистом виде не заработал в нашей команде
Мы опробовали это на нескольких проектах, даже в критериях отбора проектов написали — готовность заказчика работать по SCRUM. Недостатки: заказчику сложно объяснить, зачем ему все это нужно, достаточно сложно нормализовать процесс в команде, оценка скорости в условиях смены команд неадекватна, у многих заказчиков есть предубеждения.
Нам не удалось найти ответ на главный вопрос заказчика: «Сколько спринтов пройдет, прежде чем проект будет завершенЭ»
Что было перенято из SCRUM: процесс постоянного улучшения посредством ретроспектив – вплоть до изменения процесса; критерии приемки характеристик, составленные совместно с заказчиком; приоритезация функций; планирование покера для оценки.
Производство счастья индустриальными методами — почему мы не хотим просто писать код за деньги
Есть много людей, которые работают на работе, делают то, что им говорят, а находят удовольствие в чем-то другом – в играх, хобби, выпивке, в конце концов.
Я и мой партнер нем Мы не из таких людей, а потому со временем пришли к выводу, что тоже хотим видеть в команде людей, которым нравится то, что они делают.
И когда умный человек — особенно разработчик в широком смысле слова — хочет получать удовольствие от своей работы, в первую очередь он хочет понять, что то, что он делает, имеет смысл и кому-то нужно.
(Есть вырожденный случай - ультрагик зарывается по уши в технологии, технологии ради технологий, и все это нужно только ему и узкому кругу единомышленников).
Поскольку мы работаем на чужой бизнес, то, что мы делаем, должно приносить пользу этому бизнесу.
Или, если это продукт для обычных пользователей Интернета, он их порадует и принесет им пользу.
Как только счастье пользователей, разработчиков и клиентов — именно в таком порядке — выходит на первый план, а не технологий и процессов, мнение радикально меняется.
Я вообще не хочу думать о затраченных часах.
В основном проекты, которые нам нравятся, относятся к категории командных с фиксированной ценой.
Чтобы пользователи были довольны, нужно уметь делать хорошие интерфейсы и продумывать каждую фичу с точки зрения пользы, удобства, красоты и наконец.
Команда начинает думать о маркетинге в лучшем виде: просто сделайте хороший продукт, и пользователи распространят информацию.
Чтобы команда была счастлива, она должна знать, что все это кому-то нужно; чем активнее пользователи, тем лучше.
Команда должна видеть заказчика, у которого загораются глаза от продукта, который адекватно воспринимает разумные доводы, а не измеряет все в терминах «это на 100 баксов больше, уберем».
И важный момент — команда не должна работать в условиях постоянных сроков и срыва сроков; должны быть нормальные выходные и вечера.
Но если кто-то настолько увлечен, что даже берется за проект дома, это нормально, значит, ему это нравится.
Но лучше объяснить, что на этом пути можно зайти далеко и попытаться ограничить рабочее время каждого.
Если мы говорим о счастье клиента, важен навык «уложиться в сроки и в рамках бюджета».
Из всего вышеперечисленного у нас выработался определенный способ работы с проектом, который мы пытаемся применять в последнее время.
И это не какая-то методология — это здравый смысл + понимание бизнеса заказчика, которое заставляет нас подбирать комбинацию методологий или просто нарушать все правила, когда это оправдано.
В какой-то момент накопленные знания о 1-м законе диалектики привели к смене парадигмы.
Мы стали относиться к продукту клиента как к своему собственному.
Практики, которые мы используем сейчас
1. FFF – фиксированная цена, фиксированные сроки, гибкий объем работ.
FFF можно рассматривать как высокоуровневый способ уложиться в сроки и в рамках бюджета, гарантируя клиенту, что за те деньги, которые он платит, и время, которое он готов посвятить, он получит лучшее, что можно сделать.Одним из главных принципов здесь является уже упомянутый ЯГНИ.
По каждой особенности и пожеланию уточняются приоритеты, важность для продукта в целом и т.д. В этот момент любой человек в команде имеет право задать вопросы: «Зачем нужна эта функцияЭ», «Почему важно выпустить ее именно в этом релизеЭ» и «Что потеряет продукт, если этой функции не будет/не будет позжеЭ»
Этот принцип можно применить к любой творческой работе, в частности рассказал Андрей Шапиро , как можно сделать слайды для отчета за очень ограниченное время.
В общем, выделение конечного количества времени на решение задачи заставляет искать простой способ ее решения, иногда выходя далеко за рамки программирования.
Дальнейшие методы помогают достичь этой цели.
2. MVP – только то, что вам нужно и ничего лишнего
Итак, мы хотим понимать, что и для кого мы делаем, чтобы иметь возможность участвовать в обсуждениях с заказчиком функционала на равной или почти равной основе.Для этого используются методы, которые обычно рекомендуют использовать при бизнес-планировании (их очень любят, например, стартапы).
- Бережливый холст помогает понять основную целевую аудиторию, ее проблемы и ожидания, предлагаемые решения, затраты и доходы.
Хорошо, когда заказчик все это уже сделал.
Если нет, мы сделаем это вместе.
Цель: понять, стоит ли вообще предпринимать этот проект. Инструменты: листы А0, наклейки, ручки, маркеры.
- Персоны — это собирательные образы целевой аудитории, анимированные персонажи, выполняющие определенные роли при использовании продукта.
Цель: планируя новые функции или улучшая старые, ориентируйтесь на их «мнение», представляйте, как они отреагируют. Инструменты: листы А4, карандаши, ручки.
- Картирование воздействия — это интеллектуальная карта бизнес-целей, в которой мы пытаемся представить, как наши люди и как они помогут бизнесу достичь этих целей.
Цель: определить основные действия и функциональные возможности продукта.
Инструменты: доска и маркер или онлайн-сервис.
- Story Mapping — аналог карт воздействия, только со стороны пользователей.
Берём уже существующих персон, из которых выбираем самых важных, согласно Impact Mapping, и прописываем высокоуровневый функционал для каждого из них.
Затем мы описываем минимально необходимый набор атрибутов функций, которые сделают продукт ценным для человека.
И дополняем картину вариантами развития, которые приходят на ум только в ограниченное время.
Цель: определить объем первого релиза, также известного как минимально ценный продукт или MVP. Инструменты: доска, листы А0, наклейки, ручки, маркеры; Любая электронная таблица также подойдет.
3. Путь клиента – роли, контексты, настроения
Делаем черновой вариант навигации по страницам (если веб) или клиентских переходов между этапами в других случаях.Мы берем всех людей, которые были определены как важные, и делаем это для каждого.
Перед каждой страницей мы пытаемся понять контекст, в котором сюда пришел пользователь.
Мы ставим себя на его место и оцениваем его чувства от увиденного и его мотивацию перейти к следующим шагам.
Цель: понять, какой контент страницы мотивирует пользователя продолжать общение с продуктом, а что может заставить его уйти.
Инструменты: доска, листы А0, наклейки, ручки, маркеры.
4. Прототипирование интерфейса – быстрая проверка гипотез
Важный момент для понимания функциональности — даже если спецификация есть — это прототипирование интерфейсов.Даже если в команде нет UX-специалиста, нарисовать прямоугольники на бумаге может любой.
Очень важно договориться о едином понимании интерфейса с заказчиком.
Почему мы не работаем с дизайнером с первого дня проекта? Дизайнеры любят вникать в детали и прорабатывать макеты до конца, в цвете, со всеми тенями и градиентами.
Они художники, но у нас другая цель — нам нужно, быстро нарисовав 5 вариантов расположения блоков на странице, понять, соответствует ли макет потребностям бизнеса.
Несмотря на то, что прогрессивный метод Jpeg пропагандирует одна из самых известных дизайн-студий — Бюро Артема Горбунова — не каждый дизайнер готов менять парадигму.
Я знаю двух конструкторов Бюро, которые это прекрасно понимают, используют и учат других, имеют высшее техническое или физико-математическое образование.
Суть метода заключается в постепенном добавлении деталей.
Применительно к веб-разработке: сначала только общий набросок страниц и схема навигации, потом подробные макеты и верстка, потом реализация.
Важно: процесс постепенного улучшения и детализации идет по всем страницам вместе, а не по одной.
Если у вас есть возможность и время, вы можете поиграть со своей командой, командами других проектов и заказчиком в интерактивную игру с бумажными прототипами.
Цель: договориться о высоком уровне понимания интерфейса, вовлечь заказчика в творческий процесс — вложив в макеты частичку своей души, он уже не сможет сказать, что они никуда не годятся.
Инструменты: бумага, ножницы, наклейки, карандаши, ручки, клей; или такие продукты, как Бальсамик
5. Оптимизация процесса разработки
Итак, функционал релиза определен.Критерии приемки для всех функций составлены.
Теперь важно вместе с заказчиком определить порядок приоритетов всех функций.
И чтобы выделить некоторые из тех, которые не являются строго необходимыми, мы снова вспоминаем ЯГНИ.
Именно эти возможности уйдут под нож, если по каким-то причинам разработка не уложится в отведенный срок.
До сих пор мы требовали от заказчика только уступок — ожидаем от него согласия на урезание функционала, лояльного отношения к нашим вопросам о целях и смысле и понимания объективных причин, почему что-то нельзя сделать.
Что мы делаем сами, чтобы успеть сделать как можно больше, не жертвуя при этом качеством? Мы пытаемся использовать теорию ограничений Голдратта для оптимизации процесса разработки.
Определяем критический путь и добавляем буферы там, где это необходимо.
На схеме также показаны те места, где необходимо участие заказчика — ответы на вопросы, предоставление материалов и т. д. Цель: в каждый момент понятно, какую задачу взять на себя, заказчик видит, где от него напрямую зависит сдвиг сроков, помогает использовать буферы безопасности более грамотно, чем простое умножение срока на число пи.
Инструменты: любая электронная таблица или специальное программное обеспечение (мне неизвестное).
6. Готовность меняться
Мы не поощряем подготовку технических спецификаций.Иногда заказчик уже приходит с ним, но мы знаем, что он может дожить до конца разработки в неизменном виде только в одном случае: все до последнего сопротивляются изменениям, даже если понимают, что то, что написано в ТЗ, уже не актуально.
Вместо этого мы позволяем изменять функциональность «на лету».
Заказчику ночью может прийти в голову гениальная идея и прибежать с ней к нам.
В SCRUM, например, эта идея попадет в журнал невыполненных задач.
Это не будет рассматриваться до следующего спринта и, возможно, даже не будет обсуждаться.
Сообщаем заказчику, что по его задумке можно внести изменения в состав релиза не только в сторону добавления функционала, но и в сторону его сокращения.
Объясняем, что полдня обсуждения заставят нас выкинуть какую-то фичу из хвоста в списке приоритетов.
Если все это не охладит его пыл и он действительно считает, что идея достойна обсуждения и реализации, мы ее реализуем.
Краткое содержание
В настоящее время уже невозможно применять какую-либо методологию в чистом виде.Вам необходимо изучать чужой опыт, интересоваться приемами, не имеющими прямого отношения к программированию, и черпать оттуда инструменты и идеи.
Ну и нужно понимать, что никакие методологии и процессы не помогут вам сделать качественный продукт. Придется работать головой и развивать в себе ответственность! Для каждого.
P.S. В этой статье нет возможности подробно рассказать о каждой из техник.
Гугл также поможет, просмотрев видеопрезентации автора, где все это было объяснено чуть подробнее - вдруг кому-то не надоело читать :-)
Выступление на ту же тему, включая ответы на вопросы аудитории, есть поясняющие картинки и некоторые подробности по методам:
Узнайте больше о таких практиках, как создание карт историй, бумажное прототипирование и т. д.
Теги: #Разработка под заказ #Управление проектами #бюджет #смета #fff #разработка сайтов
-
Зона Обмена
19 Dec, 24 -
Дао Де Джин
19 Dec, 24 -
Дорогая, Я Уменьшил Наше Радио!
19 Dec, 24
