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

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

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

VAB>>а у себя я недаром начал фразой
VAB>>е) Неадекватная оценка ситуации кем-либов паре начальник-подчиненный
VAB>>т.е. именно это и имел ввиду что обратная связь должна быть двусторонней, наверное стоило это отдельно выделить, что сейчас и делаю

AF> Руководитель то не девелопер. Он может быть просто не в состоянии адекватно оценить нужно или не нужно было тратить на задачу столько времени.

еще раз подчеркиваю, таймлайн соблюден, заказчик счастлив — внешне все ОК
но накапливается неадекватность например у сотрудника, что его усилия не находят адекватной оценки — "OK, молодец, работа твоя всех устраивает, штрафов тебе не будет" — хотя сотрудник ожидал услышать что-то типа "ты уже год работаешь, качество кода на уровне, срыва сроков не было, мы хотим тебе выписать премию, повысить ЗП или просто ценим этот факт (если баблосов жалко\нету)". То что одна сторона принимает как должное может быть совсем по другому оцениваться другой стороной. Можно и в обратную сторону пример нарисовать, думаю.

AF> В итоге получаем, что даже для руководством маленькой группой нужен гений, а для руководством большой — сверх человек.

а не надо все и вся контролировать — это выглядит (как вариант) как тотальное недоверие или поиск зацепок\компромата на сотрудника для последующего полоскания при удобном случае перед командой\руководством (дабы не обошел по карьерной лестнице или просто про запас)

быть электровеником тоже не нужно, просто нужно или быть техспецом или иногда спрашивать такого человека о ситуации в команде не только с проблемными и отличившимися ребятами, а и с бойцами невидимого фронта\рабочими лошадками: темпераменты разные, один без похвалы скисает, другой после нагоняя только раскочегаривается. Один раз-два стерпит неоценку усилий или отмечание успехов соседа который просто не забывает уделить внимание своего рода PR самого себя при не лучшем кач-ве объеме работы, другой c типом хар-ра "вулкан" может 3 года копить а потом ни с того ни с сего таааакое выплеснуть...

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

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

ага, красиво, не согласиться и не поверить невозможно
и не увлечься если тебе еще нет 25 тоже

если у вас в 20 лет не вызывают горячее одобрение либерально-радикальные идеи, значит у вас нет сердца.
если в 40 лет вы еще не стали консерватором, значит у вас нет мозгов (с) Черчилль

Кстати я согласен несмотря на иронию

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

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

разве нет?!

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

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

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

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

S>Я бы добавил еще е:
S>склонение руководства к использованию техологий, которые либо бесполезны в данном проекте и для фирмы, либо вообще вредны, однако позволяют конкретному девелоперу за счет оплаченного рабочего времени изучить "модную" технологию. основная ель — пополнение собстенного "портфолио", позволяющего найти более высокооплачиваемую работу.

Обычно скорее наоборот -- налицо незнание технологий в компаниях занимающихся разработкой софта -- т.к. руководство не желает тратиться на "эти новомодные штучки". Типа -- инженер, высшее образование есть -- сам разбереться (а в планы время на самостоятельное разбирательство естественно никто не включал .
В качестве примера -- использование (точнее неиспользования) object-persistent frameworks и вообще laers в проектах, где велик риск изменения бизнес-логики. Я так знаю одну такую контору, которая кричит что подразделения по разработке софта (пишут на Java) убыточно. А присмотреться к проектам -- то сами выдумывают системы класса a-la Message Queue, то бизнес-логику в JSP засаживают ... а спрашиваешь про Hibirnate или WebSphere MQ и пр. -- оказывается, что и не слышали ..., а если и слышали -- то как в анекдоте:
-- Почему вы пилите тупой и ржавой пилой -- это ж неудобно и медленно?
-- Дык некогда точить -- пилить надо!

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

DAN>Часто встречается. решение: 1. объяснить человеку что разработка ПО это компромисс.
Правильное решение.

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

MSS>а) Перфекционизм.

MSS>б) Неряшливость.

MSS>в) Проблемы с концентрацией внимания.

MSS>г) Интриги.

