Игорь Батраков

Есть договор, где прописаны ответственность сторон, согласно ему и определяется кто прав, а кто нет.
Но исходя из общепринятых норм, верстка- верстальщику, программирование - программерам. Вообще эти процессы не должны быть разорваны во времени. Это вполне ожидаемо, что на этапе разработки понадобились доработки верстки.
Ответственным за такие не состыковки, должен быть менеджер проекта. Который ставил задачи верстальщикам и писал Т.З. Судя по всему это Вы.

Единственно не понятно почему нет верстальщика на подхвате. С ним договор должен был быть, что он обязан до сдачи проекта быть на подхвате. Но опять таки это проблема плохой организации. Если Вы заказчик, надо было такой крупный проект отдать компании, которая взяла бы все геморы на себя. Но Вы видимо решили сэкономить. Так если сэкономили, почему бы не подкинуть денег стороннему верстальщику, который оперативно решит все проблемы?

А почему вы сами не проверили верстку, когда принимали её?

Вообще программисты не должны её проверять — они получили исходные материалы от вас, которые должны были заранее пройти проверку. Программисты просто пишут код за деньги согласно ТЗ.
Это точно также, как получить от клиента тексты и фотографии для сайта, а потом сообщить клиенту, что у него в тексте куча орфографических и фактических ошибок. Чья это головная боль?

Другое дело, что у программистов нет своего верстальщика, хотя бы на аутсорсе, потому что это дополнительная услуга и дополнительный заработок.

Вообще, в таком случае я бы либо общался с верстальщиком и предъявлял ему счет за правки, который вы получили от программистов, поскольку верстальщик не доверстал, не доделал свою работу. Либо проверял макеты, соответствие макетов и верстки, чтобы найти истинную причину такого косяка.
И все же верстку кто-то принимал, кто упустил модальные окна и прочие несверстанные элементы, о которых сейчас вам сообщают программисты.

Тот кто укладывается в сроки - их для вас просто раздул.
Чем больше наказание за срыв - тем больше происходит раздутие срока.
Может дойти до разгильдяйства, которое можно проконтролировать только наблюдая за сотрудником.

У нас применяется практика раздутия сроков, но с контролем. Контролируем трафик, имеем ряд запрещенных сайтов (сжирателей времени), и контролируем приход-уход с работы. Этого достаточно как превентивной меры от лени и занятостью не там делом. Менеджеры получают отчет по активности за неделю в пятницу и могут на выходных принять решение кому в понедельник вставить пистонов.

Те кто ходят на 9:30 и уходят в 17:30 и обедают 1.5 часа получают в соотв. % зарплату в конце месяца. Колво рабочих дней * 8 - сумма по трекингу в офисе или удаленке для тех кто злостный нарушитель.

Нужно не столько наказывать, сколько тщательнее контролировать, чтобы на промежуточной стадии было видно успевает или нет.
Не успевает - овертайм. Можно овертайм даже оплатить отдельно, если причины запоздания убедительны.

Несколько овертаймов, но сданных вовремя проектов - и разработчики будут лучше продумывать свои сроки.

Ну начнете наказывать девелоперов, они начнут называть сроки вроде месяца для задач на неделю.

Тут одно дело, когда работа шаблонная, многократно выполненная (как скажем типовой сайт), в таком случае все сроки можно прикинуть более-менее точно. Другое дело, когда что-нибудь создается уникальное и не шаблонное, ошибка может быть в разы.

Я бы посоветовал два-три раза в неделю узнавать у каждого, чем он занимался предыдущие дни, какие проблемы есть, какие решения он видит, чтобы видеть в реальном времени как меняется оценка и ситуация. Но да, тут желательно бы самому разбираться хотя бы на среднем уровне, чтобы понимать о чем речь вообще.

Любое наказание - демотивация. Даже словесный бубнеж. Вы заложили погрешность расчетов или просто утвердили названные сроки "как есть"? если да, то у меня для вас плохие новости. Нужно закладывать 20%-50%

Ну человек не робот, все имеют право на ошибку, иногда всё сделано на 90% и бах ошибка с которой весь день сидеть можно...
Я бы спросил так: как уменьшить вероятность срыва сроков?

Кипятильник же

UPD:

Так то Agile призван отследить подобную хрень.