Каким должен быть штраф/ответ за пропущенный крайний срок?

Ответ 1

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

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

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

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

Изменить в соответствии с обширными комментариями ниже:

Я бы никогда не стал спорить о том, что разработчики не могут быть связаны с ожиданием доставки. Моя точка зрения заключается в ответ на конкретную гипотезу, которую задал ассер, - что характер разработки программного обеспечения в бизнесе как-то аналогичен школьной работе или любой другой работе в этом отношении. Я утверждаю, что это абсолютно не так. "Крайний срок" означает гораздо больше, чем простая дата доставки. Это фиксированная точка, по которой должен быть выполнен фиксированный объем работы. Программное обеспечение просто не работает. Я написал еще несколько параграфов, объясняющих, почему, но, честно говоря, если вы еще не верите в это, я ничего не хочу убеждать вас.

Если вы работаете над программным проектом, и ясно, что вы не сможете достичь своего крайнего срока, что вы можете сделать, чтобы исправить это? Ответ уже хорошо известен: практически ничего. Вы не можете добавить больше людей. Вы не можете "работать быстрее". Это не будет сделано вовремя. Вы говорите заинтересованным сторонам, каждый настраивается и продолжает работать (или нет). Что означало первоначальную дату?

Любой, кто заявляет о разработке программного обеспечения, аналогичен строительству мостов или домашнему заданию или что предстоящие сроки могут быть выполнены, если разработчики просто соберут свое дерьмо и отработают свои задницы, глубоко запутались в своей профессии.

Ответ 2

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

Например, если все участники не выполняли свою работу, увольте их.

Но если они сделали свою работу и многое другое, то почему она все еще пропустила? Слишком много других действий, совершаемых одними и теми же людьми? Слишком большой объем для крайнего срока (т.е. Нереалистичный срок). Или... и т.д.

Основная причина, по которой мне не хватает конечного срока, заключается в том, что людям не разрешено работать на 100% в рамках проекта, и, следовательно, любые оценки, которые у вас могут быть, хотя и точны сами по себе, на самом деле не очень полезны все. Это плюс нереальные оценки и сроки.

Ответ 3

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

Это как родитель, наказывающий ребенка, потому что у родителя был плохой день.

Рассуждение:

Сроки - это факт жизни. Люди хотят знать, сколько времени займет что-то. Самое лучшее, что мы можем сделать, это оценить/угадать. Это роль руководства, чтобы попытаться понять эту магическую, никогда правильную догадку. Когда они создают крайний срок, им нужно использовать правильные инструменты (опыт, ЗАПРОСИТЬ ПОМОЩЬ ОТ РАЗРАБОТЧИКОВ, адвокатов, ч и т.д.)

Однако....

Штраф за пропущенный крайний срок должен не отставать от рабочих. Это недостаток управления для недостающих сроков. Они должны были сказать "нет", должны были отменить проект или должны были мотивировать рабочих лучше.

В команде по строительству, если вы мочите рабочих, вы начинаете драку. В моей компании, если мы пропускаем крайние сроки, у руководства возникают проблемы. Не рабочие. Это задача менеджера по управлению проектом и тем, что сделано. Рабочие только делают все возможное. Менеджер отвечает за назначение ролей и задач.

Я не говорю, что качество работников не является фактором, но руководство должно ЗНАТЬ! Не нужно гениально знать, что проект плохо разбирается или хорошо контролируется. Спросите любого, если их менеджер знает, что происходит, и вы найдете проблему.

Мы прекратили пропускать столько сроков, когда менеджеры поняли, что это их вина за установление/согласие на предельные сроки.

</rant>

Re: Вопросы:

1. Какие действия вы видели в качестве "штрафа" за пропущенный срок, и какие из них на самом деле сделали вещи "лучше"?

• Менеджеры несут ответственность. Этот человек не получает поощрения или публично благодарит. Скорее всего, этот человек будет переведен в "менее критический" проект.

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

