Является ли разумной практикой управления проектами заставлять инженеров-программистов исправлять ошибки «в нерабочее время»?

И мало того, что они должны исправлять их, они должны исправлять их в свое время, не влияя на планы.

Это твоя проблема. Почему в ваши планы не входит время на исправление ошибок, которые, как вы знаете, будут?

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

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

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

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

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

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

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

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

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

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

Позвольте мне задать вам вопрос. Всякий раз, когда план меняется, вы меняете его в свободное время ?

Никто не робот. Нормальные люди ошибаются. И чем ценнее чья-то работа, тем больше времени потребуется на исправление в ней ошибки. Я работаю над основными компонентами, которые экономят компании массу времени. Однако, если возникает ошибка, это затрагивает множество компонентов, и для ее правильного исправления потребуется много времени. В ту секунду, когда вы позволите мне исправить ошибку в этом в свободное время , вы получите письмо от моего адвоката. Хочешь, чтобы я работал, лучше заплати за это. Вы хотите, чтобы я регулярно работал сверхурочно? Лучше иметь причину. «Нормальный бизнес» не является такой причиной. Скорее всего, потребуется несколько недель, чтобы подать заявление об отставке даже за попытку провернуть со мной такой глупый трюк.

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

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

На мой взгляд, ошибка лежит непосредственно в вашем планировании. Вы планируете, чтобы люди работали на 100%, а затем вам нужно исправить ошибку. Как будто ошибка — это то, что вы никогда не могли себе представить. Ошибки являются частью разработки и улучшения программного обеспечения. Если вы хотите исправить их вовремя, планируйте задачи для своих людей только на 70%. Или 60%. Или 90%. Все, что работает для вашего количества дефектов. Но это ваша работа, чтобы сделать это правильно. Если предположить, что ошибок не будет, а затем позволить разработчикам заплатить за вашу неспособность придумать план, соответствующий реальности, вы очень скоро получите очень пустой отдел разработки.

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

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

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

РЕДАКТИРОВАТЬ: Большая часть изменчивости производительности является случайной, т. Е. Вы не можете их контролировать. Если вы измеряете результаты процесса, предполагается, что наблюдения между +3 и -3 сигма являются случайными результатами. Однако эти результаты могут выйти за пределы допусков и, таким образом, считаться дефектом. Наказание за попытку контролировать их ТОЧНО похоже на наказание за выпадение 3 или 6 при правильном подбрасывании костей, с ожиданием того, что 3 и 6 выпадут реже после нескольких карающих ударов током. Если вы ищете аргумент для изменения этой политики, то это он. Многие дефекты возникают из-за случайных драйверов, которые НИКТО не контролирует. Попытка привлечь инженера к ответственности за них — это погоня за стохастическим шумом, тщетная попытка.

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

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

Не пытайтесь наладить здесь политику вашей компании. Измени это. Это просто неправильно по всем мыслимым стандартам.

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

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

У любого опытного разработчика в голове есть представление о следующих кривых:

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

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

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

Краткий ответ: нет!

Не такой короткий ответ:

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

Весь код содержит ошибки. Качественный код содержит меньше ошибок.

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

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

Кто-нибудь из ваших разработчиков недавно уволился? Просто спрашиваю...

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

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

Думаю, будет справедливо сказать, что я был самым сильным разработчиком в нашей небольшой команде. Я придумал всю оригинальную работу, установив шаблоны, которые другие затем стремились скопировать. Я решил много сложных задач в сложном приложении, которое мы разрабатывали. Кроме того, я был единственным членом команды, который иногда говорил «нет» требованиям неоплачиваемой сверхурочной работы — у меня были обязанности по воспитанию детей и творческая жизнь вне моей основной работы по разработке. Я считаю, что независимость мышления, которая позволила мне быть творческим разработчиком, шла рука об руку с тем, что я не был «да». Однако, когда пришло время назначать руководителя группы, и мой непосредственный начальник назвал мою фамилию, его менеджер сказал, что я «слишком много откладывал сверхурочные», и вместо этого решил дать рекламу. Я знал в тот момент, что этого достаточно, и я ушел, вскоре нашел работу, которая предлагала на 50% более высокую заработную плату и баланс между работой и личной жизнью. Чувствуя себя хорошо взращенным, вознагражденным и отдохнувшим, я лучше работаю и чувствую себя преданным своей компании. Я чувствую себя заинтересованным в продукте и с удовольствием работаю долгие часы, когда это необходимо, потому что мне нравится быть частью команды.

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

