Здравствуйте, Геннадий Майко, Вы писали:

Геннадий, любите Вы оверквотинг... эх, модераторская привычка
ГМ>--
ГМ>Попробуйте найти книгу A.Grove "High Output Management" и посмотреть там описание проведения "one-on-one" meeting. На мой взгляд, это неплохой способ не только решения конфликтных ситуаций, но и предотвращения их на корню.
Книга обнаружена по этому адресу

Однако она почему-то не входит во "Все книги Andrew S. Frove", это стоит иметь ввиду

VAB>просто по программистски рассмотрим альтернативные случаи: а что если он не специально так себя ведет, просто родился такой? по-моему не все (особенно молодые) сразу настроены на корпоративную борьбу без правил...да еще достаточно для этого подготовлены, чтобы так сознательно себя вести. хотя такой вариант (боится стать заменимым) конечно не исключается.
Привет!
Вариант нужно исключать, если его вероятность равна нулю . Еще — штатный психолог — это круто. Почему — он даст вам ту картину, которую вы увидете года через три совместной работы. Соответственно по партрету человека — выводы. Специалисты деляться на 2 типа. Под одних подстраивается работодатель. Другие должны подстраиваться под работодателя. Первый тип — это гении. Для них можно нанаять команду, которая все их мысли будет оборачивать в корпоративный стандарт. По этому поводу байка ниже. Вторые — есть молодые (== дешевые), которых нужно перекраивать. И есть опытные(!=дешевые). Вот опытные перестраиваются под стандарты быстро. А молодые... их нужно учить и объяснять. Вот у вас человек не хочет документировать код. Попросите друго человека найти его код двух месячной давности. Пригласите виновника торжества и дайте ему этот код. Через пять минут спросите что этот код делает. С очень большой вероятностью что за пять минут он ничего не скажет. Затем дайте ему документированные код... После этого, если не все так безнадежно, у него закрутяться соответствующие винтики. Я такой подход использовал и не раз. Результат — люди сами начинаю говорить: "Документирование кода — это классно", "Стандарт кода — да как мы без этого жили", "Сначала проектируем — потом пишем — по другом теперь и работать не будем". При этом — я никого не ломал. Люди сами доходят до этого.

Байка. Авторское право — не мое. Где услышал или прочитал — уже не помню. Детали — то же. Главное суть.
У фирмы расширился штат сотрудников одела. Пришли 5 новых молодых спецов. После всех приторок, молодые заметили, что старый рядовой сотрудник сидит и целыми днями играет в игры, лазеет по интернету или просто смотрит в окно. При этом, по его внешнему виду, получает он очень много. В конце концов такая вопиющая не справидливость заставила эту пятерку пойти к директору. Они предоставили кучу фактов, говорящих о том, что сотрудник ничего не делает, а получает, наверное, больше чем они все вместе взятые. Они услашили такой ответ: Вот сидя и ничего не делая, он предложил решение, которае сделало фирму и меня богатым. Теперь, если он досидит так до пенсии, это не будет стоить и милионной доли тех прибылей, которая приносит его решение. А если он еще что то предумает в таком духе — мои дети, внуки и правнуки будут обеспечены до конца своих детей. Поэтому, во первых, ему не мешайте и не лезте к нему, а так же воспринимаете его просьбы как мои приказы. Во вторых идите работать, потому что сейчас вы этого не делаете.

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

Valery A. Boronin wrote:
> всем привет!
Привет Валера.

> Итак, ситуация:
> Есть руководитель команды, и один сотрудник, работающий уже много лет, разработчик, стремящийся стать архитектором.
> Руководитель не видит для этого возможности, так как:

> 1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем квалифицированными мягко говоря.
> 2 — есть проблемы с управляемостью, сотрудник не документирует работу, пишет код в котором может разобраться только он, по сути.
> 3 — саботирует приказы, реагирует только на кнут – в стиле – «не будешь делать, так как я говорю — лишим премии».
> 4 — если сотрудник выпадет из процесса по какой-либо причине — есть кому разбираться и делать его работу, но около 2х месяцев уйдет на изучение, и через еще месяца 4, возможно, ситуация выправится.
Очень знакомо, +\- отдельные пункты для разных людей.
Сразу скажу, метод кнута сразу идёт лесом. При работе с людми имеющими интеллект выше
среднего и реально высокий уровень скилов, очень черевато потерять хорошего спеца или
столкнуться нетривиальным саботажем. А на работе, требующей хоть чуть чуть приложить
мазги, к падению эффективности в ноль.

