Как вы справляетесь с планированием/сроками работы программистов?[закрыто]

Question

Любят ли программисты устанавливать сроки?Я веб-разработчик, и графики/сроки выполнения в моей области разные.Но я работал с некоторыми разработчиками программного обеспечения/программистами, которые ненавидят сроки. Есть ли способ обойти это?

Answer 1

Во-первых, нужно различать сроки и смету.

• Сроки исходят из внешних источников, например: «Функция X должна быть готова к выставке».
• Оценки поступают из внутренних источников, например: «Выполнение функции X займет N недель».

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

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

Полезные советы для разработчиков (лидов):

• Пусть человек, выполняющий работу, составит смету.
• Убедитесь, что оценки основаны на небольших задачах, каждая из которых длится не более дня или двух.
• Используйте цикл обратной связи, чтобы позволить разработчикам улучшить свои навыки оценки.
• Навыки точной оценки позволяют вам усерднее выполнять требования сроков.

Полезные советы для маркетологов/создателей дедлайнов:

• Не заменяйте оценку сроком.
• Если срок противоречит оценке, единственные реальные варианты: (а) разработчики работают сверхурочно, (б) требования к сроку сокращаются или (в) срок пропущен.
• Объясните, почему срок важен и какова цель срока реализации функции («клиент X подпишет шестизначный контракт»).
• Поймите, что люди, которые чувствуют, что не могут уложиться в сжатые сроки, не будут мотивированы.

Answer 2

Программисты НЕНАВИДЯТ сроки по очень веским причинам!

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

По моему личному опыту, я потратил больше недели на то, чтобы заставить работать «простой» сценарий оболочки, что, по моим оценкам, заняло бы около часа.С другой стороны, на написание анализатора определений данных COBOL ушло около недели (включая все эти странные COMP COMP-3 OCCURS, переопределяющие SYNC и неактивные байты), что, по моим оценкам, заняло около двух месяцев.

Другая большая проблема заключается в том, что, столкнувшись с сжатыми сроками, программисты пропускают лучшие практики и начинают хакерство.Таким образом, экономится около 50 % времени кодирования, но увеличивается на 300 % время тестирования и отладки.

Answer 3

Традиционно вы можете регулировать только качество, функции или время, последнее из которых — крайний срок.Качество, с которым не хочется возиться.Так что, пока процесс, который вы используете, позволяет вам калибровать функции для достижения сроков, я в порядке.

Answer 4

Разработчиков необходимо привлечь к установлению сроков.Если они произвольны и созданы без участия разработчиков, они имеют право жаловаться.Проекты законно получают временные ограничения от бизнеса, но ресурсы и функции должны быть скорректированы, чтобы компенсировать это.Эти корректировки не могут быть внесены без участия разработчиков (не говоря уже о BA, QA и специалистах по эксплуатации).

Answer 5

Единственные инженеры/разработчики программного обеспечения, которых я встречал, которые ненавидят сроки, чувствуют это по одной из двух причин:

1. Они полностью дезорганизованы и знают, что они не будут соблюдать крайний срок, и поэтому они не нравятся, потому что, когда они пропускают крайний срок, это заставляет их выглядеть плохо.
2. У них нет проблем со сроками, если кто -то, кто понимает задействованную работу, устанавливает крайний срок.Худшие сроки сделаны менеджерами, пытающимися продать проект и сказать «3 недели?Нет проблем! », А затем сообщить своей команде разработчиков, что у них есть 3 недели, чтобы выпустить рабочую версию MS Office и воссоздать Интернет для маленького ребенка генерального директора.

Answer 6

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

Если кто-то из высшего руководства просто диктует, что «Функция X должна быть выполнена Y», не имея четкого представления о том, сколько времени это может занять на самом деле (некоторые вещи гораздо сложнее реализовать, чем кажется), то это Плохо. Вещь.Однако если они работают с разработчиками, чтобы оценить объем фактически необходимых усилий и сбалансировать его с остальными потребностями компании, то, как правило, все получается довольно хорошо.

Answer 7

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

Answer 8

Регулярные проверки имеют решающее значение:

• Перечислите основные этапы и результаты
• Разбейте его на более мелкие куски
• Создайте коллекцию меньших оценок
• Сделайте сроки разумными

У вас должны быть сроки, но в равной степени эти сроки должны быть реалистичными и измеримыми.Перемещение спецификации может раздражать разработчика — это может быть неизбежно, но не бойтесь перемещать вещи (после обсуждений).

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