• функция creep: менеджер продолжает добавлять в список больше вещей. < - бороться с этим списком задач, упорядоченных по приоритету. Когда вы добавляете вещи в список, сравните их приоритет с вещами вокруг него. Сделать новые вещи сложнее установить как "главный приоритет".
• слишком много ошибок в коде: менеджер должен требовать тестов (по крайней мере критически) и автоматизации. Сборка должна быть стандартной и автоматической. Реальные пользователи должны видеть код до его завершения.
• не читаемый код. Если у кого-то есть грязный код, попросите кого-нибудь "помочь" им в проекте.
• Если у вас есть проблема с продавцом, если у продавца нет функций promises, которые не существуют/работают: руководству необходимо вмешаться и объяснить проблему этому продавцу. Кроме того, не, предоставляя публичному утверждению продавца для хорошо выполненной работы, иногда помогает это.

Ответ 4

Вместо штрафа, как насчет реалистичных оценок и вознаграждения во время выпуска?

Вдохновленный комментариями к моему ответу

Может быть, вопрос должен быть "Как сделать реалистичные оценки?" Для меня я использую FogBugz история оценок и дата завершения. Они дают мне данные о том, как долго я оцениваю задачу и сколько времени она занимает. Это помогло мне дать реальную дату выпуска в долгосрочной перспективе (это не произошло за одну ночь). Я считаю, что временные графики должны быть взаимным процессом: I

• дизайн
• оценка
• разработать
• найдите недостаток в дизайне и выполните итерацию.

Ответ 5

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

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

Если ваши разработчики дают временные оценки, то я буду очень осторожен в том, чтобы вознаграждать и наказывать разработчиков за соблюдение сроков или их отсутствие. Результатом этого может быть то, что они будут корректировать свой "фактор выдумки" при оценке времени. Они давали бы себе слишком много времени (чтобы пожинать награды), что бесполезно, если они хорошо оценивают. Ваша цель должна заключаться в том, чтобы заставить их давать хорошие и надежные оценки, а не изменять способ их работы для удовлетворения этих оценок.

Ответ 6

Смерть. Чистые и простые.

Ответ 7

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

Ответ 8

О, человек...

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

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

Затем убедитесь, что крайние сроки реалистичны. Частично вы это делаете, вовлекая разработчиков в их настройку и решая, что будет сделано.

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

Ответ 9

В своей замечательной книге об управлении проектами - "Deadline" - Том ДеМарко рассказывает нам историю о менеджере проектов из западного мира управляет проектом в какой-то вымышленной посткоммунистической восточно-европейской дикой стране (дикий - действительно хороший термин, потому что граждане немного... нецивилизованны).
Однажды премьер-министр обнаруживает, что что-то пошло не так, часть его проекта резко пропустила нереалистичный график. Предыдущий премьер-министр назначил наказание за недостающий срок, просто повесив ответственного человека на крючок мясника, но поскольку графики были нереалистичными, один человек уже пропустил крайний срок.
Итак, рассказ рассказывает нам о дне, когда в западном стиле премьер-министр представлен ответственным лицом, и он должен отправить его на повешение на крюке для мясников. Премьер-министр, как и большинство людей, боится взглянуть на то, чтобы приговорить кого-то к жестокой смерти просто потому, что кто-то никогда не мог завершить свой проект вовремя. И - во что бы то ни стало - висящий этот бедный человек не продвигает проект. Поскольку это фантастический роман об управлении проектами, а не о пытках, наш герой отменяет штраф.
Но за этой историей стоит какая-то большая проблема: кто-то повесил: если вы установили крайний срок и установили какой-то штраф за пропущенный этот крайний срок, наступит день, вам, вероятно, придется наказать кого-то. И вы это сделаете? Независимо от того, какое наказание будет: висит, бонусная потеря, стрельба, разорвать сделку или какую-то плату - вам, возможно, придется наказать кого-то. Будет ли это наказание делать что-то хорошее для вашего проекта? Вы должны ответить сами. Итак: не устанавливайте штраф за пропущенный крайний срок, вы не захотите выполнять...

Ответ 10

Как уже упоминалось, прежде чем говорить о штрафах, начните с "как определить, реалистичны ли эти крайние сроки"?

Или, как однажды сказал мой босс, "Мы будем рады работать над планом, когда вы дадите нам план, который работает" .

Я все еще думаю, что это должно быть на футболке.

Ответ 11

Как только вы достигли точки, в которой люди взорвали крайний срок, вы должны спросить себя (A), каковы естественные последствия этого и (B), как вы можете лучше всего выполнить задачу и поддерживать какое-то движение к бизнес-целям (даже если вы не управляете бизнесом).

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