Ты уверен что руководитель этого 'строптивго' сотрудника соответствует занимаемой должности?

Теперь о притензиях к сотруднику.
1)
Проблемы с общением встречаются в нашей среде достаточно часто. Я их разруливаю создовая
короткие цепочки в задачах и в трудных случая непосредственно сводя людей и завязывая
между ними обсуждение вопроса. Есть случаи кода кто-то просто _НЕ_ХОЧЕТ_ делать сою работу
... случай трудный но разруливаемый. В конце концов это вопрос текущей мотивации.

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

2)
Хм, управляемость и документирование таки разные вещи. Например у меня в команде есть люди
которые _ОЧЕНЬ_ хорошо документируют и свою и чужую работу, а есть те кто делает это
плохо. ИМХО, конечно но часто достаточно небольшого описания, а полноценное
документирование уже производить тем, кто это лучше всего делает.

С упровляемостью сложнее.
Если данный индивидум посылает планы на, и делает то что ему хочется — это клиника. Но
опть же учитывая скилы и облать деятельности, например R&D, с этим можно смериться
планирую работу такого сотрудника в соответствии с его приоритетной мотивацией. И вроде
будет как бут-то он всё прекрасно выпоняет. Может просто ему дают не ту работу. Люди ведь
не машыны. Но тут уже зависти от. Вполне возможно и то, что его будет лучше перевести в
другую команду или уволить.

3)
Про соботаж приказов я уже писал. Вопрос профессианализма лидера и совместимости. Возможно
что эти люди в принципе не могут работ вместе.

4)
Дык, не делай так чтобы всё зависило от одного человека. Эпидемия грипа там, гололёд,
сосульки опять же последнее время падають на людей...

>
> Резюме:
> по сути даже за 2 месяца простоя в работе особо ничего не порушится, но уволить не хочется, все-таки есть в этом сотруднике много хорошего и полезного.
Хм, не понял. Он ултиматум поставил что-ли — либо ему дают порулить, либо он уходит?
С адекватными людьми любой ултиматум разрулить можно, неадекватного луче отпустить, есть у
меня такое ИМХО.

> Можно ли изменить ситуацию?
> Каким образом?
> Пример разговора с сотрудником от лица руководителя?
Ну ты простой как два рубля одной бумажкой.

ИМХО, надо понять его _РЕАЛЬНЫЕ_ мотивы, что он _РЕАЛЬНО_ хочет, что он _РЕАЛЬНО_ может.
Понять а надо ли это компании и команде. Если надо, доступно показать ему как соотносяться
его скилы с его запросами и решить _ВМЕСТЕ_ с ним чего же с этим длать.

Однако, всё это ИМХО. Я не психолог и не манагер. Я всего лишь тимлидер небольшой команды.

AC>Привет Валера.
Привет Алексей!

AC>Очень знакомо, +\- отдельные пункты для разных людей.
угу

AC>Сразу скажу, метод кнута сразу идёт лесом. При работе с людми имеющими интеллект выше
AC>среднего и реально высокий уровень скилов, очень черевато потерять хорошего спеца или
AC>столкнуться нетривиальным саботажем. А на работе, требующей хоть чуть чуть приложить
AC>мазги, к падению эффективности в ноль.
полностью согласен

AC>Ты уверен что руководитель этого 'строптивго' сотрудника соответствует занимаемой должности?
нет не уверен сам бы хотел позадавать вопросы но к сожалению нет такой возможности

...

>> Можно ли изменить ситуацию?
>> Каким образом?
>> Пример разговора с сотрудником от лица руководителя?
AC>Ну ты простой как два рубля одной бумажкой.
Леша, читай внимательно стартовое сообщение — я тут фактически копи-пастом сработал, но лично отношения не имею к ситуации.

а ведь вопросы то все равно правильные и логичные — хоть и простые как три рубля одной бумажкой \эх где те времена \

