То есть перевозчик, для гарантии своей безопасности, должен товар купить за свои деньги и, для получения оплаты, подготовить доказательства выполнения передачи заказчику.
Именно это будет мешать сервису развиваться.
А как решается вопросы:
1. Ответственность перевозчика за провоз чего то запрещенного и оплаты за товар?
2. Оплаты за товар? Если платит заказчик — то где гарантия того, что перевозчик не исчезнет? Если товар покупает перевозчик — то где гарантия что ему выплатят за товар и доставку?
Умножение повышения качества не дает. А вот вероятность что среди 2*Х кадров можно будет найти кадр с нормально видимыми номерами выше, чем среди Х кадров.
Вот теперь Яндекс.Диск можно трактовать как замену или альтернативу Dropbox.
Раньше, при использовании диска, смущало именно отстутствие понятных возможностей расширения.
Мы с заказчиками (максимально адекватными) поступаем обычно так — вначале делаем базовый проект, который уже можно пускать в интернет, а дальнейшее его развитие (добавление и расширение функционала) делаем уже по Agile.
Чаще всего так выходит проще, и в результате первой итерации клиент уже имеет готовый продукт, который уже может решать его задачи.
А убедить работать так на начальном этапе — очень и очень сложно.
Порядок действий:
1. Выбираю город куда ехать
2. 2 раза нажимаю на календарь (выделяю даты).
3. Выбираю колво пассажиров (только выбираю), не нажимаю «Готово», нажимаю на пустое место.
4. Система пишет в поле «двое».
4. Нажимаю Искать.
Система выдает цену за 1-ого, кнопка найти — зеленая.
Получатся, что при просто выборе — количество людей в заявке менятеся, а системе не передается.
Зачем спрашивать количество пассажиров, если и в поиске стоимость показывается только за одного, и даже при бронировании — опять же предлагают списать стоимость билета на 1 человека?
Самое противное, что таких заказчиков не всегда можно вычислить до подписания договора.
Бывает так, что на предварительных встречах представитель заказчика ведет себя очень конструктивно, готов обсуждать новые идеи, методы развития проекта в будущем и принимать предложения от разработчиков.
Но, после подписания договора и оплаты все может измениться.
«Наш директор хочет свою фотографию на главной. И это не обсуждается!»
«У наших конкурентов при запуске сайта музыка играет. А мы хотим так же, но еще громче. Ведь это позволит запомнить наш сайт.»
И так далее…
Иногда приходится сразу разрывать договор, но чувство нехорошее на душе остается.
Плюсы:
1. Простой API. Прикручивается к любому сайту за день максимум, если конечно программист нормальный.
2. Есть тестовый режим — можно тестить до посинения, отлавливая глюки и оптимизируя код. При этом оплаты полностью эмулируются.
3. Деньги приходят обычным безналом. Бухгалтерии не нужно думать как взять на баланс webmoney и тд :)
4. Есть доступ в личный кабинет, где можно отслеживать транзакции.
5. Все отлажено достаточно неплохо.
6. Все требования достаточно формализованы. Есть список требований к сайту и так далее.
Минусы:
1. Куча бумаг. Куча шагов что бы все это заполнить и так далее. Одноразовый гемморой, но все же гемморой.
2. Нужно быть в первую очередь офф-лайновой структурой (или очень крупной онлайновой). Представитель банка, через которого будет идти процессинг приезжает в офис и все осматривает, выспрашивает. Если будущий онлайн-магазин мелкая фирма в маленьком офисе у которой ничего нет — могут не дать согласования.
3. Комиссия :) Ну это не смертельно.
Именно это будет мешать сервису развиваться.
1. Ответственность перевозчика за провоз чего то запрещенного и оплаты за товар?
2. Оплаты за товар? Если платит заказчик — то где гарантия того, что перевозчик не исчезнет? Если товар покупает перевозчик — то где гарантия что ему выплатят за товар и доставку?
Раньше, при использовании диска, смущало именно отстутствие понятных возможностей расширения.
Исполнитель получит 5000 рублей
Вы заплатите 5515,46 рублей.
Так что итоговый процент при выводе на банковский счет — больше 10%.
Если фрилансеру выводить деньги на WebMoney — то заказчик заплатить уже 5691,03 рублей, то есть почти 14%.
Мы с заказчиками (максимально адекватными) поступаем обычно так — вначале делаем базовый проект, который уже можно пускать в интернет, а дальнейшее его развитие (добавление и расширение функционала) делаем уже по Agile.
Чаще всего так выходит проще, и в результате первой итерации клиент уже имеет готовый продукт, который уже может решать его задачи.
А убедить работать так на начальном этапе — очень и очень сложно.
Сервис, кстати, понравился, иначе не стал бы придираться :)
В самом тексте — Выберите количество пассажиров (двое) и класс
Chrome и Firefox
Порядок действий:
1. Выбираю город куда ехать
2. 2 раза нажимаю на календарь (выделяю даты).
3. Выбираю колво пассажиров (только выбираю), не нажимаю «Готово», нажимаю на пустое место.
4. Система пишет в поле «двое».
4. Нажимаю Искать.
Система выдает цену за 1-ого, кнопка найти — зеленая.
Получатся, что при просто выборе — количество людей в заявке менятеся, а системе не передается.
Зачем спрашивать количество пассажиров, если и в поиске стоимость показывается только за одного, и даже при бронировании — опять же предлагают списать стоимость билета на 1 человека?
Иногда они очень изобретательно маскируются :)
Все в ТЗ прописать невозможно. Даже для прописанных вещей останется свобода их трактовки.
Бывает так, что на предварительных встречах представитель заказчика ведет себя очень конструктивно, готов обсуждать новые идеи, методы развития проекта в будущем и принимать предложения от разработчиков.
Но, после подписания договора и оплаты все может измениться.
«Наш директор хочет свою фотографию на главной. И это не обсуждается!»
«У наших конкурентов при запуске сайта музыка играет. А мы хотим так же, но еще громче. Ведь это позволит запомнить наш сайт.»
И так далее…
Иногда приходится сразу разрывать договор, но чувство нехорошее на душе остается.
Добавьте супер-оружие, которое становится доступным, когда вырастает X цветочков.
Например, оружие а-ля салют — долетает до препятствия и разлетается на несколько разноцветных таблеток, которые себя ведут как изначальные снаряды.
Или заряд, который не пропадает после попадания в человечка, а продолжает летать до тех пор пока на землю не попадет.
И так далее, можно много придумать. Выдавать супер оружие по рандому. Это сделает игру более разнообразной.
Плюсы:
1. Простой API. Прикручивается к любому сайту за день максимум, если конечно программист нормальный.
2. Есть тестовый режим — можно тестить до посинения, отлавливая глюки и оптимизируя код. При этом оплаты полностью эмулируются.
3. Деньги приходят обычным безналом. Бухгалтерии не нужно думать как взять на баланс webmoney и тд :)
4. Есть доступ в личный кабинет, где можно отслеживать транзакции.
5. Все отлажено достаточно неплохо.
6. Все требования достаточно формализованы. Есть список требований к сайту и так далее.
Минусы:
1. Куча бумаг. Куча шагов что бы все это заполнить и так далее. Одноразовый гемморой, но все же гемморой.
2. Нужно быть в первую очередь офф-лайновой структурой (или очень крупной онлайновой). Представитель банка, через которого будет идти процессинг приезжает в офис и все осматривает, выспрашивает. Если будущий онлайн-магазин мелкая фирма в маленьком офисе у которой ничего нет — могут не дать согласования.
3. Комиссия :) Ну это не смертельно.
Если интересно — расскажу подробнее.
А ведь чаще всего заказчики и не задумываются о красивой и функциональной «заглушке».
Теперь будет еще один аргумент.
Если какой то сервис будет хорошо работать и при этом не требовать большого экрана — жить ему на мобильных устройствах.
Но, учитывая, что около 80% информации человек получает именно через зрение, это ооооочень отдаленная перспектива :)