всем привет!

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

Итак, ситуация:

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

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

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

И хотя, налицо конфликт между ожиданиями и целями руководителя и интересами сотрудника, в организации не принято людьми разбрасываться, и в логике начальника такого нет. Уже около года ничего не меняется в лучшую сторону или меняется, но циклами – (с руководителя требуют «прозрачности», соблюдения сроков, и прочее), грубо говоря понапрасну, так как сотрудник сейчас почти ключевой, несмотря на указанные проблемы.

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

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

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

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

Предварительно можно поговорить приватно с каждым членом команды
что он думает про идею сделать того кадра архитектором.
Если большинство будет против, то об этом можно сказать в беседе с тем,
кто желает быть архитектором.
У него будет исходная информация на этот счет и он будет знать что в нем не то...
Через полгодика/годик можно посмотреть что изменилось
в нем и настроении команды.

Но подобную работу конечно стоит затевать только если
есть надежда на то, что он "вырастет" и исправит свои недостатки.

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

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

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

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

On Tue, 21 Mar 2006 17:41:51 +0200, Valery A. Boronin <1424@users.rsdn.ru> wrote:

> всем привет!
>
> тут все про технические аспекты что-то вопросы последнее время... как насчет проявить истинное мастерство управления?
> недавно попалась задачка, показавшаяся достойной обсуждения. Сразу отмечу это не у нас на фирме, можно считать это вымышленным случаем, хотя многие наверняка с таким сталкивались по одну из сторон баррикады Просьба уточняющие вопросы не задавать по этой же причине.
>
> Итак, ситуация:
>
> Есть руководитель команды, и один сотрудник, работающий уже много лет, разработчик, стремящийся стать архитектором.
>
> Руководитель не видит для этого возможности, так как:
> 1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем квалифицированными мягко говоря.
> 2 — есть проблемы с управляемостью, сотрудник не документирует работу, пишет код в котором может разобраться только он, по сути.
> 3 — саботирует приказы, реагирует только на кнут – в стиле – «не будешь делать, так как я говорю — лишим премии».
> 4 — если сотрудник выпадет из процесса по какой-либо причине — есть кому разбираться и делать его работу, но около 2х месяцев уйдет на изучение, и через еще месяца 4, возможно, ситуация выправится.
>
> Резюме:
> по сути даже за 2 месяца простоя в работе особо ничего не порушится, но уволить не хочется, все-таки есть в этом сотруднике много хорошего и полезного.
>
> И хотя, налицо конфликт между ожиданиями и целями руководителя и интересами сотрудника, в организации не принято людьми разбрасываться, и в логике начальника такого нет. Уже около года ничего не меняется в лучшую сторону или меняется, но циклами – (с руководителя требуют «прозрачности», соблюдения сроков, и прочее), грубо говоря понапрасну, так как сотрудник сейчас почти ключевой, несмотря на указанные проблемы.
>
> Вопросы:
> Можно ли изменить ситуацию?
> Каким образом?
> Пример разговора с сотрудником от лица руководителя?



--
Andriy Ohorodnyk

Valery A. Boronin wrote:

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

Дело не только в том, плохо или хорошо сотрудник работает. Ситуация в
той или ином виде понятна всем. Просто менять сложившиеся отношения
бывает сильно дороже для всех, чем строить новые.

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

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

Mikhail

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

Это возможно, если значимые критерии работника и менеджмента совпадают,
а также их взгляды на процесс разработки.

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

Были конечно и другие моменты, но этот работал практически как on/off
переключатель. И ведь до сих пор не уверен, что осознали. Речь не
о парном программировании, речь о постоянном фидбеке и обсуждении
текущего дизайна, вместо варения в собственном соку, которые в проекте
можно было получать только от соседей-девелоперов.

Mikhail

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

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

В качестве реального примера — банальные виндовые концы строк,
по ошибке попадающие в репозиторий при коммите с юникс-сервера.
Вариантов решения проблемы два: административно всех обязать
проверять файлы или поставить автоматический чекер, выдающий
warning-и и confirmation запросы при коммите. В итоге решают,
что надо бы всех обязать. Ирония и идиотизм ситуации в том,
что это и есть исходное состояние, и уже и так известно,
что этого недостаточно. Мало ли кто где промахнется. И что ?
Бить себя в грудь и всех переубеждать ? А они больше не видят
проблемы. Мол, вон оно решение, возьмем и обяжем. А то,
что чекер сделать — плевое дело, это мимо кассы. Эх...

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

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