Баги это нормально. Это не грехи. Никто — ни Гейтс, ни Возняк, ни Торвальд, никто — не пишет чистый код без ошибок. Разработка программного обеспечения — это итеративный процесс, и устранение дефектов — лишь одна из нормальных частей этого процесса. Честно говоря, не платить разработчикам за исправление ошибок — все равно, что не платить садовникам за прополку.

Эта практика — хороший способ вытеснить лучших и умнейших, оставив вас с костяком команды из ваших худших исполнителей. Я разрабатывал программное обеспечение для истребителей 4 -го и 5-го поколений и руководил программно-интенсивными программами для USN : сертификация PMP , несколько инженерных степеней, Eagle scout, yada yada, yada. Оригинальные посты заставляют меня задаться вопросом, действительно ли проблема заключается в интеграции более эффективной практики SQA на линейном уровне для обнаружения, устранения и, что наиболее важно, предотвращения дефектов.

Каждый мало-мальски порядочный инженер с радостью исправит незначительную «счастливую радость», однако меня не удивит, если системные требования не будут должным образом задокументированы, а любые пробелы будут помечены как дефекты. Дефекты в моей отрасли убивают людей, поэтому инженеры относятся к ним серьезно.

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

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

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

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

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

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

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

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

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

Настройте хороший процесс « политики нулевых дефектов », чтобы предотвратить мгновенное исправление всего:

Я бы добавил пятую классификацию «Закрытые» для дефектов, которые никогда не должны получать приоритет, потому что они слишком тривиальны. Убедитесь, что вы общаетесь ясно и честно.

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

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

Вы выбираете:

• Разработчик A: Он пропустил точку с запятой из-за усталости и является причиной ошибки.
• Разработчик B: Сверхбыстрый программист закончил свою задачу раньше и хорошо выспался.
• Разработчик C: только что обученный разработчик, очень увлеченный, но низкий опыт означает высокий риск ошибок.
• Разработчик D: Был здесь много лет и почти полностью зомби, и команда не любит его. Никаких моральных наказаний, но чтобы что-то сделать, нужны годы.

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

Престижность Роберту Гранту за то, что он указал на разницу между контрактом с подрядчиком и контрактом с фиксированной ценой, что тоже бросилось мне в глаза. Даже будучи подрядчиком с почасовой оплатой, я пару раз выполнял работу бесплатно (час по 120 долларов в час в 2 случаях), но по моим собственным причинам для хороших клиентов.

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

ОП: Вы рассматривали этот мысленный эксперимент? Переверните процесс и заплатите разработчикам за исправление ошибок, но пусть они пишут код в свободное время. Глупо, правда?

Попробуйте предложить альтернативный подход к управлению:

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

1. Это проверяет проблему до того, как она попадет в производство, а не после
2. Радует разработчиков, потому что они не исправляют чужие проблемы, а тестируют свой код.
3. Обеспечивает объективную меру того, что ожидается от разработчиков, в отличие от «НЕТ ОШИБОК!» что недостижимо
4. Соответствие стандарту и покрытие тестами является лучшим показателем индивидуальной производительности, чем количество ошибок, что может быть связано со сложностью порученной работы, а не с навыками человека.

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

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

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

Подрядчики.

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

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

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

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

Разработчики будут учиться не тому, как улучшать, а тому, как скрывать свои ошибки и не попадаться. Это простая психология и так себя ведут даже дети, кошки и собаки. В конечном счете они создадут беспорядочный кодовый ад. Найдите причину, по которой они делают ошибки, и решите основные проблемы. Поскольку ПМ работает с разработчиками, а не против них. Дайте им время, образование, возможность учиться и делиться своими знаниями. Уход за документацией как источником знаний. Такая сложная система требует глубокого понимания. Подумайте о рефакторинге, чтобы сделать систему менее подверженной ошибкам.