>>> Можно ли изменить ситуацию?
>>> Каким образом?
>>> Пример разговора с сотрудником от лица руководителя?
> AC>Ну ты простой как два рубля одной бумажкой.
> Леша, читай внимательно стартовое сообщение — я тут фактически копи-пастом сработал, но лично отношения не имею к ситуации.
Дык, это к тебе относилось Вопросы ты задаёшь однако!
Это вроде — 'а как познакомиться с девушкой'? Ответ очень простой — познакомиться. Так же
и сдесь ИМХО, конечно, есть наверное и профи по разруливанию конфликтов, но моя иметь
уверенность, что готового сценария не существуует.

> а ведь вопросы то все равно правильные и логичные — хоть и простые как три рубля одной бумажкой \эх где те времена \
Ну нифига се простые! %) Если тебе действительно интересно, ты это лучше на E-xecutive спроси.

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

>>>> Можно ли изменить ситуацию?
>>>> Каким образом?
>>>> Пример разговора с сотрудником от лица руководителя?
>> AC>Ну ты простой как два рубля одной бумажкой.
>> Леша, читай внимательно стартовое сообщение — я тут фактически копи-пастом сработал, но лично отношения не имею к ситуации.
AC>Дык, это к тебе относилось Вопросы ты задаёшь однако!
ладно

AC>Это вроде — 'а как познакомиться с девушкой'? Ответ очень простой — познакомиться. Так же
AC>и сдесь ИМХО, конечно, есть наверное и профи по разруливанию конфликтов, но моя иметь
AC>уверенность, что готового сценария не существуует.
ага, вспомнил пример таких профи — и как разруливают конфликты

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

>> а ведь вопросы то все равно правильные и логичные — хоть и простые как три рубля одной бумажкой \эх где те времена \
AC>Ну нифига се простые! %) Если тебе действительно интересно, ты это лучше на E-xecutive спроси.
E-xecutive я не мониторю, да и не так интересно как такое разруливает высший командный состав (точнее я это знаю и так, "все это видел не раз" (С) Макаревич что ли).

Здравствуйте Valery A. Boronin, Вы писали :
> AC>и сдесь ИМХО, конечно, есть наверное и профи по разруливанию
> конфликтов, но моя иметь
> AC>уверенность, что готового сценария не существуует.
> ага, вспомнил пример таких профи — и как разруливают конфликты
>
> так вот, конечно профи есть: когда например высшему руководству надо
> сделать сокращение кадров — непопулярная в народе мера: их нанимают,

Профи действительно есть. И без негатива. Похоже Вам подойдет то, что
буржуи называют mediation. Если действительно нужно -- webmaster + [at]
+ intercitypost + . + com. Подниму старые контакты, посоветую людей в
Москве. Только, плз, если действительно нужно -- если просто интересно,
нафиг.

Здравствуйте, Valery A. Boronin, Вы писали:





VAB>Есть руководитель команды, и один сотрудник, работающий уже много лет, разработчик, стремящийся стать архитектором.

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

1. (извиняюсь конечно) неадекватное руководтство.
2. (тоже извиняюсь) всетаки неадекватный сотрудник которого не попросили "так как много лет в команде"
3. микс между пунктами 1 и 2. т.е что менеджер хорош что сотрудник хорош
4. Ваши варианты.

Теперь несколько отойдем от выяснения кто виноват, и проанализируем аргументы

VAB>Руководитель не видит для этого возможности, так как:
VAB>1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем квалифицированными мягко говоря.

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

VAB>2 — есть проблемы с управляемостью, сотрудник не документирует работу, пишет код в котором может разобраться только он, по сути.
пункт 3 пока не будем анализировать, так как к нему мы еще вернемся.

VAB>3 — саботирует приказы, реагирует только на кнут – в стиле – «не будешь делать, так как я говорю — лишим премии».

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

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

VAB>Резюме:
VAB>по сути даже за 2 месяца простоя в работе особо ничего не порушится, но уволить не хочется, все-таки есть в этом сотруднике много хорошего и полезного.
Самое трудное ( ИМХО конечно) это когото уволить. не согласиться с этим сложно .


VAB>Вопросы:
VAB>Можно ли изменить ситуацию?
Можно, не не сразу.
VAB>Каким образом?
VAB>Пример разговора с сотрудником от лица руководителя?

