Здравствуйте, Trean, Вы писали:
T>на главной странице нет полей для входа в аккаунт, что мне не нравится на всех подобных сайтах.
Подумаю.
T>На странице редактирования информации пользователя, нету кнопки cancel которая бы возвращала на страницу управления аккаунтом, приходится либо чере кнопку назад в браузере, либо через другие странице пробираться — неинтуитивно имхо.
+
T>Оценки заказчиков я бы убрал с главной страницы исполнителя, когда их наберется даже с десяток, они будут только мешать, не так уж часто их приходится смотреть.
T>Поясните зачем может понадобиться перевод денег заказчику от исполнителя? Я бы предпочел наоборот )), на том же RAC есть такая вещь как бонус, для этих целей. Ни на одном сайте я не встречал, чтобы исполнитель кому-то деньги перечислял, если только он не заходит как заказчик проекта.
Есть среди русских шароварщиков интересная мания: деньги друг у друга менять на разных сервисах. "Я тебе 100 WMZ, а ты мне 90 р. на RentAGuru". Поэтому пока на поругание оставлена возможность платежей между пользователями (пункт "Перевести средства пользователю"). Мы хотим ограничивать контакты внутри системы, но реально исполнители часто друг друга знают. И может имеет смысл оставлять им возможность передавать средства внутри системы.
T>Ни на одной странице нету справки для нее. Нет информации о комиссии, которую берет сайт за проекты (пусть даже fake).
Эти цифры есть в договорах и на страницах "Заказчикам" и "Исполнителям". Это первое, что должны прочитать данные пользователи перед началом использования сайтом.
T>Я бы посоветовал посмотреть на Guru.com, там мне тоже не все нравится безусловно (в частности навигация, пока не привыкнешь) но есть много чего, что можно позаимствовать.
Спасибо, посмотрю.
T>Сайт трудно критиковать, так как там почти ничего нет как объекта критики. Наворачивайте функционал.
Интересное резюме. А если я скажу, что внутри сайта движок от известного реального сайта обратных аукционов с емкостью 100 новых проектов в день? Мы за дешевизной проекта не гонимся
T>З.Ы. Слоган не катит: если я хочу нанять профи на неделю или на 2 месяца, мне искать другой сайт?
Слава, я конечно понимаю, что одно место натерто скипидаром и страсть как хочется получить критики (и возможно даже пользователей), но блин ! сделай проверку грамматики и синтаксиса ВСЕГО сайта. Я потыкал по разным страницам — как неуч писал, ей богу.
По поводу бажков — на страницах "Заказчикам" и "Исполнителям" меню всегда содержит одни и те же пункты вне зависимоти от того залогинен ты или нет. Это неправильно, особенно пункт меню "Выйти".
Здравствуйте, Dimonka, Вы писали:
СШ>>А какое имя вводишь?
D>Да любое — только сейчас дошло, что заглавные буквы не принимаются.. А это странно..
А вроде в сообщении об ошибке написано и пример приведён. Любопытно. Но это не странно — боремся с двойным толкованием slava и Slava. То есть со схожими написаниями пользователей.
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Собрал сайт для удалённой разработки программного обеспечения Небольшой аналог Rent A Coder. Прошу походить, посмотреть,
Заказчик обязуется не контактировать с Исполнителем в обход сервиса и не передавать свою контактную информацию Исполнителю. В случае обнаружения попытки передачи такой информации сервис может немедленно уничтожить аккаунт Заказчика и прекратить с ним работу.
эта фигня пристствует на всех подобных сайтах, в чем ее смысел? Получается что отваливается например такая цепочка — я вижу где-то (например в форуме или в частном письме) предложение типа — "напишите мне утилиту за деньги", говорю — OK, оформляем через RentAGuru и вперед — ан нет, в сообщении-то уже была "контактная информация" заказчика
Почему заказчику и исполнителю нельзя общаться мимо rentagurы? ясен пень общение по данному конкретному заказу должно быть задукоментировано, но может у нас есть и другие дела, не касающиеся rentaguru?
Почему просто не написать, что при рассмотрении споров заказчика и исполнителя принимается во внимание только информация, прошедшая через rentaguru?
Здравствуйте, Слава Шевцов, Вы писали:
СШ>А вроде в сообщении об ошибке написано и пример приведён. Любопытно. Но это не странно — боремся с двойным толкованием slava и Slava. То есть со схожими написаниями пользователей.
Ну так это делать это надо на уровне программы, а не мучить пользователей
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, Слава Шевцов, Вы писали:
СШ>>Собрал сайт для удалённой разработки программного обеспечения Небольшой аналог Rent A Coder. Прошу походить, посмотреть,
OE>http://www.rentaguru.ru/buyer-agreement.shtml
OE>
OE>Заказчик обязуется не контактировать с Исполнителем в обход сервиса и не передавать свою контактную информацию Исполнителю. В случае обнаружения попытки передачи такой информации сервис может немедленно уничтожить аккаунт Заказчика и прекратить с ним работу.
OE>эта фигня пристствует на всех подобных сайтах, в чем ее смысел?
Её смысл в том, чтобы деньги прошли через сервис, а не в обход. Это первое. Второй смысл в том, что заказчик может в следующий раз связаться с тем же исполнителем (если он его ранее не знал) только через сервис. То есть это один из способов защиты интересов сервиса. В третьих, этим защищается исполнитель от заказчика (у арбитража полнота переписки по проекту).
OE>Получается что отваливается например такая цепочка — я вижу где-то (например в форуме или в частном письме) предложение типа — "напишите мне утилиту за деньги", говорю — OK, оформляем через RentAGuru и вперед — ан нет, в сообщении-то уже была "контактная информация" заказчика
Почему? Пришли, завели проект, ты выиграл и работаете дальше. Но через сервис контактными данными не обмениваетесь. Кстати, в арбитраже замечательно рассмотрены ситуации, когда часть переговоров ведётся вне сервиса и тем не менее арбитраж эти материалы рассматривает. То есть запрета неконтактировать нет. Есть запрет непередавать контактной информации.
OE>Почему заказчику и исполнителю нельзя общаться мимо rentagurы? ясен пень общение по данному конкретному заказу должно быть задукоментировано, но может у нас есть и другие дела, не касающиеся rentaguru?
Да пусть себе общаются. Это нормально.
OE>Почему просто не написать, что при рассмотрении споров заказчика и исполнителя принимается во внимание только информация, прошедшая через rentaguru?
Если заказчик не знает исполнителя, то сервис имеет несколько больше шансов, что в следующий раз они так же будут работать на сервисе в общем проекте. Ну не любят люди платить деньги за услуги.
Здравствуйте, Dimonka, Вы писали:
СШ>>А вроде в сообщении об ошибке написано и пример приведён. Любопытно. Но это не странно — боремся с двойным толкованием slava и Slava. То есть со схожими написаниями пользователей.
D>Ну так это делать это надо на уровне программы, а не мучить пользователей
Чтобы пользователь потом утверждал, что он такого имени не вводил?
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Собрал сайт для удалённой разработки программного обеспечения Небольшой аналог Rent A Coder. Прошу походить, посмотреть,
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, Слава Шевцов, Вы писали:
СШ>>Собрал сайт для удалённой разработки программного обеспечения Небольшой аналог Rent A Coder. Прошу походить, посмотреть,
OE>http://www.rentaguru.ru/buyer-agreement.shtml
OE>
OE>Заказчик обязуется не контактировать с Исполнителем в обход сервиса и не передавать свою контактную информацию Исполнителю. В случае обнаружения попытки передачи такой информации сервис может немедленно уничтожить аккаунт Заказчика и прекратить с ним работу.
OE>эта фигня пристствует на всех подобных сайтах, в чем ее смысел?
Ну вообще-то не на всех например на Гуру.ком, можно размещать контактную информацию в бидах клиенту, то есть указывать внешние ссылки на сайты, портфолио, почту. На собственном опыте могу сказать, что мы некоторым сторонним (не с этого сайта) заказчикам предлагаем оформлять сделку через Safe Escrow сервис на Гуру. Потому что пока не уверен во вменяемости заказчика, стремно проводить сделку в обход гуру, несмотря на потерю 10% риск большой не получить денег вообще. Так что я не уверен в том, что указанное в соглашении условие необходимо, на мой взгляд оно лишнее. Лично мне на RAC это очень не нравилось, нельзя ни ссылку на свой сайт поставить, где нормально оформленное портфолио и описание сервисов, которые могут заинтересовать заказчика. Кроме того очень не удобно общаться только средствами сервиса: иногда заказчик желает поговорить по скайпу, аське и т.д. Если делать действительно удобный для исполнителей и заказчиков сервис, то такое ограничение на обмен контактной инфой между заказчиком и исполнителем будет лишним, так как обоим сторонам будет проще выполнять проект в рамках предоставляемого сайтом сервиса, чем получать гемор в обход его.
T>>Сайт трудно критиковать, так как там почти ничего нет как объекта критики. Наворачивайте функционал.
СШ>Интересное резюме. А если я скажу, что внутри сайта движок от известного реального сайта обратных аукционов с емкостью 100 новых проектов в день? Мы за дешевизной проекта не гонимся
Может быть, просто на данный момент как-то куце смотрится все, не в обиду. Но это понятно, надо ж с чего-то начинать, так что желаю успехов
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Собрал сайт для удалённой разработки программного обеспечения Небольшой аналог Rent A Coder. Прошу походить, посмотреть, почитать условия использования, схему гарантий оплаты и покритиковать. Сайт для тестирования работает сегодня и завтра (6 и 7 июня). Если что, срок продлю.
Мне кажется, не стоит разделять пробелами слова в логотипе -- выделения заглавными буквами достаточно.
Здравствуйте, Trean, Вы писали:
OE>>эта фигня пристствует на всех подобных сайтах, в чем ее смысел?
T>Ну вообще-то не на всех например на Гуру.ком, можно размещать контактную информацию в бидах клиенту, то есть указывать внешние ссылки на сайты, портфолио, почту. На собственном опыте могу сказать, что мы некоторым сторонним (не с этого сайта) заказчикам предлагаем оформлять сделку через Safe Escrow сервис на Гуру. Потому что пока не уверен во вменяемости заказчика, стремно проводить сделку в обход гуру, несмотря на потерю 10% риск большой не получить денег вообще. Так что я не уверен в том, что указанное в соглашении условие необходимо, на мой взгляд оно лишнее. Лично мне на RAC это очень не нравилось, нельзя ни ссылку на свой сайт поставить, где нормально оформленное портфолио и описание сервисов, которые могут заинтересовать заказчика.
Ты всё правильно описал. После того, как доверие появилось, можно сниматься с сервиса. Так? И сервис остаётся без работы. И это нормально, если ты приводишь заказчика. Но если заказчика ты находишь на сайте сервиса, то сервис заинтересован в том, чтобы ты _всегда_ общался с заказчиком через сервис. А значит надо предотвращать передачу контактной информации. Любой контактной информации, так как сервису заранее неизвестно о наличии связи между заказчиком и исполнителем.
Конфликт интересов сторон? Да. Но сервис живёт за счёт того, что постоянные пользователи проплачивают проекты через сайт. И иного источника существования у него нет и быть не должно. Иначе начнётся продажа статусов, рейтингов, позиций в статистике, оплате высоты расположения в списке заявок на проект. И тогда это будет помойка.
T>Кроме того очень не удобно общаться только средствами сервиса: иногда заказчик желает поговорить по скайпу, аське и т.д. Если делать действительно удобный для исполнителей и заказчиков сервис, то такое ограничение на обмен контактной инфой между заказчиком и исполнителем будет лишним, так как обоим сторонам будет проще выполнять проект в рамках предоставляемого сайтом сервиса, чем получать гемор в обход его.
Trean, такое вряд ли кто сделает. Объясню почему. В программировании escrow без разбора конфликтов смысла не имеет. Так как сначала код должен быть оттестирован заказчиком и лишь потом отпускаются деньги. Теперь представь, что заказчик не хочет отпускать деньги. Что произойдёт без системы разбора конфликтов? Эти средства вернуться спустя какое-то время обратно. Заказчик всегда сможет утверждать, что проект выполнен некорректно.
Как только появляется разбор конфликтов (арбитраж или суд), то встаёт вопрос доказательной базы. Если часть доказательной базы находится вне арбитража, то как ему рассудить стороны по справедливости? Да никак. Он не может верить расходящимся показаниям сторон. И он не предназначен для длительной тяжбы.
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Собрал сайт для удалённой разработки программного обеспечения Небольшой аналог Rent A Coder. Прошу походить, посмотреть, почитать условия использования, схему гарантий оплаты и покритиковать. Сайт для тестирования работает сегодня и завтра (6 и 7 июня). Если что, срок продлю.
Дизайн сыроват. Необходимо вынести панель входа (логин/пароль) на главную страницу, рядом же поставить ссылки для регистрации байеров и кодеров. То есть по-любому заводить боковую панель, а то таблица во весь экран смотрится не очень.
Кстати, когда проект заработает в полную коммерческую силу?
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, Trean, Вы писали:
OE>>>эта фигня пристствует на всех подобных сайтах, в чем ее смысел?
T>>Ну вообще-то не на всех например на Гуру.ком, можно размещать контактную информацию в бидах клиенту, то есть указывать внешние ссылки на сайты, портфолио, почту. На собственном опыте могу сказать, что мы некоторым сторонним (не с этого сайта) заказчикам предлагаем оформлять сделку через Safe Escrow сервис на Гуру. Потому что пока не уверен во вменяемости заказчика, стремно проводить сделку в обход гуру, несмотря на потерю 10% риск большой не получить денег вообще. Так что я не уверен в том, что указанное в соглашении условие необходимо, на мой взгляд оно лишнее. Лично мне на RAC это очень не нравилось, нельзя ни ссылку на свой сайт поставить, где нормально оформленное портфолио и описание сервисов, которые могут заинтересовать заказчика.
СШ>Ты всё правильно описал. После того, как доверие появилось, можно сниматься с сервиса. Так? И сервис остаётся без работы. И это нормально, если ты приводишь заказчика. Но если заказчика ты находишь на сайте сервиса, то сервис заинтересован в том, чтобы ты _всегда_ общался с заказчиком через сервис. А значит надо предотвращать передачу контактной информации. Любой контактной информации, так как сервису заранее неизвестно о наличии связи между заказчиком и исполнителем.
Сниматься с сервиса можно, когда сиденье на таком сайте уже не столь прибыльно как прямое заключение контрактов с крупными заказчиками. Рано или поздно это происходит, если ты конечно не фрилансер одиночка. Кроме того еще есть такой вопрос как способы оплаты, когда на себя заботу о переводже денег берет третья сторона, то это тока хорошо.
СШ>Конфликт интересов сторон? Да. Но сервис живёт за счёт того, что постоянные пользователи проплачивают проекты через сайт. И иного источника существования у него нет и быть не должно. Иначе начнётся продажа статусов, рейтингов, позиций в статистике, оплате высоты расположения в списке заявок на проект. И тогда это будет помойка.
T>>Кроме того очень не удобно общаться только средствами сервиса: иногда заказчик желает поговорить по скайпу, аське и т.д. Если делать действительно удобный для исполнителей и заказчиков сервис, то такое ограничение на обмен контактной инфой между заказчиком и исполнителем будет лишним, так как обоим сторонам будет проще выполнять проект в рамках предоставляемого сайтом сервиса, чем получать гемор в обход его.
СШ>Trean, такое вряд ли кто сделает. Объясню почему. В программировании escrow без разбора конфликтов смысла не имеет. Так как сначала код должен быть оттестирован заказчиком и лишь потом отпускаются деньги. Теперь представь, что заказчик не хочет отпускать деньги. Что произойдёт без системы разбора конфликтов? Эти средства вернуться спустя какое-то время обратно. Заказчик всегда сможет утверждать, что проект выполнен некорректно.
СШ>Как только появляется разбор конфликтов (арбитраж или суд), то встаёт вопрос доказательной базы. Если часть доказательной базы находится вне арбитража, то как ему рассудить стороны по справедливости? Да никак. Он не может верить расходящимся показаниям сторон. И он не предназначен для длительной тяжбы.
А я разве спорю? Я на оборот говорю что все это (safe escrow, conflict resolution) наоборот стимулирует исполнителя и заказчика работать через сервис.Расзбор конфликта происходит очень просто: в договоре ты описываешь ТЗ указывая там функционал, этому договору заказчик делает accept. По завершении проекта ты заливаешь на сайт deviverables (исходники, доки и пр.), которые кстати тоже оговариваются в соглашении. Если заказчик не согласен по каким либо позициям, в дело вступает conflict resolution department на сайте, и профи выступают как независимая сторона в урегулировании конфликта и их слово решающее: они либо релизят деньги либо возвращают их заказчику.
Здравствуйте, Trean, Вы писали:
СШ>>Как только появляется разбор конфликтов (арбитраж или суд), то встаёт вопрос доказательной базы. Если часть доказательной базы находится вне арбитража, то как ему рассудить стороны по справедливости? Да никак. Он не может верить расходящимся показаниям сторон. И он не предназначен для длительной тяжбы.
T>А я разве спорю? Я на оборот говорю что все это (safe escrow, conflict resolution) наоборот стимулирует исполнителя и заказчика работать через сервис.Расзбор конфликта происходит очень просто: в договоре ты описываешь ТЗ указывая там функционал, этому договору заказчик делает accept. По завершении проекта ты заливаешь на сайт deviverables (исходники, доки и пр.), которые кстати тоже оговариваются в соглашении. Если заказчик не согласен по каким либо позициям, в дело вступает conflict resolution department на сайте, и профи выступают как независимая сторона в урегулировании конфликта и их слово решающее: они либо релизят деньги либо возвращают их заказчику.
"Не так это было, не так" (с) Вождь Народов.
Это описание идеального случая. Когда строители строят здание. В мире компьютеров обстоятельства могут выясняться по пути. Мы же понимаем, что такова особенность текущего этапа развития индустрии. Поэтому приходится к тексту договора присоединять все последующие переговоры и смотреть кто с чем соглашался, кто от чего отказывался. Такова реальная жизнь. Поэтому сайт, который судит итог по первоначальному ТЗ, никому не нужен. Ни заказчику, ни исполнителю.
И вообще, зачем вести ещё какие-то переговоры, если ТЗ ясно и пользователь под него подписался? Имхо, совершенно незачем. Ан нет — хотят что-то по проектам в аськах обсуждать
Мы за дешевизной проекта не гонимся 
