Интересует такая ситуация.Допустим Подписали договор где четко прописано что срок месяц, в случаее задержек платим пени(столько-то). По вине исполнителя(не важно кого, программист, менеджер проекта..... ) эти сроки были нарушены.
Что все склоня голову платят положенные пени?
Или как-то пытаются выйти из данной ситуации.
Здравствуйте, linker,
L>День добрый.
L>Интересует такая ситуация.Допустим Подписали договор где четко прописано что срок месяц, в случаее задержек платим пени(столько-то). По вине исполнителя(не важно кого, программист, менеджер проекта..... ) эти сроки были нарушены. L>Что все склоня голову платят положенные пени? L>Или как-то пытаются выйти из данной ситуации.
Если Заказчик потребует выплатить ему пени — Исполнителю придется платить. Если дело дойдет до Арбитражного суда — будет однозначно решено в пользу Заказчика, поэтому Исполнителю упираться не стоит. Не потребует..... значит, не потребует Переговоры с Заказчиком — тоже дело не лишнее.
Если договор подписан от имени фирмы — то не имеет значения, по вине какого конкретного исполнителя (программиста, менеджера.... да хоть уборщицы тети Маруси!) эти сроки были нарушены. С точки зрения договора Исполнителем является фирма — поэтому платит фирма. Как она потом будет разбираться со своим виновным работником (в пределах юридического поля, конечно) — внутреннее дело фирмы, в которое Заказчик вникать не будет (да и не имеет права).
Здравствуйте, Vlad_SP, Вы писали:
V_S>Если Заказчик потребует выплатить ему пени — Исполнителю придется платить. Если дело дойдет до Арбитражного суда — будет однозначно решено в пользу Заказчика, поэтому Исполнителю упираться не стоит. Не потребует..... значит, не потребует Переговоры с Заказчиком — тоже дело не лишнее. V_S>Если договор подписан от имени фирмы — то не имеет значения, по вине какого конкретного исполнителя (программиста, менеджера.... да хоть уборщицы тети Маруси!) эти сроки были нарушены. С точки зрения договора Исполнителем является фирма — поэтому платит фирма. Как она потом будет разбираться со своим виновным работником (в пределах юридического поля, конечно) — внутреннее дело фирмы, в которое Заказчик вникать не будет (да и не имеет права).
Юридически то все понятно.Но заказчику нужен проект и он может пойти на компромисы.Вот я и спрашиваю были ли случаи у кого кто находило такие компромисы.
случаи-то были всякие....
Короткое резюме: зависит от. В общем случае, заказчику нужен проект — и вам тоже нужен успешный проект. Большинство заказчиков — вполне вменяемые, подвижка на небольшой срок обычно допустима (заказчики очень и очень часто закладывают сроки с некоторым запасом) и по договоренности с заказчиком можно и избежать пеней и прочих неприятностей. Нельзя избежать в двух случаях (возможно, их больше, но о чем знаю):
1. Провал по срокам совершенно фатальный и исправить ситуацию за неделю-другую невозможно. Придется все переделывать капитально с самого начала, так что срок работы над проектом фактически удваивается. Соответственно, у заказчика даже с учетом заложенного им запаса по срокам все равно "летят" все его сроки, обязательства и т.п. — и он тоже попадает на деньги.
2. Среди Больших Боссов заказчика у кого-то есть острое желание устроить образцово-показательную порку кому-нибудь из контрагентов по любому поводу, и по несчастливому стечению обстоятельств этим "козлом отпущения" стали именно Вы.... Тут возможны варианты: типа приход нового Большого Босса, желающего показать свой "профессионализм и принципиальность", в компанию Заказчика, и т.п., но сути пункта это не меняет.
Здравствуйте, linker, Вы писали:
L>Интересует такая ситуация.Допустим Подписали договор где четко прописано что срок месяц, в случаее задержек платим пени(столько-то). По вине исполнителя(не важно кого, программист, менеджер проекта..... ) эти сроки были нарушены. L>Что все склоня голову платят положенные пени? L>Или как-то пытаются выйти из данной ситуации.
Тут главное — причина нарушения сроков. Если протормозили по раздолбайству — скорее всего отмазаться не получится.
А если недооценили, но всё, что делалось в проекте честно отслеживалось с записью времени (привет сторонникам минимального менеждмента), то можно показать эти данные заказчику и попробовать договориться.
Типа "Да, иы слажали, не оценили то-то и то-то. Вы видите по документам, что мы не пинали балду, а честно вкалывали. Да, по закону мы обязаны выплатить пени, но при сложившихся обстоятельствах успеть было практически не реально. Мы, как и вы, заинтересованы в успехе проекта. Нам нужно столько-то времени, чтобы всё доделать. Мы готовы это сделать бесплатно (по минимальным ценам), если вы не против продлить сроки проекта на указанную величину."
Главное, приходить на переговоры с:
— чётким пониманием, почему произошла задержка. Если недооценили — то что именно и почему. Если протормозили — то почему
— документами, наглядно показывающими ситуацию в проекте, желательно на всём его протяжении
— конкретными предложениями (лучше несколькими) по дальнейшим действиям. Все они должны быть предварительно оценены
— точной оценкой оставшегося времени. Если заказчик согласится продлить проект, тут ошибиться будет уже недопустимо
Может, получится, может — нет. Попытаться, по крайней мере, стоит.
Вот еще дополнение к предыдущему посту:
Риск провала сроков обычно реализуется отнюдь не в последний день перед сдачей готового билда Заказчику. Обычно — много-много раньше появляются "первые звоночки" — типа накапливается постоянное отставание по сроками промежуточных вех (контрольных точек), не снижается, а, наоборот, растет количество ошибок в промежуточных релизах, уволился ведущий разработчик.... и т.п. Вот переговоры с заказчиком — об урезании функционала ли, о подвижке сроков релиза ли.... короче, по ситуации — необходимо начинать именно в этот момент. Никто не любит получать плохие известия в самый последний момент, когда нет уже времени предпринять корректирующие действия, и ваш заказчик — тоже!
Чем раньше начнете переговоры — тем больше вероятность договориться полюбовно.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, linker,
V_S>Вот еще дополнение к предыдущему посту: V_S>Риск провала сроков обычно реализуется отнюдь не в последний день перед сдачей готового билда Заказчику. Обычно — много-много раньше появляются "первые звоночки" — типа накапливается постоянное отставание по сроками промежуточных вех (контрольных точек), не снижается, а, наоборот, растет количество ошибок в промежуточных релизах, уволился ведущий разработчик.... и т.п. Вот переговоры с заказчиком — об урезании функционала ли, о подвижке сроков релиза ли.... короче, по ситуации — необходимо начинать именно в этот момент. Никто не любит получать плохие известия в самый последний момент, когда нет уже времени предпринять корректирующие действия, и ваш заказчик — тоже! V_S>Чем раньше начнете переговоры — тем больше вероятность договориться полюбовно.
А я ни где не упомянул, что приходит день сдачи проекта, а мы начинем выкручиваться.
Здравствуйте, linker, Вы писали:
L>День добрый.
L>Интересует такая ситуация.Допустим Подписали договор где четко прописано что срок месяц, в случаее задержек платим пени(столько-то). По вине исполнителя(не важно кого, программист, менеджер проекта..... ) эти сроки были нарушены. L>Что все склоня голову платят положенные пени? L>Или как-то пытаются выйти из данной ситуации.
А вот если Заказчик подписал договор, по которому он обязан заплатить по приемке работ бабки, и Исполнитель взял и сдал работу в срок, Заказчик че, я не поэл, прям склоня голову как лох должен платить положенные деньги? Или все-таки как-то пытается выйти из ситуации?
Интересно, а о чем и какой головой Исполнитель думает, подписывая договор с таким условием, как Вы приводите? Договор — это вообще серьезно, знаете-ли, и подписывая его с такой формулировкой, вы декларируете, соглашаетесь с его условиями. Подпись Исполнителя под договором означает именно это, и вовсе не подразумевает, что Вы будете нарушая его "выходить из ситуации". Что вообще значит "пытаться выйти из ситуации", я не понимаю? Нанимайте адвокатов, и пытайтесь выйти из ситуации в арбитражном суде. Или — устраивайте терки "по понятиям".
Здравствуйте, linker, Вы писали:
L>День добрый.
L>Интересует такая ситуация.Допустим Подписали договор где четко прописано что срок месяц, в случаее задержек платим пени(столько-то). По вине исполнителя(не важно кого, программист, менеджер проекта..... ) эти сроки были нарушены. L>Что все склоня голову платят положенные пени? L>Или как-то пытаются выйти из данной ситуации.
Есть несколько вариантов:
1. Посчитать, сколько будет стоить срыв сроков Вашей компании по внутренним рейтам программеров (умножьте зарплаты на два, если грубо) — зарплату ведь им платить не перестают. Сравните с полученное число суммой пеней — они же копеечные, конечно, если проектом реально занимаются и срыв сроков небольшой. Сразу станет легче на душе, главное — не знакомить с этими цифрами руководство Оно и так знает, но в этом случае будет обязано Вас наказать. В общем, ответ — заплатить и не мучиться.
2. Собрать все доптребования заказчика, посчитать, во сколько вылилась их реализация и попытаться использовать сумму в качестве аргумента при убеждении заказчика не выставлять штрафы.
3. Сделать сборку с неполным функционалом или заглушками, отдать неоттестированный и откровенно глючный код — заказчик умучается доказывать в суде, что функционал неполный.
4. Проанализировать ТЗ и законно обрезать функционал по самое не хочу. Это при условии, что нет подписанного SRS. Как правило, подписанное ТЗ — это набор общих фраз. Конечно, если были допсоглашения — хуже, но это редкость.
В общем, вот так. На практике же выставление пеней для заказчика — это такая головная боль, что если предложить ЛПР (лицу, принимающему решение) выпить с Вами, чтобы в процессе выпивки устранить недоразумение — он на это пойдет с 90% вероятностью.
Естественно, все вышесказанное справедливо только для Ex-USSR.
А вообще, лучше для Вашей компании будет п.1 — заплатить штраф по-честному. Нет более лучшего и дешевого стимула для внедрения процесса инкрементальной сборки
Здравствуйте, linker, Вы писали:
V_S>>Чем раньше начнете переговоры — тем больше вероятность договориться полюбовно.
L>А я ни где не упомянул, что приходит день сдачи проекта, а мы начинем выкручиваться.
Тогда опишите подробно ситуацию: какие сейчас видятся риски, степень их влияния, какие предупреждающие действия для этого можно предпринять, сколько идет проект и сколько времени осталось до сдачи, на сколько примерно будет задержка, какие суммы пеней и т.д. Или в процессе фиксации всего этого на бумаге Вы сами поймете выход, или Вам здесь действительно подскажут, что можно сделать.
Если нет конкретики в вопросе — не будет и конкретики в ответах. Пока, на основании данной Вами информации, можно сказать следующее: чистите критический путь, расставляйте задачи по приоритетам, фиксируйте запросы заказчика на изменения и подписывайте на их основании дополнительные соглашения с переносом сроков и изменение цены. Легче стало? Вряд ли.
В заключение приведу цитату из "Вальсируя с медведями" Демарко и Листера:
--------------------------
Риски, общие для всех проектов разработки программного обеспечения
Возможно, вы могли бы составить список из 20 или 30 проблем, которые столь вездесущи, что разумно ждать их появления, по крайней мере, в некоторой степени, в каждом проекте. Мы выбрали для работы всего пять. Мы выбрали именно эту пятерку, поскольку именно из за них происходит большинство расхождений между планом и реальностью, а также потому, что нам удалось собрать некоторые полезные данные по отрасли о размерах этих рисков. Вот наш список этих главных рисков:
1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций (нечеткое ТЗ)
5. низкая производительность
Только последний из них действительно связан с исполнением. Остальные четыре практически совсем не зависят от того, насколько усердно вы трудитесь и насколько вы компетентны и опытны в исполнении данной работы. Это стоит подчеркнуть, потому что многих руководителей смущает, не станет ли управление риском оправданием плохой работы исполнителей. Принятие разумных мер в отношении этих неконтролируемых событий — суть управления риском. Такие меры не освобождают вас от возможности неудачи, но создают резерв на случай, если некоторые из этих неконтролируемых событий обернутся против вас
--------------------
Интересно, правда? И помните, что 70% программных проектов выходят за сроки. Постарайтесь не войти в эти 70%. Желаю удачи!
Здравствуйте, linker, Вы писали:
L>День добрый.
L>Интересует такая ситуация.Допустим Подписали договор где четко прописано что срок месяц, в случаее задержек платим пени(столько-то). По вине исполнителя(не важно кого, программист, менеджер проекта..... ) эти сроки были нарушены. L>Что все склоня голову платят положенные пени? L>Или как-то пытаются выйти из данной ситуации.
1) Почитайте например Дж.Фокс "Разработка программного обеспечения", много поймете как и почему ползут сроки и чего делать.
2) Почитайте Роберта Гласса "Факты и заблуждения профессионального программирования", поймете, что в начале проекта сроки неизвестны по определению. Следовательно подписывать договор с жесткими сроками не нужно.
Здравствуйте, AZDesign, Вы писали:
AZD>2) Почитайте Роберта Гласса "Факты и заблуждения профессионального программирования", поймете, что в начале проекта сроки неизвестны по определению. Следовательно подписывать договор с жесткими сроками не нужно.
Во-первых, во многих проектах как раз срок и/или бюджет по определению известен заранее и фиксирован (ибо диктуется внешними обстоятельствами), зато функциональность может варьироваться в относительно широких пределах, и в некоторых пределах — качество. На практике — часто, почти всегда при должном умении, управляя последними, можно вывести проект к заданной дате, и, управляя ожиданиями заказчика, сделать проект успешным, если начальная ошибка планирования не была совсем грубой.
Во-вторых, в любом правильно составленном договоре на разработку и дополняющим его ТЗ (в соответствии с ГОСТ 19 или 34, а других действующих правил у нас просто нет) всегда всегда стоят именно жесткие сроки сдачи этапов. Следовательно, подписывать договор с жесткими сроками рано или поздно прийдется. И чем крупнее проект, тем скорее прийдется.
Но это не является катастрофой — ибо:
1) Правилами предусмотрена процедура внесения изменений в ТЗ, и, соответственно, этапы работ и их сроки по согласию сторон.
2) Есть возможность подвинуть сроки обойдясь и без этой процедуры, если написать в ТЗ в сроке "в соответствии с ведомостью исполнения". В данном случае, исправляется только ведомость исполнения, что вообще не предполагает особой процедуры, кроме согласия сторон. Таким образом, "жесткий срок" остается, но становится по факту крайне гибким сроком .
19-й ГОСТ (ЕСПД) есть в сети, очень разумный стандарт, регламентирующий отношения и документооборот заказчика и исполнителя, хоть и 79 года. Рекомендую.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AZDesign, Вы писали:
G>19-й ГОСТ (ЕСПД) есть в сети, очень разумный стандарт, регламентирующий отношения и документооборот заказчика и исполнителя, хоть и 79 года. Рекомендую.
0) Документ 77 года, вступил в действие в 01.01.1980 года.
1) Менеджеры до сих пор думают что ПО разрабатывается по каскадной модели, он не желают читать ни Джонса, ни Брукса, ни Фокса, ни Гласса. Этот стандарт описывает именно такую модель.
2) Никто не хочет видеть, что в этой модели нет этапа ТЕСТИРОВАНИЕ, потому что тестирование практически всегда возвращает разработчика на предыдущие этапы, что превращает каскадную модель в водопадную, и следовательно с неуправляемыми сроками.
3) На самом деле, и водопадная модель плохо описывает процесс разработки, несколько лучше процесс разработки описывает плоская спиральная модель.
4) Более точно процесс разработки описывается вертикальной спиральной моделью, и пониманием для чего нужно тестирование.
G>Во-первых, во многих проектах как раз срок и/или бюджет по определению известен заранее и фиксирован (ибо диктуется внешними обстоятельствами), зато функциональность может варьироваться в относительно широких пределах, и в некоторых пределах — качество. На практике — часто, почти всегда при должном умении, управляя последними, можно вывести проект к заданной дате, и, управляя ожиданиями заказчика, сделать проект успешным, если начальная ошибка планирования не была совсем грубой.
5) На практике Заказчик хочет получить результат вчера, в лучшем случае — завтра, за 2 копейки и самого лучшего качества. Исполнитель как правило соглашается с этими сроками (условиями) и всучает заказчику недоделанную, неработающую систему в срок. Заказчик не зная как должно быть, принимает это как выполненную работу.
Ведь именно об этом Вы пишете — "управляя ожиданиями заказчика и функциональностью" можно сделать проект успешным, с точки зрения менеджера. А с точки зрения разработчика? Читайте Гласса. Очень рекоменую.
Здравствуйте, AZDesign, Вы писали:
G>>19-й ГОСТ (ЕСПД) есть в сети, очень разумный стандарт, регламентирующий отношения и документооборот заказчика и исполнителя, хоть и 79 года. Рекомендую.
AZD>1) Менеджеры до сих пор думают что ПО разрабатывается по каскадной модели, он не желают читать ни Джонса, ни Брукса, ни Фокса, ни Гласса. Этот стандарт описывает именно такую модель.
Нет, менеджеры так не думают, это распространенное заблуждение программистов. И второе — этот стандарт не описывает такую модель, он вообще совершенно нейтрален к тому, как именно Вы будете вести разработку. Он описывает взаимодействие с заказчиком, не более того. В рамках данного стандарта несложно оформить хоть проект, который ведется по новомодному Скраму, хоть RUP-овский, никаких проблем.
AZD>2) Никто не хочет видеть, что в этой модели нет этапа ТЕСТИРОВАНИЕ, потому что тестирование практически всегда возвращает разработчика на предыдущие этапы, что превращает каскадную модель в водопадную, и следовательно с неуправляемыми сроками.
В этой модели Вы можете задавать ВООБЩЕ ЛЮБЫЕ этапы, какие захотите, о чем явно написано в стандарте, и чем все активно пользуются. Стандартные этапы даны исключительно в виде рекомендации.
И второе, — даже типовые этапы в ГОСТ 19 имеют больше общего с этапами RUP-освкой цикла, чем с мифическим существующим только в книжках вотерфолом, где формулируются исключительно критерии приемки, но не активности. И это понятно, ибо заказчика Ваши активности интересуют мало — его интересует именно приемка.
AZD>3) На самом деле, и водопадная модель плохо описывает процесс разработки, несколько лучше процесс разработки описывает плоская спиральная модель. AZD>4) Более точно процесс разработки описывается вертикальной спиральной моделью, и пониманием для чего нужно тестирование.
Более точно процесс разработки описывается моделью "контроллируемая итерация" в RUP, которая фиксируется не на активностях, а смотрит на процесс разработки ПО как на частный случай problem solving process. Именно такой взгляж на этапы и присутствует во всех ГОСТ, кроме, вероятно, 34-го.
G>>Во-первых, во многих проектах как раз срок и/или бюджет по определению известен заранее и фиксирован (ибо диктуется внешними обстоятельствами), зато функциональность может варьироваться в относительно широких пределах, и в некоторых пределах — качество. На практике — часто, почти всегда при должном умении, управляя последними, можно вывести проект к заданной дате, и, управляя ожиданиями заказчика, сделать проект успешным, если начальная ошибка планирования не была совсем грубой. AZD>5) На практике Заказчик хочет получить результат вчера, в лучшем случае — завтра, за 2 копейки и самого лучшего качества. Исполнитель как правило соглашается с этими сроками (условиями) и всучает заказчику недоделанную, неработающую систему в срок. Заказчик не зная как должно быть, принимает это как выполненную работу.
На практике к такому приводит только отсутствие компетентного менеджмента с обеих сторон, ибо его работа как раз и состоит в том, чтобы не допускать подобных ситуаций. После "сдачи" проекта разумные люди вставляют длительный этап внедрения и/или поддержки, который оплачивается отдельно (некоторая часть суммы проекта может быть перенесена на данный этап). Это нивелирует подобные "фокусы" с качеством, и выгодно обоим сторонам. Я на этом настаиваю, как Заказчик. Исполнителю это так же выгодно, кстати, если он не собирается кидать Заказчика.
Также этому способствует внимательное отношение обеих сторон к "программе и методике испытаний", которая по своей сути является приемочным тестпланом и детализацией общих требований, записанных в ТЗ. Я на этом настаиваю, когда нахожусь как на стороне Исполнителя, так и Заказчика, ибо снимает все детские проблемы с приемкой работ и взаимным непониманием.
AZD>Ведь именно об этом Вы пишете — "управляя ожиданиями заказчика и функциональностью" можно сделать проект успешным, с точки зрения менеджера. А с точки зрения разработчика?
"Управляя ожиданиями" редко можно сделать успешным проект, который не решает проблем Заказчика, ибо он поймет это если не рано, то поздно. Грамотное "управление ожиданиями" нацелено не на обман, а в первую очередь на достижение взаимопонимания сторон, и позволяет Исполнителю и Заказчику работать над проблемами совместно и кооперативно, не находясь при этом в вялотекущем конфликте по разные стороны баррикад и пытаясь друг друга по мелочи кинуть.
Я как разработчик в относительно недавнем прошлом (года 4 назад), и как менеджер в настоящем, не понимаю, что Вы называете, "проектом, успешным с точки зрения разработчика, но не менеджера". Проект успешен тогда и только тогда, когда решает проблемы, послужившие мотивацией для его старта, в условиях допустимых ограничений и расходов. Если он их решает по большей части — то он по большей части успешен. Если он эти проблемы не решает, и проблемы за отчетный период не изменились — это все равно провальный проект, даже если он соответствует ТЗ и прочим бумажкам на 100% и сдан в срок. У разработчика есть на эту тему особое мнение?
AZD> Читайте Гласса. Очень рекоменую.
Я со своей стороны очень рекомендую побольше практики. Имея богатую практику и опыт, можно себе позволить иметь свое мнение касательно того, что пишут и говорят, а не только цитировать и трактовать книги.
Здравствуйте, linker, Вы писали:
L>Но заказчику нужен проект и он может пойти на компромисы.Вот я и спрашиваю были ли случаи у кого кто находило такие компромисы.
Не совсем понятно, как Вы видите ситуацию при которой заказчик готов пойти на компромисс, потому что ему нужен проект: то есть — есть такой вариант при котором он не получит проект, если потребует пени? У Вас, что, 100% аванс получен, и Вы рассчитываете на процедуру банкротства?
Здравствуйте, linker, Вы писали:
L>Юридически то все понятно.Но заказчику нужен проект и он может пойти на компромисы.Вот я и спрашиваю были ли случаи у кого кто находило такие компромисы.
Конечно были. Я бы сказал, это является нормой. Если ситуация изменилась (так или иначе, например — вы столкнулись с неожиданными сложностями, которые не получилось заранее предусмотреть), то вы встречаетесь с Заказчиком, обсуждаете ситуацию, и по достижении договоренности вносите правки в ТЗ. ТЗ изменять по ходу работ можно, есть процедура. Сроки этапов и сами этапы являются частью ТЗ (см. ЕСПД), и их изменение обрабатывается точно так же, как изменение технических требований.
Обыкновенно Заказчик относится к этому нормально, при условии, что вы предупреждаете его заранее. Он готов к компромиссу, ибо выгода его состоит в достижении результата работ, а вовсе не в получении пеней. Если эти обстоятельства возникают в последний момент на сдаче, то это бесит Заказчика. Поставьте себя на его место, и все поймете.
Однако, Вы написали, что задержка прошла "неважно по какой причине", и что выясняется это в конце. В данном случае Вам будет очень тяжело прийти к компромиссу с Заказчиком — по всем понятиям в такой ситуации Исполнитель должен добровольно заплатить пени, а не пытаться от них увиливать, ибо последнее создает крайне негативное впечатление. Получается, что люди мало того, что все прощелкали, подставили Заказчика, который рассчитывал на работу в определенные сроки, так еще и от ответственности, на которую соглашались в начале, собираются увильнуть. Это лучшая демонстрация со стороны Исполнителя, что он недобросовестный, и что доверять ему нельзя, ибо судят людей именно по поступкам, а не по словам.
Здравствуйте, Gaperton, Вы писали:
G>Обыкновенно Заказчик относится к этому нормально, при условии, что вы предупреждаете его заранее. Он готов к компромиссу, ибо выгода его состоит в достижении результата работ, а вовсе не в получении пеней. Если эти обстоятельства возникают в последний момент на сдаче, то это бесит Заказчика. Поставьте себя на его место, и все поймете.
Так и есть.
Если управленец:
1) планирует сроки, риски, ресурсы,...
2) мониторит ситуацию на проекте
3) вовремя реагирует на расхождения с планами, привлекая кого надо
и при необходимости обновляя планы (естественно с участием заказчика)
то заказчик врядли подумает о неустойках...
Если же исполнитель начинает лепетать «Ну не шмогла я, не шмогла!»
за день до релиза, то никто на встречу исполнителю не пойдет...
Кстати, заказчик, который слабо интересуется проектом и никак его не мониторит,
тоже поступает весьма неразумно. Ну стресет он возможно что-то с исполнителя,
но время, которое деньги, будет все равно упущено.
G>>19-й ГОСТ (ЕСПД) есть в сети, очень разумный стандарт, регламентирующий отношения и документооборот заказчика и исполнителя, хоть и 79 года. Рекомендую. AZD>0) Документ 77 года, вступил в действие в 01.01.1980 года. AZD>1) Менеджеры до сих пор думают что ПО разрабатывается по каскадной модели, он не желают читать ни Джонса, ни Брукса, ни Фокса, ни Гласса. Этот стандарт описывает именно такую модель. AZD>2) Никто не хочет видеть, что в этой модели нет этапа ТЕСТИРОВАНИЕ, потому что тестирование практически всегда возвращает разработчика на предыдущие этапы, что превращает каскадную модель в водопадную, и следовательно с неуправляемыми сроками. AZD>3) На самом деле, и водопадная модель плохо описывает процесс разработки, несколько лучше процесс разработки описывает плоская спиральная модель. AZD>4) Более точно процесс разработки описывается вертикальной спиральной моделью, и пониманием для чего нужно тестирование.
Твою книжку написали до изобретения унифицированного процесса (RUP, OpenUP) и Agile. Имхо примерно в одно время с эти ГОСТом
А может ты из Мелкософта? Они до сих пор на спиральках помешаны
Переговоры с Заказчиком — тоже дело не лишнее.
