http://habrahabr.ru/post/244309/

Я часто ловлю себя на мысли, что наличие сроков при написании software может давать негативный эффект, хотя многие считают, что сроки – это полезно. Мне кажется, что их нужно применять все-таки с осторожностью (как и любую другую таблетку счастья). Я попытался проанализировать, как же сроками можно навредить проекту, а как сроками можно улучшить будущий результат.
Для тех, кому лень читать всю статью: я считаю, что сроки нужны, но менеджеры и программисты должны понимать, что иногда сроки проваливаются, и что в этом нет большой трагедии. Иногда в проваленных сроках виноваты обстоятельства, а не конкретные люди.

Иметь дедлайны для вещей, которые ты делаешь – это полезно. Но в случае с программированием есть некоторые нюансы.

Как сроки помогают писать софт

Благодаря срокам можно планировать будущее. Если мы планируем закончить работу над фичей Х через 2 месяца, то мы знаем, что через 3 месяца мы можем делать релиз новой версии нашего софта.

Сроки помогают с рационализацией/оптимизацией: если мы знаем, что по срокам Петя заканчивает работу над фичей Х через 2 месяца, а Вася заканчивает работать над своим таском через 2 дня, то нам проще сориентироваться в том, у кого сколько работы. Если завтра появится какой-то баг средней важности, то мы сможем рационально взвесить ситуацию, и решить, что мы дадим фиксать этот баг Васе, который через 2 дня будет свободен.

Сроки могут также выступать в виде дополнительного способа спецификации задания. Программист может маневрировать под влиянием сроков – где-то он будет более усерден и чистоплотен, а где-то он не будет. И это хорошо, т.к. за счет таких маневров, в конечном итоге скорость разработки софта вырастет.

Как сроки мешают писать хороший софт

К сожалению, программирование – сложная штука, и правильно рассчитать сроки наперед не могут даже хорошие специалисты. К тому же большинство программистов оценивают сроки чрезмерно оптимистично. Поэтому часто дедлайны оказываются просроченными. Получается, что программисту нужно вложить много эмоций и усилий для того, чтобы закончить какую-то задачу в оговоренные сроки. Программист может называть неоправданно оптимистичные сроки под давлением менеджеров. Еще хуже, когда менеджеры сами называют сроки программистам.

Сроки в глазах многих программистов — это какой-то карательно-упрекающий инструмент менеджеров. У таких программистов сроки вызывают некоторый эмоциональный дискомфорт. Когда программисту нехорошо на эмоциональном уровне, то скорее всего его эффективность уменьшится.

Когда программист видит, что он не успевает закрыть задачу в нужные сроки, он будет работать с повышенным усердием и повышенной концентрацией. Я вижу 2 следствия из этого:

• Уменьшается оперативная маневренность программиста. Если он знает, что он чертовски отстает по какой-то задаче, то он будет занимать более пассивную позицию в общей жизни рабочего коллектива – он перестанет помогать новичкам, будет отмахиваться первым пришедшим в голову решением, когда нужно будет обсудить какую-то будущую архитектуру. Если над «просрочиваемой» задачей работают несколько человек, то очень вероятно, что каждый из них начнет перекидывать ответственность с одного на другого, т.к. у них банально не будет времени для того, чтобы взять инициативу в свои руки и скоординировать общее взаимодействие.
• Программист, как и любой другой человек, устает. Если в среднем он писал 50 кг красивого кода, то под давлением дедлайнов он начнет писать 75 кг красивого кода. Но так длиться вечно не будет, он либо начнет писать 75 кг некрасивого кода, либо он рано или поздно «откатится» обратно на свою стандартную продуктивность в 50 кг красивого кода. И сразу после сдачи этой просроченой задачи, он скорее откатится в негативную сторону – хотя бы несколько первых дней он будет писать лишь по 30-40 кг красивого кода.

В конце концов, программист будет думать «В чем я виноват? Из-за чего я теперь должен вкладывать экстра усилия в свою работу? Только потому, что я неправильно оценил сроки?». С такими мыслями любой человек очень быстро потеряет мотивацию к своей работе.

Кто же виноват? И как спасать ситуацию?

Как обычно, истина находится где-то посредине между менеджером и программистом. Со стороны менеджера я бы:

• Позволил программисту называть свои собственные сроки (если у нас так еще не происходит). Если я вижу, что программист ощущает давление с моей стороны и пытается назвать слишком быстрые сроки, то я бы попытался убрать это давление – зачем мне программист, который называет неправильные сроки при моем виде?
• Следил за валидностью сроков (спасибо ncix). Если на мой вопрос о сроках программист отвечат «А, через месяц будет сделано». То я бы попросил программиста показать мне, как за месяц он планирует это сделать, на какие подэтапы он будет разбивать работу. Как быстро он ожидает завершить каждый из подэтапов.
• Налаживал эмоциональное взаимопонимание с программистом.
  
  • Программист тогда не будет чувствовать себя угнетенным, если у него будет «застревать» таск. Он просто пойдет к менеджеру и скажет: «Степаныч, так и так, не успеваю… Что делаем? Даем экстра ресурсы на задачу или переносим сроки?»
  • У программиста исчезнет чувство вины за неуспевание по дедлайну, и он будет более откровенен с менеджером. Сроки перестанут быть карательным инструментом менеджера в глазах программиста.
• Как следует следил бы за честностью и справедливостью в коллективе. Т.к. я предлагаю высокий уровень доверия и свободы по отношению к программистам, то могут найтись такие программисты, которые попытаются получить из этого выгоду окольными путями. Таких программистов нужно исключать из коллектива, т.к. они подрывают мораль.

Если бы я был программистом, то я бы:

• Тоже налаживал эмоциональное взаимопонимание со своим менеджером. Я не хочу завтра прийти к менеджеру и сказать «Степаныч, не успеваю...», и бояться, что Степаныч посчитает меня лентяем.
• Не давал бы слабинку: когда спрашивают о сроках и по их лицам видно, что им это нужно завтра, я бы постарался не поддаваться эмоциональному давлению и оценил бы трезво количество работы.

Мораль и раздача призов

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