суббота, 28 апреля 2012 г.

Baby steps for pussies

В современной разработке ПО сложился ряд практик сильно завязанных на то, чтобы всем было удобно маленькими шажками развивать свой продукт. Agile во многом об этом, TDD/ATDD/BDD об этом, continuous delivery об этом, A/B тесты об этом. Большая часть интернет-гигантов в том или ином виде их практикует. Многие высокотехнологичные стартапы выпустив свой мегапродукт и выжив после этого плавно переходят к управлению рисками через вышеозначенные практики. Ведь это позволяет постоянно совершенствоваться, позволяет сделать так, чтобы от вас были без ума 80% пользователей.

И их всех можно понять - эти практики позволяют довольно быстро и интерактивно дотачивать продукт. Если у вас есть много пользователей, то вы раскатываете на 1% аудитории небольшие правки. Новую анимацию, пяток разных оттенков зеленого для заднего фона, несколько разных текстов для одной и той же кнопки, маленькую новую фичу. А дальше можно просто смотреть что делают пользователи и считать что происходит. Тот вариант, которые приводит к более желательному для вас поведению остается, остальные пропадают и никто о них не вспомнит. Даже те, кто им пользовался - многие просто решат что им показалось. Если вы маленькая контора - просто выкатываете всем и смотрите что происходит. Если все плохо - быстро откатываетесь назад и делаете вид что ничего не случилось. Так дотачивали и дотачивают Facebook, большую часть сервисов Google, Twitter, Etsy, предвыборный сайт Обамы, и еще кучу всего.

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

Но у этого всего есть пара недостатков.

Первое - все эти практики в большинстве своем приводят к тому, что вчерашние стартапы приходят к жизни, в которой нет места большим, революционным изменениям. Сначала вы их боитесь, потом вся ваша инфраструктура, сложившиеся вокруг нее процессы и выросшая из этого всего культура просто не могут позволить себе большие, революционные изменения. Вы подсаживаетесь на эти маленькие экспериментики, ведь это так круто! И вы уже не думаете о больших свершениях. которые нельзя разглядеть через тысячи маленьких коммитов. Мы получаем "более быструю лошадь" вместо автомобиля. Лучшие инженеры мира при поддержке кучи денег работают над тем, чтобы помочь бизнесу решить на сколько пикселей и в какую сторону подвинуть поле ввода, чтобы вся обезличенная ими же масса принесла на 0.1% больше денег. Не обязательно даже понимать почему, достаточно видеть, что да, так будет на 0.1% больше. Маленькие шажки, которые становятся маленькими, но очень тяжелыми кандалами.

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

