Принцип YAGNI в управлении проектами

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

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

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

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


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

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

Фиксед прайс: сделать проект по ТЗ за оговоренный срок командой, в которой есть разные роли. Древняя классика — все проанализировать, оценить, запрограммировать, протестировать, внедрить и… вылететь из бюджета.
Методы борьбы:
  1. разбиение на короткие итерации,
  2. оценка рисков, вероятностные методы, умножения оценок на “пи” и т.д.,
  3. комбинация обоих вариантов — короткие итерации, каждая из которых использует оценки скорости разработки и использует управление рисками при помощи вероятностных методов, т.е., например, SCRUM.

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


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

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

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


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

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

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

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

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

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

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

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


1. FFF — fixed price, fixed timing, 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, бумажном прототипировании и т.д.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 19

    0
    Как вы обеспечиваете любовь сотрудников к каждому проекту? Каждый раз набираете новую команду?

    Я не совсем понимаю, почему вам не подошел Scrum.

    По Scrum-у stakeholder вообще ничего не обязан знать о ваших методологиях, есть product owner, который регулирует все отношения между командой, и заказчиком. Вы можете приглашать его на демки ваших инкрементов, где он может что-то комментировать, не более. Решения по продукту принимает product owner. Сроки, бюджеты, набор фич и т.п. — команда получает от product owner-а, а не от заказчика.

    Опять же, спринт можно и остановить, если заказчику (product owner-у) приперло (что вы, собственно, и делаете сейчас) — перепланировали, сделали, показали. Не обязательно все скидывать в беклог. Но стопить спринт — плохая практика, смена фокуса команды всегда выходит дороже.

    Ну а все остальное, мне кажется, можно было вычитать из умных книжек, и курсов — не стоило тратить 3 года на понимание таких базовых вещей самостоятельно (если я правильно вас понял).
      +4
      Я не совсем понимаю, почему вам не подошел Scrum

      В теории все отлично. Но на практике заказчики оказались не готовы, чтобы Product owner был на нашей стороне. А со своей стороны они не могут обеспечить все, что требуется. Сейчас мы делаем во многом то же самое, но не пугаем заказчиков разными словами и не вовлекаем в подробности процесса.

      Ну а все остальное, мне кажется, можно было вычитать из умных книжек, и курсов

      Ну да, видимо, где-то есть такой правильный список книг и курсов, где всем рассказывают, как правильно. В жизни на это натыкаешься тогда, когда пришло время, иногда случайно, по рекомендации проверенных людей. И этот процесс занимает время. А еще, наверное, Вы знаете, где учат за 2 месяца быть идеальным владельцем ИТ-бизнеса. Чтобы шишек своих не набивать, а сразу так раз — и все уметь :-)
        +1
        Как вы обеспечиваете любовь сотрудников к каждому проекту? Каждый раз набираете новую команду?

        Команда у нас все 3 года почти не меняется. Стараемся проекты искать поинтереснее. Но об этом надо писать отдельно.
          +1
          Заказчик и должен быть владельцем продукта. Участвовать в процессе и так далее. Если это не так, то вы получаете как-бы скрам, который как-бы работает.
            0
            Ну так в том и дело, что в заказной разработке очень сложно этого добиться. И это основная проблема, которую надо решить — доступ к владельцу. Если же он есть, то кто-то может и SCRUM делать, если работает. Нам показалось в нем многое недостаточным, а многое лишним.
              +1
              Насчет скрама-то я с вами полностью согласен :) Сложный фреймворк, который сейчас пихают везде, нужно это или не нужно. К тому же имеет принципиальные изъяны, например, недоделки в спринтах выявленные на демо физически не успевают попасть в следующий спринт, и отправляются в отстойник полусырого функционала, который все больше разрастается со временем.
                0
                Ну вот когда во главе угла здравый смысл, то и SCRUM будет работать — если он действительно нужен.
          +2
          Не знаю, где вы находите таких золотых заказчиков? У нас даже самые лояльные практически не дают участвовать в составлении приоритета фич. Если им уперлось, то практически невозможно хоть что-то доказать. Из личных примеров: три часа я и менеджер проекта убеждали заказчика отказаться от непродуманной фичи, которая стоила месяц+. После трех часов он нас спросил что-то, что как мы думали, он понял еще в самом начале :) В итоге, мы так и не смогли пробить его мнение, сделали фичу, через итерацию ее выпилили, так как она реально была ненужна и не работала в его модели. А он не расстроился и даже не понял ничего. Третий или четвертый год его проект двигается, а принцип остался такой же, много чего делается просто так, а потом вываливается в ведро. Как с такими работать? А уж что касается UI/UX, то тут вообще идет настоящая война. Заказчики часто рубят все подряд и хотят г*, но свое и точка =)

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

          Ваша методика хороша, мы бы тоже рады работать по такой схеме, думать о UX, о пользователях и делать действительно полезные клиенто-ориентированные проекты, но заказчики все рубят. Может расскажете, как вы их убеждаете?
            +4
            Начинали мы тоже с таких заказчиков, о которых Вы говорите. Да и сейчас такие у нас остались, не без этого. Но есть уже 2 проекта, которые сделаны вот так.

            Да, заказчиков приходится искать. Причем все это лучше всего работает, когда заказчик находится в Омске, когда можно прийти к нему в офис, а он может прийти к нам. На удаленке все это тяжело, конечно. Но возможно.

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

            Такие люди хорошо реагируют на критику через вопросы. Как я писала: «Что будет, если эта фича не появится сейчас/вообще?» Ни в коем случае нельзя говорить в духе: «Да это вам не нужно, мы совершенно точно знаем». Нет, не знаем. И мы не знаем точно, и он не знает. Мы можем только придумать способ с заказчиком вместе, как быстро проверить гипотезу о необходимости фичи.

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

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

            На первом видео в конце статьи на 59-й минуте встает дядька. Он директор производственной фирмы в Омске. Он весь доклад сидел со скептическим выражением на лице и пару раз язвительно сказал, что мы собрались заказчика учить, и это никаким заказчикам не нужно. А потом он начал задавать вопросы, как бы ему как заказчику научиться так работать и не могли бы мы это сделать. И сейчас он пришел уже и на второе мероприятие, зовет к себе в гости зайти и всячески рвется, чтобы его покоучили.

            Поэтому просто берите и пробуйте. Начните с простого — с вопросов. С выяснения целевой аудитории и бизнес-целей. С первого раза может и не получится, но надо продолжать :-)
              0
              Тут чисто работа менеджера, программисты хотят, но на своем уровне не могут. Мы в свою очередь больше думаем о своих проектах, так как любой заказчик на стороне это не тоже самое, что свое. В идеальных планах разогнать свой проект, который сейчас на старте, чтобы вся команда была на нем максимально задействована и постепенно отказаться от сторонних заказов. Но это планы на ближайшие несколько лет.
                +3
                Ну свой проект-то мы тоже хотим :-) Но до этого еще, возможно, далеко. А аутсорсинг — это возможность поработать в разных продуктах за деньги заказчика. И прокачать все те навыки, которые необходимы для успешного старта и развития своего…

                И еще — у нас нет менеджеров в чистом виде. Я программист, и Иван программист. А еще мы аналитики. Ну руководим немножко иногда :-) А программисты у нас общаются с заказчиком почти столько же, сколько мы, и задают те самые вопросы «Зачем?» и «Почему?» И это тоже одно из наших решений — не брать в команду равнодушных.
            0
            Мне всегда казалось несколько странным, что разработчики строят некую виртуальную реальность в виде среднего потребителя продукта и его поведения, даже придумывают настроения и роли. Если продукт для людей, то почему бы не включить в процесс создания продукта их? показывать им прототипы, обсуждать… У Вас не было такого опыта?
              0
              У нас пока нет живого опыта. Есть сейчас проект, на котором мы следим за отзывами и Яндекс.метрикой. Уже после релиза кое-что поменяли благодаря отзывам людей. Кроме того, я внимательно слежу за проектами типа Бухгалтерия.Контур и 2GIS и вижу, что предпринимают они.

              Виртуальных, конечно, придумывают тогда, когда нет доступа к реальным. Но с реальными юзерами есть свои проблемы. Почти никогда нельзя спрашивать людей чего они хотят. Все, что они скажут, почти всегда неправда :-) При этом они это делают не по злобе. А просто потому, что они в тот момент действительно так думают. Тот же Стив Джобс и вовсе подстраивал в итоге аудиторию под свои продукты, а не наоборот.

              Поэтому многие веб-сервисы делают так: выкатывают новую фичу или новый дизайн на часть аудитории и просто следят за метриками. Если основные показатели бизнеса растут, значит фичу/дизайн надо выкатить всем. Много есть разных вариантов, как это делать. Главное — чтобы были внятные метрики, по которым можно оценивать.

              Еще очень хороший способ дать людям почувствовать пульс аудитории — посадить разработчиков на саппорт реальных пользователей на некоторое время. Так делает СКБ «Контур», например. Так делает Джоэль Спольски. После этого они очень ответственно начинают относиться к тому, что делают. Как только у нас появится такая возможность, я обязательно так сделаю.
                0
                Джобс в каком то смысле гений и то что он делал не способен сделать никто пока что. Отчасти с Вашим утверждением соглашусь, однако, если продукт делается для людей, он решает какие то их проблемы так ведь? Если это не игровой проект. А как можно решать проблемы пользователей без их участия… Можно на эту тему подискутировать в личке впрочем, а то это может быть уже не релевантно теме топика…
                  0
                  Если бы я все это написала, статью невозможно было бы дочитать. На все эти темы есть масса книг и статей. Я просто хотела показать комбинацию методов.

                  Можно и в личке. Пишите.
              0
              Так все же как быть с “А сколько потребуется спринтов до завершения проекта?”?
                0
                У нас нет спринтов. Мы договариваемся о сроке, а затем за счет приоритезации, выкидывания ненужного, поиска более простых решений — все это в тесном контакте с заказчиком — в него укладываемся. Т.е. срок мы называем перед разработкой.
                0
                Спасибо вам!
                Это первая статья с трезвым взглядом на данную проблематику. А то в последнее время встречаю только фанатов SCRUM или чего то ещё конкретного.
                  0
                  Спасибо.

                  Фанаты вредны в любом деле на мой взгляд. Если бы я знала, как изобразить на логотипе здравый смысл, непременно сделала бы это для своей конторы.

                Only users with full accounts can post comments. Log in, please.