Ну, пока еще не начал, хочу упомянуть блог Романа Кононова о QAлификации.
На самом деле, статья — это мой вопрос вам. Как вы считаете, почему создание продукта такое сложное дело?
Вроде, когда с чем-то играешься и делаешь для себя, то за недельку собираешь очень даже мощную вещь, а вот как только нужно что-то сделать для выпуска в белый свет, то обнаруживаешь, что полгода бьешься над махоньким продуктом.
Что скажете по этому поводу?
Видимо, потому, что для выпуска в белый свет нужно проработать невероятное количество мелочей, которые в проекте для себя просто игнорируешь.
ok. То есть, большее количество требований к продукту.
Потому что одному создавать продукт очень сложно. Продукт должен отличаться бОльшей устройчивостью к внешним воздействиям (напр. некорректный ввод, который вы ну никогда бы не сделали, а юзеры обязательно так поступят) по сравнению со своим, «наколеночным» решением, где известны все слабые места.
Помимо этого есть куча вещей которые нужно сделать и они никак не связаны с программированием. Сюда входит написание end-user документации, маркетинг, брендинг и т.д. Делать это программисту очень скучно, и поэтому такие дела всегда откладываются, откладываются…
Итого, суммируя имеем
а) Большое количество требований к продукту
б) Большое количество не программистских активностей, которые НЕ выполняются.
А не бывает «в белый свет» — или же вы попытаетесь удовлетворить гипотетические потребности всех без исключения и вместо полезной софтины сделаете мега-систему настроек под всего и вся 🙂 А зачем оно?
Ну под фразой «в белый свет» я подразумеваю выпуск продукта, который будут пользовать за пределом того офиса, где он разрабатывается.
Ок, ясно. Я имел в виду продукт для большой аудитории и проблемы кастомизации.
В вашем случае, если утрировать — в случае единичного внедрения, проблемы концентрируются в области саппорта. Для которого и нужна документация и т.д. — и возможности донастройки, в общем-то, тоже — со временем неизбежно понадобится изменять функционал…
Полностью согласен.
Сходу нашел простую отговорку. Когда создаешь продукт для себя, то он всех устраивает и это можно проверить, ведь все это ты сам. Когда для других, то гарантии, что целевая аудитория будет довольна, нет. Ибо создатель и потребитель отличаются в своих потребностях, даже если не сразу, то со временем. От сюда и начинаются танцы с бубном.
Друзья и т.д. часто не сильны в критике и пытаются больше воображать, например, воображать себя создателями, а не потребителями. Потому лучше посещать разные IT встречи.
Получается — большое количество требований, причем зачастую изначально неизвестных.
Необязательно большое. Я к тому, что делая продукт для себя, он «спасет жизнь» еще, зачастую, очень маленькому количеству людей. Видимо, если собираешься выпускать в свет, то необходимо рано или очень рано изучать целевую аудиторию. Хотя начиная с себя, начинаешь решать реальную проблему, а не абстрактное решение воображаемой проблемы.
ok. Опять же, суммируя. Проблема в том, что приходится решать абстрактную, а не реальную проблему.
Я просто пытаюсь собрать ключевые идеи для следующей статьи.
Ну да, когда делаешь для других, то требования к продукту сильно повышаются. Плюс часто приходится повышать гибкость, настройки разные вводить. А когда для себя — можно прямо в коде переменные поправить 🙂
Когда для себя пишешь инструмент, то я думаю много ошибок в коде остается не найденными 🙂
Согласен. Кстати, не найден — не ошибка 😉
Угу.
То есть Увеличиваются количество требований и гибкость (то есть охват большей задачи).
Плюс к вышесказанном различие в средствах/технологиях. Если «для себя» можно сделать на коленке подручными или «лицензионными» средствами, то «в свет» это не прокатит (или прокатит, но не надолго).
Различие? В смысле, что для себя можно делать на чем угодно, а для других только на определенной?
Это действительно больная тема.
Разумеется. Разве у покупателей будет стоять все ПО и библиотеки, что нужны для решения проблемы в 2-3 строки?
А если библиотеки еще и GPL были. Случится примерно такое: http://habrahabr.ru/blogs/im/51041/
Не лучше будет если библиотека будет краденная.
*Включено воображение*
Кто-нибудь знает, что случится если Microsoft захочет подать в суд за нарушение их патентов?
Да история с Miranda и Mail.ru хороша.
Насчет Microsoft. Думаю на территории exUSSR она особо этим заниматься вряд ли будет (разве что если совсем уж припечет).
А в США легче легкого может подать в суд и отсудить все до последних трусов, если таки будет за что. Тут (в США) это дело хорошо на поток поставлено.
воот не верю я что за неделю соберешь очень даже мощную вещь … за неделю разве что работающий прототип появиться и то если писать уже в отлаженной инфраструктуре, наработанной в предыдущих проектах
ну, вся трактовка в фразе «мощная вещь». Что я имел в виду, что за неделю упорного труда (да таки зачастую поверх уже существующих наработок и в хорошо знакомой области) можно добиться достаточно интересного прототипа. И этот прототип зачастую достаточно неплохо решает задачу, которая нужна.
Как пример 10 летней давности. Была такая p2p сеть gnutella. И мне на работе выдали задачу тогда написать к ней простейший клиентик. У меня за плечами тогда было аж пол года коммерческого опыта работы. Я где-то повозился и за пару деньком сделал таки клиентик. После чего поработал с более опытным товарищем, который за часа полтора показал мне,
как можно(и нужно было написать) все тоже самое, только в 10 раз меньшим количеством кода (при той же понятности). Итого, он по большему счету мог бы за пару часов написать прототип клиента для этой сети.
Хотя дальше дело и не пошло, коммерческого продукта не писали. Но могу побиться об заклад, даже на простейший продукт на базе этого прототипа ушло бы э… ну скажем пару человеко месяцев. Вот и получается — 3 часа и пару месяцев.
нну я про то, что много времени уходит на все то, что «окружает» функционал — гуй там, инсталлятор тот же, поддержка локализаций, настройки — тот же клиент гнутеллы должен уметь работать там через сокс прокси, брать настройки из эксплорера, всякие мелочи типа отсылки ексепшенов разработчику
согласен.
кстати, забавно получается. Тот функционал который действительно НУЖЕН пользователю занимает мало времени. Ведь пользователю нужно музыку найти и скачать. А вот то, что ему не нужно (ну думаю мало пользователей получают удовольствие от исталлирования и разбирания с тем, что за прокси и куда его воткнуть) занимает много времени.
ну вот я делал как-то одну пеньсоурсовскую десктопно-сетевую програмку, только с «нужным» функционалом и сразу отрелизил (что в случае пеньсоурса естественно — чем быстрее релизишь, тем лучше) , людям понравилось и почтовый ящик начал набиваться письмами, в духе — «программа клевая, но вот на работе у нас прокся и хотелось бы пользоваться не только дома» и т.д. и т.п. ну не будешь же их посылать ?
потом вторая часть — когда прогу ставят на сотню тысяч компов — начинаешь собирать такие ошибки в своей программе и в либах, про которые даже гугль не знает… я просто когда решил писать на .нет думал что .нет более-менее стабилен… теперь так не думаю 🙂
просто в программировании это не так заметно, но действительно сделать «голый» функционал намного проще чем полноценный продукт во всех отраслях деятельности. Например, провести «по-быстрому» свет в комнату — это полчаса. «Лампочка Ильича» на потолок и кабель до щитка. А смонтировать нормальную проводку чтобы и пожаробезопасно и электробезопасно — это и штробить надо и под розетки дырки делать и штробу замазывать, подвесы под светильники делать — дел надолго. Я такие решения («голофункциональные» 🙂 , быстрые) называю радиолюбительскими. У них всегда масса проблем с документированием, ремонтопригодностью, масштабированием, переносимостью и т.д.
Суммируя, ка я делал с другими ответами.
Проблема — «документирование, ремонтопригодность, масштабирование, переносимость».
Хочу одной из следующих статей свести свои мысли по этому поводу воедино.
Особо с этим согласен. Метафора на 5+
(опять чуть не забыл ввести Captcha)
Здесь уже разные наборы требований — чтобы светило или чтобы светило и при том было эстетично.
С точки зрения надежности, имхо (?) открытая проводка на фарфоровых изоляторах лучше. И вместо турецких включателей — советские ПЕРЕключатели, которые поворачиваются. Я такой софт больше люблю, хотя… GUI… даже в линуксе как-то больше нравится… время экономит 🙂
так в том и суть. К любому продукту или решению всегда явно или неявно предъявляются требования чтобы светило и при этом соответствовало еще куче требований. То есть голый функционал + еще много-много всего. Много-много всего нужно, потому что функционал ,как правило, нужен не сам по себе, а как элемент вышестоящих технологических и бизнес процессов. И реализация функционала должна реализацию этих вышестоящих процессов улучшать, а не ухудшать. Это самое трудное для понимания. Само много-много определяется конкретными условиями эксплуатации. Например открытая проводка в смысле надежности конечно не лучше замурованной. Значительно хуже в плане пожаробезопасности(кстати проводка в пустотных перекрытиях типа гипсокартонных стен или за подвесными потолками тоже по сути открытая). Сейчас на фарфоровые изоляторы изолированные провода уже не кладут, а вот укладка в металлические лотки — сплошь и рядом и на производстве и в торговых центрах. Почему так делают? Потому что например для супермаркета недопустим простой из-за отсутствия освещения или питания холодильников — убытки большие. В большинстве случаев даже искать обрыв не станут, а просто по лоткам протянут новый кабель. Получается ремонтопригоднее и модернизируемее, а вопросы пожарной и электробезопасности там решаются пожарной сигнализацией, круглосуточной охраной и негорючим материалом лотка. Вот и почувствуйте разницу. С точки зрения технаря вопрос как подвести напряжение из точки А в точку Б — бросить кабель. С точки же зрения техпроцесса в магазине нужна система электроснабжения(а не просто электричество), в которую помимо кабелей входят: лотки, распредкоробки и промежуточные щитки, вводно-распределительное устройство со счетчиком, автоматы защиты, УЗО, подвесы, розетки, выключатели и контакторы + должностные инструкции охраны, запрещающие доступ к щиткам и лоткам неавторизованному персоналу 🙂 . + схема всего этого, чтобы электрики могли ремонтировать, ЗИП и инструменты, чтобы могли ремонтировать. Заметьте, про эстетичность еще речи не было 😉 . Для квартиры же намного безопаснее проводку замуровать в стену — и пожаробезопаснее и электробезопаснее.
Ясное дело, функционал должен улушать, к примеру, документооборот — если он есть. А то ж обычно если он и есть, то очень уж неэффективный. Или неприспособленный к автоматизации, ибо древний 🙂
Насчет замуровать в стену… Замуровали тут одни гении недавно металлопластиковые шланги в стену, под плитку, их прорвало, затопило через щели между перекрытиями энное количество электрощитков — история из жизни, потом ждали полсуток, пока автоматы просохнут.
Пришлые сантехники-аварийщики сказали «а вот нам директор запрещает металлопласт ставить, ненадежно».
Так что мнения разные бывают.
Новый кабель? Ок, не забыли бы вот только старый отключить…