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

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

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

(Как) я могу эффективно руководить командой, если я не полностью понимаю технические детали проекта?

Этому, наверное, посвящены целые книги, посвященные этой теме . У вас есть конкретная проблема, с которой вы столкнулись, или это просто чувство запугивания нового менеджера?
С какой конкретной проблемой вы столкнулись? Это немного широко, без конкретной точки преткновения
Я хотел бы знать, управляете ли вы командой — реальными людьми — проектом — например, в качестве менеджера проекта со всеми вытекающими отсюда обязанностями (часто не управляя людьми) — или какой-то комбинацией . Это будет иметь большое значение для поиска «конкретной проблемы», о которой упоминала @Rarity.
Мой совет: если вы не разбираетесь в технологии, но верите, что они разбираются, позвольте им делать то, что они делают. Уйди с их пути. Это идеальный менеджер. :)
+1, потому что я рад видеть, что нетехнический босс думает об этой проблеме - это очень распространенная проблема.

Ответы (4)

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

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

             Weighting  Plan A      Plan B  
Criteria       factor   Score   Total   Score   Total 

Performance          4    3      12      4       16

Maintainability      3    3      9       4       12

Development Speed    3    2      6       2        6

Security             5    5     25       1        5

Total                           52                39

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

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

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

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

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

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

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

Итак, пройдемся по чек-листу:

а) структура проекта — «Познакомиться с проектом (желаемый результат, ожидаемые сроки и т. д.) не составит труда» — хорошо;

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

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

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

Вы можете сделать 3 вещи:

  • Получите образование как можно быстрее. Купите книгу и прочитайте ее. Это должно дать вам общую терминологию, идеи и т. д.
  • Попросите помощи / разъяснения по пути. Частью вашей роли как менеджера/руководителя группы/руководителя является обеспечение того, чтобы все понимали, что происходит. Способ сделать это - попросить разъяснений по пути. В этом нет ничего постыдного, и люди будут относиться к вам с большим уважением, чем если вы попробуете отмазаться.
  • Какой бы ни была ваша роль в проекте, делайте ее ОЧЕНЬ хорошо. Если ваша работа заключается в том, чтобы использовать политическую поддержку проекта в вашей организации, будьте чертовски уверены, что политическая поддержка есть. Не пытайтесь делать чужую работу, потому что в конечном итоге вы только разозлите всех.