Безусловно, на подсознательном уровне фактор бренда оказывает какое-то влияние. Так это тоже заслуга создателей Амазона, что они построили бренд, который вызывает ассоциацию "Амазон - эталон электронной торговли".
Однако я думаю, что в данном конкретном случае, то как работает Амазон действительно оптимальное решение. Тут уже писали про реальный и идеальный мир. В идеальном мире все работает идеально, а в реальном мире правильно организованный бизнес пытается заранее продумать и корректно отработать и проблемные ситуации.
В клиентской зоне есть кнопочка отмены уже отправленного заказа. Насколько хорошо тут все работает сказать не могу, не пользовался.
Был случай, когда отправленные книжки тупо не дошли, потерялись по дороге. Переслали без проблем.
На самом деле в Амазоне и даже в Озоне, по-моему, есть рядом с товаром пометка типа - "на складе" (Амазон даже пишет, сколько штук осталось), или "ожидается, срок поставки такой-то", так что не все так плохо.
Конечно, никто не спорит, что лучше бы все что показывается в витрине, отправлялось и отгружалось без сбоев, однако ситуация, возникшая с моим заказом, достаточно типична для интернет-магазина, вопрос как ее правильно обработать. В большинстве отечественных магазинов поступят одним из следующих образов:
- (лучший случай) оператор напишет или перезвонит и скажет, что невозможно выполнить заказ полностью и спросит, что делать;
- проигнорируют заказ совсем (раз не можем его исполнить);
- отгрузят заказ частично, не проинформировав покупателя;
- запихают в заказ что-то похожее на отсутствующий товар
точно, вы правы, это ж Америка :)
но мне бы и до 10 сентября ждать не хотелось
А вообще и Амазону есть над чем работать - написали бы месяц буквами, все бы все поняли
Бредовые какие-то наезды на брокеров.
Короткие продажи, в т.ч. без покрытия - вполне нормальная биржевая практика, абсолютно никакого криминала в них нет. Если товарищ продавец не угадал и акции не подешевели, а подорожали - придется ему для закрытия позиции откупаться и останется он в убытках.
человек полгода работает с 9 до 18 в офисе, 5 дней в неделю
единственное отличие от штатных сотрудников - он получает не з/п по ведомости, а оплату по котракту и лишен (как правило) социального пакета, если таковой есть у компании
немногие согласятся с тем, что это фриланс
Это оптимизация расходов на налоги и минимизация рисков найма неадекватного человека для работодателя. Если реально люди работают в офисе на полный рабочий день - они наврядли являются фрилансерами по сути, хотя они являются ими по форме
The signed contract and 50% deposit is required before we schedule a time slot for your project. The remainder of your balance will be due upon project completion. Once we have received your 50% deposit and signed contract, we will provide you with a copy of the fully executed contract, a receipt for your deposit and your project start date. All projects are scheduled on a “first come, first served” basis.
Добавлю пару пунктов, чего не надо делать заказчикам:
6. Проводить бесплатные тендеры.
В таковых участвуют только пионеры (в широком смысле этого слова).
7. Рассылать запросы предложения на разработку сайта на 50 адресов электронной почты в одном письме.
Нереально качественно оценить 50 предложений по другому параметру кроме цены. Все это понимают, а значит, студии, у которых цены выше средних, скорее всего проигнорируют такую рассылку
Если очень хочется все же получить 50 предложений (хоть и непонятно зачем) - сделайте запросы индивидуальными, не афишируйте их количество
Буфер - вещь хорошая, однако когда он исчерпывается заказчик начинает удивлятся, а чего это раньше вы за это деньги не брали, а сейчас начали. Кроме того возникают опять процедурные вопросы: когда этот буфер исчерпался писать доп. соглашение на каждый чих, собирать чихи оптом или что-то еще делать
Во втором случае да, возникает отсрочка платежа по дизайну, на который вы рассчитывали. Это конечно лучше, чем работать бесплатно, но тоже не очень радует.
Мы сами в большинстве случаев сейчас работаем по описаной вами схеме "ТЗ-дополнения", и я все больше и больше убеждаюсь в ее плохой применимости к крупным и сложным проектам.
Чем больше проект - тем хуже она работает.
Людмила, если вы не сталкивались с проектами в которых в ходе их выполнения возникала необходимость редактировать самое распрекрасное ТЗ, это не значит, что таких проектов не существует в природе.
Они существуют. Допоплнения к ТЗ это вариант выхода из такой ситуации, но у него есть ряд минусов, которые я уже упоминал:
- отнимается время на процедурные вопросы. Стоит ли подписывать дополнение к ТЗ если заказчик попросил, например, поменять фамилию главного бухгалтера на сайте (ну поменяли они его во время работы над проектом)? Очевидным ответом будет проще поменять без доп. соглашений, чем разводить писанину из-за 3-х минутной работы. Однако когда подобных 3-х минутных правок накапливается несколько десятков и еще пяток-другой правок на полчаса-час уже хочется сделать доп. соглашение и выставить за них счет. Как уже говорилось можно отправить, конечно, заказчика "в лес" со всеми этими правками до завершения цикла разработки, но в результате он будет не вполне доволен, а если правка более критична для бизнеса, например у интернет-магазина поменялся мерчант аккаунт, получается, что он и вовсе не сможет пользоваться разработанным сайтом
- зачастую приводят к сдвигу одного из основных уже оговоренных этапов, что негативно сказывается на финансировании проекта. Скажем у заказчика после утверждения половины макетов дизайна неожиданно сменился корпоративный стиль (скажете - бред, так не бывает, но в жизни бывает и не такое). Что делать? Работать дальше, по старому ТЗ - работа дизайнера в болшой степени идет в мусорную корзину. Принимать доп.соглашение - да, но в результате переработки уже сделанного сдвигается срок приема дизайна и оплата по нему. Студия "попадает" на проблемы с финансированием
угу, это в теории так
на практике это работает только для маленьких проектов
Если проект расчитан на полгода - 100%, что ТЗ придется обновлять. Если обновлять его и делать изменения после окончания работ по оригинальному ТЗ - страдает заказчик, если вносить правки по ходу работ - разработчик или оба.
проблема в том, что в более-менее сложных проектах по ходу реализации самое детальное ТЗ приходится корректировать в силу разных обстоятельств.
Если студия встает в позу и отказывается это делать - это невыгодно заказчику, в результате заказчик получает проект, который соответствует ТЗ, но реально отличается от того, что ему нужно, что приводит к трениям при сдаче и неудовлетворенности заказчика.
Если студия соглашается корректировать ТЗ, при жестком ТЗ такие корректировки требуют массу времени на процедурные вопросы и приводят к затягиванию достижения какого-то этапа и соответственно получению денег и недофинансированию.
Самое удобное как для студии, так по большому счету и для заказчика работать на условиях регулярной повременной оплаты (скажем 1 раз в месяц). Оговорюсь, что при этом разработка должна вестись по чему-то вроде Скрума или другой agile методики и применимо это к достаточно крупным проектам.
iname - ООО "Элайд Стандарт Лимитед"
imena - ООО "Интернет Инвест"
Так что юр.лица разные
Однако я думаю, что в данном конкретном случае, то как работает Амазон действительно оптимальное решение. Тут уже писали про реальный и идеальный мир. В идеальном мире все работает идеально, а в реальном мире правильно организованный бизнес пытается заранее продумать и корректно отработать и проблемные ситуации.
Был случай, когда отправленные книжки тупо не дошли, потерялись по дороге. Переслали без проблем.
Конечно, никто не спорит, что лучше бы все что показывается в витрине, отправлялось и отгружалось без сбоев, однако ситуация, возникшая с моим заказом, достаточно типична для интернет-магазина, вопрос как ее правильно обработать. В большинстве отечественных магазинов поступят одним из следующих образов:
- (лучший случай) оператор напишет или перезвонит и скажет, что невозможно выполнить заказ полностью и спросит, что делать;
- проигнорируют заказ совсем (раз не можем его исполнить);
- отгрузят заказ частично, не проинформировав покупателя;
- запихают в заказ что-то похожее на отсутствующий товар
но мне бы и до 10 сентября ждать не хотелось
А вообще и Амазону есть над чем работать - написали бы месяц буквами, все бы все поняли
Короткие продажи, в т.ч. без покрытия - вполне нормальная биржевая практика, абсолютно никакого криминала в них нет. Если товарищ продавец не угадал и акции не подешевели, а подорожали - придется ему для закрытия позиции откупаться и останется он в убытках.
единственное отличие от штатных сотрудников - он получает не з/п по ведомости, а оплату по котракту и лишен (как правило) социального пакета, если таковой есть у компании
немногие согласятся с тем, что это фриланс
большая часть их требует по крайней мере частичную предоплату, и это правильно
для проверки гуглим http://www.google.com.ua/search?q=web+si…
сайт с 3-й ссылки у меня:
http://www.finerdesign.com/website-devel…
пишут:
Initial Deposit
The signed contract and 50% deposit is required before we schedule a time slot for your project. The remainder of your balance will be due upon project completion. Once we have received your 50% deposit and signed contract, we will provide you with a copy of the fully executed contract, a receipt for your deposit and your project start date. All projects are scheduled on a “first come, first served” basis.
Т.е. парни берут 50% предоплаты
И так делают почти все, с кем мы работали
6. Проводить бесплатные тендеры.
В таковых участвуют только пионеры (в широком смысле этого слова).
7. Рассылать запросы предложения на разработку сайта на 50 адресов электронной почты в одном письме.
Нереально качественно оценить 50 предложений по другому параметру кроме цены. Все это понимают, а значит, студии, у которых цены выше средних, скорее всего проигнорируют такую рассылку
Если очень хочется все же получить 50 предложений (хоть и непонятно зачем) - сделайте запросы индивидуальными, не афишируйте их количество
Довольно много опций типа слияния документов есть.
Линк - http://www.bullzip.com/
Буфер - вещь хорошая, однако когда он исчерпывается заказчик начинает удивлятся, а чего это раньше вы за это деньги не брали, а сейчас начали. Кроме того возникают опять процедурные вопросы: когда этот буфер исчерпался писать доп. соглашение на каждый чих, собирать чихи оптом или что-то еще делать
Во втором случае да, возникает отсрочка платежа по дизайну, на который вы рассчитывали. Это конечно лучше, чем работать бесплатно, но тоже не очень радует.
Мы сами в большинстве случаев сейчас работаем по описаной вами схеме "ТЗ-дополнения", и я все больше и больше убеждаюсь в ее плохой применимости к крупным и сложным проектам.
Чем больше проект - тем хуже она работает.
Они существуют. Допоплнения к ТЗ это вариант выхода из такой ситуации, но у него есть ряд минусов, которые я уже упоминал:
- отнимается время на процедурные вопросы. Стоит ли подписывать дополнение к ТЗ если заказчик попросил, например, поменять фамилию главного бухгалтера на сайте (ну поменяли они его во время работы над проектом)? Очевидным ответом будет проще поменять без доп. соглашений, чем разводить писанину из-за 3-х минутной работы. Однако когда подобных 3-х минутных правок накапливается несколько десятков и еще пяток-другой правок на полчаса-час уже хочется сделать доп. соглашение и выставить за них счет. Как уже говорилось можно отправить, конечно, заказчика "в лес" со всеми этими правками до завершения цикла разработки, но в результате он будет не вполне доволен, а если правка более критична для бизнеса, например у интернет-магазина поменялся мерчант аккаунт, получается, что он и вовсе не сможет пользоваться разработанным сайтом
- зачастую приводят к сдвигу одного из основных уже оговоренных этапов, что негативно сказывается на финансировании проекта. Скажем у заказчика после утверждения половины макетов дизайна неожиданно сменился корпоративный стиль (скажете - бред, так не бывает, но в жизни бывает и не такое). Что делать? Работать дальше, по старому ТЗ - работа дизайнера в болшой степени идет в мусорную корзину. Принимать доп.соглашение - да, но в результате переработки уже сделанного сдвигается срок приема дизайна и оплата по нему. Студия "попадает" на проблемы с финансированием
на практике это работает только для маленьких проектов
Если проект расчитан на полгода - 100%, что ТЗ придется обновлять. Если обновлять его и делать изменения после окончания работ по оригинальному ТЗ - страдает заказчик, если вносить правки по ходу работ - разработчик или оба.
Если студия встает в позу и отказывается это делать - это невыгодно заказчику, в результате заказчик получает проект, который соответствует ТЗ, но реально отличается от того, что ему нужно, что приводит к трениям при сдаче и неудовлетворенности заказчика.
Если студия соглашается корректировать ТЗ, при жестком ТЗ такие корректировки требуют массу времени на процедурные вопросы и приводят к затягиванию достижения какого-то этапа и соответственно получению денег и недофинансированию.