Ведя команду, я властный?

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

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

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

Я действительно ненавижу это.

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

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

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

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

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

Вопрос в том, являюсь ли я тем, кто неразумен?

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

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

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

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

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

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

Завернуть это

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

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

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

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

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

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

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

Не принимай это на свой счет

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

Веди и учись

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

Проверка перед презентацией клиента

Если вы руководите проектом, почему вы не рассмотрели функцию и реализацию до того, как она была представлена?

Если это не так, исправьте это

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

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

Таким образом, вы в конечном итоге идете к своему менеджеру с «Итак, вместо того, чтобы работать над тем, что в спецификации, они решили вместо этого сделать [функцию]. Теперь мы отстали, из-за функции, которая не была одобрена в первую очередь».

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

edit> И нет, я не думаю, что вы властный. Их работа становится твоей задницей.

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

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

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

Я слишком часто чувствую это эмоционально

 I of course think I'm right....I always do. 

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

Кто настоящий лидер?

Это тот, кто может уволить подчиненного, любого подчиненного. (но не нужно нанимать нового)

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

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

И худший случай, когда существуют два лидера проекта.

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

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

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

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

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

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

Затем вы публично взорвали, вам нужно публично извиниться. Это поможет вам восстановить свою репутацию.

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

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