MSS>д) Подковерные игры.

MSS>Ну вот примерно так.

MSS>Приглашаю всех внести свой вклад в тему.

IMHO, все эти факторы показывают, что существуют проблемы в менеджменте.
1. Я считаю, что в команде не достигнуто общего видения целей компании/проекта и понимания того, что нужно делать, как и когда для того, чтобы сделать все на высшем уровне и в заданые сроки + с определенным функционалом. Донесение целей и политики в руках менеджера проекта или Team Leader'a, который сможет транслировать слова бизнес-директора в разумы технических личностей.
Проработанный и донесенный до ВСЕХ членов стратегический план развития и цели проекта напрямую влияют на уменьшение влияния факторов, которые Вы указали.
2. Второй момент — это кадровая политика. На динамические в развитии проекты не стоит брать на место девелопера супер-гуру технаря. Таких людей я бы группировал в отдел Research, который разрабатывает обособленные концепции, а потом уж их применять в конкреитных проектах (High-Tech). А вот девелоперов с задатками менеджеров ("бизнес-девелоперов") бросал бы на динамику проекта.

DAN>>если не понимает применять административный ресурс: работа по вечерам и выходным (чтобы уложиться в сроки) здорово отрезвляет.
H>На мой взгляд, неверный ход. Проблему не решит, а новых проблем создаст предостаточно.
H>Никогда нельзя решать проблемы за счет личного времени сотрудников!
H>А если вы предлагаете оплачивать эти самые вечера и выходные, то некоторые девелоперы могут использовать это для увеличения своего заработка (пояснения, думаю, не нужны).
Я ж написал "если не понимает" (что ПО это компромисс).
Естественно требование выйти вечером/в субботу должно сопровождаться примерно следующим объяснением: "есть требования, есть планы, есть сроки. То что ты сделал навредило проекту с одной стороны, ты нарушил требования/планы, будь добр ущерб который ты проекту нанес устрани."

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

У нас оплачиваются переработки, но это совсем другая история: проверяется чем человек в это время занимался и оплачивается только если он грубо говоря за 50 часов в неделю сделал больше чем сделал бы за 40.

A>IMHO, все эти факторы показывают, что существуют проблемы в менеджменте.
Не стоит забывать что мотивация менеджеров и мотивация девелоперов — две большие разницы.
Девелопер может просто напросто игнорировать, то что ему будут рассказывать про "общее видение целей компании/проекта" и т.п., особенно если это выльется для него в лишний гемморой (например timesheet-ы вести, или все исключения тестировать)

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

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

A>>IMHO, все эти факторы показывают, что существуют проблемы в менеджменте.
DAN>Не стоит забывать что мотивация менеджеров и мотивация девелоперов — две большие разницы.
DAN>Девелопер может просто напросто игнорировать, то что ему будут рассказывать про "общее видение целей компании/проекта" и т.п., особенно если это выльется для него в лишний гемморой (например timesheet-ы вести, или все исключения тестировать)

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

DAN>Насчет кадровой политики — а насколько часто вы можете это себе позволить? В смысле вот этих туда, вот этих сюда? Это надо иметь много людей, много _разных_ проектов, и много кандидатов, чтобы было при отборе из кого выбирать. Это реально?

Один человек в разные моменты времени может выполнять несколько ролей. Сегодня он по плану разрабатывает, а завтра reseach'ем занимается. Главное таких людей найти!

A>Для того чтобы не игнорировали нужно правильно доносить. А если человек игнорирует — значит ему наплевать на компанию, а соответсвенно сотрудников, в которой он работает. Он одиночка и не командный игрок! Вы считаете это нормальным?
К сожалению жизнь не делится на черное и белое. И идеальные сотрудники (как и идеальное начальство) встречаются крайне редко.
Поэтому нужен контроль, нужны методы имени товарища Пряника, разработанные совместно с товарищем Кнутом, timesheet-ы, code review и т.п.

Если бы все было так просто, то все проблемы решались бы примерно следующим образом:
PM: — "ребята! пишите код без багов!"
Dev: — "Хорошо!"
QA: понуро уходят писать заявление об увольнении.