Итак вернмся к пункту 2 по поводу плхого кода и отсутствия навыков документирования. Сейчас куча всяких модных способов разработки ПО. в них есть одно общее правило. Разработка ведется итеративно. внутри итерации есть определенные фазы, например проектирование, разработка , документирование и тп. Некотрые, например ХП вообще говорят, что документирование затея нехорошая, код должен быть самодокуметирован..например, при помощи набора тестов. в принципе я лично придерживаюсь мнения что ТЩАТЕЛЬНОЕ документирование кода необходимо как раз при плохой и непрозрачной архитектуре, хотя с другой стороны очень неплохо иметь набор УМЛ диаграм для КЛЮЧЕВЫХ систем, дабы облегчить использование таких систем.
Далее с целью повышения качества програмного кода необходимо , например, делать такие вещи как кросс ревизия кода. Лично мне этот подход не сильно нравится так как придется выделять САМОГО УНОГО кто будет ее проводить. что чревато опять же личностными проблемами. более "мягкий" и как по мне действенный алгоритм — на ключевых подсистемах ИСКЛЮЧИТЬ работу ОДНОГО разработчика, не менее двух, к чему это приведет понятно. Но в любом случае у вас будет не менее ДВУХ людей, которые разберутся в написанном.. и не МЕНЕЕ двух людей способных обьяснить логику работу, что в свою очередь при выделении времени приведет к ЧЕТЫРЕМ знающим людям. ну и тп.

На месте менеджера, о котором идет речь, я бы начал парную разработку прямо сейчас, не теряя ни минуты.
Теперь далее, роль архитектора подразумевает высокую ответсвенность так как..ну вы понимаете
задача менеджера свячески СПОСОБСТВОВАТЬ развитию своей команды. в данном случае, человек, которые хочет быть архитектором должен. нет ПРОСТО обязан находить общий язык с командой. Как менеджер может ему в этом помочь ? Для начала вышеуказанный разработчик должен начать работать в качестве лида. Хотя бы с одним подчиненным. Пару ему необходимо менять. Перед началом такой практики сотруднику необходимо объяснить, что его задача не доказать всем что он самый умный, но попытатся научить остальных. Ведь если на проекте он так и будет самым грамотным разработчиком, а остальная команда не вырастет, то и ему ничего не светит как архитектору. Кстати, менеджера это тоже касается. Далее, необходимо проводить периодические командные митинги, на которых каждый будет рассказывать о проделанной и планируемой работе, а также о своих проблемах. периодические это не два раза в день но раз в одну-две недели.

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

Что касается "примера разговора с сотрудником", то хочется спросить в свою очередь, какого именно разговора? Менеджер обязан постоянно общатся с каждым подчиненным.
Итак начать нужно с того что "Сидоров ! хочу тебя попробовать на роли ведущего, тебе придется делать вот что..."
"Сидоров ! попробуем тебя на роли архитектора.. опиши для начала вот что... архитектуру того что ты тут наваял " потом предложи на всеобщее обсуждение решения Петиной задачи" ну и тп. Постоянно общайтесь со своей командой...

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

все написаннное кое где ИМХО, кое где провернено практикой...

С Уважением, Евгений

Прошу прощения за орфографию ! писал на коленке !

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>всем привет!
Приветствую!

Попробую и я проанализировать ситуацию.
Что мы видим из описания.
Сотрудник:
— Работает много лет над проектом.
— Надеется на карьерный рост
— "сотрудник сейчас почти ключевой, несмотря на указанные проблемы"
— "все-таки есть в этом сотруднике много хорошего и полезного"

Проект:
— Очевидно находится в стадии доработки/внедрения/кастомизации, коль скоро за 2 — 6 мес. ситуация при увольнении ключевого разработчика не сильно ухудшится. Хотя фраза "и через еще месяца 4, возможно, ситуация выправится" приводит к мысли, что руководитель все же побаивается лишаться данного разработчика.

Проблемы:
VAB>1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем квалифицированными мягко говоря.
Может мнение разработчика обосновано? С уверенностью можно говорить об этом конечно только после вникания в ситуацию подробно, но по косвенным признакам — похоже на правду.
Разработчик ключевой, скорее всего выполняет самую трудную с технической точки зрения работу. Возможно, принимает архитектурные решения.