Mikhail

Здравствуйте, Аноним, Вы писали:


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

Возможный ход мыслей членов команды: "Блин, этого выскочку и зазнайку в архитекторы??? Да я сам не прочь поархитектуировать (с)! Код пишет плохо (прим. читай НЕ ТАК КАК Я СЧИТАЮ ЧТО ЕСТЬ ХОРОШО!) ... Не бывать этому ...!"

А>У него будет исходная информация на этот счет и он будет знать что в нем не то...
А>Через полгодика/годик можно посмотреть что изменилось
А>в нем и настроении команды.

Тут возможны варианты ... я лично знаю одного парня -- очень талантливого человека и программиста, который писал ТАКОЙ код на Паскале (!), что разобрать было невозможно, но разрабатывал быстро ... но это работало и со свистом .

On Tue, 21 Mar 2006 23:02:27 +0200, byur <11826@users.rsdn.ru> wrote:

> Здравствуйте, Аноним, Вы писали:
>
>
> А>Предварительно можно поговорить приватно с каждым членом команды
> А>что он думает про идею сделать того кадра архитектором.
> А>Если большинство будет против, то об этом можно сказать в беседе с тем,
> А>кто желает быть архитектором.
>
> Возможный ход мыслей членов команды: "Блин, этого выскочку и зазнайку в архитекторы??? Да я сам не прочь поархитектуировать (с)! Код пишет плохо (прим. читай НЕ ТАК КАК Я СЧИТАЮ ЧТО ЕСТЬ ХОРОШО!) ... Не бывать этому ...!"
>
> А>У него будет исходная информация на этот счет и он будет знать что в нем не то...
> А>Через полгодика/годик можно посмотреть что изменилось
> А>в нем и настроении команды.
>
> Тут возможны варианты ... я лично знаю одного парня -- очень талантливого человека и программиста, который писал ТАКОЙ код на Паскале (!), что разобрать было невозможно, но разрабатывал быстро ... но это работало и со свистом .

а ситуация, когда один парень уходит ?
все переписивать заново, или молить ево штобы остался ? потому лутше
штобы он писал так как все, штобы другие могли разобрать, или
увольнять сразу, если отказываетса перестроитса — вот


--
Andriy Ohorodnyk

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

Прошу прощения. Я, вроде как не менеджер (хотя и побывал им), но,
надеюсь, мое мнение будет немного принято во внимание...

> Итак, ситуация:

Да, негатив так и прет

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

Почти??? Значит есть и нормальные отношения??? Почему нормальные? С кем?
Как, на каких принципах построены??? Копать.

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

Ему хватает времени на документацию кода??? Он способен документировать
код??? Есть ли у него стимулы документировать код??? Есть ли у него
стимулы НЕ документировать код??? Может он просто Вас боится??? Копать.

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

Гм. На заре моей трудовой деятельности меня научили одной вещи: приказ
стоит отдавать в том и только в том случае, если ты на 100% уверен, что
его выполнят. Смотреть в зеркало и рыть.

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

А может и станет намного лучше. Считать. Но только после того, как
разрыты пп 1-3.

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

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

> И хотя, налицо конфликт между ожиданиями и целями руководителя и
> интересами сотрудника, в организации не принято людьми разбрасываться, и
> в логике начальника такого нет. Уже около года ничего не меняется в
> лучшую сторону или меняется, но циклами – (с руководителя требуют
> «прозрачности», соблюдения сроков, и прочее), грубо говоря понапрасну,
> так как сотрудник сейчас почти ключевой, несмотря на указанные проблемы.
>
> Вопросы:
> Можно ли изменить ситуацию?

Можно.

> Каким образом?

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

Привет!
Что бы сказать однозначно нужно знать человека лично. Поэтому два мнения.
Первое. Мы деньги зарабатываем или мы благотварительная контора? Разговор — "Есть корпоративный стандарт? Почему не следуешь? Вот тебе наделя. В следующий понедельни экзамен. Не сдал — свободен — без отработок." И это не разбазаривание ресурсов. Хоть вы и говорите что если он выпадет, то сроки по возращению в нормальное русло работы вас устраивают. "по сути даже за 2 месяца простоя в работе особо ничего не порушится" — это однозначно не 100%, значит есть шанц, что даже недяля окажеться очень критичной. Самое плохое — что это произойдет в самый критичный момент. Конечно, можно постараться не допустить, что бы этому человеку достался на выполнение код, который модет быть критичным. Но тогда, скорей всего, он сам уйдет, так как потеряет вкус к жизни.