Или:
PM: — "доношу до вашего сведения, код надо писать без багов!"
DEV:- "хорошо!"
PM (через два дня): — у тебя баг в коде! Уволен!

DAN>>Насчет кадровой политики — а насколько часто вы можете это себе позволить? В смысле вот этих туда, вот этих сюда? Это надо иметь много людей, много _разных_ проектов, и много кандидатов, чтобы было при отборе из кого выбирать. Это реально?
A>Один человек в разные моменты времени может выполнять несколько ролей. Сегодня он по плану разрабатывает, а завтра reseach'ем занимается. Главное таких людей найти!
Далеко не всегда компания может потянуть найм таких высококвалифицированных разработчиков. Это опять же из разряда "лучше быть богатым и здоровым, чем бедным и больным"

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

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

DAN>>>если не понимает применять административный ресурс: работа по вечерам и выходным (чтобы уложиться в сроки) здорово отрезвляет.
H>>На мой взгляд, неверный ход. Проблему не решит, а новых проблем создаст предостаточно.
H>>Никогда нельзя решать проблемы за счет личного времени сотрудников!
H>>А если вы предлагаете оплачивать эти самые вечера и выходные, то некоторые девелоперы могут использовать это для увеличения своего заработка (пояснения, думаю, не нужны).
DAN>Я ж написал "если не понимает" (что ПО это компромисс).
DAN>Естественно требование выйти вечером/в субботу должно сопровождаться примерно следующим объяснением: "есть требования, есть планы, есть сроки. То что ты сделал навредило проекту с одной стороны, ты нарушил требования/планы, будь добр ущерб который ты проекту нанес устрани."
Наверно, я неверно расставил акценты. Меня поразило с какой простотой ответ "работать внеурочно" вы использовали для решения проблемы (два упоминания на пять пунктов) причем в довольно бескомпромисной форме. Ведь человеку предлагается по сути всего один вариант решения — поработать внеурочно сейчас и не отходя от кассы — если я правильно понял. А если мы говорим о ситуации, когда срыв плана оказался довольно ощутимым, нужно сначала разобратся, чьи действия/бездействия к этому привели. РМ или тимлид должны знать плюсы и минусы своих разработчиков и принимать привентивные меры дабы не допускать таких ситуаций. Не нужно об этом забывать.

DAN>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
Возможно, тогда это не те люди, которые вам нужны на проекте? Возможно такого человека лучше подключить к проекту, где его особенности будут на пользу проекту + проводить ненавязчивое (полуофициальное), так сказать, "перепостроение" мышления.

H>Наверно, я неверно расставил акценты. Меня поразило с какой простотой ответ "работать внеурочно" вы использовали для решения проблемы (два упоминания на пять пунктов) причем в довольно бескомпромисной форме. Ведь человеку предлагается по сути всего один вариант решения — поработать внеурочно сейчас и не отходя от кассы — если я правильно понял.
Я наверное тоже неверно расставил акценты. Внеурочная работа по приказу это крайне редкое явление. Крайняя мера. Кранее этой меры может быть только увольнение. Потому как в большинстве случаев команда вменяемая.

Расскажите, пожалуйста, с вашей стороны как поступать в такой гипотетической ситуации:
1. Есть требования, планы и сроки. Сроки жесткие. Грубо говоря речь идет о том чтобы хотя бы успеть закончить основные фичи.
2. Разработчик в курсе вышеперечисленных условий.
3. Разработчик вместо основного функционала занимается рющечками. Ну вот очень хочется ему такую фичу сделать. Или вместо забивания костыля (а иногда и такое приходится делать из расчета переделать в следующей версии) затевает рефакторинг на полпроекта.
4. То что он сделал надо:
— ревьювить,
— тестировать,
— документировать.
Грубо говоря день работы такого девелопера стоит проекту:
1 день его работы + 1 день который он должен был потраить на совсем другое + 0.5 дня работы тестера + 0.25 дня на ревью + 0.25 дня на документирования = 3 человеко/дня.

Ваши действия в данной ситуации? Объяснить еще раз? А потом еще раз? за 3 таких объяснения набегает грубо говоря 2 недели.