В одном случае я был в команде, которая унесла крайний срок на небольшой срок поставки более чем на три месяца - и первоначальный срок поставки был три месяца с начала! Мы неправильно поняли требования, недостаточно поговорили с клиентом и недооценили время. Менеджмент вовсе не интересовался назначением вины. Это было отчасти потому, что было бы контрпродуктивно заканчивать доставку, частично потому, что никто из нас не был "проблемным сотрудником", а частично потому, что руководство знало, что мы все очень мотивированы, чтобы исправить проблему и удовлетворить клиента. Таким образом, мы сделали это, клиент был так же счастлив, как и следовало ожидать, и мы продолжили свою жизнь, с некоторыми ценными уроками о том, как избежать ситуации в будущем.

Ответ 12

Никакого штрафа. "Сроки" и оценка были и остаются одной из самых сложных и сложных задач разработки программного обеспечения.

Смешно налагать штрафы на разработчиков за эту проблему.

Ответ 13

До сих пор в моей карьере я не видел никаких реальных штрафов за пропущенный срок (и я пропустил много). Я полагаю, что для компаний, занимающихся разработкой программного обеспечения или игр, будет продаваться в магазинах, где компания сделала promises для публики.

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

Ответ 14

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

Меня почти уволили в качестве менеджера за рассказ команде, которая сообщила мне, что я не приду в выходные и не работаю поздно. Я знаю, что эти вещи наносят ущерб проекту и моральному духу.

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

Мир полон идиотов. Управление не является исключением.

Ответ 15

Я думаю, что сам вопрос демонстрирует непонимание роли управления и управления проектами.

Существует, к сожалению, общее мнение в сознании многих со словом "Менеджер" в их названии, что управление означает, что он исцеляет/пинает окурки ленивых работников. Он соответствует тем, кто верит в закон Паркинсона.

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

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

Иногда задержка неизбежна. Вот почему мы строим случайное время. Иногда это известный риск; и пока у вас есть план резервного копирования - вы в порядке.

Что касается ответов, у вас есть четыре параметра: Область, время, деньги и качество

• Область действия - вы можете отрезать, чтобы сделать крайний срок.
• Время - фиксировано. Вы могли бы заставить своих сотрудников вытащить неделю или две в 60 часов, но после этого ваша производительность начнет страдать. И это также стоит больших денег, если вы платите им справедливо.
• Деньги - вы можете купить куски у кого-то другого, чтобы ускорить процесс. Вы могли бы даже нанимать больше людей, если работа была разрозненна настолько, что вам не нужно иметь много общения с существующим персоналом - см. Закон Брук
• Качество - Идеалистические дураки утверждают, что вы никогда не сможете сэкономить на качестве. Но вы можете. У вас нет дополнительных ошибок (одна из форм анти-качества); но вы можете поставить меньше качества. Вы кодируете свою функцию, чтобы она могла обрабатывать бесконечные строки длины, или 100 символов, достаточно хороших для этой версии? Вы упростили следующее обновление, чтобы закрепить новый модуль, или вы его свариваете и беспокоитесь о добавлении подключаемого модуля, когда вы выполните следующую версию.

Не делать этого достаточно агрессивно (когда это требуется), безусловно, приведет вас к неудаче.

Ответ 16

Как только проект опаздывает, не так много "управления" (хорошего, плохого, хорошего смысла или злонамеренного), что не приведет к еще более позднему проекту

... единственным исключением может быть удаление/предотвращение внешних отвлекающих факторов.

Ответ 17

Если вам не хватает сроков, исправьте свои оценки.

Ответ 18

С точки зрения корпоративного развития...

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

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

Люди склонны принимать реальное владение предельными сроками, когда они их устанавливают. Когда крайние сроки размещаются на них без их ввода, крайние сроки становятся бессмысленными для человека, выполняющего работу.

Ответ 19

Это, конечно, не ответ. Вот некоторые вещи, которые я взвешиваю, и то, что я делаю/поощряю, чтобы убедиться, что все будет сделано вовремя.