Второе. Если в человеке виден потенциал и способность учиться. Более того — вы хотите что бы он работал у вас и поднимался дальше по карьерной лестнице. Тут нужен приватный разговор. Его бы я выстроил так. Сначала я попытался бы выяснить его цели на ближайшие 2, 5, 10 лет. Эта информация помоглабы опредлить — готов ли человек менятся и есть ли у эта цель. Если он четко представляет себе свои цели, то объяснил бы ему, что для достижения целей нужно ументь находить компромис и подстраиваться под существующие условия. Затем показал бы ему его стороны, которые помемешают ему достичь его целей. Плавно бы подвел под то, что он сам бы проговорил все отрицательные моменты и в итоге добился бы от него вопроса "А что и как я должен сделать, что бы мои цели были достигнуты". Тут бы я предложил ему разработать план его изменения. И всячески бы помогал. Если коротко — я бы вызвал в нем желание меняться.

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

Здравствуйте, Valery A. Boronin,

Я считаю, что с народом поговорить надо. Если есть желающие работать под его руководством, то работа пойдет. Если же он не умеет ладить с людьми и не может сформировать вокруг себя группу, то вряд ли его деятельность как руководителя будет успешна.

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

Однако, в небольших и даже средних конторах (50-100 чел) распространена практика совмещения этих ролей. Что ИМХО не есть гуд, но такова реальность нашего бытия.


Успехов.

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

VAB>всем привет!

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

VAB>Итак, ситуация:

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

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

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

VAB>И хотя, налицо конфликт между ожиданиями и целями руководителя и интересами сотрудника, в организации не принято людьми разбрасываться, и в логике начальника такого нет. Уже около года ничего не меняется в лучшую сторону или меняется, но циклами – (с руководителя требуют «прозрачности», соблюдения сроков, и прочее), грубо говоря понапрасну, так как сотрудник сейчас почти ключевой, несмотря на указанные проблемы.

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

C уважением,
Геннадий Майко.

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

VAB>Есть руководитель команды, и один сотрудник, работающий уже много лет, разработчик, стремящийся стать архитектором.
VAB>Руководитель не видит для этого возможности, так как:
VAB>1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем квалифицированными мягко говоря.
VAB>2 — есть проблемы с управляемостью, сотрудник не документирует работу, пишет код в котором может разобраться только он, по сути.
VAB>3 — саботирует приказы, реагирует только на кнут – в стиле – «не будешь делать, так как я говорю — лишим премии».
VAB>4 — если сотрудник выпадет из процесса по какой-либо причине — есть кому разбираться и делать его работу, но около 2х месяцев уйдет на изучение, и через еще месяца 4, возможно, ситуация выправится.

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

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

А сотрудник об этом знает? Равно как и о списке своих, с точки зрения руководителя, недостатков?

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

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

Хоть ситуация и вымышленная, но без вопросов никак не обойтись...

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

А если он (сотрудник) прав ?

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

Как связаны между собой управляемость и документируемость кодя? Какая предметная область ? Может проблема в квалификации и мотивации команды ?

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

Все приказы считаются абсолютно правильными, не обсуждаются и не объясняются ?
Может человек умеет делать не как "говорят", а более эффективно ?

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

Эти цифры взяты на основе "наилучшего предположения", или есть все таки есть некий процесс планирования/постановки задач/контроля выполнения? Если и сейчас есть кому раазбираться и делать его работу, может большинство команды занято валянием дурака (варианты: объяснением причин сложности и невозможности сделать чего -либо, обсуждением/исследованием глобальных/универсальных концепций) ?

ИМХО, если проблема все-таки в сотруднике, и стоимость замены ~4 чел/месяца в длинном проекте, надо избавляться от его. Не обязательно, увольнять, главное убрать его с критических участков проекта. Но, сдается мне, что сотрудник просто не видит в руководителе реального лидера...

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

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

J>А сотрудник об этом знает? Равно как и о списке своих, с точки зрения руководителя, недостатков?

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

J>Это единственный способ выражения недовольства руководителем, или все таки сотруднику была изложена суть претензий?

цитата из оригинального сообщения:

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

так что ответов не могу знать

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

B>Здравствуйте, Valery A. Boronin,

