Почему создание продукта такое сложное?

Ну, пока еще не начал, хочу упомянуть блог Романа Кононова о QAлификации.

На самом деле, статья — это мой вопрос вам. Как вы считаете, почему создание продукта такое сложное дело?

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

Что скажете по этому поводу?

31 комментарий to “Почему создание продукта такое сложное?”

  1. Glader:

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

  2. Потому что одному создавать продукт очень сложно. Продукт должен отличаться бОльшей устройчивостью к внешним воздействиям (напр. некорректный ввод, который вы ну никогда бы не сделали, а юзеры обязательно так поступят) по сравнению со своим, «наколеночным» решением, где известны все слабые места.

    Помимо этого есть куча вещей которые нужно сделать и они никак не связаны с программированием. Сюда входит написание end-user документации, маркетинг, брендинг и т.д. Делать это программисту очень скучно, и поэтому такие дела всегда откладываются, откладываются…

    • Victor Ronin:

      Итого, суммируя имеем
      а) Большое количество требований к продукту
      б) Большое количество не программистских активностей, которые НЕ выполняются.

  3. А не бывает «в белый свет» — или же вы попытаетесь удовлетворить гипотетические потребности всех без исключения и вместо полезной софтины сделаете мега-систему настроек под всего и вся 🙂 А зачем оно?

    • Victor Ronin:

      Ну под фразой «в белый свет» я подразумеваю выпуск продукта, который будут пользовать за пределом того офиса, где он разрабатывается.

      • Ок, ясно. Я имел в виду продукт для большой аудитории и проблемы кастомизации.

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

  4. Слава:

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

    Друзья и т.д. часто не сильны в критике и пытаются больше воображать, например, воображать себя создателями, а не потребителями. Потому лучше посещать разные IT встречи.

    • Victor Ronin:

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

      • Слава:

        Необязательно большое. Я к тому, что делая продукт для себя, он «спасет жизнь» еще, зачастую, очень маленькому количеству людей. Видимо, если собираешься выпускать в свет, то необходимо рано или очень рано изучать целевую аудиторию. Хотя начиная с себя, начинаешь решать реальную проблему, а не абстрактное решение воображаемой проблемы.

        • Victor Ronin:

          ok. Опять же, суммируя. Проблема в том, что приходится решать абстрактную, а не реальную проблему.
          Я просто пытаюсь собрать ключевые идеи для следующей статьи.

  5. orbit:

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

    Когда для себя пишешь инструмент, то я думаю много ошибок в коде остается не найденными 🙂

  6. Владимир:

    Плюс к вышесказанном различие в средствах/технологиях. Если «для себя» можно сделать на коленке подручными или «лицензионными» средствами, то «в свет» это не прокатит (или прокатит, но не надолго).

    • Victor Ronin:

      Различие? В смысле, что для себя можно делать на чем угодно, а для других только на определенной?

      Это действительно больная тема.

      • Владимир:

        Разумеется. Разве у покупателей будет стоять все ПО и библиотеки, что нужны для решения проблемы в 2-3 строки?

        А если библиотеки еще и GPL были. Случится примерно такое: http://habrahabr.ru/blogs/im/51041/
        Не лучше будет если библиотека будет краденная.

        *Включено воображение*
        Кто-нибудь знает, что случится если Microsoft захочет подать в суд за нарушение их патентов?

        • Victor Ronin:

          Да история с Miranda и Mail.ru хороша.

          Насчет Microsoft. Думаю на территории exUSSR она особо этим заниматься вряд ли будет (разве что если совсем уж припечет).

          А в США легче легкого может подать в суд и отсудить все до последних трусов, если таки будет за что. Тут (в США) это дело хорошо на поток поставлено.

  7. ctype:

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

    • Victor Ronin:

      ну, вся трактовка в фразе «мощная вещь». Что я имел в виду, что за неделю упорного труда (да таки зачастую поверх уже существующих наработок и в хорошо знакомой области) можно добиться достаточно интересного прототипа. И этот прототип зачастую достаточно неплохо решает задачу, которая нужна.

      Как пример 10 летней давности. Была такая p2p сеть gnutella. И мне на работе выдали задачу тогда написать к ней простейший клиентик. У меня за плечами тогда было аж пол года коммерческого опыта работы. Я где-то повозился и за пару деньком сделал таки клиентик. После чего поработал с более опытным товарищем, который за часа полтора показал мне,
      как можно(и нужно было написать) все тоже самое, только в 10 раз меньшим количеством кода (при той же понятности). Итого, он по большему счету мог бы за пару часов написать прототип клиента для этой сети.

      Хотя дальше дело и не пошло, коммерческого продукта не писали. Но могу побиться об заклад, даже на простейший продукт на базе этого прототипа ушло бы э… ну скажем пару человеко месяцев. Вот и получается — 3 часа и пару месяцев.

      • ctype:

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

        • Victor Ronin:

          согласен.

          кстати, забавно получается. Тот функционал который действительно НУЖЕН пользователю занимает мало времени. Ведь пользователю нужно музыку найти и скачать. А вот то, что ему не нужно (ну думаю мало пользователей получают удовольствие от исталлирования и разбирания с тем, что за прокси и куда его воткнуть) занимает много времени.

          • ctype:

            ну вот я делал как-то одну пеньсоурсовскую десктопно-сетевую програмку, только с «нужным» функционалом и сразу отрелизил (что в случае пеньсоурса естественно — чем быстрее релизишь, тем лучше) , людям понравилось и почтовый ящик начал набиваться письмами, в духе — «программа клевая, но вот на работе у нас прокся и хотелось бы пользоваться не только дома» и т.д. и т.п. ну не будешь же их посылать ?
            потом вторая часть — когда прогу ставят на сотню тысяч компов — начинаешь собирать такие ошибки в своей программе и в либах, про которые даже гугль не знает… я просто когда решил писать на .нет думал что .нет более-менее стабилен… теперь так не думаю 🙂

  8. просто в программировании это не так заметно, но действительно сделать «голый» функционал намного проще чем полноценный продукт во всех отраслях деятельности. Например, провести «по-быстрому» свет в комнату — это полчаса. «Лампочка Ильича» на потолок и кабель до щитка. А смонтировать нормальную проводку чтобы и пожаробезопасно и электробезопасно — это и штробить надо и под розетки дырки делать и штробу замазывать, подвесы под светильники делать — дел надолго. Я такие решения («голофункциональные» 🙂 , быстрые) называю радиолюбительскими. У них всегда масса проблем с документированием, ремонтопригодностью, масштабированием, переносимостью и т.д.

    • Victor Ronin:

      Суммируя, ка я делал с другими ответами.
      Проблема — «документирование, ремонтопригодность, масштабирование, переносимость».

    • Victor Ronin:

      Хочу одной из следующих статей свести свои мысли по этому поводу воедино.

    • Слава:

      Особо с этим согласен. Метафора на 5+
      (опять чуть не забыл ввести Captcha)

    • Здесь уже разные наборы требований — чтобы светило или чтобы светило и при том было эстетично.

      С точки зрения надежности, имхо (?) открытая проводка на фарфоровых изоляторах лучше. И вместо турецких включателей — советские ПЕРЕключатели, которые поворачиваются. Я такой софт больше люблю, хотя… GUI… даже в линуксе как-то больше нравится… время экономит 🙂

      • так в том и суть. К любому продукту или решению всегда явно или неявно предъявляются требования чтобы светило и при этом соответствовало еще куче требований. То есть голый функционал + еще много-много всего. Много-много всего нужно, потому что функционал ,как правило, нужен не сам по себе, а как элемент вышестоящих технологических и бизнес процессов. И реализация функционала должна реализацию этих вышестоящих процессов улучшать, а не ухудшать. Это самое трудное для понимания. Само много-много определяется конкретными условиями эксплуатации. Например открытая проводка в смысле надежности конечно не лучше замурованной. Значительно хуже в плане пожаробезопасности(кстати проводка в пустотных перекрытиях типа гипсокартонных стен или за подвесными потолками тоже по сути открытая). Сейчас на фарфоровые изоляторы изолированные провода уже не кладут, а вот укладка в металлические лотки — сплошь и рядом и на производстве и в торговых центрах. Почему так делают? Потому что например для супермаркета недопустим простой из-за отсутствия освещения или питания холодильников — убытки большие. В большинстве случаев даже искать обрыв не станут, а просто по лоткам протянут новый кабель. Получается ремонтопригоднее и модернизируемее, а вопросы пожарной и электробезопасности там решаются пожарной сигнализацией, круглосуточной охраной и негорючим материалом лотка. Вот и почувствуйте разницу. С точки зрения технаря вопрос как подвести напряжение из точки А в точку Б — бросить кабель. С точки же зрения техпроцесса в магазине нужна система электроснабжения(а не просто электричество), в которую помимо кабелей входят: лотки, распредкоробки и промежуточные щитки, вводно-распределительное устройство со счетчиком, автоматы защиты, УЗО, подвесы, розетки, выключатели и контакторы + должностные инструкции охраны, запрещающие доступ к щиткам и лоткам неавторизованному персоналу 🙂 . + схема всего этого, чтобы электрики могли ремонтировать, ЗИП и инструменты, чтобы могли ремонтировать. Заметьте, про эстетичность еще речи не было 😉 . Для квартиры же намного безопаснее проводку замуровать в стену — и пожаробезопаснее и электробезопаснее.

        • Ясное дело, функционал должен улушать, к примеру, документооборот — если он есть. А то ж обычно если он и есть, то очень уж неэффективный. Или неприспособленный к автоматизации, ибо древний 🙂

          Насчет замуровать в стену… Замуровали тут одни гении недавно металлопластиковые шланги в стену, под плитку, их прорвало, затопило через щели между перекрытиями энное количество электрощитков — история из жизни, потом ждали полсуток, пока автоматы просохнут.

          Пришлые сантехники-аварийщики сказали «а вот нам директор запрещает металлопласт ставить, ненадежно».

          Так что мнения разные бывают.

          Новый кабель? Ок, не забыли бы вот только старый отключить…