Картинка показывает программиста и тестировщика, которые вынуждены работать сверх меры и бьют менеджера проекта. Далеко не всегда в такой ситуации виноват менеджер. Точно также можно было бы отлупить битой всех в конторе, кто пойдёт домой вовремя. Выходом всегда является непрерывное внимание руководства к каждому сотруднику и ежедневная мотивация. И я считаю, что надо избегать переработок, когда это только возможно. Они появляются, когда руководство требует от программистов выполнить сложную задачу в сжатый срок, ловит их на обещании сделать это. Часто при этом оно скидывает на исполнителей те задачи, которыми должно заниматься самостоятельно -- в том числе оценки сроков. Ведь зачастую кодер, даже будь он профи, по ряду причин не может определить правильное и гарантированное время выполения очередного этапа работы. Причинами могут быть не только непредсказуемые гуманитарные факторы, к которым руководство часто не лояльно -- болезнь, транспортные и семейные проблемы и т.п. Причиной нередко бывает неспособность руководства отслеживать взаимоодействие программистов с другими участниками бизнеса и быть справедливым судьёй. Отношения в коллективе часто бывают ключевой проблемой, в том числе и для программистов.

Бизнес также сильно страдает от неумелой кадровой политики. Считать программистов легко заменяемыми шестернями - глупо и наивно как раз потому, что введение нового программиста в курс дела зачастую намного больше ресурсов вытягивает из компании.   Владельцы бизнеса по-видимому предполагают, что создание комфортных условий для кодеров демотивирует оных. Однако на практике кодера демотивирует работа на износ намного больше, чем лояльность руководства к срокам выполнения работы. Руководителю следует присмотреться к срывающему сроки программисту и озаботиться не его заменой, а сначала причинами, по которым опытный и уже вошедший в курс дела сотрудник вдруг стал срывать срок. А программисту, в свою очередь, нужно решить, оставаться в этом бизнесе или нет. Если да -- попробовать объяснить начальству несоответствие объёма работы срокам, убедить его в этом, и впредь стараться не брать на себя ответственность за сроки, которые являются компетенцией менеджера проекта, как минимум.  А если нет -- срочно искать другую работу и переходить на неё. Работать на износ, срывая сроки, не надо, т.к. это ведёт к увольнению почти всегда.

В России, к сожалению, модно держать (особенно в небольших фирмах) одного ведущего программиста, который выполняет и функции менеджера проекта, получает приличную зарплату и является ключевым сотрудником. Остальные программисты приходят и уходят как раз потому, что вместо построения из них команды, руководство выжимает из них все соки, рассчитывая на то, что ключевой сотрудник поможет новым программистам войти в курс дела. Поскольку ключевой фигуре выгодно такое положение дел, то обычно в фирме нет доступной новым программистам, развитой и хорошо структурированной документации по разрабатываемому ПО и наработанным методикам. Нет и кадровой инфраструктуры разработки ПО -- тестировщиков, технических писателей, менеджеров проекта. Отсутствие документации и методик даже мотивируется, бывает, необходимостью проверить компетентность кодера --- сможет ли тот разобраться в чужом коде с минимальной словесной помощью ключевого сотрудника или готовящегося увольняться коллеги. Такое нередко бывает в конторах-исполнителях заказов для крупных государствееных монополий, например, для Газпрома. Основная причина -- жадность, нежелание делиться зарплатой. Срыв сроков становится коррупционно выгодным: под него можно выбить дополнительные деньги у госзаказчика, и одновременно регулярно избавляться от уставших и измученных программистов. 

Особо циничные руководители лгут программисту о перспективе повышения и предлагают ему набрать себе команду подчинённых, якобы проверяя способности его подбирать кадры. А потом, после удачного приёма кадров на работу, спешат объявить ему, что он на самом деле плохой специалист, сорвал все возможные сроки, мало сделал для фирмы и никакого повышения не достоин, и вообще больше не нужен. Чтобы защитить себя от этого, никогда, никогда не берите на себя такую работу, а лучше откройте снова доступ к своему резюме.

Кстати, а Вам нужен IT-директор, менеджер проекта, team lead или ведущий IT-специалист, который наведёт порядок в Вашем IT-бизнесе? Если нужен, то автор сих строк предлагает Вам свои услуги: http://help-in.ru/node/40

См. также -- статья по теме: http://adf.ly/RDIqc