B>Я считаю, что с народом поговорить надо. Если есть желающие работать под его руководством, то работа пойдет. Если же он не умеет ладить с людьми и не может сформировать вокруг себя группу, то вряд ли его деятельность как руководителя будет успешна.

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

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

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

все по делу, с большинством пожалуй соглашусь
по второму пункту:

SED>Затем показал бы ему его стороны, которые помемешают ему достичь его целей. Плавно бы подвел под то, что он сам бы проговорил все отрицательные моменты и в итоге добился бы от него вопроса "А что и как я должен сделать, что бы мои цели были достигнуты". Тут бы я предложил ему разработать план его изменения. И всячески бы помогал. Если коротко — я бы вызвал в нем желание меняться.
+1

SED>В такой ситуации еще видеться то, что человек так делает, потомуч то боится стать заменимым. Соответственно боиться быть уволенным.
просто по программистски рассмотрим альтернативные случаи: а что если он не специально так себя ведет, просто родился такой? по-моему не все (особенно молодые) сразу настроены на корпоративную борьбу без правил...да еще достаточно для этого подготовлены, чтобы так сознательно себя вести. хотя такой вариант (боится стать заменимым) конечно не исключается.

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

VAB>цитата из оригинального сообщения:
VAB>

Сразу отмечу это не у нас на фирме, можно считать это вымышленным случаем,

Дык я и не против. Прошу считать мои вопросы риторическими

Собтвенно, это был взгляд на проблему под другим углом.

Здравствуйте, Valery A. Boronin!

Я далек от менеджмента и никогда этим не занимался, все же есть несколько мыслей ...

В компании возник конфликт — ни в коем случае не стоит отрицать это и пытаться замаскировать под чьей-либо недостаточной квалификацией. Решать конфликты друг с другом может быть тяжело — куда проще быть посредником. В качестве посредника нельзя выбирать начальника — лучше незаинтереснованного человека, который может объективно оценить ситуацитю по месту. Однако вмешиваться сразу в их дела, не спросив разрешения тоже нельзя. Пусть спросит разрешения помочь разобраться в их конфликте. Как действовать человеку-катализатору? Тут привели уже много отличных советов, в случае, если не прав сотрудник (опросить коллег, узнать их мнения или хотят они его видеть в роле архитектора и т.д.). Если же не прав начальник... даже не знаю, как быть =). У Вас был когда-нибудь начальник, который не прав =)?

Впрочем, мне кажется, что все то, что я тут написал, Вы уже итак давно знаете =)...

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

Геннадий, любите Вы оверквотинг... эх, модераторская привычка
ГМ>--
ГМ>Попробуйте найти книгу 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. Называется — в каком объеме, каким способом и до какого предела компания может удовлетворять амбиции пусть и ключевого сотрудника. До бесконечности этого делать никто не будет, кроме того, такие вещи, как повышение оклада, не мотивируют ни на что (хотя и покупают лояльность).

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

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

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

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

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

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

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

VAB>всем привет!

Тезизы подчерпнутые из имхо толковых книг:

1. Полезность человека на данной позиции определяется тем, насколько часто к нему обращаются.

Соотв. если на архитектора кладут с пробором — ценности от него 0.

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

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

Мое имхо — архитектора или проектировщика нельзя просто так назначить, он обязан заполучить доверие большинства в команде.

On Thu, 13 Apr 2006 12:35:59 +0300, Joker6413 <16101@users.rsdn.ru> wrote:

> Здравствуйте, Valery A. Boronin, Вы писали:
>
> VAB>всем привет!
>
> Тезизы подчерпнутые из имхо толковых книг:
>
> 1. Полезность человека на данной позиции определяется тем, насколько часто к нему обращаются.
>
> Соотв. если на архитектора кладут с пробором — ценности от него 0.
>
> 2. Лидерство — есть чел. качество, такое что люди асооциируют лидера с возможностью достижения собственных целей.
>
> Соотв. если человек не смог убедительно продемонстрировать команде, что он эффективнее других видит путь достижения проектных целей — такой лидер нелегитимный.
>
> Мое имхо — архитектора или проектировщика нельзя просто так назначить, он обязан заполучить доверие большинства в команде.

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

как на меня — роли и ответственость распределить надо сначала,
а по мере утряски можно менять людей местами,

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

--
Andriy Ohorodnyk

J>Мое имхо — архитектора или проектировщика нельзя просто так назначить, он обязан заполучить доверие большинства в команде.