DAN>>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
H>Возможно, тогда это не те люди, которые вам нужны на проекте? Возможно такого человека лучше подключить к проекту, где его особенности будут на пользу проекту + проводить ненавязчивое (полуофициальное), так сказать, "перепостроение" мышления.
К сожалению у меня нет возможности с легкостью перемещать человека из команды в команду из проекта в проект. Решающую роль тут играет порог вхождения, технические скиллы и т.п.
К тому же я не совсем понимаю как перфекционизм может проявляться в одном проекте и не проявляться в другом? (это было первое упоминание)

Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
Ваши действия в данном случае?

savaDAN wrote:
>
> 3. Разработчик вместо основного функционала занимается рющечками. Ну вот
> очень хочется ему такую фичу сделать. Или вместо забивания костыля (а
> иногда и такое приходится делать из расчета переделать в следующей
> версии) затевает рефакторинг на полпроекта.
> 4. То что он сделал надо:
> — ревьювить,
> — тестировать,
> — документировать.

Заставить откатывать такие изменения.

Mikhail

>> 4. То что он сделал надо:
>> — ревьювить,
>> — тестировать,
>> — документировать.

K>Заставить откатывать такие изменения.
Это тоже несомненно используется. но день тем не менее потерян.

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

H>>Наверно, я неверно расставил акценты. Меня поразило с какой простотой ответ "работать внеурочно" вы использовали для решения проблемы (два упоминания на пять пунктов) причем в довольно бескомпромисной форме. Ведь человеку предлагается по сути всего один вариант решения — поработать внеурочно сейчас и не отходя от кассы — если я правильно понял.
DAN>Я наверное тоже неверно расставил акценты. Внеурочная работа по приказу это крайне редкое явление. Крайняя мера. Кранее этой меры может быть только увольнение. Потому как в большинстве случаев команда вменяемая.
Такое отношение вполне поддерживаю.

DAN>Расскажите, пожалуйста, с вашей стороны как поступать в такой гипотетической ситуации:
DAN>1. Есть требования, планы и сроки. Сроки жесткие. Грубо говоря речь идет о том чтобы хотя бы успеть закончить основные фичи.
DAN>2. Разработчик в курсе вышеперечисленных условий.
DAN>3. Разработчик вместо основного функционала занимается рющечками. Ну вот очень хочется ему такую фичу сделать. Или вместо забивания костыля (а иногда и такое приходится делать из расчета переделать в следующей версии) затевает рефакторинг на полпроекта.
DAN>4. То что он сделал надо:
DAN> — ревьювить,
DAN> — тестировать,
DAN> — документировать.
DAN>Грубо говоря день работы такого девелопера стоит проекту:
DAN>1 день его работы + 1 день который он должен был потраить на совсем другое + 0.5 дня работы тестера + 0.25 дня на ревью + 0.25 дня на документирования = 3 человеко/дня.
DAN>Ваши действия в данной ситуации? Объяснить еще раз? А потом еще раз? за 3 таких объяснения набегает грубо говоря 2 недели.
О ситуации с такими условиями мне сложно говорить с уверенностью (слава Богу пока жил без них).
Тут нужно оговорить два варианта: говорим о программисте, работающем на проекте довольно давно, и о новичке на проекте/в организации (на испытательном сроке).
В обоих случаях руководитель виновен на 50%.
В первом случае, если такие ситуации начали проявлятся некоторое времени назад, нужно проанализировать почему их не было ранее. Если проявляются всё время работы в фирме — нужно было внимательнее смотреть на работу человека во время испытательного срока (ошибка руководителя).
Во втором случае при отсутсвии реакции нужно раставатся.

DAN>>>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
H>>Возможно, тогда это не те люди, которые вам нужны на проекте? Возможно такого человека лучше подключить к проекту, где его особенности будут на пользу проекту + проводить ненавязчивое (полуофициальное), так сказать, "перепостроение" мышления.
DAN>К сожалению у меня нет возможности с легкостью перемещать человека из команды в команду из проекта в проект. Решающую роль тут играет порог вхождения, технические скиллы и т.п.
Типичная проблема для многих оргенизаций

