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