Здравствуйте, Слава Шевцов, Вы писали:
СШ>Олег, сколько стоит твоё время как разработчика и сколько стоит время парня из глубинки?
Не доверяю я парням из глубинки. Чем проще задача, тем больше неквалифицированых специалистов на нее претендуют. А это себе дороже --- код же прийдется и сопровождать? Я готов вынести на рентакодер сложные части проекта, с которыми лично я не сталкивался, если это будет хотя бы частично законченое решение. Один мой проект с рентакодера до сих пор на суппорте, раз в месяц возникает задача что-то приписать. Для меня это полчаса, а для другого?
СШ>>> Кроме того, два человека быстрее разработают проект чем один. Не год, а половина.
GPF>>А 12 человек напишут за месяц? Слава, Вы у кого математике учились? Явно не у Брукса
СШ>А причём тут Брукс? Брукс рассматривал вариант, когда одинаковые уже обученные программисты решают однотипные задачи. То есть они в принципе взаимозаменимы. Плюс рассматривал время на коммуникации как отягчающий фактор, который замедляет процесс разработки комманды.
Перечитайте книгу, Слава Коммуникации убивают половину проектов. А аутсорсинг самый что ни на есть классический пример испорченного телефона.
Даже при предложенной Вами схеме, где есть управляющий центр, который руководит 3-мя программистами, а сами программисты с собой не общаются
Ц а не Ц
/ | \ / | \
П П П П - П - П
затраты на коммуникации будут такими огромными, что проект скорее всего потонет. И уж точно он потонет, если человек будет при этом работать на другой работе.
СШ>У нас другая история: есть продукт, который состоит из деталей, которыми один программист обычно не владеет. А вот два или три уже владеют. Поэтому если продуктом занимается один человек, то мы должны учитывать время обучения для того, чтобы создать часть функционала. Если продуктом занимаются два/три человека, то вопрос обучения часто отпадает — мы заранее можем так подобрать людей, чтобы они уже всё нужное умели и друг друга не знали: исключаем клонирование.
СШ>Это как крупные игрушки создают: один пишет музыку, другой графику, третий движок. И втроём они создадут игрушку за меньшее количество человеко-часов, чем один человек.
Угу... один программист пишет музыку, другой рисует спрайты. Игра обречена на "успех".
И как таким чудесным образом мы избежим клонирования? Человек который написал весь код не сможет купить графику и музыку?
СШ>Брукс в играх и в шароваре отдыхает.
Брукс разбирается в управлении софтверными проектами. Если Вы считаете, что написание крупной игрушки или серъезной шаровары сильно отличается от того, что говорит Брукс, я бы порекомендовал Вам, Слава, пойти поработать на дядю понабраться опыта управления серъезными проектами.
GPF>>Слава, Вы когда нибудь подтирали задницу за другим программистом? А за дешевым программистом?
СШ>А Вы когда-нидудь имели возможность проводить code review до оплаты? И возможность отказать в оплате до приведения кода к Вашим стандартам? А ведь именно это и возможно на моём сервисе. И это избавляет умных людей от плохого кода.
Дисциплинированные программисты, следующие стандартам кодирования сидят по дядям. В аутсорс (как правило идут люди горячие, и заставить их следовать требованиям большая проблема.
Слава, Вы думаете, что потратив месяц на разработку и отказавшись заплатить программисту, я не потеряю 50-150% от этих денег? Вы слишком мало цените месяц человека который стартует бизнес. А Вы можете гарантировать, что мне не придется отказаться от второго программиста, третьего?
СШ>>>До этого код должен лечь в Роспатент. А после создания клона в милицию должна лечь заявка о нарушении УК. И никаких проблем.
GPF>>Все еще укладываемся в 300-500 баксов?
СШ>500 р. на Роспатент жалко?
Сорри. Некомпетентен
СШ>>>И что разработка для шароварщика это непрофильная деятельность. А всё непрофильное должно быть на аутсорсе.
GPF>>Непрофильная деятельность для шароварщика — слона мыть. Все что касается его бизнеса (разработка в том числе) есть профильная деятельность.
СШ>Тогда зачем отдавать сабмит на аутсорс Руденко?
А с чего Вы решили, что профильность\непрофильность как-то коррелирует с необходимостью отдавать на аутсорс?
Здравствуйте, savaDAN, Вы писали:
Y>>улыбнуло. Y>>опыт работы на дядю необходим разве что только для дальнейшей работы на дядю, вот и все.
DAN>без опыта работы на дядю велик риск что о многих технологиях разработки ПО вы никогда не узнаете и будете писать программы на коленке,
а большинство програм шароварщиков и написаны на коленке
DAN> теряя продажи из-за большого количества багов, низкой скорости разработки и высокой стоимости развития приложения.
совсем необязательно. можно иметь опыт работы на дядю и писать глючные и тормозные программы. легко.
DAN>PS: книжки-книжками,
про книжки я вообще ничего не говорил.
DAN>но во-первых, надо знать что читать, во-вторых, все тонкости понять можно только вживую.
ну и как работа на дядю поможет понять тонкости шароварного предпринимательства?
DAN>>Иначе я могу сказать что без результата и денег можно остаться и работая по алгоритму предложенному Славой выше, Y>элементарно
И? какой практический смысл для беседующих и общественности будут нести эти фразы? только трафик подымать.
DAN>>без опыта работы на дядю велик риск что о многих технологиях разработки ПО вы никогда не узнаете и будете писать программы на коленке, Y>а большинство програм шароварщиков и написаны на коленке
Ага, поэтому большинство шароварок и пылятся на сайтах с продажами раз в год.
DAN>>PS: книжки-книжками, Y>про книжки я вообще ничего не говорил.
Это альтернативный источник знаний. у читающего предыдущий пост наверняка возникнет вопрос "а как же книжки?".
DAN>>но во-первых, надо знать что читать, во-вторых, все тонкости понять можно только вживую. Y>ну и как работа на дядю поможет понять тонкости шароварного предпринимательства?
Работа на дядю научит разрабатывать ПО наиболее эффективно и с наименьшими затратами, т.е. сделает вас более конкурентноспособным на рынке наколеночных шароварщиков.
Для тех кто считает что в шароварном бизнесе главное маркетинг — лучше идти работать в МЛМ. там будет лучше получаться.
Недавно человек постил историю своей шароварки в которой очень правильно сказал "не продавалось потому что продукт был плохой, как стал хороший — начало продаватся".
Маркетинг несомненно необходим хорошему продукту, но плохому продукту он врядли _сильно_ поможет.
PS: все вышесказанное мое ИМХО, священных войн, пожалуйста, затевать не надо.
СШ>А если совсем серьёзно, то может стоит задуматься над тем, что простой банковский программист с его $1500 в месяц сейчас способен без отрыва от основной работы организовать и профинансировать из части своей зарплаты личный шароварный бизнес?
Ты абсолютно прав.
[offtop]
Слава, слушай а можешь ты сделать опционально будут ли биды других видны или, как на ренте. Решает заказчик. Ы
[/offtop]
прошу прощения, не заметил этого ответа, пишу отдельное сообщение.
DAN>> теряя продажи из-за большого количества багов, низкой скорости разработки и высокой стоимости развития приложения. Y>совсем необязательно. можно иметь опыт работы на дядю и писать глючные и тормозные программы. легко.
можно. с дуру и ото-самое сломать можно, гласит народная мудрость.
Скажите пожалуйста, означает ли это что, _не_ поработав на дядю, программы у этого гипотетического шароварщика будут более быстрые и безглючные? Смею утверждать, что, не имея вообще никаких знаний об индустрии ПО, этот самый шароварщик не напишет вообще никаких програм, ни глючных не тормозных. проект просто рухнет
Хм, в этом плане ваше утверждение с точки зрения рынка верно: не стоит работать на дядю! Не стоит читать книжек по разработке ПО! Талантище пробьет себе дорогу и так и ценой нечеловеческих усилий и изобретения паттернов заново напишет таки хорошее шароваренье, а посредственность не напишет вообще ничего, тем самым избавив рынок от обилия никому не нужных полупрограмм
Здравствуйте, savaDAN, Вы писали:
DAN>>>Иначе я могу сказать что без результата и денег можно остаться и работая по алгоритму предложенному Славой выше, Y>>элементарно DAN>И? какой практический смысл для беседующих и общественности будут нести эти фразы? только трафик подымать.
Здравствуйте, savaDAN, Вы писали:
DAN>>>без опыта работы на дядю велик риск что о многих технологиях разработки ПО вы никогда не узнаете и будете писать программы на коленке, Y>>а большинство програм шароварщиков и написаны на коленке DAN>Ага, поэтому большинство шароварок и пылятся на сайтах с продажами раз в год.
это всего лишь слова.
DAN>>>но во-первых, надо знать что читать, во-вторых, все тонкости понять можно только вживую. Y>>ну и как работа на дядю поможет понять тонкости шароварного предпринимательства? DAN>Работа на дядю научит разрабатывать ПО наиболее эффективно и с наименьшими затратами, т.е. сделает вас более конкурентноспособным на рынке наколеночных шароварщиков.
а зачем мне конкурировать с другими шароварщиками? мне нужно сделать продукт, который будет продаваться. как сделать — на коленке или следуя каким-то супер-методикам не суть важно.
DAN>Для тех кто считает что в шароварном бизнесе главное маркетинг — лучше идти работать в МЛМ. там будет лучше получаться.
МЛМ непосредственно не занимался, но в свое время очень интересовался и с МЛМ знаком хорошо, а вот кто-то налево и направо раздающий советы как быть и что делать похоже не очень, иначе так бы не заявлял.
DAN>Недавно человек постил историю своей шароварки в которой очень правильно сказал "не продавалось потому что продукт был плохой, как стал хороший — начало продаватся". DAN>Маркетинг несомненно необходим хорошему продукту, но плохому продукту он врядли _сильно_ поможет.
похоже кто-то запутался. анализ рынка, определенное позиционирование будущего продукта делается до начала разработок, таким образом плохой продукт — это уже результат плохого маркетинга, и сам процесс разработки здесь по значимости далеко не на первом месте.
в общем такое ощущение, что кто-то пытается доказать не то, что работа на дядю полезна для шаровары, а то, что он сам не зря на дядю горбатился
Здравствуйте, savaDAN, Вы писали:
DAN>прошу прощения, не заметил этого ответа, пишу отдельное сообщение.
DAN>>> теряя продажи из-за большого количества багов, низкой скорости разработки и высокой стоимости развития приложения. Y>>совсем необязательно. можно иметь опыт работы на дядю и писать глючные и тормозные программы. легко. DAN>можно. с дуру и ото-самое сломать можно, гласит народная мудрость. DAN>Скажите пожалуйста, означает ли это что, _не_ поработав на дядю, программы у этого гипотетического шароварщика будут более быстрые и безглючные? Смею утверждать, что, не имея вообще никаких знаний об индустрии ПО, этот самый шароварщик не напишет вообще никаких програм, ни глючных не тормозных. проект просто рухнет
ну я написал и не одну, причем не какие-то тривиальные часики или ОЕ-бекап, и чувствую себя неплохо в финансовом плане. сейчас набираю людей на полный рабочий день к себе в оффис. как я уже говорил на дядю в своей жизни я работал целый месяц, и о да! это было очень полезно! я понял, что никогда больше не стоит работать на дядю
DAN>Хм, в этом плане ваше утверждение с точки зрения рынка верно: не стоит работать на дядю! Не стоит читать книжек по разработке ПО! Талантище пробьет себе дорогу и так и ценой нечеловеческих усилий и изобретения паттернов заново напишет таки хорошее шароваренье, а посредственность не напишет вообще ничего, тем самым избавив рынок от обилия никому не нужных полупрограмм
DAN>>Ага, поэтому большинство шароварок и пылятся на сайтах с продажами раз в год. Y>это всего лишь слова.
Я регулярно пользуюсь различными шароварками и отлично вижу что большинству из них необходимы услуги а) юзабилиста, б) тестировщика. К исходному коду шароварок доступа не имею, но судя по некоторым багам (любой GPF яркий тому пример) могу косвенно судить что и с архитектурой/качеством кодирования тоже все далеко не гладко.
Шароварками этими самыми пользуюсь потому как а) не всегда хватает денег чтобы купить чего-нибудь настоящее, б)пользуюсь ими до появления конкурентов имеющих лучшее качество...
Это к вопросу о качестве.
К вопросу о "пылении" — тут по-моему и примеров никаких приводить не надо. достаточно зайти на любой сайт с коллекциями этих самых шароварок. Успешных продуктов имхо единицы.
Y>а зачем мне конкурировать с другими шароварщиками? мне нужно сделать продукт, который будет продаваться. как сделать — на коленке или следуя каким-то супер-методикам не суть важно.
Вы слишком узко понимаете слово конкуренция. Конкурировать можно например и с собой — для наколеночного продукта стоимость фикса бага будет стоить например 10 человеко/часов, для правильно задизайненного и написанного — человеко/час.
В общем в эту сторону дискуссию продолжать больше не вижу смысла, т.к. это все равно что сравнивать как лучше: пешком или на машине. Если чтобы получить удовольствие — лучше пешком: окрестности обозреваешь, мечтаешь там и все такое.. а если чтобы добраться из пункта А в пункт Б — лучше наверное на машине.
Рано или поздно в любом сегменты шаровары появится конкурент, который работая более эффективно при прочих равных вытеснит вас из рынка. смысла в том чтобы пренебрегать любым конкуретным преимуществом (будь то более эффективная разработка или маркетинг или еще чего) я не вижу.
Y>МЛМ непосредственно не занимался, но в свое время очень интересовался и с МЛМ знаком хорошо, а вот кто-то налево и направо раздающий советы как быть и что делать похоже не очень, иначе так бы не заявлял.
Про МЛМ это была шутка, извините, забыл поставить смайлик.
И советов я никаких не раздаю. что в ИТ хорошо — практически любой предмет спора можно измерить.
Кстати, что-то не вижу от вас до сих пор контраргументации, а именно: работа на дядю шароварщкику ни к чему, разрабатывать софт на коленке — rulezz!
Y>похоже кто-то запутался. анализ рынка, определенное позиционирование будущего продукта делается до начала разработок, таким образом плохой продукт — это уже результат плохого маркетинга, и сам процесс разработки здесь по значимости далеко не на первом месте.
В данном случае под плохим продуктом я понимаю прежде всего некачественный продукт (напомню: в рамках данной дискуссии я утверждаю, что применение индустриальных методик разработки ПО даже в рамках шаровары удешевляет его разработку и повышает качество).
Т.е. дерьмовая реализация даже самой отличной идеи может завалить ее на корню потому что программа которая не решает своей задачи из-за немерянного количества багов или жуткого UI считай что не программа.
Вы в свою очередь утверждаете что качество самого продукта дело десятое. Можно ли как-то обосновать ваше мнение?
Попутно, ответьте пожалуйста на вопрос: а остались ли еще в шароварении области которые заняты единственным продуктом и в которых нет конкуренции?
Y>в общем такое ощущение, что кто-то пытается доказать не то, что работа на дядю полезна для шаровары, а то, что он сам не зря на дядю горбатился
Ах оставьте... свои размышления по поводу целесообразности тех или иных поступков я не привык с кем бы то ни было обсуждать, а уж сожалеть или каким-то иным образом рефлексировать по их поводу тем более
Y>ну я написал и не одну, причем не какие-то тривиальные часики или ОЕ-бекап, и чувствую себя неплохо в финансовом плане. сейчас набираю людей на полный рабочий день к себе в оффис. как я уже говорил на дядю в своей жизни я работал целый месяц, и о да! это было очень полезно! я понял, что никогда больше не стоит работать на дядю
Чтобы продолжать дискуссию да и общественности я думаю будет интересно узнать:
0. Что это за софт собственно такой?
1. Какой софт вы используете для управления проектами (для требований, планирования, багтрекинга, хранения исходных кодов)
2. Какова примерно продуктивность по вашим проектам? Думаю достаточным будет а) размер проекта в строках кода (с указанием языка), б) количество человекочасов (суммарное) потраченное на его разработку.
3. Сколько версий продукта было выпущено.
4. Сколько дефектов (под дефектами будем считать классическое употребление этого термина — количество ошибок найденных уже после релиза продукта)
Взамен могу, например, опубликовать статистику по какому-нибудь из своих проектов (сразу говорю — я не шароварщик):
Имеем: проект на 120 тыс. строк кода, 7 релизов, время жизни с первого релиза по текущий момент — 1.5 лет, эксплуатируется достаточно широко (заказная разработка, но на крупного заказчика), количество дефектов — 4.
PS: в конечном итоге эта дискуссия может выродиться в соглашение о том что для шароварки допустимо невысокое качество... по крайней мере до тех пор пока не придет более успешный конкурент.
PPS:самое интересное у вас начнется когда вы будете разрабатывать продукты не в одиночку, а командой, а размер проекта перевалит за 100 тыс. строк кода. Вот тогда и предлагаю вернуться к дискуссии о методиках
Здравствуйте, savaDAN, Вы писали:
Y>>а зачем мне конкурировать с другими шароварщиками? мне нужно сделать продукт, который будет продаваться. как сделать — на коленке или следуя каким-то супер-методикам не суть важно. DAN>Вы слишком узко понимаете слово конкуренция. Конкурировать можно например и с собой — для наколеночного продукта стоимость фикса бага будет стоить например 10 человеко/часов, для правильно задизайненного и написанного — человеко/час. DAN>В общем в эту сторону дискуссию продолжать больше не вижу смысла, т.к. это все равно что сравнивать как лучше: пешком или на машине. Если чтобы получить удовольствие — лучше пешком: окрестности обозреваешь, мечтаешь там и все такое.. а если чтобы добраться из пункта А в пункт Б — лучше наверное на машине. DAN>Рано или поздно в любом сегменты шаровары появится конкурент, который работая более эффективно при прочих равных вытеснит вас из рынка. смысла в том чтобы пренебрегать любым конкуретным преимуществом (будь то более эффективная разработка или маркетинг или еще чего) я не вижу.
И тут Остапа понесло (с)
только что были боинги, уже едем на машине из А в Б, а нас в это время вытесняют конкуренты с рынка. честно говоря мне трудно вам отвечать, т.к. ваши посты абсолютно не тезисные, а просто обрывки случайный мыслей. сказали, что на дядю работать полезно для шаровары, так развивайте эту тему, приводите аргументы. пока я услышал лишь какие-то попытки объяснить что работая на дядю мы получаем знаниея и опыт разработки. все. только вот вы похоже не можете себе представить, что это все можно получить и в других местах.
DAN>Кстати, что-то не вижу от вас до сих пор контраргументации, а именно: работа на дядю шароварщкику ни к чему, разрабатывать софт на коленке — rulezz!
а почему я должен аргументировать? это вы высказали мысль, вот и доказывайте, что она правильная.
вот еще вопрос: как опыт подчинения защитается как опыт управления?
Y>>в общем такое ощущение, что кто-то пытается доказать не то, что работа на дядю полезна для шаровары, а то, что он сам не зря на дядю горбатился DAN>Ах оставьте... свои размышления по поводу целесообразности тех или иных поступков я не привык с кем бы то ни было обсуждать, а уж сожалеть или каким-то иным образом рефлексировать по их поводу тем более
тем не менее вы уцепились за свою бредовую идею и продолжаете ее продвигать
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[11]: Подумалось...
От:
Аноним
Дата:
29.08.05 09:34
Оценка:
Y>ну я написал и не одну, причем не какие-то тривиальные часики или ОЕ-бекап, и чувствую себя неплохо в финансовом плане. сейчас набираю людей на полный рабочий день к себе в оффис.
Yxiie, а город у вас какой — Борисполь (так, кажется)? И какие у вас зарплаты на полный рабочий день? Просто те деньги, которые для вашего города кажутся огромными, для Москвы могут оказаться копейками. И это еще одна особенность шаровары — доход как бы не зависит от города (продают практически все за границей), но в то же время место жительства шароварщика играет большую роль.
Здравствуйте, savaDAN, Вы писали:
Y>>ну я написал и не одну, причем не какие-то тривиальные часики или ОЕ-бекап, и чувствую себя неплохо в финансовом плане. сейчас набираю людей на полный рабочий день к себе в оффис. как я уже говорил на дядю в своей жизни я работал целый месяц, и о да! это было очень полезно! я понял, что никогда больше не стоит работать на дядю DAN>Чтобы продолжать дискуссию да и общественности я думаю будет интересно узнать: DAN>0. Что это за софт собственно такой? DAN>1. Какой софт вы используете для управления проектами (для требований, планирования, багтрекинга, хранения исходных кодов) DAN>2. Какова примерно продуктивность по вашим проектам? Думаю достаточным будет а) размер проекта в строках кода (с указанием языка), б) количество человекочасов (суммарное) потраченное на его разработку. DAN>3. Сколько версий продукта было выпущено. DAN>4. Сколько дефектов (под дефектами будем считать классическое употребление этого термина — количество ошибок найденных уже после релиза продукта)
вот еще чего, столько пунктов описывать, такое ощущение, что мне ТЗ подогнали
это уже на работу похоже, а я здесь отдыхаю, как не трудно заметить
лень мне описывать, скажу что все делалось лично мной по наитию
проекты можешь посмотреть на www.enkord.com
DAN>Взамен могу, например, опубликовать статистику по какому-нибудь из своих проектов (сразу говорю — я не шароварщик): DAN>Имеем: проект на 120 тыс. строк кода, 7 релизов, время жизни с первого релиза по текущий момент — 1.5 лет, эксплуатируется достаточно широко (заказная разработка, но на крупного заказчика), количество дефектов — 4.
эти цифры мне ни о чем не говорят, т.к. я не знаком с вашей спецификой
DAN>PS: в конечном итоге эта дискуссия может выродиться в соглашение о том что для шароварки допустимо невысокое качество... по крайней мере до тех пор пока не придет более успешный конкурент.
DAN>PPS:самое интересное у вас начнется когда вы будете разрабатывать продукты не в одиночку, а командой, а размер проекта перевалит за 100 тыс. строк кода. Вот тогда и предлагаю вернуться к дискуссии о методиках
опять вы тянете не туда изначально речь шла о шароварщике, и я нигде не говорил, что методики не нужны. они не нужны для одного человека.
кстати тема моей магистерской работы в универе была "Автоматизация управления проектами програмных разработок" так что не надо передо мной пальцы гнуть, я это еще в школе учил
Y>>ну я написал и не одну, причем не какие-то тривиальные часики или ОЕ-бекап, и чувствую себя неплохо в финансовом плане. сейчас набираю людей на полный рабочий день к себе в оффис.
А>Yxiie, а город у вас какой — Борисполь (так, кажется)?
Киев
А>И какие у вас зарплаты на полный рабочий день?
Обыкновенные киевские зарплаты.
А>Просто те деньги, которые для вашего города кажутся огромными, для Москвы могут оказаться копейками.
А для Нью-Йорка тем более
А>И это еще одна особенность шаровары — доход как бы не зависит от города (продают практически все за границей), но в то же время место жительства шароварщика играет большую роль.
ну посчитайте какие деньги нужны для стартапа из 5 человек — оффис, техника, зарплаты, и.т.д. думаю даже для Москвы не так уж и мало получится, хотя конечно в Москве я стартонуть не решился бы
DAN>Я регулярно пользуюсь различными шароварками и отлично вижу что большинству из них необходимы услуги а) юзабилиста, б) тестировщика. К исходному коду шароварок доступа не имею, но судя по некоторым багам (любой GPF яркий тому пример) могу косвенно судить что и с архитектурой/качеством кодирования тоже все далеко не гладко.
С таким же успехом можно сказать: "Я достаточно часто пользуюсь софтом, написанным в крупных коммерческих конторах. Глюки на глюке. Похоже, внедряли за откаты или еще не пойми за что. Если бы софт такого качества выложили как шаровару — т.е. на основе try/buy — то никто бы после trial ни за что не купил".
Пример? Да хотя бы прога для подготовки бух. данных 2-НДФЛ для сдачи в налоговую. Кто работал, тот поймет.
А еще был у меня страшный глюк с клиент-банком (тоже в крупной компании по "правильным" технологиям писанном).
Короче, ваш аргумент — это не аргумент. В "больших проектах" использование правильных технологий иногда напоминает обезьяну с гранатой (или вы только на дядю с исключительно качественными разработками работали?).
Так вот, работая на дяду, клепающего глюки, вы сами, скорее всего, вряд ли на что-то сможете повлиять — скажет дядя — надо клепать фигню за откаты, и будете клепать. А вот в качестве шароварщика выбор только за вами — что и как использовать, в какие сроки.
DAN>К вопросу о "пылении" — тут по-моему и примеров никаких приводить не надо. достаточно зайти на любой сайт с коллекциями этих самых шароварок. Успешных продуктов имхо единицы.
Если ходить по помойкам с пад-файлами, то да, а если зайти на тот же realarcade, то большинство продуктов как раз качественны.
Коммуникации убивают половину проектов. А аутсорсинг самый что ни на есть классический пример испорченного телефона.