1.) Правильно установите приоритеты. Проекты всегда будут иметь различную степень завершения. Это не двоичный переключатель "done" / "not done". Если сначала выполняются наивысшие приоритеты, легче усвоить. В идеале вам следует быстро дойти до того, что он работает, но он не делает все, что нам нужно, и это выглядит не очень красиво. Когда-то там он может быть выпущен, если он абсолютно необходим.

2.) Я обнаружил, что лучший способ справиться с этим - сделать выпуск как можно меньше. Это делает оценки более точными. Если ваш босс или "рынок" диктует, что ваша оценка неприемлема, подумайте о том, чтобы при необходимости назначить больше разработчиков этой задаче. Иногда задача не может быть действительно легко разделена, или только один человек, знакомый с кодом. Если это не высокий приоритет, просто скажите, какие полномочия будут занимать дольше. Установление разумных целей и управление ожиданиями являются ключевыми.

3.) Что касается мотивации, вознаграждения и наказания... есть много врачей, которые написали целые книги по этим предметам. По моему опыту, предоставление программистам чего-то сложного и позволяющего им иметь некоторую свободу делать это по-своему - это хорошее начало. Слушание - это то, что менеджеры должны делать хорошо, чтобы добиться успеха. Если разработчик опытный, вы должны просто объяснить проблему и позволить разработчику придумать решение. Если их решение не так хорошо, как вы имели в виду, вы можете предложить его и перейти оттуда. Просто диктовать, как что-то делать, даже для новых программистов, редко бывает эффективным. Заставить разработчиков думать о вещах поможет им решить свои проблемы самостоятельно. Это связано с делегированием, поскольку это работает только в том случае, если разработчики могут самостоятельно выполнять работу.

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

5.) Спросите (не требуйте), если разработчик может позавтракать или работать в выходные дни. Делайте это только тогда, когда это имеет очень важное значение (например, недостаток безопасности, который дает пользователю доступ к данным, к которым они не могут получить доступ, новый закон/правила, которые вы должны соблюдать и т.д.). Если они скажут "нет", не держите его против них. Вероятно, не их вина, что все не получилось; и даже если это так, разумно, что они планировали время, когда они не ожидали, что они будут работать. Если они захотят войти, убедитесь, что они знают вашу искреннюю признательность. Компенсируйте их хорошо для того, чтобы помочь, когда они не обязаны, покупка обеда не стоит много, и это очень хороший жест. Не делайте привычки ожидать, что люди будут работать поздно/в выходные дни, если это не будет частью их контакта/соглашения (или если им это нравится).

6.) Поймите, почему вещи отстают от графика. Вы обещали что-то, что было невозможно (учитывая доступность людей, ожидаемое качество и выделенное время)? Был ли какой-то другой проект поднят и занят ресурсами, и крайний срок не был скорректирован? Был ли код сложнее, чем ожидалось? Дать оценки времени сложно. Вам нужно все планировать, иметь опыт и знать, как долго каждый разработчик возьмет на себя эту задачу. Компенсируйте непредвиденные проблемы, которые, вероятно, возникнут и дадут программисту более короткий срок, чем ваш босс или клиент. Всегда всегда делать это рано. И если вы почти всегда делаетесь рано или вовремя, то один раз, когда вы пропустили свой срок, будет более понятным, если у вас есть какое-то объяснение.

7.) Помните, что это обычно сводится к времени, качеству и деньгам. Обычно вы можете выбрать любые два, но третье нужно будет уравновесить уравнение. Поэтому, если это нужно сделать быстро и в ограниченном бюджете, вы можете ожидать, что качество пострадает. Если вам это нужно быстро и качественно, ожидайте заплатить много денег и т.д.

8.) Я бы сказал, что вещь № 1, которая работает для меня, - это слушать. Если ваши слишком занятые лай заказы, то вы, возможно, даже не знаете о проблемах с компанией. Теперь только потому, что разработчик говорит, что "код отстой, дизайн ужасен, и нам нужно переписать все, если мы хотим что-то сделать своевременно", не означает, что это произойдет. Но если вы слышите такие комментарии и объясняете, что мы не можем позволить себе это сделать, или нас убьют на рынке, это будет слишком дорого. И спросите, что можно сделать, чтобы убедиться, что вещи не получат много/хуже. Спросите, есть ли способ, который мы можем очистить с течением времени. Можем ли мы просто (переписать) один класс и построить на его основе новый материал? Можем ли мы постепенно перенести на новый дизайн одну функцию/сегмент/модуль за раз? Вы понимаете, откуда они идут, и наоборот, вы, вероятно, можете решить хотя бы некоторые из проблем. Просто помните, что компрометация работает в обоих направлениях.