DAN>К тому же я не совсем понимаю как перфекционизм может проявляться в одном проекте и не проявляться в другом? (это было первое упоминание)
Рискну выразить предположение, что причиной подобного поведения при реализации задания является неудовлетворенность программиста. Есть люди, которые довольно плохо себя чувсвуют при жостких условия работы, люди любящие креатив. Им для раскрытия своего потенциала необходимо больше свободы действий. В такой ситуации полностью раскрывается их потенциал.
При "разборе полетов" будет не лишним выянить это.
З.Ы. Сам такой. Был в аналогичной ситуации: работа нудная, креатива никакого, вот от скуки и пришел к подобной ситуауции. Проблему решил сменой работы. В итоге я доволен, бывший работодатель тоже не в обиде.

DAN>Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
DAN>Ваши действия в данном случае?
Узнать, чего человеку не хватает. Если просто разгильдяй — нужно увольнять при первой же возможности (имеется в виду, что это может быть нецелесообразно именно в данный момент при нехватке ресурсов). Если же есть какое-то внутренне недовольство, но вполне/частично обоснованое — попытатся решить.

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

A>>Для того чтобы не игнорировали нужно правильно доносить. А если человек игнорирует — значит ему наплевать на компанию, а соответсвенно сотрудников, в которой он работает. Он одиночка и не командный игрок! Вы считаете это нормальным?
DAN>К сожалению жизнь не делится на черное и белое. И идеальные сотрудники (как и идеальное начальство) встречаются крайне редко.
DAN>Поэтому нужен контроль, нужны методы имени товарища Пряника, разработанные совместно с товарищем Кнутом, timesheet-ы, code review и т.п.

DAN>Если бы все было так просто, то все проблемы решались бы примерно следующим образом:
DAN>PM: — "ребята! пишите код без багов!"
DAN>Dev: — "Хорошо!"
DAN>QA: понуро уходят писать заявление об увольнении.

DAN>Или:
DAN>PM: — "доношу до вашего сведения, код надо писать без багов!"
DAN>DEV:- "хорошо!"
DAN>PM (через два дня): — у тебя баг в коде! Уволен!

То, что ты привёл в качестве примера как раз подтверждает точку зрения Architect'а. Если менеджер говорит такое девелоперам — то эта как раз так классическая проблема менеджмента — не умение (или не желание) донести свои мысли до подчинённых. Что есть первейшая и главная задача любого менеджера. Менеджер получает свои деньги в первую очередь за умение общаться — понимать людей и доносить до них свои мысли — причём так, что бы они это поняли. Если он не умеет или не хочет этого делать — его надо менять.

Кроме того, начинать всегда лучше с себя. Если у менеджера в голове бардак то как он сможет ясно и чётко донести до девелоперов цели их работы и расставить приоритеты? Это всё равно что ожидать от пьяного в стельку глубокого стратегического мышления. Менеджер сам должен ясно и чётко предствалять себе — чего он хочет, каковы его цели, что он хочет получить от каждого из девелоперов, расставить приоритеты (и уметь быстро соображать в меняющихся обстоятельствах). Вот тогда он сможет и донести свою мысль до разработчиков и убедиться в том, что его правильно поняли.

DAN>>>Насчет кадровой политики — а насколько часто вы можете это себе позволить? В смысле вот этих туда, вот этих сюда? Это надо иметь много людей, много _разных_ проектов, и много кандидатов, чтобы было при отборе из кого выбирать. Это реально?
A>>Один человек в разные моменты времени может выполнять несколько ролей. Сегодня он по плану разрабатывает, а завтра reseach'ем занимается. Главное таких людей найти!
DAN>Далеко не всегда компания может потянуть найм таких высококвалифицированных разработчиков. Это опять же из разряда "лучше быть богатым и здоровым, чем бедным и больным"
Тогда ей нуджно ставить подходящих людей (квалифицированы они или же просто хорошо соображают) на ключевые позиции и наделять их адекватными полномочиями.
Или вы надеетесь, что компания целиком состоящая из людей, которые не квалифицированы или плохо соображают — что они делают — сможет вести себя эффективно и адекватно — в том числе и по отношению к процессу разработки?

