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

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

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

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

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

Здравствуйте, 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, от проджект менеджмента и аналитика меня избавили. Хотя, навык есть.

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

G>Что значит "в паре"? Кто из них главный?

А оно нужно знать кто главный?
А так — зависит от конкретной компании. Чаще главный — техлид. Просто в силу того что у техлида скорее всего несколько команд, и каждая со своим тимлидом.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

G>>Что значит "в паре"? Кто из них главный?

НС>А оно нужно знать кто главный?
Конечно, иначе коллективная безответственность.

НС>А так — зависит от конкретной компании. Чаще главный — техлид. Просто в силу того что у техлида скорее всего несколько команд, и каждая со своим тимлидом.
Главный вопрос в том, кто задачами управляет. Этот человек и должен разбираться в том, что делают люди. Естественно для каждой команды и должен быть один такой человек.

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

НС>>А оно нужно знать кто главный?
G>Конечно, иначе коллективная безответственность.

С чего вдруг? Над ними обоими есть начальник, он и отвечает.

НС>>А так — зависит от конкретной компании. Чаще главный — техлид. Просто в силу того что у техлида скорее всего несколько команд, и каждая со своим тимлидом.
G>Главный вопрос в том, кто задачами управляет.

Что значит "управляет задачами"?

G>Этот человек и должен разбираться в том, что делают люди. Естественно для каждой команды и должен быть один такой человек.

А над командами сразу СЕО? Или, по твоему, "кправление задачами" начинается и заканчивается внутри каждой команды?
Что то у тебя какое то очень примитивное представление об оргструктуре. В мелких организациях может такое и есть, а вот в тех что покрупнее ситуация посложнее. Это я не еще вспоминаю про всякие матричные истории.

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

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

тыжтимлид

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

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

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>>>А оно нужно знать кто главный?
G>>Конечно, иначе коллективная безответственность.
НС>С чего вдруг? Над ними обоими есть начальник, он и отвечает.
Если есть начальник, который за все отвечает, то ни тимлид, ни техлин не нужны. А если нужны, то не нужен начальник. Третьего не дано.


НС>>>А так — зависит от конкретной компании. Чаще главный — техлид. Просто в силу того что у техлида скорее всего несколько команд, и каждая со своим тимлидом.
G>>Главный вопрос в том, кто задачами управляет.
НС>Что значит "управляет задачами"?
Это значит распределяет задачи между исполнителями и определяет когда задача готова.

G>>Этот человек и должен разбираться в том, что делают люди. Естественно для каждой команды и должен быть один такой человек.

НС>А над командами сразу СЕО?
Не обязательно. Может быть сколько угодно слоев управления над тилидом.

НС>Или, по твоему, "кправление задачами" начинается и заканчивается внутри каждой команды?
Управление задачами — назначение конкретных исполнителей. На более высоких уровнях задача ставится команде в целом.

НС>Что то у тебя какое то очень примитивное представление об оргструктуре. В мелких организациях может такое и есть, а вот в тех что покрупнее ситуация посложнее. Это я не еще вспоминаю про всякие матричные истории.
Как это противоречит тому что я говорю? Я доношу очень простую формулу: если ты ставишь задачи людям и отвечаешь за результат, то ты обязан разбираться в их работе. Иначе программисты очень быстро запудрят тебе мозги и будут делать то, что хотят они. Не важно какая у тебя формально должность при этом.

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

НС>>С чего вдруг? Над ними обоими есть начальник, он и отвечает.
G>Если есть начальник, который за все отвечает, то ни тимлид, ни техлин не нужны.

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

НС>>Что значит "управляет задачами"?
G>Это значит распределяет задачи между исполнителями

Тимлид, очевидно.

G> и определяет когда задача готова.

Что значит готова? Готова к проду? Тогда это QA.

НС>>А над командами сразу СЕО?
G>Не обязательно. Может быть сколько угодно слоев управления над тилидом.

Ты только что решил, что они не нужны, ведь есть тимлид.

НС>>Или, по твоему, "кправление задачами" начинается и заканчивается внутри каждой команды?
G>Управление задачами — назначение конкретных исполнителей.

Исполнителей у задачи обычно много.

G> На более высоких уровнях задача ставится команде в целом.

И?

G>Как это противоречит тому что я говорю?

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

G>Я доношу очень простую формулу: если ты ставишь задачи людям и отвечаешь за результат, то ты обязан разбираться в их работе.

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

G>Иначе программисты очень быстро запудрят тебе мозги и будут делать то, что хотят они. Не важно какая у тебя формально должность при этом.

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

SD>Это также подразумевает и очень высокую зарплату тимлида, верно? Ведь и работа самая важная и тяжелая.

в большиий конторах с устоявшейся культурой типа top tier banks — процесс налажен и работает как часы. Гарантом его работы является благополучие работающих в этих местах людей, большинство менеджеров — экс контракторы с 10+ годами опыта работы в системе.

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

尿Ǥ푙> В американском майкросфте и оракле писали кипятком на отставных офицеров брали на рук. должности без айти опыта, не знаю как сейчас.

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

G>Если есть начальник, который за все отвечает, то ни тимлид, ни техлин не нужны. А если нужны, то не нужен начальник. Третьего не дано.

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

Если начальника (менеджера) из этого уравнения удалить, все становится на свои места. Непонятно только, зачем было начальника/менеджера переименовывать в "тимлида".

Могу лишь предположить, что это продолжение "перехода на эзопов язык", порожденное ИТ-гигантами. Когда менеджеров стали переименовывать в "лидеров". Потому что так звучит толерантнее. Забавные, вообще, процессы. Одно время, помню, было так — "подчиненный reports to начальник". Потом это признали немодным, и в системе поменяли на "подчиненный supported by начальник". В какой-то момент ржать над этим стали совсем уж громко. В основном из-за того, что это появилось в первую очередь у секретарш, которых переименовали в "executive assistants" — у тех с самого начала было написано как "секретарша supports начальник". Лулзы ловили зачетные.

Года 3-4 назад стали требовать так: "подчиненный led by начальник". И теперь не "начальник manages команду", а "начальник leads команду". Нужно ли говорить, что по факту ничего не изменилось?

G>Это значит распределяет задачи между исполнителями и определяет когда задача готова.

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

G>Как это противоречит тому что я говорю? Я доношу очень простую формулу: если ты ставишь задачи людям и отвечаешь за результат, то ты обязан разбираться в их работе.


Вот тут в точку!

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

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

Метания говн друг в друга — это скорее какие-то мелкие конторы или с сильным совковым привкусом менеджмента.

я вижу это постоянно. отсутствие (рабочей) дисциплины в первую очередь выливается в поднятые OP проблемы.

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

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

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

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