Банальный конфликт: один программист нелестно отозвался о коде другого. Слово за слово, один обозвал другого говнокодером.

Нет, ну явно он не скажет: Ты, Вася — говнокодер, каких еще поискать.

Он напишет что-то типа: Такой код мог написать только человек далекий от программирования.

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

Вот кто такие конфликты решает? Менеджер? Тимлид? Скрум мастер? Какими скилами необходимо для этого обладать?

Здравствуйте, Yodo, Вы писали:

Y>Банальный конфликт: один программист нелестно отозвался о коде другого. Слово за слово, один обозвал другого говнокодером.

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

Здравствуйте, Yodo, Вы писали:

Y>Банальный конфликт: один программист нелестно отозвался о коде другого. Слово за слово, один обозвал другого говнокодером.

Y>Нет, ну явно он не скажет: Ты, Вася — говнокодер, каких еще поискать.
Y>Он напишет что-то типа: Такой код мог написать только человек далекий от программирования.
Y>Далее зависит от толстокожести Васи. Одному пох. Другой будет страдать и копить взаимную неприязнь, саботировать какие-то решения, предложенные первым. Потом все выскажет на стендапе или тупо уволится, потому что не хочет работать с мудаками.

Y>Вот кто такие конфликты решает?
Y>Менеджер?
Менеджеры бывают разные, скорее нет, чем да

Y>Тимлид?
Да

Y>Скрум мастер?
нет

Y>Какими скилами необходимо для этого обладать?
Навыками решения конфликтов

1) Прекратить истерику если она есть. Человек в состоянии повышенного эмоционального возбуждения может начать говорить\писать\делать что-то совсем неадекватное. Это надо прекратить.
Сначала просто попросить успокоиться. Если не поможет, то попытаться отвлечь чем-то, каким-то срочным поручением. Если и это не поможет, то просто отправить отдыхать. Истерика сама пройдет.
2) Перевести претензии из личных в рабочие, желательно объективные. Их может и не быть, возможно кто-то не допонял.
3) Если объективно конфликт все еще существует, то найти решение. Могут сами участники подсказать, можно самому придумать и обсудить с ними. Иногда возможно просто развести конфилктующих по разным песочницам.
4) Обязательно провести воспитательную беседу о недопустимости такого поведения и личных оскорблений. Напомнить что надо быть профессионалами и что все на одной стороне.


Чтобы не допускать такого — регулярные 1-на-1 встречи и выяснением что у кого "болит".

Это все обязанности тимлида.

G>Это все обязанности тимлида.

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

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

Здравствуйте, SkyDance, Вы писали:

SD>Наблюдение со стороны: за последние 10 лет этот самый "тимлид" превратился из опытного инженера в какое-то супер-существо, которое и в софт-скиллах лучше менеджера, и кодит лучше программистов, да еще и в состоянии выдать кучу бумаг на гора. Еще и презентации проводить.

SD>Иными словами, почти единорог. Выполняющий всю сложную (и черную) работу, в т.ч. работу менеджера по разруливанию конфликтов.

По сути — это руководитель, который знает специфику в ИТ. А руководитель отвечает за все вопросы своей команды. Для этого оно и нужен.
И презентации он тоже должен уметь проводить, от этого зависит то, как о нём и его команде думает начальство и клиенты.

Вот как раз кодить хорошо ему не обязательно. Но уровень должен быть не ниже среднего, а лучше немного выше. Сильно хорошо нереально, т.к. банально не будет на это время.

Здравствуйте, alzt, Вы писали:

A>И презентации он тоже должен уметь проводить, от этого зависит то, как о нём и его команде думает начальство и клиенты.

С этого места подробнее. Какого рода презентации?

A>По сути — это руководитель, который знает специфику в ИТ. А руководитель отвечает за все вопросы своей команды. Для этого оно и нужен.
A>И презентации он тоже должен уметь проводить, от этого зависит то, как о нём и его команде думает начальство и клиенты.

Я ж говорю, единорог, швец, жнец, на дуде игрец.

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

Здравствуйте, Yodo, Вы писали:

Y>Он напишет что-то типа: Такой код мог написать только человек далекий от программирования.

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

Здравствуйте, SkyDance, Вы писали:

G>>Это все обязанности тимлида.

SD>Наблюдение со стороны: за последние 10 лет этот самый "тимлид" превратился из опытного инженера в какое-то супер-существо, которое и в софт-скиллах лучше менеджера, и кодит лучше программистов, да еще и в состоянии выдать кучу бумаг на гора. Еще и презентации проводить.
SD>Иными словами, почти единорог. Выполняющий всю сложную (и черную) работу, в т.ч. работу менеджера по разруливанию конфликтов.

По-моему сильно меньше, чем 10 лет. Это началось с появления массовой удаленки. Оказалось что эти самые "менеджеры" неспособны управлять программистами, которые не сидят в одном загоне опенспейсе по соседству с кабинетом менеджера. Поэтому тимлиду понадобилось стать еще и мастером по софт-скиллам. А менеджеры наоборот атрофировались, в отсутствие управления людьми.