Я не премьер-министр. Я разработчик.

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

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

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

Ошибки — это ваши результаты. Вы не должны бояться их или заставлять кого-либо бояться. Вы должны поддерживать их, поощряя всех находить и сообщать о них, насколько это возможно. Вы никогда не должны наказывать свою команду или программистов за ошибки! Это было бы ужасной ошибкой. Посмотрите это видео: https://www.youtube.com/watch?v=7DYr8GYzJ6Q

Проблема, которую вы описываете, кажется, продолжается в течение некоторого времени в вашей рабочей группе. Вашим инженерам платят 1 1/2 их зарплаты в нерабочее время или больше? Настало время действовать прямо сейчас, чтобы не ввести в свой рабочий коллектив шаблон, который будет сложнее исправить в ближайшие несколько лет. Исследования менеджмента показывают, что не заработная плата является фактором № 1, влияющим на мотивацию сотрудников/работников. Это качество их рабочей среды. Люди предпочитают иметь работу, на которой они могут реализовать себя, прежде чем желать более высокой зарплаты. Вы описываете свои задачи по разработке своих продуктов как сложные, вызывающие больше ошибок, чем вам хотелось бы. Программирование в 2018 году — это не то же самое, что в начале 1980-х, когда я прошел курс базового языка программирования, прежде чем изучать бизнес-администрирование, пока не получил степень MBA. Ошибки в компьютерных программах имеют меньше причин для существования сейчас, чем раньше, потому что мы достигли невиданного прежде уровня технологий. Решение ошибок — не самая интересная задача для инженера. Возможно, вы могли бы выбрать или нанять несколько человек, которые занимаются только отладкой; люди, которым это нравится. Этот шаг может расстроить вашу команду инженеров. Это было бы неплохо. Вы должны послать четкий сигнал, что вы совсем не удовлетворены тем, что происходит, пока не стало слишком поздно. Большинство жителей Северной Америки тратят больше, чем зарабатывают. Вы можете получить серьезную негативную реакцию от своих инженеров, если им абсолютно необходимы дополнительные деньги. Кроме того, иногда члены команды саботируют собственную работу, чтобы избавиться от своего менеджера. Не ждите, пока вы доберетесь туда. Сегодня у вас есть симуляторы, чтобы проверить, работают ли ваши программы; насколько я понимаю, некоторые члены вашей команды оставляют нерешенными ошибки, которые они находят или создают. Управление проектами, работа в команде с бюджетом и сжатыми сроками требуют постоянного контроля процедур. Деловое администрирование должно планировать, организовывать, направлять и оценивать/контролировать. За последние два десятилетия в управление вошли некоторые ереси. Некоторые люди не терпят, чтобы их работа оценивалась и контролировалась. Я хочу сказать, что вы должны действовать быстро, прежде чем такая исключительная процедура, как работа в нерабочее время, станет нормой на вашем предприятии. За последние два десятилетия в управление вошли некоторые ереси. Некоторые люди не терпят, чтобы их работа оценивалась и контролировалась. Я хочу сказать, что вы должны действовать быстро, прежде чем такая исключительная процедура, как работа в нерабочее время, станет нормой на вашем предприятии. За последние два десятилетия в управление вошли некоторые ереси. Некоторые люди не терпят, чтобы их работа оценивалась и контролировалась. Я хочу сказать, что вы должны действовать быстро, прежде чем такая исключительная процедура, как работа в нерабочее время, станет нормой на вашем предприятии.

Есть ли опытные менеджеры проектов, которые могут поделиться мудрыми советами по этой теме?

Как и ожидалось, все остальные предсказуемые ответы кричали "абсурд!" но не так много альтернатив было предложено. Ведь руководству неприятно иметь дело с тем, что «операция прошла успешно, но пациент умер», или, в нашем случае, «код готов, но не работает».

Что мы сделали, так это сократили команду до 2-3 разработчиков и выделенного ресурса QA. Таким образом, «единица разработки» является неполной, пока ее не утвердил QA. Поскольку QA и разработчики работают рука об руку, они не противостоят друг другу, это совместная работа, направленная на достижение совершенства.

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

Это гарантирует, что ваша «идеальная» функция ничего не ломает.

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