VAB>2 — есть проблемы с управляемостью, сотрудник не документирует работу, пишет код в котором может разобраться только он, по сути.
Под документированием можно разное понимать: от комментариев до написания документации пользователя. Вполне вероятно, разработчику лень писать документацию. Но вопрос решается относительно легко. Нужно сказать, что в обязанности Архитектора одной из главных входит поддержание документации в актуальном состоянии (и ведь по большей части это правда ). Став на эту должность он будет документировать и заставлять других (когда поймет зачем нужны те или иные бумажки и когда с него начнут требовать в первую очередь их, а не программный код)!
Ну а про код, в котором никто не может разобраться тут 2 варианта: либо код сложен из-за того, что работник плохой в профессиональном плане программист, либо его уровень выше понимания остальных членов команды. Правильное — выбирайте по ситуации
Я склоняюсь ко 2-му, т. к. в первом случае довольно легко человека пристыдить более аккуратному члену команды, а таких, видимо нет в наличии.

VAB>3 — саботирует приказы, реагирует только на кнут – в стиле – «не будешь делать, так как я говорю — лишим премии».
Ну почему доходит-то до такого??? К менеджеру вопрос.
Почему опытный разработчик высказывает свое мнение (наверно не безосновательное), а оно не принимается. Подобная фраза — последний агрумент, когда возразить нечего.
Программист предлагает другое решение, но оно более долгое в реализации? — Наделите его ответственностью, как и пишут в книжках, скажите, хорошо, но сделать надо жестко в такой срок. Не сделаете, лишите премии, себя, меня и весь отдел.
(Помним, к тому же, что 2 — 6 мес. для проекта терпимый срок)
Программист предлагает решение, которое сам не может реализовать? — Не верю (по ситуации)
Программист предлагает решение, которое не понятно? — Возможно. Нужно попробовать вникнуть и поговорить, чем оно лучше/хуже решения менеджера.
Программист предлагает решение, которое не целесообразно? — Возможно. Нужно поговорить, он ведь основывается на своем опыте, который большой судя по описанию.

VAB>4 — если сотрудник выпадет из процесса по какой-либо причине — есть кому разбираться и делать его работу, но около 2х месяцев уйдет на изучение, и через еще месяца 4, возможно, ситуация выправится.
До этого дошло скорее потому, что уровня других разработчиков явно не хватает.
Выходы:
1. Нанять еще человека такого же уровня и передать ему дела. — Менеджер так бы и сделал, будь у него возможность, но ... либо штат не позволяет, либо зарплата разработчика меньше рыночной для его уровня.
2. Методично переделывать работу исходного разработчика силами других членов команды.

Что делать:
1. Проанализировать все-таки реальную ситуацию.
2. Поговорить с разработчиком, разобрав по пунктам все замечания к нему. Без наездов, по-нормальному.
3. Дать ему должность Архитектора (они и так эти функции скорее всего выплоняет) и потребовать все что в этом случае полагается.
— У руководителя будет козырь: всегда можно сказать о неполном служебном соответствии, мол, архитектор вам не программист, нужно еще много чего делать...
— Пусть сам новоиспеченный архитектор подготовит себе замену по всем участкам, т. к. на работу разработчиком у него времени будет мало, хочешь-не хочешь, а дела придется кому-то передать
— Через некоторое время, когда все дела будут переданы ...

И еще сценарий:
1. Уволить трудного работника и не тянуть нервы и не морочить голову ни ему (раз сидит на месте, значит надеется на что-то), ни себе, ни друзьям и знакомым .

Извиняюсь за сумбур и объем — просто излил поток сознания по вопросу, мож и пригодится кому

Самые главные вопросы:

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

Пока нет ответов на эти вопросы — разрулить конкретно данный case невозможно, возможно только разглагольствовать об "архитекторах вообще".

>Став на эту должность он будет документировать и заставлять других (когда поймет зачем >нужны те или иные бумажки и когда с него начнут требовать в первую очередь их, а не >программный код)!

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

Бумажки должны быть только а) наброски при первоначальном продумывании, цель — оценить реализуемость, возможные пути реализации, их плюсы и минусы. Реальный код "пересиливает" эти бумажки. Еще б) особо сложные части продукта, вызывающие серьезные разногласия среди девелоперов. Особое внимание в этих бумажках надо уделить перечислению различных путей реализации с плюсами и минусами. Цель бумажки — задать примерное направление, куда двигаться.

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