DAN>PS: т.е. мне в рамках данного топика куда как интересней услышать как обычного (среднестатистического) разработчика убедить работать хорошо, а то что с классными разработчиками все будет классно — никто не сомневается.
Ставить его в условия, когда он будет в тонусе и ясно и чётко доносить до него, что нужно сделать — обязательно выслушивая его и помогая ему использовать его творческий потенциал так, что бы это сочеталость с интересами бизнеса — теми результатами, которые желательно было бы получить.

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

DAN>Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
Ты уверен, что можно находиться "в потоке" 5*8?

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

MSS>Предлагаю открыть эту тему. Как мне кажется, она играет огромную роль в управлении проектами.

+1 Согласен, и даже более того, я бы сказал основную

MSS>Итак. Какие мы знаем проблемы в психологии взаимоотношений руководства с девелоперами, которые могут выйти боком?

Я думаю дело не в подробном анализе каждой проблемы. Роль человека, чтоящего над девелоперами, имхо, похожа во многом на роль тренера в команде (для примера футбольной). Одным из главных качеств, как на мой взгляд, является умение оценить вклад каждого человека в проект, умение провести с ним беседу и настроить в нужном ключе, поддержание рабочей атмосферы, которую легко нарушить, но нелегко воссоздать. А мотивация она у каждого своя. Кому-то денег, кому-то интересные задачи, кому-то 31 день оплачиваемого отпуска, кому-то вермя на реализацию своих идей. Это тоже надо понимать и предоставлять.

Вот, как мне кажется, отличный пример психологической мотивации:

Был случай, когда Демьяненко, Бессонов и еще кто-то приехали на базу сборной в несколько помятом состоянии. Лобановский вызвал их, дал, как говорится, на орехи. А на установке Валерий Васильевич сказал: "А повязочку, Толя, придется отдать Ринату Дасаеву". Демьяненко был готов сквозь землю провалиться. Далее Лобановский продолжил: "Кстати, Толя, ты на какой позиции сегодня играешь?". — "Левого защитника, Васильич".- "Нет, Толя, ты сегодня будешь играть левого защитника, полузащитника и нападающего". Демьяненко вышел — и забил гол.
После матча Лобановский сказал: "Толя, такой ты мне нравишься. Ринатик, верни повязку".

P. S. Ты случаем в Киевском Динамо не подрабатываешь в свобное время?

DAN>>Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
SC>Ты уверен, что можно находиться "в потоке" 5*8?
Нет конечно.
Но быть не в потоке можно тоже по разному: можно книжки по ИТ читать, можно RSDN (опять же много полезного), а можно например на love.mail.ru или irc тусоваться.
А вообще, если человек работает, успевает по планам и т.п. — пусть себе делает что хочет, как хочет и когда хочет.
Единственно в чем он теряет это в перспективе/карьерном росте, но это уже личное дело каждого.

Цель.
На многочисленных мозговых штормах я заметил странную особенность человеческого сознания уходить от решения конкретного вопроса, и тогда приходиться «спускать» разработчиков на землю словами: а что это нам даст, а приблизит ли это нас к цели, а собственно, кто-то помнит, зачем мы здесь собрались?
Итак, господа разработчики и руководители проектов, давайте определимся с целью данного обсуждения. Что же мы хотим получить в результате? После изучения всего вышесказанного позволю себе сделать вывод: обсудить некоторые тезисы, которые не совсем совпадают с нашим собственным представлением. Это все здорово, но как-то размыто. Поэтому предлагаю более реальную цель: ответить себе на два вопроса, чем я хочу заниматься и ради кого я работаю?
Термины.
Если я говорю хороший разработчик, хороший руководитель – то это обозначает, что люди адекватны (логическое мышление, ответственность и т.п.) и люди заинтересованный в результате (материальное и моральное удовлетворение).
Проект – бывают разные, большие и не очень, критичные и так себе, поэтому предлагаю под эти термином понимать временной континуум примерно в 1 год, когда основная часть усилий команды тратиться на создание ПО для конкретного рынка или заказчика.
Руководитель проекта. Прежде все я имею в виду руководителей софтверных проектов с типичными обязанностями менеджера (планирование, координация, контроль, обучение, риски, коммуникации и т.п.). Сфера ИТ включает в себя так же системное администрирование, у этой сферы своя специфика, во многом не совпадающая с софтверной, поэтому руководство админами здесь не упоминается.
Самое главное правило. Правило дающее ответ на вопрос «ради кого я работаю?».

