Как стать автором
Обновить
18
Карма
0
Рейтинг

Пользователь

  • Подписчики 11
  • Подписки

Управление конфликтами в команде – эквилибристика или жизненная необходимость?

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

Управление конфликтами в команде – эквилибристика или жизненная необходимость?

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

Управление конфликтами в команде – эквилибристика или жизненная необходимость?

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

Управление конфликтами в команде – эквилибристика или жизненная необходимость?

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

Управление конфликтами в команде – эквилибристика или жизненная необходимость?

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

Управление конфликтами в команде – эквилибристика или жизненная необходимость?

Статья написана исходя из опыта работы в разных компаниях, не какой-то одной конкретной. Одна из основных причин конфликтов на работе в любой из них — недостатки рабочего процесса, серые зоны в нём (неясные ожидания, недостаточно детально описанные роли, обязанности сторон в процессе, и т.д.), своего рода, undefined behavior. По аналогии с программным кодом, конфликт — это исключение, exception, который обрабатывается отдельно от нормального исполнения кода. Я работал (или плотно взаимодействовал) с разными компаниями, но пока не встречал формальных систем управления конфликтами в них. Если Вы видели и можете поделиться — было бы интересно почитать.

Управление командой программистов: как и чем их правильно мотивировать? Часть первая

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

Если растёт именно качественный опыт, а не просто количество лет, отсиженных на работе, обычно человек начинает работать над архитектурой систем, становится техническим (именно техническим) лидом, занимается какими-то сложными, сильно нагруженными, распределёнными штуками, техническими исследованиями, генерит спеки протоколов, разрабатывает API, пишет статьи, выступает на конференциях, и т.д. То есть, делает вещи, которые даже три-четыре-пять начинающих программистов, собранных вместе, сделать не смогут. Поэтому если жизнь компании зависит от софта, который она разрабатывает (а программисту, мне кажется, стоит работать именно в такой компании), в таких компаниях обычно нет предела роста для технического специалиста и после 20, и после 30 лет работы. Если есть желание продолжать быть разработчиком, я бы скорее поискал такую компанию, чем рассматривал вариант перехода в менеджеры или тимлиды. Это всё-таки работа другого рода. Это не теория, я видел много таких людей, программистов, начальник у которых, скажем, старший вице-президент, и которые получают зарплату на уровне директоров или вице-президентов, и которые репортят этому же вице-президенту. В западных компаниях есть такой термин «fellow», об этом можно почитать, например, здесь: www.quora.com/What-are-the-different-levels-of-software-engineers-at-Google

Управление командой программистов: как и чем их правильно мотивировать? Часть первая

Цель у бизнеса обычно другая, это факт. Как правило, в цели бизнеса входит: 1) зарабатывание денег и 2) рост/развитие/стабильность/продолжительность.
Однако если не думать о мотивации и развитии людей, в компании останутся только люди, которым некуда больше идти. Неочевидно, что они сильно поспособствуют получению прибыли бизнесом и его стабильности.

Управление командой программистов: как и чем их правильно мотивировать? Часть первая

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

Управление командой программистов: как и чем их правильно мотивировать? Часть первая

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

Вредные советы: как правильно писать техническую документацию? Часть вторая

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

Вредные советы: как правильно писать техническую документацию?

Кирилл, спасибо за интересные дополнения!

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность