Как мне подойти к «один на один» с менеджером моего босса, когда есть проблемы с проектом?

Я бы посоветовал, если у вас есть время до «большой встречи»:

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

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

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

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

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

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

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

Чрезвычайно своевременный ответ был опубликован сегодня в блоге LinkedIn, написанном Стивом Синофски, который несколько месяцев назад был президентом подразделения Windows в Microsoft, под названием « Выгоды от 1:1 на уровне пропуска — советы и подводные камни» . Примерно половина из них приходится на менеджеров, проводящих собрание. Не пропустите это: прочтите это, чтобы понять, какие цели может преследовать менеджер вашего менеджера, когда он делает это один на один с вами.

Другая половина сообщения в блоге предназначена для вас как отдельного участника, который собирается на эту встречу, и в ней много мудрости, начиная со следующего:

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

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

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

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

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

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

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

Встреча с Боссом своего Босса - опять же такт и честность.

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

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

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