Это все предоставляется еще на этапе ТЗ.
Так не надо планировать ресурсы на разработку до того, как будет полностью сдано ТЗ.
Все равно, между сдачей ТЗ и началом разработки проходит минимум неделя. В среднем - до две-три.
Я вообще-то не понимаю, как без наличия ТЗ или хотя бы функциональных спецификаций можно оценить стоимость разработки.
Ну, ежели ему дать полный доступ - то да, а вообще-то для таких случаев есть право Execute, я уж не говорю, про подписанные процедуры.
Воистину так! 🍻
Я и говорю, что подрядчику, как ни в чем не виноватому, просто встречную заяву на заказчика надо было дать. Сумма действительно смешная, но если в структурах есть знакомые - почему бы не поразвлекаться :) Только не грозить, а сразу направлять. Заказчику даже официального запроса хватит :)
Смотря где... ежели в крупном городе - то да, а если в Мухо...ске, то палочка в раскрытии дела не помешает. Вспомните дело Поносова :)
Перед тем, как делать - оцените соотношение сил :)
Удачи.
Да ничего подобного!!!! Просто надо тон выбирать. А если по 2-3 раза в день клиенту звонить и отчитываться что уже сделано и при этом напоминать что ОН должен сделать, то он будет только рад :)
Кстати, это тоже немаловажный момент, особенно при работе с крупным клиентом. Фактически работы могут во всю идти еще до подписания договора ( договоры иногда проходят циклы согласования по два месяца ), но у меня, к примеру четко записано, что отсчет времени начинается с момента поступления денег на мой расчетный счет, или, в некоторых случаях, на корсчет моего банка :) Естественно, работы заранее я начинаю только в случае 100% уверенности в заказчике.
И что такого? За ТЗ денег получили? Мы, к примеру, иногда делаем ТЗ заранее зная, что делаться все будет собственными силами Заказчика. Более того, в процессе работы мы их консультируем. Всех денег не заработаешь, и на все рук не хватает. Мы делаем работу, требующую высокой квалификации, а мелочевкой заниматься не всегда выгодно :)
Shaitan, Не парьтесь, если Заказчик выдаст Вам деньги без расходника - то он их выдаст просто из черной кассы. Ему такие фортели дороже выйдут. Договор тоже не помешает, даже не договор а описание той работы, которую Вы должны будете сделать. Главное подписи там должны быть с обоих сторон.
Заказчик физлицо или Юрлицо? Расходный ордер заполнялся? Если юрлицо, или сайт для его юрлица - то он просто готовый клиент для практикантов с налоговой или ОБЭПа:)
Предоставьте туда копию заявы Заказчика в милицию, копию Вашей объяснительной, копию расписки и предположение о том, что деньги Вам были выплачены из черной кассы :)
Развлекуха заказчику обеспечена. ОБЭП действует не по заявлению а по факту, а он налицо :)
Но уж слишком суммы малы :)
Удачи! и не продешеви :)
В договоре можно просто указать, что при задержке сроков по вине заказчика срок исполнения увеличивается как минимум на время просрочки предоставления материалов, не считая общевыходных и праздничных дней. :)
При просрочке предоствалени материалов Вы пишете официальное уведомительное письмо заказчику где говорите о том, что к такому-то сроку такие-то и такие-то материалы Заказчиком предоставлены не были и поэтому, на основании пункта x.y.z. Договора, с учетом текущей загрузки Исполнителя, предполагаемый срок окончания работ - 32 мартобря :)
Письмо обязательно зарегистрируйте, чтобы потом на него можно было ссылаться... или просто пошлите его по почте с уведомлением о вручении. Уведомление и копию храните до полного окончания работ по договору.
"Пользователь должен видеть только то, что ему разрешено видеть".
Поясняю - Стандартный селект с джойном из 5-6 таблиц.
В результате - выводятся таблица всего в 5-7 колонок. А каждая таблица может содержать и другие, совсем не предназначенные для просмотра этим пользователем данные. Но он, составив правильно запрос, в Вашей модели безопасности, может их получить. Более того, злоумышленник сможет получать из этих таблиц данные совсем к нему не отоносящиеся.
В модели с API мы явно запрещаем пользователю доступ к таблицам, но разрешаем - к процедурам. В этом случае мы полностью контролируем то, что мы выдаем пользователю.
В данном конкретном случае она на 100% оправдана. Это интеграционное решение. Причем, насколько я понял, уже существует система, к которой Олегу надо прикрутить дополнительные сервисы, причем не затрагивая архитектуры самой системы. Такие требования бывают, как правило, в случае, когда саму систему планируют развивать дальше. А дальнейшее развитие, с очень высокой вероятностью, подразумевает изменение структуры данных, например введения дополнительнх справочников.. Следовательно, такое развитие предусматривает и паралельное внесений изменений в сервисы Олега. Именно паралельное... иначе все перестанет работать. Наличие четкого прописанного API решает проблему синхронной модернизации системы. Т.е. можно развивать каждую из подсистем отдельно, не при этом не трогая API, и внося в него соответствующие изменения каждый со своей стороны.
В данном случае я не совсем корректно выразился. Я имел в виду уже существующую команду программистов, которая будет дальше развивать систему. Я повторяю - это интеграционная задача, и подходить к ней надо со всей серьезностью.
Это миф. Если система не устроит заказчика, он просто остановит развитие проекта и начнет заново с другой командой. Если все делать профессионально, то должно получаться хорошо с первого раза, и в дальнейшем заказчик будет самостоятельно сопровождать систему, заказывая только новый функционал. Переделки - это просто пустая нервотрепка. Гораздо проще изначально максимально правильно поставить задачу, сделать прототип, наконец.
Мы, таки, бизнесом нанимаемся, или делим весь мир на черное и белое? :)
Топик изначально был не о возможности создания системы, а об оценке трудозатрат на такую систему, и как следствие, справедливой цене работы.
Тогда можно сидеть на попе ровно и ждать пока клиент созреет до Ваших условий :)
Работу можно смело бить как минимум на 3 этапа, причем по каждому из них можно смело брать деньги.
1. Разработка архитектуры системы и принципов ранжирования документов.
2. Разработка ТЗ на API, который будет писать третья сторона. При этом надо оговорить, что Вы не несете ответственности за API, и при изменениях в системе API должен быть неизменным. Т.е. Если есть процедура GetText c двумя входными параметрами, то после изменения внутри системы процедкра должна работать так же. максимум, можно добавлять в процедуру опциональные дополнительные параметры.
3. Непосредственно сама разработка, с учетом уже существующего и отлаженного API.
Так предоплату в размере 30% под банковскую гарантию еще никто не отменял в гостендерах :)
И полтинник в Вашем случае - это действительно себестоимость или даже демпинг.
А кто такому заказчику мешает сначала почитать этот форум, и попытаться оценить стоимость работы, а потом, через ЛС найти подрядчика... Время жаль? Тогда плати деньги :)
