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

Возможно, вы захотите взять некоторые аргументы из книги Фредерика Брукса «Мифический человеко-месяц ». Хотя первоначально она была написана еще в 1975 году (пересмотрена в 1995 году), она по-прежнему остается одной из самых важных работ, касающихся управления командами разработчиков программного обеспечения.

Он наиболее известен кодификацией закона Брукса :

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

Причины:

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

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

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

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

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

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

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

Тем не менее, вы можете попробовать.

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

Допустим, вам нужно выкопать колодец диаметром 1 м и глубиной 15 м. Одному человеку нужно 15 часов, чтобы выкопать его. Сколько человек потребуется, чтобы выполнить задание за 1 ч?

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

Вы можете немного ускорить работу, заменив утомленного человека свежим, чтобы второй человек немного помог. Это не будет 1/2 времени, сохранение будет, вероятно, не более 1/3. Но добавление третьего человека, скорее всего, ничуть не поможет. Эти двое будут обмениваться друг с другом каждый час или около того, чтобы восстановить свою выносливость. Так что, если вы настаиваете на использовании третьего рабочего внутри дыры, единственным эффектом будет то, что вы потеряете больше времени, когда они меняются местами, или просто больше людей ждут своей очереди, получая оплату, но не принося никакой дополнительной ценности. В лучшем случае никакой выгоды, в худшем — потери.

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

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

И это при условии, что все рабочие квалифицированы. Что, если рытье колодца требует особой точности, и вы нанимаете для этого неподготовленного временного работника? Вам нужно научить их, поэтому вы потратите первый час на то, чтобы показать, как правильно делать стены так, чтобы они не разваливались, и как добиться идеально круглой формы. Тогда они будут работать на 50% скорости тренированного человека, и их работа все равно не будет идеальной, поэтому парню-перманенту придется делать исправления, теряя некоторое время своей работы. На самом деле, прежде чем новый человек сможет принести что-либо, кроме задержек, колодец будет готов. И это займет больше времени, чем если бы умелец копал один. Вы по-прежнему можете использовать временную шкалу для этих вспомогательных или простых задач (пока я копаю посередине в перерыве, оставьте стены нетронутыми), но это все равно 5, в лучшем случае 10%.

И это так же просто, как размахивать лопатой. Кодирование намного сложнее.

Обобщите это примерно так:

Очевидно, что вам нужно обучить разработчика, и 1 месяц — это минимум, чтобы заставить их работать на базовом уровне производительности , если они квалифицированы . Во время обучения вам нужно инвестировать время одного штатного разработчика в обучение, а работу временных сотрудников в любом случае нужно проверять, поэтому добавление кого-либо в команду менее чем на 4-6 месяцев — это пустая трата времени.

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

Если ваш менеджер не может понять такое сравнение, ваш последний вариант — снова выйти на рынок труда.

Это отваживается на общие советы по разработке программного обеспечения....

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

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

3. Тесты составляют хорошую спецификацию. TDD — это хороший способ убедиться, что вы получаете именно то, что хотите. Дайте кому-нибудь задание написать нужный вам код (на примере уже написанных вами тестов).

4. Одноранговое программирование может быть вариантом. Вы можете сразу исправить ситуацию и ответить на вопросы по ходу дела.

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

У тебя уже есть. Все, что вы можете сделать, это настойчиво рассказать об этом боссу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модульные тесты

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

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

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

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

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

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