9.) Отрицательное повторное применение, похоже, приводит к увеличению оборота, что является дорогостоящим. Наличие кучки людей, которые не знакомы с вашим кодом, также не ограничивает сроки. Деньги - один из мотиваторов, но я ушел с более высокооплачиваемой работы, чтобы пойти туда, где я счастлив раньше, и я знаю, что я не один. Свободное питание, когда команда делает хорошую работу, на самом деле не так дорого. Я не слишком увлекаюсь групповыми действиями, так как они либо сокращают время сотрудников, либо уходят с рабочего времени. Это работает иногда, но сокращение личного времени сотрудников, чтобы они могли общаться с коллегами, а не быть со своими друзьями, не так уж и великому вознаграждению. Если все перестают работать, это тоже дорого... так что это зависит от размера компании, культуры и т.д.

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

Ответ 20

Ваш вопрос по своей сути ошибочен: он предполагает, что наказание - лучший способ управлять людьми. В целом, люди плохо реагируют на наказание или угрозы наказания; он выявляет худшее поведение, делает мотивацию внешней и отвлекает от внутренней мотивации. Вознаграждения и взятки (угрозы вознаграждения) - это другая сторона одной и той же монеты и не лучше.

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

Чтобы управлять любой хаотичной системой, делайте много измерений и будьте готовы быстро изменить курс. В случае программирования:

• Возьмите самые маленькие шаги. Не "прерывайте задачу небольшими шагами", так как вы потратите много времени на планирование, которое не сработает, как вы планировали. Хаос, помнишь?

• Выберите наименьшие шаги, которые обеспечивают наибольшее значение.

• после короткого периода переоценить свой план на основе того, что вы узнали

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

Вы можете признать это как мышление за SCRUM.

Ответ 21

Flogging

Ответ 22

Есть две возможности:

• Крайний срок был упущен, потому что кто-то не выполнял свою работу.
• Крайний срок был нереалистичным.

Вместо того, чтобы думать о штрафах, я бы предложил сделать посмертное определение того, что пошло не так, и найти способы улучшить следующую оценку срока.

Ответ 23

Вы спрашиваете: "Каким будет наказание...". Похоже, вы спрашиваете с точки зрения "внутри компании".

В реальной жизни штрафы часто бывают быстрыми и серьезными - потеря бизнеса, иски, плохая репутация в отрасли. Это РЕАЛЬНЫЕ штрафы, наложенные клиентами, которым обещали что-то на определенную дату, которая не была выполнена.

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

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

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

Приветствия,

-Ричард

Ответ 24

• Я видел, как руководители покинули компанию вскоре после того, как были пропущены некоторые крайние сроки. Это изменило все, но не обязательно делало вещи лучше или хуже. Я видел некоторые договорные обязательства, такие как clawbacks, как способ наказать кого-то за отсутствие крайнего срока, что я не уверен, насколько хорошо они работают.

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

Ответ 25

Каким будет наказание за установление нереалистично короткого периода разработки против всех советов разработчиков и их потенциальных клиентов?

Похоже, что это происходит почти так же часто, как команды разработчиков, которые несут даты отправки.

Ответ 26

Это не вопрос программирования, а вопрос управления.

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

Ответственность за соблюдение сроков лежит на менеджерах. Существуют разные подходы, но ни один из них не включает в себя "наказание" разработчиков за выполнение своей работы. Здесь важно понимать так называемое управление проектами triangle. Это означает, что проект программного обеспечения может быть хорошим (то есть соответствовать требованиям, хорошим качеством), быстро (соблюдение сроков) и дешевым (количество сотрудников, инструменты). Проблема в том, что можно выбрать только 2 из этих 3 свойств.

Итак, если менеджмент хочет что-то хорошее и быстрое - это не будет дешево.

Если менеджмент хочет что-то хорошее и дешевое - он не будет быстрым.

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

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

Хорошее и дешевое по определению предполагает, что крайние сроки будут упущены (Blizzard, создатели World Of Warcraft являются хорошим примером такого подхода)