Как сказать. Если его не считают сильным профессионалом — то да.

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

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

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



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


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


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



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



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

MSS>Некоторые компоненты, такие, как GUI, вообще не поддаются юнит-тестированию.
Я сталкивался с умельцами кто тестировал ГУИ... вынужден согласится — мрачно но TDD штука прикольная



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

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

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

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

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

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

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

MSS>То-то у Microsoft есть понятие owner для любого куска кода. который часто один, хотя и меняется во времени.
И правильная политика. На любой работе должен быть 1 ответсвенный. Наверное поэтому и придумали ПМ, ведущих разработчиков архитекторов и тп.



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

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



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

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

Олухов надо гнать. А раз не выгнали, то поверте — под нормальным ведущим олух хотябы беды не наделает

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

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

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

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


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

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


MSS>Какая прелесть. Совок образца Константина Устиныча Черненко. Вы хоть время в MS Project на участие в этих митингах не забыли саллоцировать?
Между прочим есть очень важный фактор. Кажется — вовлеченность в проект. Очень важный мотиватор. Что касается черненко, то я не слышал о таком ПМ



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


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


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

Я очень рад, что мы с вами в большинстве вопросов сходимся

Евгений Веселов

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

VAB>Руководитель не видит для этого возможности, так как:
VAB>1 — есть проблемы в общении почти со всеми членами команды, выражающиеся в том, что свое мнение сотрудник всегда считает самым важным, а остальных членов команды не совсем квалифицированными мягко говоря.
VAB>2 — есть проблемы с управляемостью, сотрудник не документирует работу, пишет код в котором может разобраться только он, по сути.
VAB>3 — саботирует приказы, реагирует только на кнут – в стиле – «не будешь делать, так как я говорю — лишим премии».
VAB>4 — если сотрудник выпадет из процесса по какой-либо причине — есть кому разбираться и делать его работу, но около 2х месяцев уйдет на изучение, и через еще месяца 4, возможно, ситуация выправится.
А может он прав? И в команде что-то не так?
1. Задача архитектора выработать доказанное решение в форме понятной сверху (менеджменту и соседним структурам) и снизу (разработчикам). Может он просто плохо выполняет такие требования(что к сожалению часто бывает) и чем вызывает у сотрудника вполне обоснованный протест(типа что тут делает этот лох, когда я лучше)?
2. Задача team-leader не только корректно управлять заданиями и временем работы сотрудников. Его задача знать весь код и все особенности этого кода. Может он не выполняет свои функции если придется новому сотруднику разбираться в недокументированном коде?

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

Автор: Maxim S. Shatskih
Дата: 11.04.06

. А то тут все домыслы идут. Может там вообще XP....

GZ>1. Задача архитектора выработать доказанное решение в форме понятной сверху (менеджменту и соседним структурам) и снизу (разработчикам). Может он просто плохо выполняет такие требования(что к сожалению часто бывает) и чем вызывает у сотрудника вполне обоснованный протест(типа что тут делает этот лох, когда я лучше)?
GZ>2. Задача team-leader не только корректно управлять заданиями и временем работы сотрудников. Его задача знать весь код и все особенности этого кода. Может он не выполняет свои функции если придется новому сотруднику разбираться в недокументированном коде?

Честно говоря, у меня возникает мнение, что архитектор и тимлид в классическом понимании нужны _только_ тогда, если в компании всего 2 толковых разработчика, а остальные — лохи.

А если толковы _все_ разработчики? нужны ли вообще тогда функции архитектора и тимлида, или тут стоит почерпнуть что-то из XP?

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

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

MSS>>Такая маленькая мелочь. Чем выше позиция, тем меньше таких людей. Отсюда следствие — далеко не каждый сотрудник растет безгранично. Более того — у каждого сотрудника есть некий потолок, после которого он уже не способен к росту. По достижении этого потолка человек может хоть 10 лет на одном проекте на той же позиции сидеть.
M>Трудно с этим не согласится, но лично мне например ( и не только мне) больше по душе люди которые развиваются постоянно. Но я категорически не согласен с наличием строго вертикального роста. т.е классный разработчик -- проектный менеджер или системный аналитик. Кстати за вопросы по повышению квалификации команды тоже в ответе ПМ



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


MSS>>Согласен. Не будет более опытный человек всерьез прислушиваться к менее опытному. Почти никогда.
M>Ага и вам как ПМ осталось определить кто в каком вопросе самый опытный. Есть такой тест по работе командой(для менеджеров) дают набор работ из совершенно "левой" предметной области. Нужно их в правильном порядке расставить. два человека делая сие независимо и вместе имеют разыне результаты. Командный результат лучше..


