Comments 24
А еще бывает, что появление конфликтной среды вызвано дефицитом неформального общения. Там где один сотрудник должен видеть в другом человека, видится несуразный исполнитель обязанностей. И в этом случае часто помогают различные посиделки в барах всем отделом или другие выездные мероприятия.
UFO just landed and posted this here
Вполне понятная ситуация. Команда пилит свой модуль, а тут с какого-то соседнего отдела прилетает патч, решающий проблемы этого отдела, выглядящий криво и чужеродно. Соседнему отделу то что? Запатчили и забыли. А принявшим потом каждый день на этот код смотреть и морщиться от его несоответствия своим стандартам.
UFO just landed and posted this here
Если отдел другой, код явно не в модуле, и смотреть на него каждый день вовсе не обязательно… :)Написано же:
(назовём его Паша) подготовил патч с изменениями в систему развёртывания пакетов, которую разработали и поддерживали коллеги из соседнего департамента
То есть этот Паша влез в чужой код, который не ему поддерживать и написал так, как владельцы кода не любят.
Это вы ещё не знаете, какие придирки к принятию кода в open-source, например, в linux kernel. Там не то что 2 часа, 20 раз будешь переделывать. А чем коммерческий продукт хуже? Он должен заплывать говнокодом, потому что кому-то жалко 2 часа?
UFO just landed and posted this here
Отсутствие стандартов (особенно между подразделениями) — это факап менеджера (более высокого уровня, ответственного за взаимодействия подразделений). Почему рядовые программисты должны тут нести ответственность.
Говнокод — понятие субъективное, применимость решения сильно зависит от проекта. Например, можно заучить как мантру, что глобальное состояние это плохо, и между 100500 функций таскать миллион параметров, лишь бы не обращаться к глобальным переменным. А можно написать визуально чистый код, где-то на 50-м слое обращающийся к глобальной, но поскольку проект гарантированно однопоточный, в этом нет ничего некорректного. Или тот же пример из статьи — свои велосипедные контейнеры против STL. По всем понятиям, STL — хорошо, но, как оказалось, не в данном проекте.
Говнокод — понятие субъективное, применимость решения сильно зависит от проекта. Например, можно заучить как мантру, что глобальное состояние это плохо, и между 100500 функций таскать миллион параметров, лишь бы не обращаться к глобальным переменным. А можно написать визуально чистый код, где-то на 50-м слое обращающийся к глобальной, но поскольку проект гарантированно однопоточный, в этом нет ничего некорректного. Или тот же пример из статьи — свои велосипедные контейнеры против STL. По всем понятиям, STL — хорошо, но, как оказалось, не в данном проекте.
То же самое с точки зрения конечного функционала, но другое с точки зрения организации кода, именования переменных, дизайна, и т.д. В общем, такое, которое устроит владельца/ответственного за систему, и которое он примет в качестве её части. Понятно, что есть другой путь — пойти к Игорю или к его менеджеру и договориться, чтобы он приказал ему принять патч, как есть. Но правильно ли это? Мне кажется, дизайн, код, это скорее зона ответственности программиста, а не его менеджера.
То же самое с точки зрения конечного функционала, но другое — с точки зрения организации кода, именования переменных, дизайна, и т.д. В общем, такое, которое устроит владельца/ответственного за систему, и которое он примет в качестве её части.
Понятно, что есть другой путь — пойти к Игорю или к его менеджеру и договориться, чтобы он приказал ему принять патч, как есть. Но правильно ли это? Мне кажется, дизайн, код, это скорее зона ответственности программиста, а не его менеджера.
Понятно, что есть другой путь — пойти к Игорю или к его менеджеру и договориться, чтобы он приказал ему принять патч, как есть. Но правильно ли это? Мне кажется, дизайн, код, это скорее зона ответственности программиста, а не его менеджера.
То же самое — с точки зрения конечного функционала, но другое с точки зрения организации кода, именования переменных, дизайна, и т.д. В общем, предлагается то решение, которое устроит владельца/ответственного за систему, и которое он примет в качестве её части. Понятно, что есть другой путь — пойти к Игорю или к его менеджеру и договориться, чтобы он приказал ему принять патч, как есть. Но правильно ли это? Мне кажется, дизайн, код, это скорее зона ответственности программиста, а не его менеджера.
Меня при чтении удивил момент, что code review — практически добровольный труд ответственного. Хочу проверяю, не хочу не проверяю. Особенно, если не пилит автор кода.
Мне кажется, что это само по себе нездоровая постановка вопроса, когда программист должен бегать и убеждать, что его код нужно пропихнуть в бой. Как по мне, эта административная вещь должна решаться автоматически. Пришел код на ревью — загорелась зеленая лампочка.
Пролежал рабочий день без рассмотрения — красная. На второй день лампочка загорается у руководителя ревьювера. На третий — у руководителя руководителя.
Мне кажется, что это само по себе нездоровая постановка вопроса, когда программист должен бегать и убеждать, что его код нужно пропихнуть в бой. Как по мне, эта административная вещь должна решаться автоматически. Пришел код на ревью — загорелась зеленая лампочка.
Пролежал рабочий день без рассмотрения — красная. На второй день лампочка загорается у руководителя ревьювера. На третий — у руководителя руководителя.
Заголовок спойлера
Вообще, в сферу ответственности программиста пытаются впихнуть как-то слишком много. Архитектура, гайдлайны, качество кода, оптимальность, скажем понятны. Потом туда добавляется расшифровка бизнес-процессов а вместе с ним генерирование бизнес-логики. Т.е. бизнес проблему еще не осознал до конца, а уже требует ее качественное решение. ОК. Потом сюда же добавляются навыки руководителя и проектного мышления. Оценка и контроль времени и рисков. Стратегическое мышление и планирование. И естественно, параллельно самостоятельно профессионально расти вширь и ввысь.
Зачем такому сотруднику компания? А еще точнее, что его заставляет продолжать работать программистом, кроме любви к работе с кодом. Он исполняет роль полноценного руководителя средней степени крупности, но при этом без формальных полномочий. Мне не кажется, что обычно программист горит желанием заниматься всеми этими дополнительными вещами и с удовольствием продолжал бы «платить» компании и своему начальнику за то, чтобы просто хорошо решать нормально поставленные задачи без лишнего погружения в бизнес, коммуникации и прочее.
Зачем такому сотруднику компания? А еще точнее, что его заставляет продолжать работать программистом, кроме любви к работе с кодом. Он исполняет роль полноценного руководителя средней степени крупности, но при этом без формальных полномочий. Мне не кажется, что обычно программист горит желанием заниматься всеми этими дополнительными вещами и с удовольствием продолжал бы «платить» компании и своему начальнику за то, чтобы просто хорошо решать нормально поставленные задачи без лишнего погружения в бизнес, коммуникации и прочее.
UFO just landed and posted this here
То, что Вы пишете, верно в случае, если автор и ревьюер работают в одной компании. Но для opensource разработки так не работает. Представьте, что вы работаете в, скажем, Dell, а коллега, который ревьюит ваш код — в HP. Вы не можете пойти в HP и объяснять им, в каких случаях и какие лампочки у них должны зажигаться. Общего менеджера у автора кода и ревьюера нету. Кроме того, количество поступающего на ревью кода превышает мыслимые возможности ревьюеров. Часть ревью неизбежно приходится игнорировать. Во-первых, их реально слишком много, во-вторых, в реальности не весь поступающий код нужно принимать. Это коммюнити, ограничений нет и патчи может присылать кто угодно и какого угодно качества. Если руководитель и руководитель руководителя начнут разгребать ревью своих программистов, руководить им уже будет некогда. Обычно это работает с помощью количественных метрик, в частности, сколько ревью делал разработчик, каково время реакции, какая именно реакция в среднем. Но реагировать на каждый патчик нереально.
Насколько я понимаю оригинальный текст — речь именно про одну компанию. Более того, чуть ли не один отдел. И в рамках одной компании игнорить код на ревью — ну, скажем мягко, неэффективно. Конечно, это должно входить в KPI, метрики, да куда угодно. Код на ревью — в том числе твой код, твоя ответственность. Понятно, что бывают ситуации, завалы-авралы, но в общем и целом, моя позиция именно такая — код написан и отдан на ревью. Горячий шарик ответственности перешел из твоих рук в руки ревьювера. Если код лежит без движения и сроки затягиваются — ответственен в этом именно ревьювер. По-дружески можно подойти потыкать, но это не обязанность.
если это тайное менеджерское знание существует — почему никто из них им не пользуется?
Судя по тексту, в компании система управления конфликтами отсутствует)
Статья написана исходя из опыта работы в разных компаниях, не какой-то одной конкретной. Одна из основных причин конфликтов на работе в любой из них — недостатки рабочего процесса, серые зоны в нём (неясные ожидания, недостаточно детально описанные роли, обязанности сторон в процессе, и т.д.), своего рода, undefined behavior. По аналогии с программным кодом, конфликт — это исключение, exception, который обрабатывается отдельно от нормального исполнения кода. Я работал (или плотно взаимодействовал) с разными компаниями, но пока не встречал формальных систем управления конфликтами в них. Если Вы видели и можете поделиться — было бы интересно почитать.
вот тут интересная технология разрешения конфликтов morningstarco.com/index.cgi?Page=About%20Us/Colleague%20Principles
Обычно рассматривают стиль поведения людей с трех позиций: Ребенок, Родитель, Взрослый.
А у вас куда-то Родитель делся, хотя такой стиль поведения очень часто встречается у старожилов и часто бывает непосредственной причиной конфликтов при общении с новичками в команде.
А у вас куда-то Родитель делся, хотя такой стиль поведения очень часто встречается у старожилов и часто бывает непосредственной причиной конфликтов при общении с новичками в команде.
Управление конфликтами в команде это эквилибристика, которая давно стала жизненной необходимостью.
Очевидно, что автор обладает изрядным практическим опытом (или общается с теми, кто им обладает). Можно вполне использовать, как руководство.
ИМХО проблемы всегда 2: плохо поставленные процессы (читай «не на месте, кто их ставил») и / или психологическая несовместимость. Если «И», то смена команды / проекта часто не эффективна и всё заканчивается рано или поздно сменой работы.
Очевидно, что автор обладает изрядным практическим опытом (или общается с теми, кто им обладает). Можно вполне использовать, как руководство.
ИМХО проблемы всегда 2: плохо поставленные процессы (читай «не на месте, кто их ставил») и / или психологическая несовместимость. Если «И», то смена команды / проекта часто не эффективна и всё заканчивается рано или поздно сменой работы.
С выброшенным из исходно взятой тразакционной модели «Родителем» исходные посылы, а за ними и выводы-советы, теряют в валидности. Как минимум, в предложенном представлении «взрослого» часть черт поведения выглядит как от наставительно-долженствующего «родителя». Скажем, «должно быть так и только так» — это из «родительских» проявлений.
И «взрослая» позиция — это, в том числе, и соблюдение границ. Так что вопрос «почему я?» про задачу в ней вполне уместен. Но тут он занесён в исключительно «детские».
И «взрослая» позиция — это, в том числе, и соблюдение границ. Так что вопрос «почему я?» про задачу в ней вполне уместен. Но тут он занесён в исключительно «детские».
В статье предложено рассмотрение конфликтов, исходя из несколько другой модели, чем та, на которую Вы ссылаетесь. В отличие от психологической модели родитель/взрослый/ребёнок, которая рассматривает эмоциональную составляющую конфликта в целом, в любой обстановке (семья, работа, и т.д.), в статье рассматриваются три составляющие, которые, на мой взгляд, важны именно для конфликтов в условиях команды (организации), т.е. группы людей, работающих вместе долгое время и объединённых неким рабочим процессом. Первая — эмоциональная позиция каждой из сторон, как важный фактор для решения или развития конфликта здесь и сейчас (как раз тот момент, который подробно рассмотрен в трансактной модели), вторая — недостатки рабочего процесса как важный фактор наличия серых зон, неопределённых ожиданий, способствующих возникновению конфликтов, и третья — общий уровень эмоциональной культуры команды, как долгосрочный фактор, влияющий на первые два. Это три фактора, которые менеджеру команды стоит держать в фокусе своего внимания. На мой взгляд, тут нет противоречий, просто несколько иной фокус рассмотрения.
Sign up to leave a comment.
Управление конфликтами в команде – эквилибристика или жизненная необходимость?