Суть.
Сколько нужно времени на взращивание хорошего разработчика? Я имею в виду человека пришедшего на работу по окончанию ВУЗа (или же на последнем курсе) и имеющего базовые представления в программировании. В большинстве своем это 2 года. Пол года на то чтобы человек определился, куда он попал и чего от него ждут. Еще пол года на совершенствование знаний и навыков. Добавим к этому еще год и получим хорошего разработчика. Да, бывают исключения… но редко.
А сколько времени необходимо на выращивание руководителя проекта? Отвечу – 10 лет. Скорее всего, услышу много возражений, и правильно! Только для того, чтобы понимать, что ты все еще плохой руководитель необходимо потратить несколько лет. Все же я попробую обосновать цифру: 1 год – полный нуль, 2 – ага, я руковожу людьми, я принимаю решения, на мне огромная ответственность. 3..4 – совершенствование знаний, 5..6 – проект = команда, учимся работать с людьми, 7-10 – зрелость, опыт. За это время руководитель успевает поработать в среднем в 7 проектах. Что не так уж и много, но вполне достаточно чтобы в 35 лет осознать, что появился опыт, что люди и проекты бывают разные и каждому случаю нужен свой индивидуальный подход. И что серебряной пули не существует.
Не зря я задавал вопрос о времени. Ни какие книги, ни какие курсы не дадут того, что даст опыт. Опыт = время. Время = жизнь (ВАША жизнь!). Итак, определяйтесь, хотите ли вы стать руководителем (конечно же хорошим) или все же остаться хорошим разработчиком.
Тезисы.
Все же высказанные выше мысли (на форуме) задели и меня, поэтому попытаюсь ответить на них.

О восприятии.
Восприятие руководителем людей в команде как "винтиков". Каюсь, грешен. Сам однажды не сдержавшись, высказал такое своему разработчику. Хотя нет, не каюсь, в той ситуации это было сказано по делу и поделом. Поверьте, когда разработчик увольняется и при это называет в качестве причины «лидер заставлял исправлять баги», сдерживаться не хочется (но это классика звездной болезни, а о таких тут не говорят).
Конечно же, когда я говорю о «винтиках», то имею в виду, прежде всего себя. Ребята, я ваш руководитель, но я ничем не отличаюсь от вас, я в той же самой упряжке. Работа может нравиться и не нравиться (так же как и профессия), но если ты «подписался» ее сделать, то старайся оставлять эмоции за дверью офиса. И не трать энергию на самоедство или демотивацию, она еще пригодиться для выполнения рутинной работы.

Об истоках и харизме.
Откуда берутся руководители проектов? Как верно было замечено это бывшие хорошие разработчики. Из личного опыта могу судить, что приходящие из других сфер могут ужиться в команде при одном условии: архитектор или лидер разработки заменит ему личный опыт программирования. Нужна ли руководителю харизма и лидерские качества? Да, но зависит от команды. В любом случае, отношения в команде необходимо выстраивать таким образом, чтобы люди работали, а не ждали лидера или милашку. Есть предположение, что при определенной направленности (желании и работе над собой) и то и другое со временем вырабатывается. Судить самому тяжело. Спрошу у команды ( ).

О руководстве, общении.
Не хочу долго распространяться, поэтому коротко. Правило №1: прежде чем менять людей – измени себя. Правило №2: единственный способ снять или предупредить конфликт – общение. Считайте, что общение это часть обучения команды (так же как обучение новой технологии), которое обязан поддерживать руководитель.