MSS>>А вот если менеджер пытается лезть в технику... вот тут-то саботаж и начинается.
M>Менеджер обязан разибратся в области в которой он работает... Кроме этого конечно же лучше иметь экспертом которымподобные вопросв можно делегировать.



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



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

MSS>>Некоторые компоненты, такие, как GUI, вообще не поддаются юнит-тестированию.
M>Я сталкивался с умельцами кто тестировал ГУИ... вынужден согласится — мрачно но TDD штука прикольная



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

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

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

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

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

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

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

MSS>>То-то у Microsoft есть понятие owner для любого куска кода. который часто один, хотя и меняется во времени.
M>И правильная политика. На любой работе должен быть 1 ответсвенный. Наверное поэтому и придумали ПМ, ведущих разработчиков архитекторов и тп.



MSS>>Нет. Задача менеджера — обеспечить получение того продукта, ради которого трудится команда и тратятся ресурсы. С требуемым качеством и в требуемые сроки.
M>Хорошая книжная формулировка. Кстати еще менеджеру необходимо научится искать интерационные и компромисные решения да и выдать продукт хреновой командой не удасться..как ни крути. Хотя конечно бывают исключения...

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



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

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

M>Олухов надо гнать. А раз не выгнали, то поверте — под нормальным ведущим олух хотябы беды не наделает

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

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

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

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


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

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


MSS>>Какая прелесть. Совок образца Константина Устиныча Черненко. Вы хоть время в MS Project на участие в этих митингах не забыли саллоцировать?
M>Между прочим есть очень важный фактор. Кажется — вовлеченность в проект. Очень важный мотиватор. Что касается черненко, то я не слышал о таком ПМ



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


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


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

M>Я очень рад, что мы с вами в большинстве вопросов сходимся

M>Евгений Веселов

Написал длииинный такой ответ, и тут у меня упал IE, в соседнем окне которого был открыт RTFный документ. Увы.

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

Например, формализация всего делового общения между сотрудниками — дело а) благое б) азы управления бизнесом, то, с чего начинаются стандарты управления ISO 9000 и прочее.

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

Цель формализации — очевидна. Убрать межличностный элемент.

Что же касается "вовлеченности в проект" как мотиватора — слабенький это мотиватор, хилОй совсем. Это такой же мотиватор, как переходящее красное знамя в 83ем году.

По сравнению с такими вещами, как деньги и как наличие/отсутствие хамства — это просто пустяк.

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

MSS>Честно говоря, у меня возникает мнение, что архитектор и тимлид в классическом понимании нужны _только_ тогда, если в компании всего 2 толковых разработчика, а остальные — лохи.
Нет. Проблема в том, что у простого программера и архитектора(или человека выполняющего его функции) и роль и знания достаточно разные. Оружие архитектора не код, а некоторый документ(не важно в чем но он быть обязан) в котором описывается требования к архитектуре, как будут они выполняться, и т.д. Задача программистов — детализация и реализация. И стоимость ошибки архитектора и разработчика, разные на порядки. Нет ничего страшнее чем хреновый архитектор(разве что только хреновый PM). А не каждый разработчик сможет выполнять роль архитектора без дополнительного обучения.
Что касается Team Leader, то тут вопрос даже другой. Одной из задачей team leader уменьшить риски связанные с уходом того, или иного члена команды. Он должен знать что, где и как все работает. Это его прямая обязанность, ради которой он может даже пожертвовать ролью играющего тренера.

MSS>А если толковы _все_ разработчики? нужны ли вообще тогда функции архитектора и тимлида, или тут стоит почерпнуть что-то из XP?
Вот только не надо половинчатых решений. Слишком много проблем сразу получается. Возьмем даже ту что здесь проявилось. Для XP — чрезвычайно важный момент парное программирование(или хотя бы Code Review), общее обсуждение проекта и закладка на неправильные и недоделанные решения. Как только убираем что-то система падает с грохотом и начинается бардак вплоть до провала проектов. Собственно именно поэтому и возник вопрос, какой здесь принятый процесс.
Самое болезненное (и распроспространенное) это когда вообще не принят ни один процесс разработки. Сколь толковыми разработчики не были, если нет ни одного человека который владел бы всей информации о проекте, риски проекта повышаются.