Как стать автором
Обновить

Комментарии 6

К сожалению, проект не удалось закончить в нужный срок.

Я конечно извиняюсь за занудство, но гораздо лучше будет написать: "Проект не удается завершить к указанному сроку" и объяснить причины. Заранее, причем, чем раньше, тем лучше. В идеале - при постановке задачи и желательно не устно, а например е-мейлом. Подумать, что можно было бы сделать, чтобы уложиться в срок и дать свои предложения. Потому что не только менеджеры должны думать и планировать, но и исполнители.

Запрашиваю статью-побратим о ситуациях, когда в дедлайн вписались, но лучше бы не вписывались. И поделюсь примерчиком в стиле бравого солдата Швейка.

Был как-то случай в одной геймдевской конторе, которая пока есть, но уже как бы нет.
Кому-то приспичило выпустить обновление в релиз. В пятницу. В пять вечера. Рецепт упеха!

Конечно же, ОПЯТЬ упустили типовую ошибку при формировании версии, из-за которой от 1к до 100к игроков (по крайне оптимистичным прогнозам - ивент, хвосты которого так удачно убрали патчем, был... мягко говоря, популярным) не смогло бы войти в игру до момента исправления.
То есть примерно до вечера понедельника потому, что люди закончили деплоить - люди разошлись.
Пятница же.

Дошло до продьюсера, совершенно случайно подзадержавшегося в здании и перехватившего первые слухи о полундре. Именно тогда можно было увидеть, как по жизни наиспокойнейший уравновешенный человек "мерцает" между режимами KALM и PANIK со скоростью до 60 раз в минуту.

Пришлось первому же попавшемуся под руку болвану, только номинально умеющему что-то кодить, срочно клепать на коленке фикс для клиентской стороны, для раздачи через техподдержку в индивидуальном порядке. Справился он с третьей попытки (проблема то типовая и даже распоследняя макака уже примерно понимала, что где надо на клиенте подпирать), хотя. Должен. Был. Уже. БЫТЬ. ДОМА. С. ЛЮБИМОЙ. ЖЕНЩИНОЙ. ААРРРРРРРРГХ!!!

И шо вы думаете, ни постмортема, ни крепкого рукопожатия за трудовой подвиг!

> почему не соблюдаем дедлайны и что с этим делать

Потому что фундаментально невозможно спрогнозировать за сколько будет выполнена задача, в свою очередь потому что на это влияет бесконечное число факторов. Что с этим делать? Смириться, или отбыть в другую вселенную.

Можно даже без другой Вселенной. Просто, при планировании закладывать коэффициент 1.5-2. И поскольку факторов бесконечное количество, то этот запас времени будет покрывает 95-99% случаев. Причем, как показывает моя практика, даже при наличии запаса времени, разработчик не бездельничает, а просто делает работу более качественно, например без технического долга. Или даже задел на будущее в виде хорошо продуманной архитектуры.

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

Просто, при планировании закладывать коэффициент 1.5-2

Умножать конечно стоит, но на всех случаи жизни это не поможет. У меня был как-то случай, когда столкнулся с ошибкой в API Райффайзен банка. У меня месяц ушел на то, чтобы доказать им, что ошибка с их стороны.

Открываем трудовой договор. Смотрим количество часов, которые вы должны отработать. Честно отрабатываете эти часы.

А все эти разговоры про горящие сроки - просто желание бизнеса заплатить за 160 часов программиста в месяц, а по итогу получить 200 или еще больше. Хотите сохранить свое здоровье - тренируйте стойкость к такому разводу. Иначе потом на врачей будете работать.

P.S. Конечно, проблемы начинаются тогда, когда вы сами озвучили сроки, а потом не можете сдержать слово. Здесь есть следующие варианты:

  • Не говорить никаких сроков, которые спрашивают здесь и сейчас (типа давай, за 5 секунд в голове прикинь и скажи сроки). Если руководство хочет реальных сроков - их нужно считать: вникать в задачу, декомпозировать её на небольшие понятные задачи на 15-20 минут. И одна только такая декомпозиция и анализ может занять несколько дней.

  • Если все же вас просят оценить здесь и сейчас, обязательно добавляйте слова "на вскидку...", "я думаю что..." и т.д. В общем никаких точно и железно.

  • Если вас часто просят оценить задачу сходу - потратьте пол часа и объясните людям, что оценивать сроки за 5 секунд некорректно и невозможно - это тоже самое, что тыкать пальцем в небо. Обязательно расскажите про случаи, когда какая-то задача на первый взгляд выглядела просто, а стоило вникнуть - оказывалось, что там еще это делать и это и это. Если таких историй вспомнить с ходу не можете (хотя у любого опытного программиста они были) - вспомните, запишите и заучите, чтобы всегда иметь аргументы на руках.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий