Overdue - фриланс - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нужно сделать два шага: Отправлен заказчику прототип/готовая версия, если прототип, то заказчик его получает и жмет кнопку "получить", от этого времени отсчет останавливается. Он тестит его три месяца, но до тех пор пока не нажмет кнопку "отправить на доработку" - время стоит. Как только он отправил, отсчет начинает идти дальше. Тогда все будут счастливы.
Да, что-то подобное необходимо.
А то, что Санёк предлагает учитывать время заказчика - это жена должна у мужа заказывать, тогда можно учесть, да и то не всегда.
Нужно сделать два шага: Отправлен заказчику прототип/готовая версия, если прототип, то заказчик его получает и жмет кнопку "получить", от этого времени отсчет останавливается. Он тестит его три месяца, но до тех пор пока не нажмет кнопку "отправить на доработку" - время стоит. Как только он отправил, отсчет начинает идти дальше. Тогда все будут счастливы.
А если заказчик отморозился и кнопку получил не нажал?
Нет уж каждый отвечает за себя, сделал дело, нажал свою кнопку прототип, стоп-тайминг пока заказчик не подтвердит шаг.
А если заказчик отморозился и кнопку получил не нажал?
Нет уж каждый отвечает за себя, сделал дело, нажал свою кнопку прототип, стоп-тайминг пока заказчик не подтвердит шаг.
По своему опыту знаю - Исполнитель халатно относится к вопросам тестирования, поэтому, если работа сделана хорошо, то и принята будет быстро.
Я обычно ставлю две недели на исполнения - редко кто укладывается.
Да, что-то подобное необходимо.
А то, что Санёк предлагает учитывать время заказчика - это жена должна у мужа заказывать, тогда можно учесть, да и то не всегда.
а не будет соблазна лепить сроки в один час )
тут ведь не семечки щёлкают, а программы делают от которых после зависит финансовое благополучие заказчика )
"это вам не мелочь по карманам тырить" (с) )
а не будет соблазна лепить сроки в один час )
тут ведь не семечки щёлкают, а программы делают от которых после зависит финансовое благополучие заказчика )
"это вам не мелочь по карманам тырить" (с) )
Тем более нужно дать время заказчику всё без суеты проверить. Но это не должно сказываться на исполнителе.
Исполнитель за себя отвечает выставляя время исполнения, он же не учитывает обстоятельства другой стороны.
Тем более нужно дать время заказчику всё без суеты проверить. Но это не должно сказываться на исполнителе.
Исполнитель за себя отвечает выставляя время исполнения, он же не учитывает обстоятельства другой стороны.
обычно на проверку даю заказчику неделю, в выходные в тестере, в будни на демке, после демка останавливается и заказчик сам объявляется.
если не успел, даю ещё время неделю, после прошу оплатить, с условием что обнаруженные косяки поправлю. Но обычно после окончания первой недели происходит оплата.
ЗЫ: если за себя отвечает, так пусть подумает на перёд.
обычно на проверку даю заказчику неделю, в выходные в тестере, в будни на демке, после демка останавливается и заказчик сам объявляется.
если не успел, даю ещё время неделю, после прошу оплатить, с условием что обнаруженные косяки поправлю. Но обычно после окончания первой недели происходит оплата.
ЗЫ: если за себя отвечает, так пусть подумает на перёд.
Не проще самому исполнителю проверить отработку положений ТЗ? Оперативно исправить. Заказчику выдать готовую программу.
Получается что большинство разработчиков так и работает как описано выше.
Сделал заказ отдал:
1. Заказчик сам проверяет и копается в программе -- не нашел баги - очень хорошо.
2. Заказчик нашел баги можно обещать что поправлю потом. Кто то согласиться, а кто то нет. Заказ просрочен в связи с правками.
Может просто более ответственно подходить к реализации? Сроки действительно учитывать и на тесты, и на исправление.
Оговаривать с заказчиком и исполнителем больший срок чем сиюминутные "хотелки".
Не проще самому исполнителю проверить отработку положений ТЗ? Оперативно исправить. Заказчику выдать готовую программу.
Получается что большинство разработчиков так и работает как описано выше.
Сделал заказ отдал:
1. Заказчик сам проверяет и копается в программе -- не нашел баги - очень хорошо.
2. Заказчик нашел баги можно обещать что поправлю потом. Кто то согласиться, а кто то нет. Заказ просрочен в связи с правками.
Может просто более ответственно подходить к реализации? Сроки действительно учитывать и на тесты, и на исправление.
Оговаривать с заказчиком и исполнителем больший срок чем сиюминутные "хотелки".
А первый пост читал?
Как на счёт той ситуации?