Воо, здорово! LINQ - это однозначно будущее .NET. Спасибо за статью, я надеюсь многих .NET-чиков, которые еще не пользуются, заставит задуматься о том, что стоит попробовать LINQ ;)
Абсолютно согласен.
И при этом для описания собственно алгоритма может использоваться только функциональный или декларативный код. Объекты нужны для описания сущностей на более высоком уровне, на уровне проектирования, и для использования технических особенностей, таких как инкапсуляция, полиморфизм и наследование. А в методах самих классов то - функциональный стиль по сути. Последовательность кода, который должен выполниться для решения задачи и выполнения тестов.
Так что полностью поддерживаю "ООП дизайн + реализация в каком угодно стиле".
Все очень верно с этой точки зрения!
Просто вот люди любят устраивать холивары по поводу ООП versus functional-style.
Так, по-моему, они запросто сосуществуют НА РАЗНЫХ УРОВНЯХ!
Объекты используются, допустим, для описания бизнес-логики и способов взаимодействия сущностей на высоком уровне. А на самом низком уровне, на уровне алгоритмов - функциональный стиль! А как еще можно описать алгоритм, кроме как функционально! Или декларативно (но это уже немного другая тема).
Ну здесь не столько разница, сколько одно является "наворотом" поверх другого, то есть лямбда-выражения используют механизмы анонимного делегирования. Также верно то, что не все возможности анонимных delegates доступны в лямбдах. Просто технологии разные все равно, хотя появились одновременно в C# 3.0.
Лямбду, как я понимаю, вообще сделали просто для упрощения синтаксиса для наиболее распространенных ситуаций, где требуется делегирование.
У автора в заметке промелькнули мысли по поводу функционального и ОО-программирования и мышления.
Так вот, я думаю, что от языка это не зависит. Язык действительно зависит от задачи и от предпочтений автора кода. А вот как мыслить - "функционально" или "объектно-ориентированно" - вот в этом вся соль. А как при этом еще стать "лучшим специалистом"?
Ну что тут я могу сказать. Могу посоветовать автору хотя бы поинтересоваться одной темой и, возможно, понять - Test-Driven Development IS a rule!
Это как раз к вопросу о смене "окружения". Надо менять сами принципы и подходы к написанию кода, а не язык. Надо прекращать писать код, который "возможно и не пригодится".
Конечно, против Test-Driven-стиля разработки тоже есть аргументы, но они с лихвой перекрываются достоинствами подхода к программированию и проектированию.
P.S. Кстати, есть один очень красивый язык - Ruby ;)
Ну в шарпе анонимные функции и лямбда-выражения - это разные вещи, хотя одно и использует другое. Впрочем, и то и другое очень применимо и правда существенно уменьшает код.
На самом деле, любая работа - в той или иной мере - ответственность. Чем ее больше - больше доход (я не говорю, зарплата, потому что доход может быть с процентов от доли компании, к примеру).
И люди, которые берут ответственность (включая, ответственность за решение вопросов с Иванами Ивановичами и Марьями Ивановнами) остаются в достатке. Риск высок, сложно, много всего. Но оно того стоит. Разумеется, не для всех.
И вот уж тут действительно не принципиально - работать на дядю или иметь свой бизнес.
К слову, есть еще хорошая траектория - так вклиниться в "дядин" бизнес, чтобы в тебе были заинтересованы настолько, что включат в твою мотивацию партнерский процент - а вот это уже работа на себя.
"ты получаешь всЁ, что заработал, а не з/п + %"
Ну нельзя так категорично это рассматривать.
Ведь свой бизнес может и не быть столь успешным + ты получаешь всю ответственность и все риски на себя.
А работу на дядю тоже можно рассматривать по разному.
Допустим, можно владеть 100% своей компании с оборотом в 500 тысяч евро в год.
А можно получать з/п в 5000 EUR + иметь 2% от компании, оборот которой - 500 млн евро в год. А можно и 10% и быть генеральным директором этой компании.
Второй вариант - это работа на дядю. И тут дело в целях человека.
А вообще, если рассматривать еще более общую картинку - когда ты владелец не 100%, а скажем, даже 99% - это в какой-то мере уже работа на дядю, который вложил этот 1%.
Кстати говоря, еще есть такой момент - уровень богатства и благосостояния не связан напрямую с тем, свой бизнес или работа на дядю. Интересно, будет ли тут поднята такая тема :)
Млин, жалко нельзя комментировать чаще, чем раз в 5 минут, а хабр еще и не позволяет добавлять слишком длинные комменты.
Хотел сказать еще, что самое интересное начинается в кризисных и просто сложных ситуациях. Так вот, у многих "ex-специалистов", выросших до управленцев часто возникает первое желание - "засучить рукава и, например, сесть программировать", так как они делают это лучше всех (вполне возможно) и знают это.
На практике - чаще всего это оказывается самой большой ошибкой. В кризисной ситуации как нельзя лучше надо обдумывать именно принимаемые решения! Для всего остального - есть наемные специалисты. Чаще всего решить серьезный кризис, участвуя в роли "главного специалиста", не удается. Если удается - значит проблема была недостаточно серьезной :)
У меня лично одним из переломных моментов была ситуация, когда я в определенный момент, сидя за компом и проектируя структуру какой-то системы по одному очень срочному проекту, просто осознал, что ДЕЛАЮ НЕ СВОЮ РАБОТУ!!! Черт! Как так? Вся моя сущность противилась тому, что я делал с одной стороны, а с другой - я понимал, что "я в этом лучший". Но надо было еще постоянно принимать решения, включая решения по другим проектам! Что делать?
И чтобы побороть желание сделать все самому и побыстрее, я поставил себе ультиматум:
"Вот есть задача. Вот есть ты, вот комп. Тебе нужно решить эту и еще множество других задач в определенные сроки. Вперед! Условие одно: нельзя дотрагиваться до мышки и клавиатуры. Можно использовать телефон и умение грамотно выражать свои мысли. Все!". Конечно, это образно. Смысл в том, чтобы не делать самому никакой технической работы, а работать ТОЛЬКО головой. И если задача решается - значит ты хороший управленец. Если нет - повод задуматься, а стоит ли тебе "тянуть бизнес".
У меня такой подход сработал. Голова начинает работать просто в совершенно другм направлении. Намного более глобальном и масштабном. Это сильно помогло тогда и помогает до сих пор. Интересно, кто как еще решает подобные вещи.
Да, интересная статья, но, опять же, это только определенный взгляд на ситуацию.
Примерно, как "два крайних примера: ужасный, рабский, неинтересный, безперспективный труд на дядю и прелестный, дарящий, свободу и независисмость, успешный, собственный бизнес"
Вполне может быть наоборот. То есть, границ-то и нет, как таковых.
Все эти сложности - это правда, но тут от человека зависит, готов ли он к ним и хочет ли он их (причем, еще не факт, что это окупится финансово в итоге и дело точно выгорит). Умение принимать решения "здесь и сейчас" - это и есть показатель хорошего управленца. В случае правильных решений, конечно же. Впрочем, даже у великих профи бывают осечки.
Здесь в статье также затронута тема того, кем же человек хочет быть - специалистом в некоторой области или управленцем. И здесь, опять же, выбирает каждый для себя.
Если человек хочет писать код и делать это круче всех, но хочет свой бизнес (по каким-либо причинам) - надо нанимать директора (можно за процент от бизнеса - тогда это "совместное предприятие"). И вариантов развития событий на самом деле масса.
Но вот какой есть момент - личное время. Да, придется все время в голове держать ситуацию, чтобы держать ее под контролем. Но это вовсе не значит, что надо все время работать. На деле ПРАВИЛЬНЫЕ решения зачастую бывают намного ценнее многочасовой работы над чем-то.
И время всегда можно научиться планировать (и нужно для успеха своего бизнеса). А вот работу - ее нужно делегировать другим. Это очень неочевидный момент для начинающих бизнесменов.
Допустим, человек начинает некий бизнес, потому что считает, что он хорошо разбирается в предметной области и вообще отличный специалист. И поначалу он в своей же новоиспеченной компании занимается именно той работой, которую умеет делать, как профессионал. При этом совершенно необходимо одновременно УПРАВЛЯТЬ компанией, иначе ничего не получится. Грубо говоря, хорошая технология "не выгорит", если процесс работы над ней не будет управляться. И наоборот - нужно чем-то управлять, нужна эта самая "хорошая технология".
И самое сложное - в определенный момент решить, чем именно хотелось бы заниматься. Заниматься и тем и другим, как показывает практика, не получается. Берешься за одно - "валится" другое. И наоборот. И здесь в очередной раз приходится "переступать через себя" - тебя просто раздирает ощущение, что все, кого ты нанял "делают не так круто", ты бы сделал это лучше. Это так. НО! С этим придется смириться! И использовать только инструменты управления! Или быть специалистом.
"Право создавать что угодно у заказчика есть и так. Вы же не запретите ему заниматься какой-либо деятельностью."
Я имел в виду, как бы не отнять у себя право создавать аналогичное.
А передача прав (включая внесение соответствующего пункта в договор) может быть требованием заказчика и вообще условием сотрудничества с его стороны.
А исключительные права и лицензии не связаны, совершенно верно. Лицензия дает набор ограниченных прав на использование. Я же говорил про ситуацию, когда заказчик требует, чтобы права на создаваемый продукт принадлежали ему.
Кстати, есть еще момент, касающийся прав на продукт - некоторые заказчики хотят подтверждения получения ими прав на получившийся продукт. Нюансы в этом вопросе иногда встают боком, но это не касается сайтов, а более приближено к проектам по созданию интранет-систем. Поскольку проекты под заказчика, передача прав не является проблемой, однако могут быть моменты, когда надо быть начеку и не передать заказчику право создавать аналогичные продукты.
Алексей, отлично.
Радует адекватный подход к проблеме! :)
Еще хотел бы добавить...
Я уже писал в другом топике, что мы используем SLA или Договор+SLA.
Так вот, изначально оговариваем то, что работа - это сервис, услуга.
Но в соглашении есть интересный момент, касающийся как раз таки того, что в результате работы появляется некоторый ПРОДУКТ. И некоторые хотят оформить работу как договор подряда (а бывает еще и продукт поставить на баланс компании). Здесь вопрос только в том, чтобы правильно аргументировать свою позицию и бизнес-модель студии, как мне кажется.
Дело в том, что мы еще стараемся избегать лишней волокиты с "составлением и утверждением ТЗ", поскольку ни одно ТЗ к моменту завершения любого этапа в любом проекте не является актуальным (всегда есть поправки, предпочтения, "передумали", придумали новое и так далее). В таком режиме становится очень сложно определить "конечность" - свойство, которое должно присутствовать у продукта. Однако, этап закончить нужно, и, когда возможно, определяется набор "фич", определяющих логическое завершение этапа. А в некоторых случаях, критериями окончания этапа считается вообще покрытый объем работ и иногда временные рамки (например, работа по поддержке ведется по тому же соглашению, что и _итеративная_ разработка и разработка здесь тоже оплачивается по освоенному объему).
Таким образом, продукт у нас получается, как бы, не основным предметом, а "побочным эффектом" :)
P.S. Мы называем документ "SLA", так как это действительно документ, ориентированный на описание ПРОЦЕССА, а не ПРОДУКТА. Так как продукт - это что-то законченное, финальное, а процесс - это как раз то, что происходит и за что мы хотим получать свои денежки, даже если этот процесс не заканчивается.
Терминология необязательна, можно называть это Договором, если кому-то так удобнее, но это будет не очень верно концептуально, так как договор - это обычно набор некоторых конечных условий и все привыкли воспринимать его именно так.
Более того, часто SLA не исключает договор - бывает, что "чисто юридическая специфика" остается в договоре. И предметом договора является сам SLA, содержащий, в свою очередь, всю "специфику процесса".
Мы, кстати, поступаем немного по-другому.
У нас нет договоров. Есть аналогичный документ, который используют компании, бизнес которых ориентирован не на продукт, а на сервис (например, провайдеры). Это SLA, Соглашение об уровне сервиса.
Так вот, смысл в том, что этот документ НЕ имеет финальной суммы или сроков. Финальную сумму, сроки, объем работ и список имеют только короткие приложения к SLA, добавляемые со временем и по времени необходимости. Кстати, важно, что приложения именно "короткие" - лучше сделать "мало" и утвердить работу. Затем - следующий этап. В таком случае риски - минимальные для всех.
Акт подписывается по завершению работ по очередному приложению к SLA. Этот процесс может быть хоть бесконечен!
Т.е. сам SLA (в отличие от договоров, которые обычно приходится видеть) - содержит больше специфики и, в том числе, точный регламент НЕ того КАКИЕ работы проводятся, а КАК проводятся работы и на КАКИХ условиях.
Думаю, всем знакома ситуация, когда разработка давно закончена, но не сделана другая часть работ, "блокирующая" подписание акта и выплату. Вывод - надо делить этапы, разделять их на разные приложения к Соглашению SLA. И получается, что можно вести сколько угодно разных (даже очень мелких) работ или даже нескольких проектов параллельно. По одному SLA, в котором оговорены все условия.
Как кто-то уже упоминал выше в топике - может возникнуть проблема с тем, что "бухгалтерия не хочет" обрабатывать наборы актов. Здесь уже делать вывод в каждом конкретном случае.
Во-первых, можно комбинировать в одном акте работу по нескольким приложениям, а во-вторых, каждый решает для себя, что ему дороже - угодить клиенту или защитить себя.
И есть еще маленький аспект - здесь надо быть настойчивее и решать эти вопросы ТОЛЬКО с людьми, которые принимают решения. Бухгалтерия их не принимает - она только исполняет.
Ну вообще, Scrum - это методология ведения самого процесса. Независимо от того, как оформлены юридически отношения с заказчиком и какие этапы содержатся в договоре.
Зависимость условий договора по срокам может быть, но отнюдь не обязательна в связи с какой-то методологией.
Astoria Data Services - это действительно мощная вещь.
И при этом для описания собственно алгоритма может использоваться только функциональный или декларативный код. Объекты нужны для описания сущностей на более высоком уровне, на уровне проектирования, и для использования технических особенностей, таких как инкапсуляция, полиморфизм и наследование. А в методах самих классов то - функциональный стиль по сути. Последовательность кода, который должен выполниться для решения задачи и выполнения тестов.
Так что полностью поддерживаю "ООП дизайн + реализация в каком угодно стиле".
Просто вот люди любят устраивать холивары по поводу ООП versus functional-style.
Так, по-моему, они запросто сосуществуют НА РАЗНЫХ УРОВНЯХ!
Объекты используются, допустим, для описания бизнес-логики и способов взаимодействия сущностей на высоком уровне. А на самом низком уровне, на уровне алгоритмов - функциональный стиль! А как еще можно описать алгоритм, кроме как функционально! Или декларативно (но это уже немного другая тема).
Лямбду, как я понимаю, вообще сделали просто для упрощения синтаксиса для наиболее распространенных ситуаций, где требуется делегирование.
Так вот, я думаю, что от языка это не зависит. Язык действительно зависит от задачи и от предпочтений автора кода. А вот как мыслить - "функционально" или "объектно-ориентированно" - вот в этом вся соль. А как при этом еще стать "лучшим специалистом"?
Ну что тут я могу сказать. Могу посоветовать автору хотя бы поинтересоваться одной темой и, возможно, понять - Test-Driven Development IS a rule!
Это как раз к вопросу о смене "окружения". Надо менять сами принципы и подходы к написанию кода, а не язык. Надо прекращать писать код, который "возможно и не пригодится".
Конечно, против Test-Driven-стиля разработки тоже есть аргументы, но они с лихвой перекрываются достоинствами подхода к программированию и проектированию.
P.S. Кстати, есть один очень красивый язык - Ruby ;)
И люди, которые берут ответственность (включая, ответственность за решение вопросов с Иванами Ивановичами и Марьями Ивановнами) остаются в достатке. Риск высок, сложно, много всего. Но оно того стоит. Разумеется, не для всех.
И вот уж тут действительно не принципиально - работать на дядю или иметь свой бизнес.
К слову, есть еще хорошая траектория - так вклиниться в "дядин" бизнес, чтобы в тебе были заинтересованы настолько, что включат в твою мотивацию партнерский процент - а вот это уже работа на себя.
Ну нельзя так категорично это рассматривать.
Ведь свой бизнес может и не быть столь успешным + ты получаешь всю ответственность и все риски на себя.
А работу на дядю тоже можно рассматривать по разному.
Допустим, можно владеть 100% своей компании с оборотом в 500 тысяч евро в год.
А можно получать з/п в 5000 EUR + иметь 2% от компании, оборот которой - 500 млн евро в год. А можно и 10% и быть генеральным директором этой компании.
Второй вариант - это работа на дядю. И тут дело в целях человека.
А вообще, если рассматривать еще более общую картинку - когда ты владелец не 100%, а скажем, даже 99% - это в какой-то мере уже работа на дядю, который вложил этот 1%.
Так что точек зрения масса.
Хотел сказать еще, что самое интересное начинается в кризисных и просто сложных ситуациях. Так вот, у многих "ex-специалистов", выросших до управленцев часто возникает первое желание - "засучить рукава и, например, сесть программировать", так как они делают это лучше всех (вполне возможно) и знают это.
На практике - чаще всего это оказывается самой большой ошибкой. В кризисной ситуации как нельзя лучше надо обдумывать именно принимаемые решения! Для всего остального - есть наемные специалисты. Чаще всего решить серьезный кризис, участвуя в роли "главного специалиста", не удается. Если удается - значит проблема была недостаточно серьезной :)
У меня лично одним из переломных моментов была ситуация, когда я в определенный момент, сидя за компом и проектируя структуру какой-то системы по одному очень срочному проекту, просто осознал, что ДЕЛАЮ НЕ СВОЮ РАБОТУ!!! Черт! Как так? Вся моя сущность противилась тому, что я делал с одной стороны, а с другой - я понимал, что "я в этом лучший". Но надо было еще постоянно принимать решения, включая решения по другим проектам! Что делать?
И чтобы побороть желание сделать все самому и побыстрее, я поставил себе ультиматум:
"Вот есть задача. Вот есть ты, вот комп. Тебе нужно решить эту и еще множество других задач в определенные сроки. Вперед! Условие одно: нельзя дотрагиваться до мышки и клавиатуры. Можно использовать телефон и умение грамотно выражать свои мысли. Все!". Конечно, это образно. Смысл в том, чтобы не делать самому никакой технической работы, а работать ТОЛЬКО головой. И если задача решается - значит ты хороший управленец. Если нет - повод задуматься, а стоит ли тебе "тянуть бизнес".
У меня такой подход сработал. Голова начинает работать просто в совершенно другм направлении. Намного более глобальном и масштабном. Это сильно помогло тогда и помогает до сих пор. Интересно, кто как еще решает подобные вещи.
Примерно, как "два крайних примера: ужасный, рабский, неинтересный, безперспективный труд на дядю и прелестный, дарящий, свободу и независисмость, успешный, собственный бизнес"
Вполне может быть наоборот. То есть, границ-то и нет, как таковых.
Все эти сложности - это правда, но тут от человека зависит, готов ли он к ним и хочет ли он их (причем, еще не факт, что это окупится финансово в итоге и дело точно выгорит). Умение принимать решения "здесь и сейчас" - это и есть показатель хорошего управленца. В случае правильных решений, конечно же. Впрочем, даже у великих профи бывают осечки.
Здесь в статье также затронута тема того, кем же человек хочет быть - специалистом в некоторой области или управленцем. И здесь, опять же, выбирает каждый для себя.
Если человек хочет писать код и делать это круче всех, но хочет свой бизнес (по каким-либо причинам) - надо нанимать директора (можно за процент от бизнеса - тогда это "совместное предприятие"). И вариантов развития событий на самом деле масса.
Но вот какой есть момент - личное время. Да, придется все время в голове держать ситуацию, чтобы держать ее под контролем. Но это вовсе не значит, что надо все время работать. На деле ПРАВИЛЬНЫЕ решения зачастую бывают намного ценнее многочасовой работы над чем-то.
И время всегда можно научиться планировать (и нужно для успеха своего бизнеса). А вот работу - ее нужно делегировать другим. Это очень неочевидный момент для начинающих бизнесменов.
Допустим, человек начинает некий бизнес, потому что считает, что он хорошо разбирается в предметной области и вообще отличный специалист. И поначалу он в своей же новоиспеченной компании занимается именно той работой, которую умеет делать, как профессионал. При этом совершенно необходимо одновременно УПРАВЛЯТЬ компанией, иначе ничего не получится. Грубо говоря, хорошая технология "не выгорит", если процесс работы над ней не будет управляться. И наоборот - нужно чем-то управлять, нужна эта самая "хорошая технология".
И самое сложное - в определенный момент решить, чем именно хотелось бы заниматься. Заниматься и тем и другим, как показывает практика, не получается. Берешься за одно - "валится" другое. И наоборот. И здесь в очередной раз приходится "переступать через себя" - тебя просто раздирает ощущение, что все, кого ты нанял "делают не так круто", ты бы сделал это лучше. Это так. НО! С этим придется смириться! И использовать только инструменты управления! Или быть специалистом.
"Право создавать что угодно у заказчика есть и так. Вы же не запретите ему заниматься какой-либо деятельностью."
Я имел в виду, как бы не отнять у себя право создавать аналогичное.
А передача прав (включая внесение соответствующего пункта в договор) может быть требованием заказчика и вообще условием сотрудничества с его стороны.
А исключительные права и лицензии не связаны, совершенно верно. Лицензия дает набор ограниченных прав на использование. Я же говорил про ситуацию, когда заказчик требует, чтобы права на создаваемый продукт принадлежали ему.
Радует адекватный подход к проблеме! :)
Еще хотел бы добавить...
Я уже писал в другом топике, что мы используем SLA или Договор+SLA.
Так вот, изначально оговариваем то, что работа - это сервис, услуга.
Но в соглашении есть интересный момент, касающийся как раз таки того, что в результате работы появляется некоторый ПРОДУКТ. И некоторые хотят оформить работу как договор подряда (а бывает еще и продукт поставить на баланс компании). Здесь вопрос только в том, чтобы правильно аргументировать свою позицию и бизнес-модель студии, как мне кажется.
Дело в том, что мы еще стараемся избегать лишней волокиты с "составлением и утверждением ТЗ", поскольку ни одно ТЗ к моменту завершения любого этапа в любом проекте не является актуальным (всегда есть поправки, предпочтения, "передумали", придумали новое и так далее). В таком режиме становится очень сложно определить "конечность" - свойство, которое должно присутствовать у продукта. Однако, этап закончить нужно, и, когда возможно, определяется набор "фич", определяющих логическое завершение этапа. А в некоторых случаях, критериями окончания этапа считается вообще покрытый объем работ и иногда временные рамки (например, работа по поддержке ведется по тому же соглашению, что и _итеративная_ разработка и разработка здесь тоже оплачивается по освоенному объему).
Таким образом, продукт у нас получается, как бы, не основным предметом, а "побочным эффектом" :)
Хорошая и очень эргономичная штучка.
Терминология необязательна, можно называть это Договором, если кому-то так удобнее, но это будет не очень верно концептуально, так как договор - это обычно набор некоторых конечных условий и все привыкли воспринимать его именно так.
Более того, часто SLA не исключает договор - бывает, что "чисто юридическая специфика" остается в договоре. И предметом договора является сам SLA, содержащий, в свою очередь, всю "специфику процесса".
У нас нет договоров. Есть аналогичный документ, который используют компании, бизнес которых ориентирован не на продукт, а на сервис (например, провайдеры). Это SLA, Соглашение об уровне сервиса.
Так вот, смысл в том, что этот документ НЕ имеет финальной суммы или сроков. Финальную сумму, сроки, объем работ и список имеют только короткие приложения к SLA, добавляемые со временем и по времени необходимости. Кстати, важно, что приложения именно "короткие" - лучше сделать "мало" и утвердить работу. Затем - следующий этап. В таком случае риски - минимальные для всех.
Акт подписывается по завершению работ по очередному приложению к SLA. Этот процесс может быть хоть бесконечен!
Т.е. сам SLA (в отличие от договоров, которые обычно приходится видеть) - содержит больше специфики и, в том числе, точный регламент НЕ того КАКИЕ работы проводятся, а КАК проводятся работы и на КАКИХ условиях.
Думаю, всем знакома ситуация, когда разработка давно закончена, но не сделана другая часть работ, "блокирующая" подписание акта и выплату. Вывод - надо делить этапы, разделять их на разные приложения к Соглашению SLA. И получается, что можно вести сколько угодно разных (даже очень мелких) работ или даже нескольких проектов параллельно. По одному SLA, в котором оговорены все условия.
Как кто-то уже упоминал выше в топике - может возникнуть проблема с тем, что "бухгалтерия не хочет" обрабатывать наборы актов. Здесь уже делать вывод в каждом конкретном случае.
Во-первых, можно комбинировать в одном акте работу по нескольким приложениям, а во-вторых, каждый решает для себя, что ему дороже - угодить клиенту или защитить себя.
И есть еще маленький аспект - здесь надо быть настойчивее и решать эти вопросы ТОЛЬКО с людьми, которые принимают решения. Бухгалтерия их не принимает - она только исполняет.
Зависимость условий договора по срокам может быть, но отнюдь не обязательна в связи с какой-то методологией.