Пользователи, функции и «танцующие медведи»

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

      Понимаю: рынок, конкуренция, сроки, клиенты. Но нет ничего хуже, чем отдавать руководство в руки пользователям и слепо следовать их прихотям. Гонка за функциональностью — это ложная гонка, выигравший ее никакого приза не получит, кроме, пожалуй, рабства перед Заказчиком. Прелесть продукта не в обилии функций, а в правильной их подгонке, сбалансированности, удобности.
      Единственный выход в данной ситуации — бранчевать продукт: делать отдельную пользовательскую ветку, и, если такова политика разработки, добавлять в нее требуемые функции. А публичную ветку держать чистой и понятной. Только вот радости такой подход уже не принесет — ни пользователям, ни разработчикам, так как обе ветки постепенно превращаются в функциональных монстров, «танцующих медведей».
      Понятны мотивации заказчика — он хочет получить единый продукт и использовать его (хотя требуемая ему функциональность может быть достигнута за счет интеграции с другими продуктами): хочу все и сразу и за те же деньги. Только вот результат больше походит не на пестрое бабушкино одеяло, сотканное из сотни лоскутков но теплое и красивое — а на половую тряпку из этих же лоскутков, об которую все вытирают ноги и нашивают новые лоскутки взамен прорвавшихся. Использовать все равно можно будет — только сложно и неудобно. И не в том качестве.
      Источник проблемы — что ж, их минимум два: отсутствие высокоуровнего идеологического проектирования (того, что называется проектированием взаимодействия — не путать с системной архитектурой) и стремление угодить гипотетическому заказчику в данный момент. В отсутствие этих двух вещей можно только смягчить монструозность продукта, распихав функции максимально аккуратно (да-да — юзабилити — тестирование, перепроектирование).
      Мораль: а нет ее. Точнее, она очевидна — прописная истина, так сказать. Наряду с системной архитектурой (а даже до нее) должен быть (обязан быть!) этап выяснения, а что же мы конкретно делаем, и какие задачи с помощью нашего продукта можно решать. Но самое главное — донести это до клиентов. Чтобы не было нужды забивать микроскопами гвозди. Ну и не смешивать публичные сервисы с сервисами для конкретного клиента.

    Комментарии 3

      0
      А если посмотреть с точки зрения инвестора?

      Ты вложил деньги в весьма специфический продукт, который не факт что будет не то что популярен, а вовсе востребован на рынке (из-за своей специфики)

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

      С точки зрения инвестора это ли не выход? Ты пристраиваешь то что уже есть, а только потом начинаешь разрабатывать публичную ветку, опираясь на опыт реального использования, которая быть может принесет дополнительную прибыль.
        0
        давай разберем:
        1. Инвестор нашел гипотетического заказчика, который возможно подсядет на продукт. А возможно и нет.
        2. Работа напильником идет в сторону, предложенную левой ногой заказчика — без проработки, проверки, исследования реальных нужд заказчика (реальных, а не выдуманных им).
        3. Результатом такой работы напильником выйдет очередной монструозный пакет напичканный разрозненной функциональностью.

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

        Даже если заказчик купит такой продукт (читай — будет вынужден), конечные пользователи этого заказчика вряд ли будут счастливы.

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

        Пользователь конкретный и пользователь публичный — разные звери. Что надо одному — на фиг не упало другому. Именно потому в google docs есть то, что есть — и ничего лишнего. Так что публичная ветка потом — это очень спорный момент.

        А описанный тобой подход (обтачивании на пользователях в агрессивном виде) хорош там, где нет конкурентов, или где есть большие деньги (пример — Microsoft). Для маленьких компаний это губительно: самое лучшее, что в таком случае будет — это фирма навсегда будет привязана к двум — трем заказчикам. И будет выполнять любые их прихоти. Так что в долгосрочной перспективе дешевле выйдет продумывать продукт, а не подтачивать его напильником.
          0
          "Для маленьких компаний это губительно: самое лучшее, что в таком случае будет — это фирма навсегда будет привязана к двум — трем заказчикам."

          у нас все к этому идет по-моему.

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

      Самое читаемое