Что должно штраф/ответ за пропавших без вести крайнего срока быть? [закрытый]

Вы спрашиваете "какой должен быть штраф ...". Похоже, вы спрашиваете с точки зрения «внутри компании».

В реальной жизни наказания часто бывают быстрыми и суровыми - потеря бизнеса, судебные процессы, плохая репутация в отрасли. Это НАСТОЯЩИЕ штрафы, налагаемые клиентами, которым к определенному сроку было обещано что-то, что не было выполнено.

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

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

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

Ура,

-Ричард

позвольте клиенту управлять продвижением функции, а не вам).

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

Ура,

-Ричард

позвольте клиенту управлять продвижением функции, а не вам).

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

Ура,

-Ричард

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

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

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

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

Two obvious questions come to mind when a deadline was missed:

1. Was the deadline feasible?
2. Did external factors impact performance?

Obviously, if someone presents you with a deadline that doesn't make sense then there shouldn't be any penalty for missing the deadline. Also, if someone misses a deadline because they were called up for jury duty that also shouldn't be held against them as well.

In the event those questions don't apply then the next thing to do is to figure out what went wrong. If you based your estimate for how long something would take, and thus the deadline, on the developers estimation of how long it would take them to write the code then perhaps they were too optimistic in their responses.

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

• Срок был пропущен потому что кто-то не выполнил свою работу.
• Срок был нереальным.

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

Порка

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

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

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

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

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

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

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

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

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

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

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

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

А как насчет реалистичных оценок и своевременных релизов?

---

На основе комментариев к моему ответу

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

1. дизайн
2. оценка
3. разработка
4. нахожу недостаток в дизайне и итерации.

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

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

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

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

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

О, чувак ...

Во-первых, есть внешние и внутренние дедлайны, и они должны быть разными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В мире полно идиотов. Менеджмент не исключение.

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

К сожалению, в сознании многих распространено восприятие слова «Менеджер». название, что менеджмент означает лечить / пинать задницы ленивым работникам. Это также согласуется с теми, кто верит в закон Паркинсона.

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

То есть , менеджер проекта уже должен знать, что проект / задача не выдержат срока. Они должны задавать вопросы и знать, что происходит. У них есть право либо сократить задачи, либо увеличить / перебалансировать ресурсы, чтобы выполнить работу (или сказать спонсору, что если вы не дадите ресурсы, это не будет выполнено вовремя). И поэтому штраф идет на PM, будь то ничто, плетка, понижение в должности или увольнение.

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

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

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

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

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

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

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

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

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

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

s Закон

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

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

s Закон

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

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

или 100 символов достаточно для этой версии? Упростите ли вы установку нового модуля при следующем обновлении, или вы приварите его и беспокоитесь о добавлении подключаемого модуля, когда будете делать следующую версию.

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

или 100 символов достаточно для этой версии? Упростите ли вы установку нового модуля при следующем обновлении, или вы приварите его и беспокоитесь о добавлении подключаемого модуля, когда будете делать следующую версию.

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

Если проект опаздывает, «менеджмент» (хороший, плохой, благонамеренный или злонамеренный) мало что может сделать, что не приведет к тому, что проект будет еще позже

. .. Единственным исключением, возможно, является устранение / избегание внешних отвлекающих факторов.

Если вы опоздали в сроки, исправьте свои оценки.

Developers should never be penalized for Management's mistakes.

It's like a parent punishing a child because the parent had a bad day.

Reasoning:

Deadlines are a fact of life. People want to know how long something will take. The best we can do is estimate/guess. It is the role of management to try to figure this magical, never correct guess. When they create a deadline, they need to use the right tools (experience, ASKING FOR HELP FROM DEVELOPERS, lawyers, hr, etc)

However....

The penalty for missing a deadline should not fall back on the workers. It is the management's fault for missing deadlines. They should have said no, should have scaled back the project or should have motivated the workers better.

In a construction crew, if you piss of the workers, you start a fight. In my company, if we miss deadlines, the management gets in trouble. Not the workers. It's the manager's job to control the project and what is done. The workers are only doing what they can. The manager's are in charge of assigning roles and tasks.

I'm not saying the quality of workers isn't a factor, but the management should KNOW that! It doesn't take a genius to know that a project isn't well thought through or nicely controlled. Ask anybody if their manager has any idea what's going on and you'll find the problem.

We stopped missing as many deadlines when the managers realized it was their fault for setting/agreeing to the deadlines.

</rant>

Re: The questions:

1.What actions have you seen applied as 'penalty' for missed deadline, and which of these actually made things 'better'?

• Manager has less responsibility. This person does not get promoted or publicly thanked. Most likely this person will be moved to a "less-critical' project.

2.What project-management responses caused the project to fail outright, and what responses restored working order and resulted in code that could be maintained afterward?

• feature creep: manager keeps adding more stuff in the list. <- fight this off with a List of tasks ordered by priority. When you add things to the list, compare their priority with the things around it. Make new things harder to be set as "top priority."
• too many bugs in the code: Manager need to require tests (atleast critical) and automation. Builds need to be standard and automatic. Real users need to see the code before it is "finished."
• un-readable code: Institute peer code reviews. If someone has dirty code, ask someone to "help" them with a project.
• If you have the salesman problem, where the salesman promises features that doesn't exist/work: Management needs to step in and explain the problem to that salesman. Also, not giving that salesman public affirmation for a job well done sometimes helps this.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле это не вопрос программирования, а скорее вопрос управления.

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

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

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

Если руководство захочет что-то хорошее и дешевое - этого не будет. Быть быстрым.

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

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

Хороший и дешевый по определению предполагает, что сроки будут пропущены (Blizzard,

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

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

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

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

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

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

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

1. Какие действия вы считаете применяемыми в качестве «наказания». за пропущенный срок, и какие из них в конечном итоге привели к more-good-code?

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

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

2. Какие меры руководства проекта привели к полному провалу проекта?

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

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

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

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

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

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

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

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

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

4. Какие ответы привели к появлению большего количества плохого кода?

1. Кричать. Проклятие. Оскорбления. (К сожалению, это все еще происходит на некоторых рабочих местах)
2. Больше «управления проектами» - посредством людей, встреч, отчетов о состоянии.
3. Получение оценок программного обеспечения на более ранней стадии процесса, чтобы «мы могли лучше планировать». Оценки должны быть сделаны позже, когда у ваших сотрудников будет больше данных и они лучше поймут проблему.
4. Нежелание разработчиков (это не ваша вина, менеджер облажался).
5. Нежелание руководителей проектов (это '' Это не ваша вина, разработчики облажались).
6. Добавление к проекту дополнительных неквалифицированных сотрудников.

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

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

1. Насмешки
2. Ношение «тупой шляпы» в течение недели (для людей, не выполняющих вовремя)
3. Блокирование с дерева (из-за поломки ABI / API и прочего)

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