Меняющиеся требования к проекту. Даже несмотря на согласованное ТЗ и прописанные «санкции» за такие действия.
Внедряйте скрам. Методология разработки, по которой вина за срыв сроков перекладывается на заказчика. А заказчик получает право менять требования «на лету». Все довольны, бюджет освоен.
Я «обезьяна с гранатой» (как ты сам однажды определил мою сущность), сиречь, фрилансер.
Впрочем, твоё предложение заслуживает серьёзного внимания. Такое можно попытаться внедрить и при работе в одиночку (сформулирую, внесу в текст договора), и при работе в команде (иногда случается и в группе поработать).
В первую очередь некомфортные окружающие условия (включая плохую технику). Во вторую очередь низкая мотивация, хочется знать, что результат кому то нужен и облегчит жизнь. В третью очередь глупые требования.
Вот был я на семинаре по этому скраму и что-то показалось мне, что это «научное» обоснование раздолбайства разработчиков и нежелание учиться планировать.
Ещё бы знать, где они есть. Если бы узнал, то попросил бы, может, и меня немножко научили бы.
Но вот для меня загадка, как я при всём при этом умудряюсь почти всегда в сроки укладываться, и по качеству продукта вроде претензий нету («народу нравится»). :)
как я при всём при этом умудряюсь почти всегда в сроки укладываться, и по качеству продукта вроде претензий нету
У меня такая же фигня. Правда натяжка «почти» чуть поболее, наверное. А вот ежели бы умели планировать время, делали бы куда быстрей.
Я вот на работе не сильно афиширую свою производительность. А то попробуй — покажи, что ты можешь работать раза в 4 продуктивней: с шеи же не слезут! За те же копейки.