Об ответственности.
Тоже кратко. Каждый член команды должен знать: сколько времени ты забираешь у команды (опоздания, личные обстоятельства и пр.), столько она имеет право забрать у тебя. (и при этом не имеет смысла четко подсчитывать по минутам, себе дороже).

О поощрении инициативы и большей свободе для разработчика.
Поощрения – каждому свое, но в 95% случаев это деньги. По собственному опыту могу судить, что никакие социальные программы не прокатывают. Бесплатные обеды и медицинская страховка со спортзалом практически не влияют на принятие решения о смене места работы. Предполагаю, что связано это с двумя факторами: (1) дикий рынок, всегда найдется только что открытый оффшор который срочно, за любые деньги набирает разработчиков; (2) моральный дискомфорт, когда кто-то за туже или худшую работу получает больше. По первому фактору могу лишь сказать, что ходят слухи, что цена производства ПО в Киеве уже выше, чем в Индии. По второму, социальная программа действительно делает ЗП выше, вопрос только на сколько?
Для решения проблем с инициативой необходимо приветствовать идеи. Например, в моей команде все знают: принимаются все идеи даже самые безумные. Здесь важно два момента: (1) ни одна не должна потеряться; (2) человек получит аргументированный ответ, почему его идея хороша или плоха. Не проблема так же, давать разработчику выпустить пар, то есть пусть некоторое время потратит на реализацию своей идеи и сам убедиться хорошо это или плохо. Руководитель в любом случае выигрывает.
Ну и конечно старое доброе правило: хвали прилюдно, ругай с глазу на глаз.

О без умном (это не опечатка) поощрении.
Помните: что поощряем то и имеем. При этом поощрением может случить и безмолвное согласие с безобразием или боязнь ранить чувства человека. Правда – лучшая политика.

О команде и защите.
Я руководитель проекта. Я работаю в команде. Команда = продукт. Благополучие команды = благополучие продукта = благополучие руководителя. Поэтому старайтесь защищать команду в целом и каждого его члена от негативных сторонних влияний. Например, от непроизводственных отделов, от высшего руководства, от заказчика. Отдела кадров, вместо того чтобы отправить своего сотрудника к вам вызывает ваших по одному для подписи какой-то бумаги. Отдел маркетинга задолбал вашего аналитика. Сделайте так, чтобы никто и ничто не причиняло беспокойства вашим ребятам. Люди должны максимально концентрироваться на работе и задача руководителя гарантировать это.

О компании.
Забудьте о компании. Разве вам мало проблем в команде и проблем с заказчиком? Лучшей заботой о компании будет вовремя сданный проект.

Вывод.
Создается впечатление, что рвение разработчиков в «начальство» – это пережиток совковского восприятия мира в стиле «я начальник — значит я крутой» (там немного другая поговорка, но смысл такой). Поверьте старому украинцу, быть руководителем – это не круто, это ГЕМОРОЙ.

Но выбор за вами и помните две вещи:
---------------
(1) Чем бы вы ни занимались необходимо стать лучшим. А чтобы стать лучшим необходимо любить свою работу.
(2) Нельзя быть хорошим программистом и хорошим руководителем – это не совместимо. Или ты руководишь или управляешь. Одно из двух. Как только ты начинаешь программировать — ты перестаешь руководить. Как только перестаешь руководить – начинается хаос. Если стали на стезю руководителя, не сворачивайте и не оборачивайтесь. Программист умер – да здраствует руководитель!
-------------------------------

Ну и последняя фраза, которая должна запомниться (Штирлиц обещал).
Конечно же, в таком маленьком эссе не возможно описать все, всего его много (помните про 10 лет). Но главное должно запомниться мы не только работаем с людьми, но и РАДИ ЛЮДЕЙ. Итак, самое главное правило:
МЫ РАБОТАЕМ ДЛЯ ЛЮДЕЙ


Литература:
"Человеческий фактор" ДеМарко, Листер.
"Программируем командный дух" by Мак-Карти
«Человеческий фактор в программировании» Лари Константин

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

Красиво сказал, нужно записать, а лучше в книге по компетенции менеджеров ИТ-проектов!