Здравствуйте, alzt, Вы писали:

A>По сути — это руководитель, который знает специфику в ИТ. А руководитель отвечает за все вопросы своей команды. Для этого оно и нужен.

Есть Team Lead, есть Project Manager, есть System Architect, есть System Analytic. Не нужно всё валить на Team Lead. Он всего лишь ведущий программист с некоторым количеством подчинённых.

Здравствуйте, SkyDance, Вы писали:

SD>Наблюдение со стороны: за последние 10 лет этот самый "тимлид" превратился из опытного инженера в какое-то супер-существо, которое и в софт-скиллах лучше менеджера, и кодит лучше программистов, да еще и в состоянии выдать кучу бумаг на гора. Еще и презентации проводить.
SD>Иными словами, почти единорог. Выполняющий всю сложную (и черную) работу, в т.ч. работу менеджера по разруливанию конфликтов.

Тут есть нечеткость в названиях должностей, в разных местах на тимлиде разная ответственность. В некоторых компаниях тимлид — это вот как ты написал, сталкивался с таким.

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

Получается вполне сбалансированная комбинация. У тимлида в приоритете софтскилы, у техлида — хардскилы.

Здравствуйте, fmiracle, Вы писали:

F>Тимлид должен хорошо знать бизнес-функционал системы, но программировать может даже и вообще не уметь.
Самая большая глупость которую только можно придумать. Если ты руководишь людьми, то должен понимать в их работе настолько, чтобы мог оценить их работу. Для этого надо обладать не только соответствующими техническими знаниями, но и изрядным опытом. Не даром во всех рабочих специальностях прораб, бригадир или мастер это в первую очередь опытный работник. Даже Брукс почти 50 лет назад описал модель команды "бригада главного хирурга", где во главе стоит именно хирург (то есть специалист), а не эксперт в анатомии.
Если тимлид не будет понимать что делают программисты в его команде, то они легко навешают лапши на уши и будут делать то, что хочется им, а не нужно для компании или проекта.

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

F>В паре с ним работает техлид — это именно самый старший из разработчиков, участвует в планировании релизов как мнение со стороны разработки, он же курирует разработку именно в плане решениях технических вопросов.
Что значит "в паре"? Кто из них главный? Как разделены обязанности?
два человека не будут просто так работать "в паре" если у них пересекается зона ответственности. Это перманентный конфликт.

Таргет стейт — главным и единственным источником дискомфорта должнен быть твой тимлид, а не сосед справа.

Здравствуйте, Maniacal, Вы писали:

A>>По сути — это руководитель, который знает специфику в ИТ. А руководитель отвечает за все вопросы своей команды. Для этого оно и нужен.

M>Есть Team Lead, есть Project Manager, есть System Architect, есть System Analytic. Не нужно всё валить на Team Lead. Он всего лишь ведущий программист с некоторым количеством подчинённых.

Ещё тех лид, scrum master. Много команд, где наняты разные люди на все эти задачи? И сколько обычно в таких командах программистах работает? Почему-то сразу вспомнилась картинка про Васю.

Здравствуйте, SkyDance, Вы писали:

SD>А менеджер команде зачем? Или "тимлид" это новое название менеджера, которому платят меньше денег (он же не менеджер, да), но требуют больше технических знаний (ведь он же не менеджер).

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

Здравствуйте, Yodo, Вы писали:

Y>Банальный конфликт: один программист нелестно отозвался о коде другого. Слово за слово, один обозвал другого говнокодером.

Y>Нет, ну явно он не скажет: Ты, Вася — говнокодер, каких еще поискать.

Y>Он напишет что-то типа: Такой код мог написать только человек далекий от программирования.

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

Y>Вот кто такие конфликты решает? Менеджер? Тимлид? Скрум мастер? Какими скилами необходимо для этого обладать?


git merge

Здравствуйте, gandjustas, Вы писали:

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

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

Здравствуйте, Yodo, Вы писали:
Y>Банальный конфликт: один программист нелестно отозвался о коде другого. Слово за слово, один обозвал другого говнокодером.

<очень краткий курс кофликтологии>
все конфликты сводятся к личной безопасности
</очень краткий курс кофликтологии>

Y>Вот кто такие конфликты решает? Менеджер? Тимлид? Скрум мастер?

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

Y>Какими скилами необходимо для этого обладать?

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

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

Здравствуйте, alzt, Вы писали:

A>Ещё тех лид, scrum master. Много команд, где наняты разные люди на все эти задачи? И сколько обычно в таких командах программистах работает? Почему-то сразу вспомнилась картинка про Васю.

Ну, в предыдущем проекте я был Team Lead, в текущем System Architect и System Software Developer, от проджект менеджмента и аналитика меня избавили. Хотя, навык есть.