А>Ну а про код, в котором никто не может разобраться тут 2 варианта: либо код сложен из-
>за того, что работник плохой в профессиональном плане программист, либо его уровень выше
>понимания остальных членов команды. Правильное — выбирайте по ситуации

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

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

Сразу предсказываю результат — провал, лишение камрада премии, но и неприятные последствия для компании в целом. Реально доводить ситуацию до провала ради воспитания трудного сотрудника — не много ли чести?

К тому же нельзя мотивировать девелопера "ворочайся быстрее". Ни в коем случае нельзя, кроме разве что написания каких-то preview для демонстрации конкретному клиенту. Причина — такая установка приводит к чудовищному снижению качества кода. О вразумительной архитектуре тут можно забыть.

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

>А>3. Дать ему должность Архитектора (они и так эти функции скорее всего выплоняет) и
>потребовать все что в этом случае полагается.

Ага. А для этого руководство должно само для себя решить, что именно нужно от позиции архитектора. Конкретику.

>бы, правильно выразиться, карьерно. Суть конфликта на 80% именно в этом. время жизни
>разработчика на проекте примерно от 6 месяцев до полутора года(личный опыт, не

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

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

VAB>>Руководитель не видит для этого возможности, так как:
VAB>>1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что
>свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем
>квалифицированными мягко говоря.
>M>Боюсь что это справедливо для практически всех разработчиков, менеджеров .. да и
>вообще людей разных проффессий.

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

>нужно ЧЕТКО сделать то, что сказал менеджер.

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

А вот если менеджер пытается лезть в технику... вот тут-то саботаж и начинается.

>Сейчас куча всяких модных способов разработки ПО.

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

>в них есть одно общее правило. Разработка ведется итеративно.

Да. Это не "модные способы", а реальные требования, налагаемые рынком или заказчиками, короче, бизнесом. Нужна версия 1.0, а потом нужна 1.1, и уже стоит задуматься и о 2.0.

> внутри итерации есть определенные фазы, например проектирование, разработка ,
>документирование и тп.

Абсолютно не согласен. Как представлю себе внесение в MS Project "палочки" о документировании кода — так дурно становится — как можно так неэффективно работать? Код должен всегда пребывать в относительно документированном состоянии, критерий "документированности" — понятность соседу. Особенно это к интерфейсам относится.

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

При помощи собственных комментариев в первую очередь. Тратить время на юнит-тесты (время, часто сравнимое с написанием самого кода) имеет смысл только в особо ответственных местах, где хотелось бы не допускать появления баги ну почти любой ценой (в пределах ресурсов).

Некоторые компоненты, такие, как GUI, вообще не поддаются юнит-тестированию.

>набор УМЛ диаграм для КЛЮЧЕВЫХ систем, дабы облегчить использование таких систем.

Не надо делать из диаграмм культа, тем более из УМЛ.

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

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

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

Такую цель стоит решать напрямую митингом, а не уповать на доп. инструменты типа диаграмм.

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

Когда время есть — то конечно. А уж кросс-ревизия ради _вычитки явных багов_ — просто благо, особенно в системном софте, где поиск 1 бага часто занимает несколько дней. Кросс-ревизия _ради повышения читаемости_ — тут я более скептически отношусь, тому есть причины.

>Лично мне этот подход не сильно нравится так как придется выделять САМОГО УНОГО кто
>будет ее проводить. что чревато опять же личностными проблемами.

Да, личностных проблем при ревизии _на предмет читаемости и стильности_ будет куча. Вот на предмет явных багов — нет. Человек обычно спокойно относится к тому, что в его коде нашли явный баг. Другое дело, если ему сказали — "у тебя тут вообще все отстойно" — при том, что все работает.

>более "мягкий" и как по мне действенный алгоритм — на ключевых подсистемах ИСКЛЮЧИТЬ >работу ОДНОГО разработчика

Microsoft делал и делает совершенно иначе, и как-то лидирует на рынке ключевые подсистемы Windows написаны в 89-92 годы очень небольшим количеством людей, кое-где в одиночку. За большое время, порядка полутора лет каждая.

>людей, которые разберутся в написанном.. и не МЕНЕЕ двух людей способных обьяснить

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

M>задача менеджера свячески СПОСОБСТВОВАТЬ развитию своей команды.

Нет. Задача менеджера — обеспечить получение того продукта, ради которого трудится команда и тратятся ресурсы. С требуемым качеством и в требуемые сроки.

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

>находить общий язык с командой. Как менеджер может ему в этом помочь ? Для начала
>вышеуказанный разработчик должен начать работать в качестве лида. Хотя бы с одним
>подчиненным.

То есть?

Мы имеем — есть очень важный кусок проекта, на нем сидит 1 девелопер, который с заморочками, но в общем справляется, и труднозаменим. Ему предлагается — дать в нагрузку олуха царя небесного, просто из каких-то "менеджерских" соображений.

Вы можете себе представить, как упадет производительность этого девелопера (и олух-помощник ее совсем не повысит)? как это отразится на проекте в целом?

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

Тут же предлагается обратное.

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

За-чем??? не, ну правда, ну зачем??? у каждого из остальных — есть свой кусок работы, который тоже надо делать. Зачем отрывать от этого время ради обучения у того, первого девелопера? в ситуации, когда на тебе накопилось 100 issues в source control, человеку уже совсем не до получения знаний о _чужой_ компоненте проекта.

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

Налицо еще и неправильное понимание роли архитектора. Архитектура — она не зависит от исполнителей. Неужели это не понятно? Это чисто техническая вещь. Может быть хорошая архитектура при отстойной команде. Может быть наоборот.

Архитектор софта — это вообще практически не социальная роль. Он с объектами и абстракциями работает, а не с людьми. Это работа "человек — знаковые системы", а не работа "человек — человек".

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

Какая прелесть. Совок образца Константина Устиныча Черненко. Вы хоть время в MS Project на участие в этих митингах не забыли саллоцировать?

M>Теперь далее, команде нужно четко объяснить вектор развития карьеры

Ни одна компания не может обеспечить всему персоналу карьерный рост в плане количества подчиненных и наименования позиции. Да это и не есть цель никакой компании.

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

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

Скажем точнее — не в крупных компаниях, а в бестолковых.

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

А вот это очень и очень правильно. И людей надо приучать к _конструктиву_ в конфликтных и прочих гнилых ситуациях.

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

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

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

Ага, ага, есть такое слово "аттестация". Модное ныне, даже в спаме рассылают. Причина — это один из немногих способов массового увольнения, разрешенных в ТК

SED>Вариант нужно исключать, если его вероятность равна нулю . Еще — штатный психолог -
> это круто.

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

>Почему — он даст вам ту картину, которую вы увидете года через три совместной работы.

Он даст одну из возможных картин. А какая из возможностей реализуется через 3 года — неизвестно.

>Соответственно по партрету человека — выводы. Специалисты деляться на 2 типа. Под одних
>подстраивается работодатель. Другие должны подстраиваться под работодателя. Первый тип —
>это гении. Для них можно нанаять команду, которая все их мысли будет оборачивать в
>корпоративный стандарт. По этому поводу байка ниже. Вторые — есть молодые (== дешевые),
>которых нужно перекраивать. И есть опытные(!=дешевые). Вот опытные перестраиваются под
>стандарты быстро. А молодые... их нужно учить и объяснять.

Да, да, да. Совершенно согласен.

>игры, лазеет по интернету или просто смотрит в окно. При этом, по его внешнему виду,
>получает он очень много.

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

SED>Мораль такова, что если гений не хочет меняться — найимите людей которые
>удут "прослойкой" между ним и фирмой.

За исключением "улыбочного" момента, байка очень хорошая. Единственное что — такому "гению" обычно серьезный job title придумывают, и не сажают его в одну комнату с рядовыми и за одинаковый стол с ними. В части играния игрушки в рабочее время — да, все так.

Здравствуйте, Maxim S. Shatskih, Вы писали:

AC>>Проблема непризнаного авторитета, на самом деле, более важна и сильнее сказывается на
MSS>Замечание по ходу: а если человек сам себя считает техническим авторитетом, другие сотрудники тоже его таким считают, а вот руководство — нет? например, потому, что он на работу не вовремя приходит? что тут будем делать?

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

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

Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>С психологами ныне сложно. Образование стало модным уже лет 5 как, и туда каждая лахудра идет. Некоторые психологи есть полные дубы, на практике именно в психологических вопросах хуже среднего девелопера

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


MSS>Улыбнуло кто-то всерьез верит, что по виду человека можно судить о его доходе?
аха и их большинство! Так как богатых и крепких серядничков — абсолютное меньшиство — и именно они знают что по одежке не судят. А остальные... Со всеми вытекаующими.

MSS>За исключением "улыбочного" момента, байка очень хорошая. Единственное что — такому "гению" обычно серьезный job title придумывают, и не сажают его в одну комнату с рядовыми и за одинаковый стол с ними. В части играния игрушки в рабочее время — да, все так.

Здравствуйте, Maxim S. Shatskih, Вы писали:

>>Став на эту должность он будет документировать и заставлять других (когда поймет зачем >нужны те или иные бумажки и когда с него начнут требовать в первую очередь их, а не >программный код)!

MSS>"Бумажек важнее кода" быть не должно.
Должно-должно
Я не совсем те бумажки имел ввиду.
Комментарии в коде это так, на закуску. Они конечно должны быть, и хотелось бы, чтобы были качественные, но это не главное.
Главное для архитектора — описание архитектуры (включая диаграммы и даже возможно сценарии работы пользователя с системой, если их не проработал аналитик). Часто архитектор многие моменты держит в голове, а объяснения происходят из уст в уста...
Если, как я предположил (может и не обоснованно), разработчик выполняет роль архитектора он запросто может лениться описывать свои решения и для большого проекта это будет поважнее недокументированного кода, отсюда — сложность в понимании другими.
В исходном тексте написано: "сотрудник не документирует работу", что за работа, комментарии или другие документы???
А еще по важнее кода будут различные договоренности с заказчиком + технические требования, которые еще возможно подписывают (ну я думаю, здесь не тот случай).

MSS>Документация вне кода и в параллель коду — зло.
Мы о разной документации говорим

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

MSS> Но если все остальные девелоперы еще хуже....
А почему же он такой плохой все еще в команде?!

MSS>Сразу предсказываю результат — провал
Знаете что бывает с пророками

MSS>Реально доводить ситуацию до провала
Я из текста понял, что к провалу ситуация приблизится, если сотрудник уйдет, а вот если останется, да еще будет оценен ... не знаю-не знаю ...

MSS>ради воспитания трудного сотрудника — не много ли чести?
А вот и корень всех проблем!!!
С одной стороны "не много ли чести", с другой — неудовлетворенные карьерные амбиции.
Кто знает, может он халатно относится к части работы (которую считает не слишком важной) именно поэтому!
Надо вставать на позиции друг друга, друзья мои!
Чаще всего (может конечно мне так попадалось), люди вокруг — вполне вменяемые. И почти всегда можно договориться. Но тут появляются принципы с обеих сторон и понеслась...

MSS>К тому же нельзя мотивировать девелопера "ворочайся быстрее".
Нет, я не это имел в виду.
Сроки надо ставить реальные. А иногда (и так чаще всего бывает) их заказчик определяет, так что ... крутись как хочешь. Но итог: сделаешь — получшь деньги, нет — нет

MSS>Для борьбы с овердизайном хорошо подходит приурочивание бонусов к релизу продукта, или хотя бы к майлстонам. Типа создал овердизайн — затормозил работу — затянул сам себе премию.
Это если время позволяет... В данном случае наверно позволяет.

MSS>Ага. А для этого руководство должно само для себя решить, что именно нужно от позиции архитектора. Конкретику.
Бесспорно!

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

Документы по функционалу — это да. Но документы по внутренним техническим деталям реализации (т.е. именно архитектуре) — вот их уже можно заменить комментариями.

А>А еще по важнее кода будут различные договоренности с заказчиком + технические требования, которые еще возможно подписывают (ну я думаю, здесь не тот случай).

Так это не совсем архитектора работа.

А>С одной стороны "не много ли чести", с другой — неудовлетворенные карьерные амбиции.

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

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

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

А>Сроки надо ставить реальные. А иногда (и так чаще всего бывает) их заказчик определяет, так что ... крутись как хочешь. Но итог: сделаешь — получшь деньги, нет — нет

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

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

Естественно, работа в таком режиме означает, что сроков де-факто просто нет, и все надо сделать "вчера".