И, наконец, дешевый и быстрый обычно означает режущие функции и освобождение от ошибок.

Ответ 27

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

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

Обычно у вас есть два варианта:

• Ловить (нанимать дополнительных работников, работать больше или удалять функции).
• Сообщите своему клиенту, что что-то пошло не так (даже лучше: , что пошло не так)), и вам понадобится больше времени.

Для второго варианта я не имею в виду, что никогда не будет наказаний. Но из моего личного опыта, пока клиент заранее информирован и предлагает решения (желательно три: дать больше денег для дополнительных работников/удалить функции, чтобы сэкономить время/принять проект, опаздывающий), они будут открыты для обсуждения, Который всегда лучше конфликтов:)

Ответ 28

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

Но чтобы ответить на ваши конкретные вопросы:

1. Какие действия вы видели в качестве "штрафа" за пропущенный срок, и из которых в конечном итоге более исправный-код?

"Казнь", которую я видел за пропущенные сроки для менеджеров и разработчиков, варьируется от ничего, до продвижения, до простой передачи. Самые суровые наказания, которые я лично наблюдал, были менеджером, "переведенным" на менее важный проект, а бизнес-единица потеряла финансовый бонус.

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

2.Какие ответы на проект-менеджмент заставляли проект не работать напрямую?

Это отдельная отдельная дискуссия... но в этом вопросе есть некоторые неотъемлемые предвзятости - управление проектами виновато.

Три главных вещи, которые я лично видел в PM, делают саботаж проекта (в порядке степени):

• Игнорировать данные/рекомендации/предупреждения от их технического персонала.
• Запросите оценки в начале процесса разработки. Это приводит к оценкам с ошибкой в ​​10 раз (потребуется один месяц, дайте или возьмите десять месяцев).
• Отклонить/изменить/потребовать оценки программного обеспечения, чтобы они соответствовали произвольному бюджету и графику. Это не означает, что разработчики должны игнорировать бизнес-требования, но требования к бизнесу должны быть одинаково установлены разработчиками и не-разработчиками.

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

Мне еще предстоит увидеть функциональную организацию разработки программного обеспечения. Таким образом, исправление, как правило, представляет собой много крови, пота и слез от нескольких героических разработчиков, работающих с высокопрофессиональным PM, который знает, как защищаться от политики внутри компании (т.е. Отклонять BS от их сотрудников).

4. Какие ответы привели к более-плохому коду?

• Кричать. Материться. Оскорбления. (К сожалению, это все еще происходит на некоторых рабочих местах)
• Больше "управления проектами" - либо с помощью людей, встреч, отчетов о статусе.
• Получение программных оценок ранее в этом процессе, чтобы "мы могли лучше планировать". Оценки должны появиться позже, когда у вашего персонала больше данных и лучшего понимания проблемы.
• Препятствовать разработчикам (это не ваша вина, менеджер прикрутил).
• Препятствовать менеджерам проектов (это не ваша ошибка, разработчики прикрутили).
• Добавление дополнительного, неквалифицированного персонала в проект.

Ответ 29

Меня уволили за отсутствие крайнего срока, я закончил 98% с продуктом, внешними силами и сроками, которые у этой фирмы не позволяют правильно разрабатывать программное обеспечение. Даже я могу признать, что я написал какой-то плохой код в данных обстоятельствах, но я также написал неплохой код для поддержки. Не было дано никакого объяснения для ползучести функции, infact, технические спецификации не были детализированы заранее, и была необходима адаптация функциональности, поскольку для обзора управления были доступны ограниченные и ошибочные версии программного обеспечения. Я мог бы общаться лучше, но когда я общался, было подчеркнуто, что крайние сроки не подлежат обсуждению.

Ответ 30

Я не сторонник этого, и я не реализую ни одно из них, это просто то, что я слышал, что было интересно/нечетно

Просто читал и смотрел видеоролики по циклам выпуска (обычно в FOSS), кажется, что обычные вещи:

• Насмешка
• Ношение шляпы "Данс" на неделю (для людей, не совершающих вовремя).
• Запрет от дерева (для поломки ABI/API и т.д.)

Хотя я полагаю, что это программное обеспечение с открытым исходным кодом для вас!