Здравствуйте, msk78, Вы писали:
M>Здравствуйте, The Lex, Вы писали:
M>Именно итеративные подходы советуют сдавать часть функционала, если вы не успеваеете. Чтобы не получилось так, что вы часть функционала сдать по-просту не можете, потому что продукт будет не пригодным к использованию (например, машина без руля), необходимо общаться с заказчиком, выяснять основной функцианал. Причём, действительно основной, а не так, что "серая звёздочка по центру — must be. (А у представителя заказчика в подсознании "трусики жены напоминает")" M>Надо уметь работать с заказчиком, договариваться...
Хм. С этим кто спорит? Я с этим спорю? Да, я прекрасно понимаю (причем на практике), что выпустить что-то работающее и таки выполняющее ряд основных задач своего пользователя — это лучше, чем не выпустить ничего или "выпустить ничего". Но только вот ты правильно написал и я еще раз повторюсь: решать это исключительно _заказчику_.
А описанный тобой подход говорит не о продукте — как рыночной единице — а именно о продукте, как системе — наборе функций-функционала. И здесь правило — в каждой итерации выдавать готовые фичи. К общему продукту как он есть-будет представлен на рынке это относится лишь косвенно. А если не успеваем все — то да, договариваться с заказчиком.
И если заказчик сказал "серая звёздочка по центру — must be" — не умничаем, а делаем, сколь бы это ни напоминало бы "в подсознании трусики жены". Потому что программисты — а особенно это относится к русским программистам — они, сцуко, умные! Они лучше знают, что для _продукта_ заказчика главное, а что — можно отложить на потом, да и вообще не делать, а убедить (задолбать, ага) заказчика, что это все ему на самом деле совершенно не нужно. Это, товарищи, суровая правда жизни с нашими программистами.
M>Хороший пример есть в книжке Кента Бека про космопорт на примере продажы билетов.
Я предлагаю разделить создание объектов единичных — вроде разработки-доработки-внедрения CRT систем — и создание продуктов массовых, конкурирующих на рынке с массой аналогичных, вроде читалок и ай-падов. Иначе мы говорим о разных сущностях.
M>Функционал вполне конкретный — читалка, а не 20% разного. Качественный плэер в ридере для людей — второе. А ежели ридер не выполняет по-человечески базовой функциональности, то это, мягко говоря, плохо.
Это потому, что ты оцениваешь, ориентируясь на "космопорт". Космопорт — он один и конкурентов у него вообще нет — его важно именно вообще запустить и чтобы он пусть с некими огрехами и отсутствием бара и цитрусовых в холле выполнял свою самую главную функцию. И даже билеты для начала можно через интернет продавать.
С ридером-читалкой такой "пардон" не пройдет — покупать или не покупать ридер-читалку человек решает в течение буквально пары минут: в табличке сравнил набор функций и стоимость, примерно заценил внешний вид — и пошел выписывать чек. Все. Рынок там оборачивается гораздо быстрее, чем в случае космопорта и пр. В случае с ридером-читалкой пока мы выпустим весь функционал — вообще мода на эти ридеры-читалки давно пройдет и уже надо будет выпускать ридеры-листалки.
M>Прототипом для статейки были Оникс Букс и Иривер Стори. Букса уже нет на полках. Смели всю партию в МСк и СПб. Народ требует. Show must go on. M>Иривер до сих пор лежит, хотя время выхода продуктов приблизительно одно.
Я не в курсе — ты о чем?
M>Почему? Да, потому что читалка Оникс выполняет свои прямые функции и выполняет их хорошо. Основные нарекания к ней — к побочному функционалу. M>Иривер Стори — совсем другая история Хают как раз-таки исключительно глюкавый основной функционал — чтение и, как следствие, книга, подчёркиваю, книга, слабо пригодна для чтения. Народ берёт, да, но не так интенсивно.
Имеем два продукта, оба с полным функционалом не успевшие к своему выпуску, но не успевшие с разными подходами. Я где-то спорил, что между продуктами с глюкавым основным функционалом и с глюкавыми или отсутствующими фичами покупатель выберет таки второй?
M>Вы для чего покупаете книгу? Лазить в и-нете или слушать музыку? Читать, конечно же! Так что Iriver Story, Reading — failed.
M>И, да, кстати говоря, 80% пользователей как раз-таки предпочтут брать классную читалку, чем ждать рюшечек-игрушечек с кривым базовым функционалом (see Оникс Букс zum Beispiel). Полный функционал ждут в основном гики.
Ты сам работал с продуктами — с выпуском и с конкуренцией с десятком точно таких же "классных читалок"? Ну чтобы придумать, как сделать так, чтобы именно твою читалку купили как минимум 10% пользователей, а еще лучше — чтобы твою читалку покупали чаще, чем другие? Это при том, что основной функционал у них — туп как дерево и за год истории существования этих читалок выточен до идеала. Усложню задачу: мы выпустили отличную читалку — нас покупают! Классно! Но прошел год — надо обновлять линейку продуктов, потому что конкуренты не спят — вон, доделали таки свой плеер в своей читалке и теперь мы точно знаем выйдут на рынок с _новым_ (обновленным — не суть важно) продуктом. И теперь нам надо сделать тот самый десерт, о котором говорилось в "гастрономической аналогии". Потому что "кормят" везде одинаково — потому что за это время все научились отлично жарить картошку фри и печь блинчики. И чтобы победить в этой борьбе — а это только кажется что везде идилия — надо иметь изюминку.
Пример? Ну тот же Apple.
Другой пример? Нетбуки. Что с того, что мы сейчас можем сделать любой нетбук с любым неглючным функционалом? Они уже никому не нужны — поезд продуктового рынка ушел — это вам не космопорт.
Это, конечно, если мы обсуждаем конкретно продуктовый рынок, а не обычных сферических коней в вакууме.
Здравствуйте, msk78, Вы писали:
G>>Не факт. Это только риск потери клиентов. Посмотрите на Apple, сколько клиентов они потеряли из-за того что iPhone не умет WiFi (появился только в 3Gs)?
M>Спасибо. Эппл в этом плане отличный пример.
Apple в этом плане еще и отличный пример того, что на этом рынке важен именно полный заявленный функционал. Потому что конкурентов — море — и к моменту, когда Apple доделает 3G, уже появится куча клонов с _большей_ функциональностью. Корявоватых, не столь стильных, не таких крутых — пусть Apple все равно будет лучшим, но момент первенства будет утерян.
ЗЫ: хотя в данном вопросе — Apple iPad — имхо, будет утерян весь свежевыдуманый сегмент рынка, поскольку уже сейчас видно, что пользователям кроме фанатов трудновато "заценить" "тот же айфон — только большой".
ЗЫ: а вот успел бы Apple к сроку выпуска — +$50 за Wi-Fi и +$100 за 3G на каждой проданной единице — сколько денег потеряно! Да, товарищи, это совершенно реальные деньги — ибо за космопорт все равно заплатят — сегодня, завтра, через год — а эти деньги компания уже не получит никогда.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
G>>Открою тайну, продажи продукта зависят в большей степени от маркетологов, а не от качества продукта.
F>наличие продаж зависит от маркетинга.. а вот количество продаж уже от качества продукта.. F>в качестве примера выступает тот же apple..
Неверно. На надо спорить с фактами.
Здравствуйте, gandjustas, Вы писали:
G>>>Открою тайну, продажи продукта зависят в большей степени от маркетологов, а не от качества продукта. F>>наличие продаж зависит от маркетинга.. а вот количество продаж уже от качества продукта.. F>>в качестве примера выступает тот же apple.. G>Неверно. На надо спорить с фактами.
До программистов ещё дело не дошло. Я пробовал выразить иную мысль. Ведать не сильно удачно.
Попытаюсь иначе
В долгой беседе исполнителя и заказчика (как правило представителя заказчика), заказчик говорит, например: "DJVu формат — обязательно должен быть, это для нас важно". Но в действительности таких "очень важно для нас" вы на протяжении беседы с заказчиком упомянули уже очень много. И "плэер очень важен для нас" (жена босса любит), и меню в клеточку "очень важно" и т.д.
В этих "очень важно(must-be)" перемешано всё, начиная от действительно необходимого функционала, без которого нельзя и кончая второстепенным, всякие звёздочки, плэеры...
Так вот наша задача, не быть пассивным перед заказчиком, а пытать его, выяснять, быть дотошным, любопытным.
Наши же эффективные менеджеры в своём большинстве просто слепо следуют тому, что говорит заказчик, не пытаясь вникнуть в его бизнес-процесс.
Как следствие, может быть приблизительно следующее:
Выходит продукт.
А заказчик вам говорит: "#$%@$, почему нет поддержки FB2!!! Без этого формата это просто груда железа! Я же вам говорил!"
Вы: Ну, мы сделали важные фичи... ДэЖаВю...
Заказчик: Мля, Вы же не спросили! Я бы вам сказал, что да, ДэЖаВю важная и звёздочка в полэкрана важна! Но воспроизведение FB2 — это всё. Я думал, вы это понимаете и без меня!!!
Программисты — непосредственные исполнители. Они ничего не решают. Решаете вы, как руководитель...
ДОВЕСОК
Поэтому, если заказчик занимается нефтью и при этом требует в приложении кнопку в полэкрана с надписью "Сиськи", то имеет смысл насторожиться и переспросить, выяснить зачем, как это влияет на его бизнес-процесс.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
G>>>>Открою тайну, продажи продукта зависят в большей степени от маркетологов, а не от качества продукта. F>>>наличие продаж зависит от маркетинга.. а вот количество продаж уже от качества продукта.. F>>>в качестве примера выступает тот же apple.. G>>Неверно. На надо спорить с фактами.
F>ты просто уделал меня аргументами..
Бывает. Честно говоря не кайф сейчас описывать кучу жизненных ситуаций, где стараниями маркетологов впихивалось барахло вместо качественного продукта.
Кроме того я сейчас волей случая имею отношение к продажам и маркетингу и уже отлично усвоил что не в качестве продуктов дело.
Качество должно быть не ниже определенного уровня и набор фич не должен быть меньше минимально необходимого.
Я тут слегка перекомпоновал...
M>Программисты — непосредственные исполнители. Они ничего не решают. Решаете вы, как руководитель...
Абизянки. Знаю я — еще бы и не умничали столько.
M>Так вот наша задача, не быть пассивным перед заказчиком, а пытать его, выяснять, быть дотошным, любопытным. M>Наши же эффективные менеджеры в своём большинстве просто слепо следуют тому, что говорит заказчик, не пытаясь вникнуть в его бизнес-процесс.
M>ДОВЕСОК M>Поэтому, если заказчик занимается нефтью и при этом требует в приложении кнопку в полэкрана с надписью "Сиськи", то имеет смысл насторожиться и переспросить, выяснить зачем, как это влияет на его бизнес-процесс.
Ты говоришь о заказчике, который занимается нефтью — у которого бизнес-процесс — нефть. Ты делаешь далекоидущие выводы, что мол на "сиськи" имеет смысл насторожиться, а это не так. Более того: в случае заказчика с бизнес-процессом "нефть" мы снова возвращаемся к реализации "чего-то для решения задач в бизнес-процессе" — это _не_ продукты, о которых говорю я. В моем случае твое "вникнуть в бизнес-процесс заказчика" — задача фактически _не_ реализуемая, ибо это вообще не нашего ума дело, а у заказчика этим делом занимается маркетинговый отдел, отдел продаж, рекламный отдел, отдел по связям с общественность, и еще куча народу, которые по бюджету — гы-гы-гы! — многократно превышают наш с тобой, выделенный на нас, программистов, на разработку продукта. Точнее не так — на _нашу_ часть разработки продукта. Ибо "продукт" — тот, о котором говорю я, а не на который обратно сворачиваешь ты — это нечто гораздо большее, чем то, что мы видим с точки зрения программистов и даже с точки зрения конкретных потребителей, купивших уже готовое "нечто".
Очень-очень-очень смело — и глупо — брать на себя ответственность "насторожиться при виде сисек и выяснить зачем". Не выясним — ответ "так надо!" вполне удовлетворителен и даже более чем хорош. Бороться с этим — бессмысленно.
M>В долгой беседе исполнителя и заказчика (как правило представителя заказчика), заказчик говорит, например: "DJVu формат — обязательно должен быть, это для нас важно". Но в действительности таких "очень важно для нас" вы на протяжении беседы с заказчиком упомянули уже очень много. И "плэер очень важен для нас" (жена босса любит), и меню в клеточку "очень важно" и т.д.
И это все вот совершенно тупо и четко даже не "очень важно", а просто именно в таком количестве и должно быть.
M>В этих "очень важно(must-be)" перемешано всё, начиная от действительно необходимого функционала, без которого нельзя и кончая второстепенным, всякие звёздочки, плэеры...
Если мы столь круты, чтобы решать или хотя бы предполагать что именно "действительно необходимого функционала, без которого нельзя", а что — "второстепенным, всякие звёздочки, плэеры" — мы находимся не на своем месте и нам надо идти в продакт-манагеры. Там и з/п чуть повыше, и карьерная лестница подлиннее — можно дорасти до продакт-директора, а там и до Самого Главного Директора рукой подать. А мы — программисты. Нам сказали — мы делаем. Это все.
Что будет, если у меня, заказчика, исполнитель начнет выяснять "что важно, а что — второстепенно"? Я тут же насторожусь и поинтересуюсь _его_ бизнес-процессами и на кой ляд ему эта информация. Потому как — ну так уж случилось — я сам вырос из программистов и точно знаю, что все эти "важно — не важно" выясняются с одной целью: чего-то не успеть. А зачем мне такие программисты, которые начинают проект, закладывая в него уже сразу же, что они в полном объеме его не успеют?
От программистов ответы простые и короткие: сроки и бюджет. Все. "Торговаться фичами" можно только на уровне продакт-манагеров: на совещании всех отделов по данному продукту мы решаем первостепенность фич и на основании полученных от программистов сроков именно _мы_ решаем, какие фичи заказать чтобы успеть к намеченному сроку выпуска продукта, а от каких вероятнее всего отказаться вообще. А здесь читаем внимательно: при этом еще и уменьшив расходную часть бюджета, рассчитанную на программистов!
А вот если программисты озвучили бюджет и начинают "выяснять приоритеность фич" с заказчиком... Не смешите мои тапочки! Брать лопатку и по ... таких программистов — с ними все равно только мозги ..., бизнес не сделаешь, деньги потеряешь, продукт не выпустишь, рынок упустишь, и еще много чего "не".
Я понятно объясняю?
M>Как следствие, может быть приблизительно следующее: M>Выходит продукт. M>А заказчик вам говорит: "#$%@$, почему нет поддержки FB2!!! Без этого формата это просто груда железа! Я же вам говорил!" M>Вы: Ну, мы сделали важные фичи... ДэЖаВю... M>Заказчик: Мля, Вы же не спросили! Я бы вам сказал, что да, ДэЖаВю важная и звёздочка в полэкрана важна! Но воспроизведение FB2 — это всё. Я думал, вы это понимаете и без меня!!!
Честно? Простите за выражение, срать.
Есть контракт — в котором перечислены все фичи, которые нужно было реализовать. Программисты под ним подписались. И не успели. По контракту есть неустойки. По бизнесу есть потеря репутации. В любом случае такие программисты благополучно вылетают в трубу.
Я знаю что я как бы идеалист и на самом деле как раз программисты все равно остаются. Потому что они-то как раз ни за что и не отвечают.
Здравствуйте, msk78, Вы писали:
M>Как же работает программная индустрия во всём мире сегодня? M>Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach).
Как интересно. А откуда дровишки-то?
Ты, наверное, серьезное и статистически достоверное исследование провел на тему — "как в действительности работает программная индустрия во всем мире, что бы не заявляли пиарщики", да?
Или, может быть, тебе было видение свыше на эту тему?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, msk78, Вы писали:
M>>Как же работает программная индустрия во всём мире сегодня? M>>Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach).
G>Как интересно. А откуда дровишки-то?
G>Ты, наверное, серьезное и статистически достоверное исследование провел на тему — "как в действительности работает программная индустрия во всем мире, что бы не заявляли пиарщики", да?
G>Или, может быть, тебе было видение свыше на эту тему?
Здравствуйте, Gaperton, Вы писали:
G>Второй, "военный", имеющий мало общего с первым, — это то, что получилось в результате бурления говн^D^D^D... брожения умов в американском department of defence, который придумал первый стандарт на процесс разработки ПО, по которому, по слухам, надо было все выполнять в один заход, и которого из ныне живущих толком никто не видел, и никто по нем не работал.
Здравствуйте, A.Lokotkov, Вы писали:
G>>Второй, "военный", имеющий мало общего с первым, — это то, что получилось в результате бурления говн^D^D^D... брожения умов в американском department of defence, который придумал первый стандарт на процесс разработки ПО, по которому, по слухам, надо было все выполнять в один заход, и которого из ныне живущих толком никто не видел, и никто по нем не работал.
AL>Для шатлов и прочего fly-by-wire, по слухам, до сих пор так работают (плюс статья от 1984 г, 1.6MB).
Рискну предположить, что там итерации крутить с демонстрациями заказчику — дороговато выйдет .
А если серьезно — софт для таких систем строго говоря "софтом" в привычном понимании не является — это часть программно-аппаратного комплекса. Причем, по своим свойствам — это больше "хард", чем "софт".
К примеру. В декабре 2009 года мы вдвоем с одним из программистов заколбасили первичный загрузчик для ARM, который пойдет в микросхему в масочный ROM. Это простая программа на С. Масочный ROM называется так потому, что его содержимое задается масками, и он является таким образом частью топологии микросхемы. В частности — его невозможно изменить в уже произведенных микросхемах, и дорого менять — для этого надо будет перевыпустить часть масок.
Поэтому, в нем ошибок, так же как в аппаратуре, быть не должно. И он был накрыт тестами по всей науке, и верифицирован на модели микросемы, вместе с железом.
Вопрос, достойный "философии программирования". Этот загрузчик на С, это что — софт или хард?
Здравствуйте, Gaperton, Вы писали: G>Поэтому, в нем ошибок, так же как в аппаратуре, быть не должно. И он был накрыт тестами по всей науке, и верифицирован на модели микросемы, вместе с железом.
Штоб я так гражданский софт верифицировал — проще об стену убиться. Тест-план составлял методом white-box, на основе анализа cyclomatic complexity, плюс — составлением и анализом формальных спецификаций. Это несложно, но трудоемко, и высысывает мозг напрочь.
Это нифига не софт, короче. Его менять нельзя, так же, как и хард.
Здравствуйте, Gaperton, Вы писали:
G>Поэтому, в нем ошибок, так же как в аппаратуре, быть не должно. И он был накрыт тестами по всей науке, и верифицирован на модели микросемы, вместе с железом. G>Вопрос, достойный "философии программирования". Этот загрузчик на С, это что — софт или хард?
Все, что сделано на кристалле, вроде бы является хардом (или firm-ом). Однако:
1. Некоторое время назад почти все ПЗУ были, условно говоря, масочными, поэтому обновлять софт было либо очень дорогим удовольствием, либо вообще невозможно, тем более "на лету".
2. Софт и хард тогда сами по себе были очень дорогими штуками. Поэтому далеко не всякий мог себе позволить говно-автоматизацию или три-четыре десятка микропроцессорных систем на борт. А уж если и позволял, то наличие багов и недофич контрактом не подразумевалось. При этом недофичи и баги софта на уровне пользователя практически вообще не отделялись от общесистемных.
Ну, и можно было бы далее развить эти тезисы и придти к оптимистическому (для индусов и китайцев) и печальному (для остальных) выводу: софт и хард становятся все более и более "мягкими", world's gone wrong и армагеддон близок. Только мне неохота и некогда -- надо перепиливать кривой индусский говнокод, криво работающий на кривой китайской железке.
P.S. Под "индусами" и "китайцами" подразумеваются определенные типы разработчиков софта и железа, абсолютно вне национальной принадлежности.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Ну, и можно было бы далее развить эти тезисы и придти к оптимистическому (для индусов и китайцев) и печальному (для остальных) выводу: софт и хард становятся все более и более "мягкими", world's gone wrong и армагеддон близок. Только мне неохота и некогда -- надо перепиливать кривой индусский говнокод, криво работающий на кривой китайской железке.
Ну, скажем так. Все смешалось в современном мире.
ПЛИСы — это такой хард, который по всем признакам неотличим от "софта". Прошивку ПЛИС можно почти всегда обновить (если это не Antifuse ПЛИС, который шьется один раз, или что-то подобное).
Микрокод — это тоже "хард", который более похож на софт.
Масочное ПЗУ (так же как OTP ROM, однократно программируемое) — это такой софт, который обладает всеми признаками "харда".
И. Если софт является частью высоконадежного программно-аппаратного комплекса, обновление софта к которому невозможно или затруднено — то весь комплекс, включая софт, обладает признаками "харда".
Отсюда натуральная разница в процессе разработки. Как только у нас высокая цена ошибки + затруднения в ее исправлении пост фактум — мы имеем скорее "хард", чем софт, и начинает рулить ватерфолоподобный PSP/TSP, с его фокусом на обеспечении качества. Ничего лучше человечество для таких ситуаций не придумало. Плюс подход а-ля Эрланг/OTP в архитектуре, рассчитанный на работу в присутствии ошибок — let it crash и прочие прелести.
Здравствуйте, Gaperton, Вы писали:
G>Это на самом деле огромный контраст в сравнении...
...с вебсайтами и онлайн-сервисами, которые всегда в состоянии "бета", и это совершенно нормально и правильно.
Здравствуйте, msk78, Вы писали:
M>Сроки сдачи софта (Народное творчество )
M>[Ругать написанное бессмысленно]
Типа, тебя всё равно ничего не проймёт?
M>[Критика, мнения приветствуются]
Сейчас будет.
M>Заинтересовался недавно покупкой электронной читалки. Начал штудировать мегабайтные фолианты отзывов. M>Читал в основном плохие отзывы и смотрел на соотношение плохих и хороших. Народ хает в целом всё равномерно, но. M>Основные нарекания в основном касаются софта. Народ больше всего хает глюкавое и сырое программное обеспечение.
M>Ежели функциональность прошивки гаджета мала, но стабильна, разработчик регулярно выпускает обновления, то народ пишет что-то в стиле "да, функциональность слабовата, но апдэйты выходят регулярно, надо брать. Скоро уберут все недостатки. Жди новой прошивки через неделю...". M>Народ в данном случае чувствует себя защищённым и такой товар сметает с полок.
По-моему, ты описываешь поведение людей, которым нечем заняться, кроме как качать прошивки. Единственно, от чего они защищаются — от чувства бессмысленности своего существования. Потому из двух кривых продуктов они выбирает кривой продукт, который требует постоянного к себе внимания. Кому — тамагоччи, кому — прошивки.
Думаю, что маркетологи прекрасно понимают этот аспект человеческого поведения, потому, вероятнее всего, сознательно проводят политику "непрерывных обновлений". В принципе, не-маркетологам это тоже хорошо известно.
M>Как же работает программная индустрия во всём мире сегодня?
А потом из поведения этой группы людей ты пытаешься делать глобальные индукции. Правомерность таких индукций настолько эфемерна, что опровергать по пунктам не вижу никакого смысла.
M>Чтобы не заявляли пиарщики [... скип всё ...] они твердят как мантру "срок, срок, срок...".
Кстати, (как это ни странно) именно упомянутая тобой группа как раз твердит это самое "срок, срок, срок": "регулярно выпускает обновления", "скоро уберут все недостатки", "жди... через неделю". Символы временных отсчётов тебе подчеркнуть или сам найдёшь?
P.S.: Между прочим замечу, что я здесь опираюсь не на первичные цитаты, а на твой пересказ. Задумайся над этим.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: О сроках сдачи софта
От:
Аноним
Дата:
09.04.10 22:31
Оценка:
G>Не факт. Это только риск потери клиентов. Посмотрите на Apple, сколько клиентов они потеряли из-за того что iPhone не умет WiFi (появился только в 3Gs)?
Здравствуйте, Аноним, Вы писали:
G>>Не факт. Это только риск потери клиентов. Посмотрите на Apple, сколько клиентов они потеряли из-за того что iPhone не умет WiFi (появился только в 3Gs)?
А>Прежде чем заявлять такую ерунду попробовали может быть погуглить? Например http://answers.yahoo.com/question/index?qid=20080923152002AALVUy8
А все повелись
Я WiFi с блютусом перепутал. Нету у iPhone нормальной поддержки голубого зуба, а WiFi просто глючит.
Имеем два продукта, оба с полным функционалом не успевшие к своему выпуску, но не успевшие с разными подходами. Я где-то спорил, что между продуктами с глюкавым основным функционалом и с глюкавыми или отсутствующими фичами покупатель выберет таки второй? 