13 комментариев:

  1. Мощная мысль, респект.

    Однако не развита в полной мере.

    Может быть, возможно потыкать булавками в примеры?

    ОтветитьУдалить
    Ответы
    1. Примеры маленьких шажков я кажется явно назвал - google, Twitter, facebook. Их много сейчас. И они регулярно нас радуют поехавшим дизайном, не работающим функционалом и 500-ми ошибками.

      Со смелыми шагами тоже просто - смотрите на весь сочный свежий Apple. Правда сейчас их уже готовые девайсы почти не меняются. Был google wave, который провалился, но это было реально круто. Есть Xbox.

      Удалить
  2. Сергей, приведи четкие примеры, когда были сделаны революционные изменения в каком-то проекте.
    Мысли интересные, но хотелось бы вполне внятно понимать, что потратив кучу бабла на разработку революц. идей, потом получишь невероятный успех в этом проекте. Подход "идти мелкими шажками" дает какие-то гарантии, а что со статистикой проектов революционных? Примеры бы, цифры..

    ОтветитьУдалить
    Ответы
    1. Ходьба мелкими шажками дает только стабильную прибыль. Ну +/-. Вы копите технические долги, вы как Twitter - после взрывного старта тупо крутите дизайн и делаете что уже сделано другими на базе вашего API чем-то дефолтным. Т.е. просто ждете когда кто-нибудь придумает "телефон с одной кнопкой" для вашей отрасли

      Удалить
  3. Что такое большие революционные изменения?
    Вчера мы делали интернет магазин, а сегодня хостим видео?

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

      Удалить
    2. Этот комментарий был удален автором.

      Удалить
    3. Если у них есть яйца, то никакого страха нет. Как видим - не у всех. Ну и процитирую Скотта Хаффмана (Google): “One thing we spend a lot of time talking about is how we can guard against incrementalism when bigger changes are needed. It’s tough, because these testing tools can really motivate the engineering team, but they also can wind up giving them huge incentives to try only small changes. We do want those little improvements, but we also want the jumps outside the box. If you rely too much on the data, you never branch out. You just keep making better buggy whips.”

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

      Удалить
    4. Ну и новый проект это ок, но иногда и старые нужно сильно менять, иначе это будет новый MySpace или orkut

      Удалить
    5. Ну то есть гугл с тремя крупными проектами только из тех, которые на слуху были за последние 5 лет, два из которых пролетели, а третий сожрал половину рынка телефонов - это пример компании у которой есть страх перед новыми проектами? А то, как они пинками всех загнали на новый tap интерфейс - это видимо страх перед изменением старых проектов, ага.
      Facebook, который сделал встроенный мессенджер, api приложений, на моей памяти минимум один раз радикально сменил интерфейс для смещения фокуса пользователя, а на старте вообще полностью поменял рекламную парадигму и это всё чтобы не стать майспейсом - это тоже такой пример?
      Twitter - это пример убыточной компании, там страх есть не у тех людей, которые делают мелкие итеративные изменения, а у тех, которые не могут бросить этот купленный много лет назад дорогой чемодан без ручки. А когда перспективы были радужными и рулили те самые апологеты маленьких изменений, они вроде как не зассали в свое время стать стотысячной блогоплатформой вместо инновационного sms-мессенджера.
      Про то, как изменился Etsy несколько лет назад, ты сам ссылку на статью кидал :) Или тебе таких изменений мало, надо чтобы каждые полгода?
      А можно ещё примеры тех многих компаний, где именно культура маленьких непрерывных изменений останавливает проекты в развитии, а не политика владельцев или создателей?

      Удалить
    6. Скотт Хаффман, которого я процитировал выше это дииректор по качеству поиска. Есть еще такой дядя как Дуглас Боумэн, который когда-то работал дизайнером в Google и который ушел из-за того что я описал выше. Собственнно его прощальный псто: http://stopdesign.com/archive/2009/03/20/goodbye-google.html

      Есть Noah Sussman, наше все от Etsy, который всю прошлую неделю писал как они борют подобный инкрементализм и порожденную им ментальность "маленьких шажков" у инженеров.

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

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

      ЗЫ: Удивительно, что никого не беспокоит второй пункт в моем посте. Или всем плевать на пользователей или все согласны. Я даже не знаю что думать)

      Удалить
  4. Ну можно честно говорить, что нам похуй на пользователей, а можно делать вид что не похуй, выкладывая "протестированные" релизы раз в месяц. Интеграл под кривой количества репортов от времени будет тот же, только в одном случае форма кривой будет пила, а в другом плато с пиками.
    Насчет мнения мощных чуваков, в проектах, в которых инициатива идёт от инженера, наверное они правы. Но ведь проекты, в которых начальство загоняет персонал могучей рукой к счастливому завтра никто не отменял. Выйдет смешно, если очередная инновация будет давать лучший эффект в тоталитарных конторах с кубиклами и гимнами по утрам :) Собственно, осталось дождаться, пока MS встроит все необходимые для этого инструменты в студию, чтобы можно было любого среднестатистического инженера научить.

    ОтветитьУдалить
  5. На примере sony видно, к чему это приводит
    Здесь более детально
    http://www.forbes.ru/tehno-column/tehnologii/81907-kak-umirala-kompaniya-sony

    ОтветитьУдалить