имею честь представить вам свой скромный труд «Руководство командой разработчиков программного обеспечения. Прикладные мысли». Читать здесь.
ДЛЯ КОГО?
Книга адресована в первую очередь менеджерам проектов и лидерам команд разработчиков программного обеспечения (ПО). Книга будет полезна руководителям отделов и служб ИТ, поскольку позволит им глубже понять особенности разработки программных систем и учесть эту специфику при построении эффективных производственных процессов в подразделении. Думаю, что изложенные мысли могут оказаться полезными в практике HR-служб, для грамотного руководства улучшениями в области подбора, оценки, развития и закрепления наиболее эффективных сотрудников. И, наконец, все остальные участники проектов разработки ПО смогут применить изложенные здесь принципы для повышения личной эффективности: адекватной постановки индивидуальных целей, стратегического планирования личного профессионального и карьерного развития, успешного решения своих задач на основе эффективного взаимодействия с другими участниками команды.
ЧТО ВНУТРИ?
[…] Первая и главная мысль, которою мне хотелось бы донести до читателя, состоит в том, что творческими командами разработчиков ПО невозможно управлять, их можно только направлять и вести. А для этого не достаточно быть эффективным управленцем, необходимо еще получить признание от команды в качестве лидера. Ответ на вопрос, почему прежние методы управления людьми не работают, дан во Введении.
Следующая моя мысль о том, что все люди разные, требуются терпимость и умение принимать людей такими, какие они есть. Недостатки людей – это, как правило, оборотная сторона их достоинств. Следует эти достоинства разглядеть и постараться использовать их с максимальной отдачей для общего дела. В главе 1, на основе последних наработок в типологии Майерс-Бриггс и соционики, обсуждаются профессиональные психологические особенности разработчиков ПО, которые необходимо учитывать при формировании команд, организации их деятельности и их мотивации на достижение общего успеха.
Лидер – это главным образом состоявшаяся личность, поэтому глава 2 посвящена личностному росту и развитию эмоционального интеллекта. В главе 3 рассмотрены вопросы эффективного межличностного взаимодействия и конструктивного разрешения производственных конфликтов на основе доверия и взаимовыгоды, без которых не бывает эффективных команд.
Для российского менталитета командная работа достаточно органичный вид коллективной деятельности. Сельская община, профессиональные артели, рабочие бригады, временные научные творческие коллективы – все это страницы нашей истории. Что такое команда, ее отличие от рабочей группы, динамика ее становления, командные роли участников и стратегии руководителя на разных этапах развития команды – все это обсуждается в главе 4.
Главная проблема успешного командообразования – это создание и сохранение высокой степени мотивации ее участников на общий успех. Но не может быть эффективной мотивации, если руководитель не исключил из своего управленческого арсенала демотивирующие практики. В глава 5 приведен обзор наиболее часто используемых антипаттернов руководства командами, которые приводят к фатальной демотивации исполнителей и делают невозможным создание самоорганизуемой и самоуправляемой команды. Работники приходят в компанию, как правило, не потому, что привержены ее миссии. И не для того, чтобы заработать еще больше денег для владельцев бизнеса. Работая в конкретной компании, участвуя в конкретном проекте, каждый работник стремится к достижению своих индивидуальных целей. «Лучшей заботой о компании будет вовремя сданный проект» (с) анонимный пост на rsdn.ru. Поэтому, в главе 6 рассмотрены вопросы мотивации участников команды на достижение общего успеха в совместной работе, на основе достижения личных целей каждого.
Создание и закрепление эффективной команды — это стратегическое приобретение компании, поэтому последняя глава 7 посвящена вопросам подбора, развития и сохранения эффективных команд.
Мои мысли, надеюсь, принесут вам пользу. Но это произойдет только в том случае, если у вас самих уже возникли аналогичные вопросы «почему». Так как, если вопрос поставлен правильно, то это половина решения проблемы. А если таких вопросов у вас нет, то мои ответы вам, вряд ли, удастся куда-либо приложить.[…]
БЛАГОДАРНОСТИ
[…] Особая благодарность членам сообщества RSDN.ru, в первую очередь, господам под никами bkat, Gaperton, Spidola, Курилка. Мысли и статьи участников я регулярно и с большим интересом изучаю, творчески переосмысливаю и стараюсь использовать в своей работе.
Здравствуйте, craft-brother, Вы писали:
CB>Уважаемые коллеги,
CB>имею честь представить вам свой скромный труд «Руководство командой разработчиков программного обеспечения. Прикладные мысли». Читать здесь.
Большое спасибо. С интересом прочел, нашел немало интересных мыслей.
Однако по ходу чтения осознал вещь, которую не понимал раньше. Принципиального значения она не имеет, конечно, но все-таки...
Всем, в общем-то, понятно, что программисты — зверьки психологически нежные. Ими нельзя руководить — это их угнетает. К ним нельзя применять меры дисциплинарного воздействия — их это демотивирует. Им нельзя навязывать свое мнение — это плохо влияет на их самооценку. Им нельзя говорить, что они хреново работают — критика воспринимается ими, как акт агрессии. С ними нельзя быть неискренним — они умные люди и сразу это чувствуют.
Человек (начальник), который этого не понимает — априори дурак. Если он этого не понимает на форуме rsdn-а — он автоматически огребет мегатонны минусов. Если он этого не понимает просто на форуме — ему в крайне нелицеприятных выражениях объяснят, кто он таков и где его место (место это дурно пахнет и вдобавок, как правило, плохо освещено). Если он этого не понимает в реальной жизни — он получит низкую производительность труда, саботаж и высокую текучку кадров.
Но вот то, что я буквально сейчас с удивлением осознал. Программистов, при всей их сверхъестественной ранимости, почему-то совершенно не обижают методологии управления разработкой, созданные исходя из предположения, что любой программист по определению является капризной примадонной, неспособной владеть собой, да и вообще конструктивно работать в команде без тщательнейшей психологической работы своего менеджера.
Т.е. утверждение, что программисты нуждаются в управлении, действует на многих, как пресловутая красная тряпка на быка. А лишь поверхностно завуалированная оценка программистов в целом, как плохо владеющих собой истеричек (или скорее маленьких детей), почему-то воспринимается сообществом вполне одобрительно. Что лично мне представляется достаточно удивительным, учитывая, что профессия наша почти исключительно мужская.
Как результат — есть множество книг и статей, в которых менеджерам рассказывают о том, как они должны приспосабливаться к психологическим особенностям (а часто — просто капризам) своих разработчиков, но я не знаю ни одной серьезной работы на тему — как программист должен работать над собой, чтобы не создавать проблем своим собственным неконструктивным поведением. Очевидно, что именно менеджерам в силу положения (и как правило возраста и опыта) и полагается нести основную ответственность за психологический климат, но ведь многие вообще отрицают какую-либо ответственность исполнителей.
Это не было бы большой проблемой, если бы мы жили в условиях избытка хороших менеджеров в IT, но ведь на практике-то ситуация прямо обратна — при всей серьезности проблемы нехватки хороших программистов, хороших менеджеров все равно еще меньше. Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
Здравствуйте, mrozov, Вы писали:
... M>...Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
Здравствуйте, sc, Вы писали:
M>>...Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
sc>Нет никакой проблемы — нет интереса.
Проблема есть. А интереса к ней нет, поскольку личности незрелой и инфантильной страшно признаться себе в том, что проблема есть.
Это ведь не только программистов касается. Интроспекция и развитие собственной личности -- дело трудное и часто неприятное. Поэтому легче делать вид, что проблемы нет.
Здравствуйте, TheBeard, Вы писали:
TB>Проблема есть. А интереса к ней нет, поскольку личности незрелой и инфантильной страшно признаться себе в том, что проблема есть.
TB>Это ведь не только программистов касается. Интроспекция и развитие собственной личности -- дело трудное и часто неприятное. Поэтому легче делать вид, что проблемы нет.
Здравствуйте, TheBeard, Вы писали:
TB>Здравствуйте, sc, Вы писали:
M>>>...Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
sc>>Нет никакой проблемы — нет интереса.
TB>Проблема есть. А интереса к ней нет, поскольку личности незрелой и инфантильной страшно признаться себе в том, что проблема есть.
TB>Это ведь не только программистов касается. Интроспекция и развитие собственной личности -- дело трудное и часто неприятное. Поэтому легче делать вид, что проблемы нет.
Я имел ввиду, что все это является очевидным, поэтому неинтересным для обсуждения. Думаю, что в среднем, кол-во "проблем" одинаково для программистских и непрограммистских коллективов.
M>Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки?
Согласен на 100%. Именно эту мысль я хотел донести в главе «Личная эффективность». Видимо, получилось недостаточно убедительно.
Здравствуйте, sc, Вы писали:
sc>Я имел ввиду, что все это является очевидным, поэтому неинтересным для обсуждения. Думаю, что в среднем, кол-во "проблем" одинаково для программистских и непрограммистских коллективов.
Боюсь, что это не так. В непрограммистских коллективах обычно не принято ожидать от непосредственного руководства подтирания попки. Люди чаще всего возлагают ответственность за решение психологических проблем не на начальство, а на себя. Как следствие — проблем становится меньше.
П: Я не понимаю, почему я должен следовать этой архитектуре? Кому она нужна! (У меня
проблемы и мне от этого плохо!)
М: Ты недооцениваешь важность концептуальной целостности системы. (Мне еще раз указали
на то, что я плохой программист!)
П: Без всякой архитектуры я бы мог сделать это гораздо быстрее. (Иначе я не смогу
справиться с заданием в срок!)
М: Ты ошибаешься. Если ты не будешь следовать архитектуре, то пожалеешь об этом, когда
придется ее сопровождать. Следует больше доверять опыту нашего архитектора. (Со мной не
считаются и не хотят понять!)
Ну неужели я один вижу, что этот диалог является точным воспроизведением диалога между мужчиной и его блондинистой истеричной подружкой из руководства по пониманию женской логики?
В силу своей интроверсии, граничащей с аутизмом, программист просто не в состоянии...
Прелестно...
Как получилось, что весьма самолюбивые и обидчивые представители почти чисто мужской профессии стали воспринимать такое отошение к себе, как должное?
Мне кажется, что идеология управления в IT, соглашаясь с тезисом о том, что всю ответственность за процесс несет PM, который при этом однако не должен использовать аминистративные рычаги давления, заводит ситуацию в тупик. Мне кажется, что индустрии необходимо работать над тем, чтобы имидж эмоционально-неустойчивого и слабо мотивированного программиста воспринимался негативно в самой программистской среде.
Мой тезис. Если менеджер в своей работе не умеет применять навыки психолога — он непрофессионален. Если менеджеру в его работе приходится применять на практике навыки психолога — значит его персонал непрофессионален. Для многих это самоочевидно. Но для многих — нет.
M>Мой тезис. Если менеджер в своей работе не умеет применять навыки психолога — он непрофессионален. Если менеджеру в его работе приходится применять на практике навыки психолога — значит его персонал непрофессионален. Для многих это самоочевидно. Но для многих — нет.
Все люди разные. Встречаются программисты, которые волком смотрят, когда пытаешься детализировать им требования с точки зрения архитектуры ("- Я сам знаю как я лучше сделаю!"), а встречаются те, которые хотят чётких детальных формальных требований ("- Сами не знают чего хотят!"). Это вопрос ответственности. Кто-то готов брать на себя ответственность за решения и хочет это делать, чтобы иметь свободу действий, а кто-то боится. Причём обе позиции часто наблюдаются не как чёрное и белое, а просто в разной степени.
В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ
И к каждому нужен свой подход.
VGn>В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ
Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
N_C>Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
Не мальчик для битья, а ответственное лицо. Ответственное лицо — это лицо, которое несёт ответственность. А "для битья", "перевод стрелок" — это как кто себя поставит.
Советую ознакомиться с основами менеджмента прежде чем разглагольствовать о "подтирании попок". В часности, с историей развития менеджмента от рабовладельчества до современного времени. И понять, что ИТ это не феодальное хозяйство и даже не капиталистический завод. Отрасль передовая, постиндустриальная, следовательно и управление обязанно быть продвинутым.
M>... не капиталистический завод. Отрасль передовая, постиндустриальная, следовательно и управление обязанно быть продвинутым.
Что, если не капиталистический завод, управляющие ответственности не несут? Чушь! Управление — всегда и везде управление. Недаром все хорошие управленцы поголовно читают Макиавелли.
Здравствуйте, VGn, Вы писали:
M>>... не капиталистический завод. Отрасль передовая, постиндустриальная, следовательно и управление обязанно быть продвинутым.
VGn>Что, если не капиталистический завод, управляющие ответственности не несут? Чушь! Управление — всегда и везде управление. Недаром все хорошие управленцы поголовно читают Макиавелли.
Имелось ввиду, что если раньше для управления применялись принуждение и грубая физическая сила, то сегодня самые эффективные инструменты — интеллект и харизма лидера. К сожалению, стремление понять человека зачастую воспринимается окружающими как слабость. А ответственность никто не отменял.
Здравствуйте, Nikolay_Ch, Вы писали:
VGn>>В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ N_C>Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
Да ну. Может Вам просто не повезло со средой? У нас, например, никто не считает что ПМ не нужен, впрочем как и на соседних проектах тоже.
Здравствуйте, VGn, Вы писали:
M>>Мой тезис. Если менеджер в своей работе не умеет применять навыки психолога — он непрофессионален. Если менеджеру в его работе приходится применять на практике навыки психолога — значит его персонал непрофессионален. Для многих это самоочевидно. Но для многих — нет.
VGn>Все люди разные. Встречаются программисты, которые волком смотрят, когда пытаешься детализировать им требования с точки зрения архитектуры ("- Я сам знаю как я лучше сделаю!"), а встречаются те, которые хотят чётких детальных формальных требований ("- Сами не знают чего хотят!"). Это вопрос ответственности. Кто-то готов брать на себя ответственность за решения и хочет это делать, чтобы иметь свободу действий, а кто-то боится. Причём обе позиции часто наблюдаются не как чёрное и белое, а просто в разной степени. VGn>В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ VGn>И к каждому нужен свой подход.
Вообще для всего сектора интеллектуального труда свойственно более "чуткое", "психологическое" управление. Разница лишь в том, что с нынешним состоянием дел на рынке труда, программисты могут себе позволить давить на менеджеров. И средства давления — капризы и увольнение. Если бы работу было найти тяжело — каприз было бы меньше. (Ыы, сам программист, и получается говорю против себя же ( )
Кстати говоря, многие "умные" менеджеры понимают что капризничают программисты не просто так. Конфликт возникает когда программист чем то не доволен: Повысили коллегу а не его, низкая з/п (субъективно), решил супер задачу — а менеджер не оценил и т.д. К капризам лучше прислушаться, найти причину и избавиться от нее. Мы ведь все знаем, как дорого обходится замена человека. И опять таки, это относится ко всему интеллектуальному труду, а не только к IT.
Есть еще одна крайность, которую должны учитывать именно хорошие менеджеры. Сам сталкнулся с такой ситуацией: Хорошего программиста, не супер гения, а просто хорошего программиста перевели к нам в команду (с С++ desktop на .NET web). За 3 месяца он не сделал ничего. Абсолютно. Все что делал приходилось переделывать. Уже стоял вопрос о его увольнении, но волею судеб освободилось место на С++ desktop продукте и его перевели туда. Что вы думаете? Человек просто расцвел! Очень быстро разобрался с проектом, уже закончил несколько серьезных задач, постоянно проявляет инициативу и не остается в стороне от общекомандных дел. Начальник очень доволен... К людям относится нужно очень внимательно, и это забота исключительно менеджмента.
Мне, например, нужны свобода и ответственностью. Нужны как воздух. Мне просто необходимо создавать огромные системы, решать задачи клиента, находящегося на другом побережье, чуствовать и нести ответственность за свой код. За свою делову переписку и за принятые мной решения. Именно ради этого я занимаюсь программированием. Но в команде у меня есть человек, который при любой ответственности начинает паниковать, теряться. Только не думайте что он плохой программист, наоборот. Если точно рассказать что от него требуется, предупредить о всех известных ньюансах и расставить приоритеты — он сделает свою работу просто великолепно. Раскопает любой код и соберет обратно. И так соберет что ненарадуешься. А мне вот кровь с носа необходимо самому расставить приоритеты, самому знать все грабли и предупредить о них коллег при первой же возможности. Вы хотите сказать что это не задача менеджера удержать нас, таких разных в одной команде? Раздать задачи так, что бы всем было интересно и все были довольны? А если менеджер этого не сделает, то я буду капризничать и мои коллеги тоже будут капризничать и все мы уволимся подальше от такой компании. (А если бы рынок был перегретым, и работу было бы найти тяжело, то мы бы не капризничали, но КПД было бы очень низким. Прямо как в рабовладельческие времена)
TT>Да ну. Может Вам просто не повезло со средой? У нас, например, никто не считает что ПМ не нужен, впрочем как и на соседних проектах тоже.
Да мне вообще... Не везет...
Хотел быть ТЛ — не вышло — проскочил ступеньку... Хотел быть в софтверной компании не случилось...
Блин, а в мечтах так хочется поработать в нормальной софтверной компании на нормально поставленном процессе разработке ПП...
M>Имелось ввиду, что если раньше для управления применялись принуждение и грубая физическая сила, то сегодня самые эффективные инструменты — интеллект и харизма лидера. К сожалению, стремление понять человека зачастую воспринимается окружающими как слабость. А ответственность никто не отменял.
Хе-хе... Это пока есть куда идти — т.е. есть голод рынка по профессионалам. Как только голода не будет — опять начнется тоже самое — принуждение и грубая физическая сила (ну будет она в виде ора, например)...
TT>Кстати говоря, многие "умные" менеджеры понимают что капризничают программисты не просто так.
Конечно же нет! Однако сама манера сталкиваясь с проблемой — "капризничать" — это реакция истерички, а не нормального, взрослого мужика. Нормальный мужик, сталкиваясь с проблемой, должен ее решать, а не капризничать в ожидании, когда кто-нибудь догадается сменить ему памперс.
TT>Есть еще одна крайность, которую должны учитывать именно хорошие менеджеры. Сам сталкнулся с такой ситуацией: Хорошего программиста, не супер гения, а просто хорошего программиста перевели к нам в команду (с С++ desktop на .NET web). За 3 месяца он не сделал ничего. Абсолютно. Все что делал приходилось переделывать. Уже стоял вопрос о его увольнении, но волею судеб освободилось место на С++ desktop продукте и его перевели туда. Что вы думаете? Человек просто расцвел! Очень быстро разобрался с проектом, уже закончил несколько серьезных задач, постоянно проявляет инициативу и не остается в стороне от общекомандных дел. Начальник очень доволен...
Отличный пример! Сам от такого как-то пострадал. Однако из этого примера можно сделать и прямо противоположный вывод.
Хороший программист добровольно согласился на перевод на другую технологию. Никто ему пистолет к виску не приставлял. Он мог отказаться. Он мог уволиться. Но он дал свое согласие.
После этого вместо того, чтобы освоить новую технологию и начать с ней работать (как это делают нормальные люди) "За 3 месяца он не сделал ничего. Абсолютно.". Это называется — непрофессионализм. В таких случаях нужно либо отказываться от работы, либо сжать зубы и делать через "немогу". Понятно, что эффективной работы не получится — это очевидно. Понятно, что это яркий пример неэффективного использования ресурсов. Это все — очевидно. Но и ваш "хороший программист" в этой истории себя показал с далеко не лучшей стороны.
То, что менеджер в своей работе обязан учитывать психологические моменты — это очевидно. Но вот предположение, что любые проблемы в проекте — это по-определению проблемы менеджера и других они не касаются — явный перебор.
Ну что там далеко за примером ходить — рядом лежит топик про мотивацию. Тимлидер спрашивает — "вот у меня люди потеряли мотивацию, не работают — что делать?". Ему отвечают — "это потому, что ты — хреновый менеджер". Нет, ребята. Это потому, что они — хреновые программисты. А хороший менеджер отличается от просто менеджера как раз тем, что непрофессиональные исполнители не в состоянии сорвать его проект, потому что он знает, как нивелировать их недостатки.
Здравствуйте, mrozov, Вы писали:
M>я не знаю ни одной серьезной работы на тему — как программист должен работать над собой, чтобы не создавать проблем своим собственным неконструктивным поведением.
Не в тему и не для программистов (рассчитано на менеджерско-тимлидскую аудиторию, как мне показалось), но прочтение Steve McConnell, Rapid Development очень и очень помогает в плане "работать над собой".
А вообще подумалось, а с какой стати программисты будут стремиться "не создавать проблем", если за это денег не платят? Это же на собеседовании не очень заметно Это потом, когда-нибудь, когда будешь увольняться , может-быть, скажут, мол, приятно было поработать. Не способствует современная рыночная ситуация и отношение "типичного" менеджмента росту программистов "над собой" — думается, вполне обычным будут размышления из серии "некогда читать всякую психологию и прочую муть, для этого надо мной есть ПМ да девочка-айчарка, им за это деньги платят, а у меня тут фреймворк v.3.1415.926 вышел, надо учить новые фичи, пора коллегу за пояс заткнуть"
Еще, кстати, интересно — какой процент народу из ПМно-ТЛного менеджмента действительно "работает над собой" ?
Здравствуйте, mrozov, Вы писали:
TT>>Есть еще одна крайность, которую должны учитывать именно хорошие менеджеры. Сам сталкнулся с такой ситуацией: Хорошего программиста, не супер гения, а просто хорошего программиста перевели к нам в команду (с С++ desktop на .NET web).
Совершенно не известно, почему он согласился на переход. Может просто не хватило воли отказаться от перевода. Сам в свое время сдуру согласился взяться за задачу, в теме по которой нифига не разбирался, потому как не сумел отстоять своё "я в этом не разбираюсь, никогда не сталкивался и в разумные сроки реализовать не смогу" перед боссовым "надо!".
TT>>За 3 месяца он не сделал ничего. Абсолютно. Все что делал приходилось переделывать. Уже стоял вопрос о его увольнении, но волею судеб освободилось место на С++ desktop продукте и его перевели туда. Что вы думаете? Человек просто расцвел! Очень быстро разобрался с проектом, уже закончил несколько серьезных задач, постоянно проявляет инициативу и не остается в стороне от общекомандных дел. Начальник очень доволен... M>После этого вместо того, чтобы освоить новую технологию и начать с ней работать (как это делают нормальные люди) "За 3 месяца он не сделал ничего. Абсолютно.". Это называется — непрофессионализм. В таких случаях нужно либо отказываться от работы, либо сжать зубы и делать через "немогу". Понятно, что эффективной работы не получится — это очевидно.
Вообще то если читать внимательно, то можно заметить выделенное. ИМХО это означает что он все таки сжал зубы и делал через "немогу".
M>Ну что там далеко за примером ходить — рядом лежит топик про мотивацию. Тимлидер спрашивает — "вот у меня люди потеряли мотивацию, не работают — что делать?". Ему отвечают — "это потому, что ты — хреновый менеджер". Нет, ребята. Это потому, что они — хреновые программисты. А хороший менеджер отличается от просто менеджера как раз тем, что непрофессиональные исполнители не в состоянии сорвать его проект, потому что он знает, как нивелировать их недостатки.
Из этой фразы я понял что и программеры хреновые и манагер хреновый. Вообще в жизни не бывает четкого разделения: хороший — плохой. Между черным и белым есть огромное колво оттенков серого. Так что и винить кого то одного во всем нельзя. Что впрочем не означает что бОльшая часть вины за провал не может лежать на ком то конкретно.
Здравствуйте, mrozov, Вы писали:
TT>>Кстати говоря, многие "умные" менеджеры понимают что капризничают программисты не просто так. M>Конечно же нет! Однако сама манера сталкиваясь с проблемой — " это реакция истерички, а не нормального, взрослого мужика. Нормальный мужик, сталкиваясь с проблемой, должен ее решать, а не капризничать в ожидании, кокапризничать" -гда кто-нибудь догадается сменить ему памперс.
И какие методы решения возможны
Ну разве что сферический мужик в вакууме. А на практике получается что сталкиваясь с проблемой наши "мужики" редко решают ее по существу. Я имею ввиду не ИТ, а Российскую действительность вообще. Ноют что в стране все плохо но не решают проблему (даже незнают где эта проблема). Ноют что коррупция но сами берут взятки (не все поголовно, ессесно). Ноют что надоели нерадивые водители, но никто не "стучит" видя нарушение. Касательно ИТ, то вот какие варианты пришли в голову:
1) Поговорить с менеджером по поводу своих претензий — иногда может решить проблему. Но для этого нужно (а) сформулировать претензии, что само по себе не легко (б) иметь адекватного мереджера. Как уже было сказанно в этой ветке с ними дефецит. Кроме того и адекватный менеджер не всегда решит проблему в пользу программиста. Что тогда?
Да и решиться на откровенный разговор со своим начальником очень нелегко. Пусть я буду истеричкой, но мне это дейтсвительно по человечески тяжело. Возможно конечно изза отрицательного опыта таких разговоров в прошлом.
2) Уволиться — не решить проблему, а уйти от нее. Как в песенке "Walk away to save your face, you never were a genius."
3) Встать в штыки против руководства требуя решения — очень рискованно. Даже незнаю, применимо ли это в офисной среде.
M>Хороший программист добровольно согласился на перевод на другую технологию. Никто ему пистолет к виску не приставлял. Он мог отказаться. Он мог уволиться. Но он дал свое согласие. M>После этого вместо того, чтобы освоить новую технологию и начать с ней работать (как это делают нормальные люди) "За 3 месяца он не сделал ничего. Абсолютно.". Это называется — непрофессионализм.
Мне кажется ему веб и .NET просто на душу не лег. Нельзя заставлять человека писать на чем угодно. У каждого есть личные предпочтения и их нужно учитывать. Также несоответствие нынешнего проекта личным предпочтеням нельзя называть непрофессионализмом.
В таких случаях нужно либо отказываться от работы, либо сжать зубы и делать через "немогу". Понятно, что эффективной работы не получится — это очевидно. Понятно, что это яркий пример неэффективного использования ресурсов. Это все — очевидно. Но и ваш "хороший программист" в этой истории себя показал с далеко не лучшей стороны.
Согласен, он мог форсировать ситуацию с поиском С++ проекта либо внутри этой компании либо в другой. Решил сжать зубы и терпеть. Незнаю что им двигало.
M>То, что менеджер в своей работе обязан учитывать психологические моменты — это очевидно. Но вот предположение, что любые проблемы в проекте — это по-определению проблемы менеджера и других они не касаются — явный перебор.
Согласен. Главная задача менеджера это создать/удержать команду вместе, создать командный дух, максимизировать КПД каждого сотрудника и направить общий вектор их работы в нужную сторону. Но это очень крутой начальник которые сможет все перечисленное сразу. ИМХО.
M>Ну что там далеко за примером ходить — рядом лежит топик про мотивацию. Тимлидер спрашивает — "вот у меня люди потеряли мотивацию, не работают — что делать?". Ему отвечают — "это потому, что ты — хреновый менеджер". Нет, ребята. Это потому, что они — хреновые программисты. А хороший менеджер отличается от просто менеджера как раз тем, что непрофессиональные исполнители не в состоянии сорвать его проект, потому что он знает, как
нивелировать их недостатки.
Ну этому бедняге не повезло, он из разработчиков стал их начальником. Ему по определению будет тяжело, каким бы менеджером он не был. Однако в общем случае, он хреновый менеджер, раз люди не признали его таковым и потеряли мотивацию. Здесь
кстати тема, раздают книжку по мотивации. Читать рекомендую внимательно фильтруя, т.к. книга довольно однобокая (все показанно только со стороны подчиненного и совершенно не учтены интересы компании в целом. Мотивация стоит во главе угла). Тем не менее в книге много интересных и верных идей о мотивации. За нее 100% отвечает менеджер.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, mrozov, Вы писали:
CC>Совершенно не известно, почему он согласился на переход.
А это, по совместительству, еще и совершенно не важно. Важно то, что он согласился. А потом — не отказался. Хотя возможности — были — они всегда есть. Более того, давай поспорим — он не приходил к своему PM-у с информацией о том, что писать на c# у него не получается и он просит найти ему место в проекте на c++. Это почти наверняка.
CC>Вообще то если читать внимательно, то можно заметить выделенное. ИМХО это означает что он все таки сжал зубы и делал через "немогу".
Хреново делал. Чем делать так, что приходится переделовать — лучше не делать вообще. Или делать в час по чайной ложке. Есть достойные выходы из такой ситуации — я сам в ней бывал и потому знаю. А как ни в чем ни бывало продолжать получать неслабую зарплату, не принося своей компании никакой пользы — и прекрасно зная об этом — попросту недостойно. Закона против такого поведения нет, что верно — то верно. Но вот положа руку на сердце — ты считаешь это достойным мужчины?
CC>Из этой фразы я понял что и программеры хреновые и манагер хреновый.
Ты понял неправильно. Менеджер сделал то, что считается его работой (по крайней мере обратного мы не знаем). Распределил работу по исполнителям, контролировал ход выполнения, координировал общение между участниками проекта. Проводил воспитательные беседы.
Определить с помощью телепатии причины, по которым конкретный исполнитель работает неэффективно (и скорее всего — скрывает это) — это высший пилотаж. По-настоящему хороший менеджер должен уметь и это тоже. Но это не значит, что программист, которому кажется, что ему недоплачивают, должен никому ничего не говоря забить на работу и ждать, пока кто-нибудь сообразит, чем конкретно его нужно мотивировать.
Компания, которая может себе позволить нанять гениального PM-а как правило может себе позволить нанять действительно профессиональных программистов. Хочешь работать в успешной компании, над успешным проектом? Вноси свой вклад, не жди, что все сделают другие.
Здравствуйте, TafT, Вы писали:
TT>Здравствуйте, mrozov, Вы писали: TT>Ну разве что сферический мужик в вакууме.
Идеалы — имеют значение, даже если им никто не соответствует. Это планка, на которую равняются. За последние 5 лет я вижу, что эта планка опускается все ниже на фоне халявы с работой и зарплатой. Давай просто сойдемся на том, что речь идет о недостойном поведении. Стремиться нужно к другому.
TT>Согласен. Главная задача менеджера это создать/удержать команду вместе, создать командный дух, максимизировать КПД каждого сотрудника и направить общий вектор их работы в нужную сторону. Но это очень крутой начальник которые сможет все перечисленное сразу. ИМХО.
Вот собственно именно об этом и речь.
Многие люди полагают, что если их начальник "не очень крутой" — значит он хреновый. А раз начальник хреновый — значит можно вообще ничего не делать.
Это неправильно. Это ненаказумо, но неправильно. Правильно — помочь. Или хотя бы не создавать проблем самому.
TT> Здесь
кстати тема, раздают книжку по мотивации.
Я прочел. Не впечатлился, честно говоря. Я ждал примеров того, как PM, сталкиваясь с определенными трудностями, приступал к их решению — с тем или иным результатом. А получил набор жалоб но то, как менеджеры не смогли решить проблемы автора. Полезность такой информации ограничена.
TT>>Здравствуйте, mrozov, Вы писали:
M>Идеалы — имеют значение, даже если им никто не соответствует. Это планка, на которую равняются. За последние 5 лет я вижу, что эта планка опускается все ниже на фоне халявы с работой и зарплатой.
Да, это естественное влияние рынка. Сейчас работодатели конкурируют за разработчиков. Следовательно условия работы улучшаются а качество разработчиков ухудшается. Будут еще времена когда все будет наоборот, а потом опять так же.
Давай просто сойдемся на том, что речь идет о недостойном поведении. Стремиться нужно к другому.
Сори, не понял.
TT>>Согласен. Главная задача менеджера это создать/удержать команду вместе, создать командный дух, максимизировать КПД каждого сотрудника и направить общий вектор их работы в нужную сторону. Но это очень крутой начальник которые сможет все перечисленное сразу. ИМХО. M>Вот собственно именно об этом и речь. M>Многие люди полагают, что если их начальник "не очень крутой" — значит он хреновый. А раз начальник хреновый — значит можно вообще ничего не делать.
На эту тему уже высказывалось, что мир не бинарный, не черно-белый. Есть еще оттенки серого.
M>Это неправильно. Это ненаказумо, но неправильно. Правильно — помочь. Или хотя бы не создавать проблем самому.
Ну знаете, вот честно, если меня начальник обидит: заденет за живое или просто потому что он хам по натуре — врятли я ему буду помогать. Лучше всего именно немешать. Вообще если начальник сам не просит помочь или если не возникла достаточно серьезная ситуация — помощь будет лишней. Может даже вредной. Я говорю о том, что помогать безсмысленно. Начальник, пока все хорошо, не примет моей помощи, а может даже наоборот подумает: "Да не нужна мне его помощь, у меня и так дело отлично идут". Сотрудник на такую реакцию опять может обидеться. Поэтому помощь нужна именно в критической для начальника ситуации. Тогда он оценит мою помощь, примет ее, и еще раз убедится какой у него отличный коллектив
Кстати подумалось, Вы действительно верите в то, что "мужик" может забить на все обиды и неудачи и несмотря ни на что ломиться на пролом к заветной цели победы коммунизма?
Ну как вот в примере с помощью начальнику. Представьте, Вы видя что вектор ситуации в компании постепенно ухудшается (но сама ситуация еще в норме) идете к своему менеджеру, показываете негативные факторы и строите прогноз куда скатится компания с такой тенденцией. Потом Вы высказываете ряд предложений, что можно сделать, что бы компания и дальше процветала. (Вы вчера весь вечер старались, продумывали все аспекты, что бы съекономить драгоценное время свое начальника, что бы вся информация была как можно более наглядной. Вы долго старались.) Начальство Вас вежливо (в лучшем случае) благодорит, а все ваши старания откладывет в черный ящик. Ничего в компании не меняется. Неужели после такого отношения со стороны руководства к Вам вы абсолютно не поддадитесь чувствам и по прежнему будете вносить предложения, ценить и помогать своему менеджеру? Подозреваю что нет. А ведь не "по мужски" получается. Или я неправильно понял Ваше "по мужски"?
TT>> Здесь
кстати тема, раздают книжку по мотивации. M>Я прочел. Не впечатлился, честно говоря. Я ждал примеров того, как PM, сталкиваясь с определенными трудностями, приступал к их решению — с тем или иным результатом. А получил набор жалоб но то, как менеджеры не смогли решить проблемы автора. Полезность такой информации ограничена.
Да, действительно очень жаль что нету примеров и методов увеличения мотивации. Да и вообще нету разностороннего анализа этой проблемы, но жалобы очень адекватны. В концентрированной и утрированной форме оно напоминает бред, но в реальности именно так все и происходит. Просто не все сразу.
Здравствуйте, TafT, Вы писали:
TT>Давай просто сойдемся на том, что речь идет о недостойном поведении. Стремиться нужно к другому. TT>Сори, не понял.
Если программист позиционирует себя, как профессионала, то он не должен сваливать все свои проблемы на PM-а. Особенно когда его неспособность их решать — очевидна. Именно что особенно. Мы все порой ведем себя не лучшим образом, но если наш идеал поведения скатывается до бабы и тряпки — значит все, приехали.
TT>На эту тему уже высказывалось, что мир не бинарный, не черно-белый. Есть еще оттенки серого.
Дык я же именно об этом. Но у людей эти оттенки работают почему-то только в одну сторону. А в другую — ни-ни. Низя.
TT>Кстати подумалось, Вы действительно верите в то, что "мужик" может забить на все обиды и неудачи и несмотря ни на что ломиться на пролом к заветной цели победы коммунизма? TT>Ну как вот в примере с помощью начальнику. Представьте, Вы видя что вектор ситуации в компании постепенно ухудшается (но сама ситуация еще в норме) идете к своему менеджеру, показываете негативные факторы и строите прогноз куда скатится компания с такой тенденцией. Потом Вы высказываете ряд предложений, что можно сделать, что бы компания и дальше процветала. (Вы вчера весь вечер старались, продумывали все аспекты, что бы съекономить драгоценное время свое начальника, что бы вся информация была как можно более наглядной. Вы долго старались.) Начальство Вас вежливо (в лучшем случае) благодорит, а все ваши старания откладывет в черный ящик. Ничего в компании не меняется. Неужели после такого отношения со стороны руководства к Вам вы абсолютно не поддадитесь чувствам и по прежнему будете вносить предложения, ценить и помогать своему менеджеру? Подозреваю что нет. А ведь не "по мужски" получается. Или я неправильно понял Ваше "по мужски"?
Я не буду саботировать работу даже в том случае, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников. Пример взят из жизни. Я продолжу работу над проектом. После стабилизации ситуации — сменю место работы. Однако я встречал людей, которые полагали, что если руководство не позволяет им внести определенные изменения в архитектуру, значит они имеют законное право на прямой саботаж. Опять же — из жизни.
В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил. Но возводить слабость в принцип, заявлять, что разработчик имеет право на любое поведение, а расхлебывать все должен PM (а если он не справляется — значит он полный урод) — это уже верх свинства! В любых проблемах виноват в первую очередь тот, кто их создает. И только потом тот, кто не смог помочь в их решении. По-моему — это очевидно.
Здравствуйте, mrozov, Вы писали:
M>Я не буду саботировать работу даже в том случае, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников. Пример взят из жизни. Я продолжу работу над проектом. После стабилизации ситуации — сменю место работы.
Ничего себе. Респект и уважуха. Только мне такой подход абсолютно непонятен, объясните зачем вести себя таким образом. Какая цель такой стратегии поведения?
M>В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил.
Что такое "достойных выход" здесь?
M>В любых проблемах виноват в первую очередь тот, кто их создает. И только потом тот, кто не смог помочь в их решении. По-моему — это очевидно.
Тут я с вами согласен. Это не приемлемо. Но и другая крайность тоже не имеет смысла имхо. Истина где то посредине.
ПС: Сори что задаю тупые вопросы, просто не хочу что бы мы спорили об одном и том же, называя вещи разными словами.
Ладно, ладно, я загнул — для красного словца. Действительно, кое-что есть (про Code Complete я даже помню). Вот только программисты тщательно читают главы про ООД и рефакторинг и часто скипают все про персональную ответственность.
Взять, скажем, XP. Кого не спроси — всем нравится XP. Многие даже по нему работают — только без парного кодирования, представителя заказчика в офисе и предварительного написания тестов (хорошо, если они пишутся хотя бы задним числом). Ну и итерации длятся месяца по 2-3. Но в остальном — настоящее XP — начальства не признают, документацию не пишут, проектированием "наперед" не занимаются.
Люди тщательно вычитывают рекомендации для менеджеров — чтобы найти в них подтверждение исключительности своей профессии. И заучивают наизусть целые абзацы про ответственность менеджеров... начисто игнорируя все, что касается ответственности исполнителей.
V>А вообще подумалось, а с какой стати программисты будут стремиться "не создавать проблем", если за это денег не платят?
Но паттерны-то и хардкорные методы оптимизации они разучивают? Интерес к саморазвитию есть, причем огромный, вот только направленность у него узко-специфическая. А за что платят деньги — это очень спорно.
V>Еще, кстати, интересно — какой процент народу из ПМно-ТЛного менеджмента действительно "работает над собой" ?
Не знаю. Но уровень ответственности заметно повыше.
M>>Я не буду саботировать работу даже в том случае, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников. Пример взят из жизни. Я продолжу работу над проектом. После стабилизации ситуации — сменю место работы. TT>Ничего себе. Респект и уважуха. Только мне такой подход абсолютно непонятен, объясните зачем вести себя таким образом. Какая цель такой стратегии поведения?
Это называется "лояльность". Правда я, к сожалению, ещё не встречал фирмы, которая бы относилась максимально лояльно к своим сотрудникам, требуя лояльности от них.
В действительности:
испытательный срок не сокращают НИКОГДА,
повышения зарплаты надо требовать,
премии когда грядёт что-то нехорошее,
увольнение только пинком под зад,
про советы начальству здесь уже было — фактически менеджеры чаще менее лояльны, чем разработчики.
Здравствуйте, TafT, Вы писали:
TT>Ничего себе. Респект и уважуха. Только мне такой подход абсолютно непонятен, объясните зачем вести себя таким образом. Какая цель такой стратегии поведения?
Самоуважение?
В конце-концов в проекте есть еще немало участников, которые заинтересованы в его успешном завершении. У меня конфликт с одним из них. И что? Разве мне самому, в конце концов, не лучше будет иметь в послужном списке успешный проект?
И потом — мне именно за это и платят деньги. Деньги я беру, а работать не буду?
M>>В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил. TT>Что такое "достойных выход" здесь?
В описаной вами ситуации? Сложный вопрос. Их может быть два, по-ситуации. Сменить работу, если контора безнадежна. Сделать то, что зависит от тебя, а ошибки других пусть будут на их совести.
При этом — я категорически против переработок. Но если уж мне оплатили мое время и я согласился на именно эти условия, то разве не очевидно, что свое дело нужно делать хорошо? А если мне нужен кто-то, кто будет меня подгонять или, как это теперь называется, "мотивировать", то разве это не проявление моей же слабости?
M>>В любых проблемах виноват в первую очередь тот, кто их создает. И только потом тот, кто не смог помочь в их решении. По-моему — это очевидно. TT>Тут я с вами согласен. Это не приемлемо. Но и другая крайность тоже не имеет смысла имхо. Истина где то посредине.
А кто говорит о другой крайности? Неужто я??? Хде?!!
TT>ПС: Сори что задаю тупые вопросы, просто не хочу что бы мы спорили об одном и том же, называя вещи разными словами.
Это ж разве тупые...
Здравствуйте, mrozov, Вы писали:
CC>>Совершенно не известно, почему он согласился на переход. M>А это, по совместительству, еще и совершенно не важно. Важно то, что он согласился. А потом — не отказался. Хотя возможности — были — они всегда есть.
Лично знаю неплохого в общем то программера, которого уломать на что либо стрёмное типа предложенного — раз плюнуть. И он будет сидеть пыхтеть и ковырять. И получаться у него не будет, либо так, что надо будет переделывать. И не придет он жаловаться что у него не получается и проситься на тот проект, который он умеет. Потому как устроен он так.
M>Более того, давай поспорим — он не приходил к своему PM-у с информацией о том, что писать на c# у него не получается и он просит найти ему место в проекте на c++. Это почти наверняка.
Я предпочитаю сперва узнать побольше инфы о том, что и как происходило. И лишь потом делать сколь либо серьезные выводы.
CC>>Вообще то если читать внимательно, то можно заметить выделенное. ИМХО это означает что он все таки сжал зубы и делал через "немогу". M>Хреново делал. Чем делать так, что приходится переделовать — лучше не делать вообще. Или делать в час по чайной ложке. Есть достойные выходы из такой ситуации — я сам в ней бывал и потому знаю. А как ни в чем ни бывало продолжать получать неслабую зарплату, не принося своей компании никакой пользы — и прекрасно зная об этом — попросту недостойно. Закона против такого поведения нет, что верно — то верно. M>Но вот положа руку на сердце — ты считаешь это достойным мужчины?
Эмоции в сторону! Не справляется — выяснить почему, и принять меры к исправлению ситуации.
M>Определить с помощью телепатии причины, по которым конкретный исполнитель работает неэффективно (и скорее всего — скрывает это) — это высший пилотаж.
Спрашивать разучились? Статистики по прошлым таскам тоже нету?
M>Компания, которая может себе позволить нанять гениального PM-а как правило может себе позволить нанять действительно профессиональных программистов.
Живой пример: компания наняла продюсера за весьма приличные бабки и... лишила его реальных рычагов управления проектом. В результате профи за бабки конторы ничего не делает. Потому как делать не может — нет полномочий, а разорвать контракт видимо не так просто.
M> Хочешь работать в успешной компании, над успешным проектом? Вноси свой вклад, не жди, что все сделают другие.
Какой то странный перебор на эмоциях у вас наблюдается...
Здравствуйте, TafT, Вы писали:
TT>Кстати подумалось, Вы действительно верите в то, что "мужик" может забить на все обиды и неудачи и несмотря ни на что ломиться на пролом к заветной цели победы коммунизма? TT>Ну как вот в примере с помощью начальнику. Представьте, Вы видя что вектор ситуации в компании постепенно ухудшается (но сама ситуация еще в норме) идете к своему менеджеру, показываете негативные факторы и строите прогноз куда скатится компания с такой тенденцией. Потом Вы высказываете ряд предложений, что можно сделать, что бы компания и дальше процветала. (Вы вчера весь вечер старались, продумывали все аспекты, что бы съекономить драгоценное время свое начальника, что бы вся информация была как можно более наглядной. Вы долго старались.) Начальство Вас вежливо (в лучшем случае) благодорит, а все ваши старания откладывет в черный ящик. Ничего в компании не меняется. Неужели после такого отношения со стороны руководства к Вам вы абсолютно не поддадитесь чувствам и по прежнему будете вносить предложения, ценить и помогать своему менеджеру? Подозреваю что нет. А ведь не "по мужски" получается. Или я неправильно понял Ваше "по мужски"?
+10^100
Очень знакомая ситуация.
Здравствуйте, mrozov, Вы писали:
TT>>Давай просто сойдемся на том, что речь идет о недостойном поведении. Стремиться нужно к другому. TT>>Сори, не понял. M>Если программист позиционирует себя, как профессионала, то он не должен сваливать все свои проблемы на PM-а. Особенно когда его неспособность их решать — очевидна. Именно что особенно. Мы все порой ведем себя не лучшим образом, но если наш идеал поведения скатывается до бабы и тряпки — значит все, приехали.
Как в таком случае не нарушая субординации и действуя в рамках "мужского поведения" профи должен действовать для того, чтобы несмотря на соплю-менеджера вести компанию к светлому будущему?
TT>>На эту тему уже высказывалось, что мир не бинарный, не черно-белый. Есть еще оттенки серого. M>Дык я же именно об этом. Но у людей эти оттенки работают почему-то только в одну сторону. А в другую — ни-ни. Низя.
Каждый из нас сидит на своей колокольне. Менеджер должен все таки быть еще и психологом в какой то мере и уметь менять "угол зрения" на проблему с персоналом.
M>Я не буду саботировать работу даже в том случае, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников. Пример взят из жизни. Я продолжу работу над проектом. После стабилизации ситуации — сменю место работы.
Из жизни контрпример: стабилизация так и не наступила...
M> Однако я встречал людей, которые полагали, что если руководство не позволяет им внести определенные изменения в архитектуру, значит они имеют законное право на прямой саботаж. Опять же — из жизни.
Является ли саботажем отстаивание своей точки зрения, основанной на опыте, учитывая что то, что требует менеджер противоречит здравому смыслу?
Профи может разумеется "заткнуться и сделать как ему говорят". Но после этого ИМХО он имеет полное право покинуть компанию.
Профи отличается от кодера тем, что имеет достаточный опыт, чтобы высказывать свое мнение и вести диалог и обсуждение. Если его не слушать то получится как в той басне про крота и орла. Ту, в которой орел проигнорировал экспертную оценку крота о состоянии корней дерева, что и привело к обрушению проекта
M>В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил.
Эмоции — в сторону. Призывы и лозунги — фтопку!
M>Но возводить слабость в принцип, заявлять, что разработчик имеет право на любое поведение, а расхлебывать все должен PM (а если он не справляется — значит он полный урод) — это уже верх свинства!
За последний год я куда чаще сталкивался с вопиющей некомпетентностью топ-менеджмента нежели разработчиков.
M>В любых проблемах виноват в первую очередь тот, кто их создает. И только потом тот, кто не смог помочь в их решении. По-моему — это очевидно.
Не так уж и просто бывает докопаться до истинного виновника проблем. Потому как иногда такой детектив раскручивается.
Мы каждый видим проблему со своей стороны гораздо лучше, чем представляем себе как она выглядит со стороны оппонента.
Здравствуйте, TafT, Вы писали:
M>>Я не буду саботировать работу даже в том случае, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников. Пример взят из жизни. Я продолжу работу над проектом. После стабилизации ситуации — сменю место работы. TT>Ничего себе. Респект и уважуха. Только мне такой подход абсолютно непонятен, объясните зачем вести себя таким образом.
Это героизм. Бессмысленный и беспощадный.
TT>Какая цель такой стратегии поведения?
Мне тоже поясните. С точки зрения логики — чисто эмоциональный поступок из категории "я птица большая, я птица сильная!"
"Почему вы должны спасать корабль, который капитан направил на рифы?" (С)
M>>В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил. TT>Что такое "достойных выход" здесь?
ИМХО — вспомнить наконец что работа для человека а не человек для работы и уйти оттуда.
Здравствуйте, mrozov, Вы писали:
TT>>Ничего себе. Респект и уважуха. Только мне такой подход абсолютно непонятен, объясните зачем вести себя таким образом. Какая цель такой стратегии поведения? M>Самоуважение?
Самовнушение!
В бизнесе всегда должна быть определенная доля цинизма. На благородных донах любят ездить подонки.
"Всегда надо иметь в себе мужество признаться что проект провален, остановить его и заняться минимизацией потерь, чтобы возможно перезапустить потом по более удачной схеме." (С)
M>В конце-концов в проекте есть еще немало участников, которые заинтересованы в его успешном завершении. У меня конфликт с одним из них. И что? Разве мне самому, в конце концов, не лучше будет иметь в послужном списке успешный проект?
Какова вероятность успешного завершения проекта? Сколько времени и сил понадобится для завершения этого проекта?
Если уйти на другой проект, который идет хорошо — не потребуется ли на нем меньшее количество времени и сил для успешного завершения?
M>И потом — мне именно за это и платят деньги. Деньги я беру, а работать не буду?
Деньги платят за выполненную работу а не за разрыв %опы. Часто за лояльность конторы награждают такой подачкой, что лучше бы вообще ничего не дали — результат не такой разрушительный был бы. Впрочем бывают и исключения, но редко.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, TafT, Вы писали:
M>>>Я не буду саботировать работу даже в том случае, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников. Пример взят из жизни. Я продолжу работу над проектом. После стабилизации ситуации — сменю место работы. TT>>Ничего себе. Респект и уважуха. Только мне такой подход абсолютно непонятен, объясните зачем вести себя таким образом. CC>Это героизм. Бессмысленный и беспощадный.
Согласен, что лучшим вариантом будет блокировать попытки интриговать, а если есть возможности, то и самому поинтриговать не в ущерб работе. Если возможностей нет, то почему бы и не продолжить работу не замечая интриг ? Вообще тут лучше действовать от конкретной ситуации — общего рецепта не существует.
TT>>Какая цель такой стратегии поведения? CC>Мне тоже поясните. С точки зрения логики — чисто эмоциональный поступок из категории "я птица большая, я птица сильная!" CC>"Почему вы должны спасать корабль, который капитан направил на рифы?" (С)
Позволю себе ответить — потому, что профессионал выполняет работу независимо от сложности, а конфликт с одним из участников проекта (даже если это руководитель) всего лишь добавляет этой сложности равно как и опыта в копилку. Не бывает проектов идеальных — на каждом нужно принимать те или иные решения и бороться с проблемами как технического так и организационного плана, если их не получается упреждать. Конфликт это та же проблема решение которой нужно искать и это не менее интересно/полезно нежели искать проблему в коде. Я скорее не понимаю почему нужно бросать работать. Может поясните ?
M>>>В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил. TT>>Что такое "достойных выход" здесь? CC>ИМХО — вспомнить наконец что работа для человека а не человек для работы и уйти оттуда.
Да почему уйти то ? Разве бежать от проблемы это лучший выход ? По моему это крайняя мера — не так ? Ведь если вы не участвуете в интригах, не умеете им противостоять, не выработали поведенческих моделей, то и высоко не подняться.
Здравствуйте, Laughing_Silencer, Вы писали:
L_S>Если возможностей нет, то почему бы и не продолжить работу не замечая интриг?
В сверическом вакууме это возможно. В реале есть куча факторов, которые могут деморализовать работника. К примеру если в результате интриг/раздолбайства менеджмента результат работы отдела (в режиме "срок исполнения — месяц назад!") выкидывается в мусор, и дается команда копать в другую сторону в таком же режиме. При этом "для мотивации" еще введут пару штрафов за опоздания на 5 минут. И все, через некоторое время такой вот "работы" процесс с большой вероятностью затормозится до неприличия. Или того хуже, как бывает: весь отдел встанет и уйдет.
L_S>Вообще тут лучше действовать от конкретной ситуации — общего рецепта не существует.
+1
CC>>"Почему вы должны спасать корабль, который капитан направил на рифы?" (С) L_S>Позволю себе ответить — потому, что профессионал выполняет работу независимо от сложности, а конфликт с одним из участников проекта (даже если это руководитель) всего лишь добавляет этой сложности равно как и опыта в копилку. Не бывает проектов идеальных — на каждом нужно принимать те или иные решения и бороться с проблемами как технического так и организационного плана, если их не получается упреждать. Конфликт это та же проблема решение которой нужно искать и это не менее интересно/полезно нежели искать проблему в коде. Я скорее не понимаю почему нужно бросать работать. Может поясните ?
Профессионал это тот, кто получив задание выдает результат невзирая ни на какие привходящие обстоятельства. (С)
С этим я согласен.
Другой момент, что подобных профи-терминаторов, которые будут работать в любых условиях очень мало. Да и какой дурак будет работать, если ему надо будет для выполнения задания обходить искусственно созданные препятствия? Будет как в анекдоте:
Приезжает молодой офицер в отпуск к отцу в деревню, только поел и сразу спать, проснулся — поел — спать и так несколько дней, взволнованный отец:
— Сынок, может че случилось?
— Все нормально, батя, от вводных отдыхаю.
— А че такое вводные?
— Ну, батя, так сразу и не объяснить.
— Так давай завтра попробуем, а?
— Нееее.......
— Ну давай, я хоть посмотрю как ты там.
— Ну ладно, батя, ты вот что завтра делаешь?
— В лес съездить надо дров заготовить, если успеем — сено в сарай закидать. ...
В четыре часа от громкого крика "подъем" просыпается весь дом.
Отец:
— Сынок, ты че? В семь встали б, успели.
Сын:
— Подъем!!!
Мать накрывает на стол.
С: — Вводная № 1 — Кухня захвачена противником!
О: — Ну сынок, поели б, а?
С: — Кухня захвачена противником!
Вышли на крыльцо.
С: Вводная № 2 — Телега сломана!
О: Сынок, ну вот же телега-то, ты че!
С: Телега сломана, поедем на санях.
Еле добрались до места.
С: Вводная № 3 — Пила не работает!
О: Вот же пила, сынок, нормальная.
С: Не работает! Будем топорами рубить
Вымотались все, погрузили дрова, едут домой, доехали до моста через реку.
С: Вводная № 4 — Мост взорван!
О: Вот же мост-то.
С: Мост взорван! Будем брод искать.
Долго-долго искали брод. Нашли. Переправились. Подъезжают к деревне, вечереет.
С: Вводная № 5 — Лошадь убита!
О: Но вон же дом-то. Вот же лошадь!
С: Лошадь убита! на себе дотаскаем.
Ночь, тишина, звезды. Отец выходит на крыльцо, закуривает.
— Ничего же не сделали. А как заебались.
Ну и кому это в здравом уме скажите надо?
Мы все люди со своими человеческими заморочками. Да и задания у программерского состава не звучат как "закончить проект" — это задания менеджменту. Программер профи в случае если его не устраивает сложившаяся ситуация и он не видит устраивающих его путей решения — закончит все свои открытые таски, не будет брать новые и уволится. И правильно сделает — потому как если он осознает что работа тут "через немогу" то от того, что он будет себя заставлять плохо будет и проекту и ему.
CC>>ИМХО — вспомнить наконец что работа для человека а не человек для работы и уйти оттуда. L_S>Да почему уйти то ? Разве бежать от проблемы это лучший выход ? По моему это крайняя мера — не так ? Ведь если вы не участвуете в интригах, не умеете им противостоять, не выработали поведенческих моделей, то и высоко не подняться.
Трудно интриговать будучи не на позиции менеджера а программером.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Laughing_Silencer, Вы писали:
L_S>>Если возможностей нет, то почему бы и не продолжить работу не замечая интриг? CC>В сверическом вакууме это возможно. В реале есть куча факторов, которые могут деморализовать работника. К примеру если в результате интриг/раздолбайства менеджмента результат работы отдела (в режиме "срок исполнения — месяц назад!") выкидывается в мусор, и дается команда копать в другую сторону в таком же режиме. При этом "для мотивации" еще введут пару штрафов за опоздания на 5 минут. И все, через некоторое время такой вот "работы" процесс с большой вероятностью затормозится до неприличия. Или того хуже, как бывает: весь отдел встанет и уйдет.
В данной ситуации не хватает многих факторов — зарплата, условия работы, интересность проекта, перспективы роста и т.п. Для данной крайней ситуации без учета этих факторов вижу следующий вариант — с руководством можно поговорить всем отделом и если им пофиг на их уход, то тогда соглашусь. Правда я сомневаюсь, что в жизни бывают такие ситуации когда абсолютно весь коллектив не видит никаких перспектив и руководство даёт им всем уйти — разве что не профильная организация не знающая как избавиться от своего ИТ отдела в кратчайшие сроки
L_S>>Вообще тут лучше действовать от конкретной ситуации — общего рецепта не существует. CC>+1
CC>>>"Почему вы должны спасать корабль, который капитан направил на рифы?" (С) L_S>>Позволю себе ответить — потому, что профессионал выполняет работу независимо от сложности, а конфликт с одним из участников проекта (даже если это руководитель) всего лишь добавляет этой сложности равно как и опыта в копилку. Не бывает проектов идеальных — на каждом нужно принимать те или иные решения и бороться с проблемами как технического так и организационного плана, если их не получается упреждать. Конфликт это та же проблема решение которой нужно искать и это не менее интересно/полезно нежели искать проблему в коде. Я скорее не понимаю почему нужно бросать работать. Может поясните ? CC>Профессионал это тот, кто получив задание выдает результат невзирая ни на какие привходящие обстоятельства. (С) CC>С этим я согласен. CC>Другой момент, что подобных профи-терминаторов, которые будут работать в любых условиях очень мало. Да и какой дурак будет работать, если ему надо будет для выполнения задания обходить искусственно созданные препятствия? Будет как в анекдоте:
А какой интерес работать, если препятствий нет ? Нет сложностей, нет опыта — нет опыта, нет роста. Завершение проекта это не только техническая задача, так почему бы и не набраться опыта в организационной части и не попробовать нивелировать недостатки руководства. Я к чему речь то веду — если человек профи в какой-то области и ему интересно расти дальше не только в технической области одиночкой, а работать в коллективе (любая техническая позиция начиная со старшего разработчика уже связана с организационными обязанностями и чем выше, тем больше), то надо набираться опыта. Кстати, если человек очень сильный технический профи влияющий на ход проекта, то интриги его скорее всего обойдут стороной. Редко бывает, что ПМ ни с того ни с сего начал интриговать против своего подчиненного — видимо есть причины внушающие ему опасения
CC>Мы все люди со своими человеческими заморочками. Да и задания у программерского состава не звучат как "закончить проект" — это задания менеджменту. Программер профи в случае если его не устраивает сложившаяся ситуация и он не видит устраивающих его путей решения — закончит все свои открытые таски, не будет брать новые и уволится. И правильно сделает — потому как если он осознает что работа тут "через немогу" то от того, что он будет себя заставлять плохо будет и проекту и ему.
Опять же без конкретной ситуации сложно оценить, но в любой ситуации есть варианты кроме как прятать голову в песок или уходить...
CC>>>ИМХО — вспомнить наконец что работа для человека а не человек для работы и уйти оттуда. L_S>>Да почему уйти то ? Разве бежать от проблемы это лучший выход ? По моему это крайняя мера — не так ? Ведь если вы не участвуете в интригах, не умеете им противостоять, не выработали поведенческих моделей, то и высоко не подняться. CC>Трудно интриговать будучи не на позиции менеджера а программером.
Понятно, что ПМ-у интриговать против программера легко, но во первых с какой-то целью он это делает (ведь по иерархии он выше следовательно и цель должна быть существенной), а во вторых программер и опыта больше наработает при решении таких проблем
Здравствуйте, Laughing_Silencer, Вы писали:
L_S>В данной ситуации не хватает многих факторов — зарплата, условия работы, интересность проекта, перспективы роста и т.п. Для данной крайней ситуации без учета этих факторов вижу следующий вариант — с руководством можно поговорить всем отделом и если им пофиг на их уход, то тогда соглашусь.
Что считать за "им пофиг на их уход"? Ситуация когда их выслушали и ничего сколь либо существенно не изменилось считается за "пофиг"?
L_S>Правда я сомневаюсь, что в жизни бывают такие ситуации когда абсолютно весь коллектив не видит никаких перспектив
Абсолютно весь — разумеется не бывает. Знаю случай когда начался исход "ветеранов", опытных людей, которые прекрасно знали ситуацию на проекте в целом.
L_S> и руководство даёт им всем уйти
Обычно руководство разумеется не хочет чтобы люди уходили. Но бывает что при этом никаких существенных попыток исправить ситуацию не предпринимает.
CC>>Профессионал это тот, кто получив задание выдает результат невзирая ни на какие привходящие обстоятельства. (С) CC>>С этим я согласен. CC>>Другой момент, что подобных профи-терминаторов, которые будут работать в любых условиях очень мало. Да и какой дурак будет работать, если ему надо будет для выполнения задания обходить искусственно созданные препятствия? Будет как в анекдоте: L_S>А какой интерес работать, если препятствий нет ? Нет сложностей, нет опыта — нет опыта, нет роста.
Ты анекдот читал? Какая польза проекту если часть времени тратится не на решение задачи а на борьбу с маразмами собственного руководства?
По мне так это пустая трата времени.
L_S> Завершение проекта это не только техническая задача, так почему бы и не набраться опыта в организационной части и не попробовать нивелировать недостатки руководства.
В таком случае надо переквалифицироваться из разработчика в менеджеры.
L_S> Я к чему речь то веду — если человек профи в какой-то области и ему интересно расти дальше не только в технической области одиночкой, а работать в коллективе (любая техническая позиция начиная со старшего разработчика уже связана с организационными обязанностями и чем выше, тем больше), то надо набираться опыта.
Оно то да, но сперва не мешало бы получить опыт успешного ведения организационных обязанностей а потом уж получать опыт бодания с вышестоящими. Или наоборот. В любом случае лучше раздельно, т.к. получать и тот и другой опыт сложнее и соотвественно менее эффективно. А если при этом еще и девелопить...
L_S> Кстати, если человек очень сильный технический профи влияющий на ход проекта, то интриги его скорее всего обойдут стороной.
Как сказать. Жизнь сложная штука, и происходящее в ней не всегда поддается логике.
CC>>Мы все люди со своими человеческими заморочками. Да и задания у программерского состава не звучат как "закончить проект" — это задания менеджменту. Программер профи в случае если его не устраивает сложившаяся ситуация и он не видит устраивающих его путей решения — закончит все свои открытые таски, не будет брать новые и уволится. И правильно сделает — потому как если он осознает что работа тут "через немогу" то от того, что он будет себя заставлять плохо будет и проекту и ему. L_S>Опять же без конкретной ситуации сложно оценить, но в любой ситуации есть варианты кроме как прятать голову в песок или уходить...
Ну, уход это подведение черты: "здесь улучшения не предвидится". Это последняя стадия конфликта.
Разумеется до ухода есть смысл попытаться исправить проблему со своей стороны, попинав менеджмент. Но если там все глухо — не стоит тратить силы на метание бисера.
CC>>Трудно интриговать будучи не на позиции менеджера а программером. L_S>Понятно, что ПМ-у интриговать против программера легко, но во первых с какой-то целью он это делает (ведь по иерархии он выше следовательно и цель должна быть существенной), а во вторых программер и опыта больше наработает при решении таких проблем
Опыт штука полезная. Но опять таки, если тебе нужен опыт такого рода.
У меня подобный опыт уже есть — больше как то не хочется.
И вынес я из этого опыта то, что такие ситуации надо прекращать как можно раньше.
Потому как:
1) я теряю время на бодания вместо того чтобы потратить время на полезную деятельность
2) опыт в моей специальности идет при этом гораздо медленее
3) нервы — мои, мне за них не платят и запасные не выдают
4) денег в таких конторах платят обычно меньше рыночных
Здравствуйте, CreatorCray, Вы писали:
CC>Как в таком случае не нарушая субординации и действуя в рамках "мужского поведения" профи должен действовать для того, чтобы несмотря на соплю-менеджера вести компанию к светлому будущему?
Он должен делать свое дело. Этого достаточно.
CC>Из жизни контрпример: стабилизация так и не наступила...
У любой истории есть свой конец. Просто он не обязательно счастливый. CC>Является ли саботажем отстаивание своей точки зрения, основанной на опыте, учитывая что то, что требует менеджер противоречит здравому смыслу?
Нет. Проведено совещание, все заинтересованные лица высказали свою точку зрения. Менеджер остался при своих.
Можно эскалировать проблему выше. Высшая инстанция на сторону разработчика НЕ ВСТАЛА.
С этого момента нужно работать, а не партизанить.
CC>Профи может разумеется "заткнуться и сделать как ему говорят". Но после этого ИМХО он имеет полное право покинуть компанию.
Ну разумеется. Это и есть профессиональный подход. CC>Профи отличается от кодера тем, что имеет достаточный опыт, чтобы высказывать свое мнение и вести диалог и обсуждение.
Профи отличается от не профи тем, что работает за деньги и деньги эти честно отрабатывает.
M>>В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил. CC>Эмоции — в сторону. Призывы и лозунги — фтопку!
Гы.... ну правильно. Лозунг — "Это должен делать менеджер" — это счастливое исключение из правила.
CC>За последний год я куда чаще сталкивался с вопиющей некомпетентностью топ-менеджмента нежели разработчиков.
Я думаю, что это вам так просто кажется.
Попробуйте как-нибудь сами побыть на месте руководства.
Здравствуйте, CreatorCray, Вы писали:
M>>И потом — мне именно за это и платят деньги. Деньги я беру, а работать не буду? CC>Деньги платят за выполненную работу а не за разрыв %опы. Часто за лояльность конторы награждают такой подачкой, что лучше бы вообще ничего не дали — результат не такой разрушительный был бы. Впрочем бывают и исключения, но редко.
Если честное выполнение своей работы за заранее оговоренные деньги в рамках стандартного рабочего времени для вас "разрыв %опы", значит вы не только не являетесь профессионалом, но даже и не имеете ни малейшего понятия о том, что это такое.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Laughing_Silencer, Вы писали:
L_S>>В данной ситуации не хватает многих факторов — зарплата, условия работы, интересность проекта, перспективы роста и т.п. Для данной крайней ситуации без учета этих факторов вижу следующий вариант — с руководством можно поговорить всем отделом и если им пофиг на их уход, то тогда соглашусь. CC>Что считать за "им пофиг на их уход"? Ситуация когда их выслушали и ничего сколь либо существенно не изменилось считается за "пофиг"?
Да
L_S>>Правда я сомневаюсь, что в жизни бывают такие ситуации когда абсолютно весь коллектив не видит никаких перспектив CC>Абсолютно весь — разумеется не бывает. Знаю случай когда начался исход "ветеранов", опытных людей, которые прекрасно знали ситуацию на проекте в целом.
L_S>> и руководство даёт им всем уйти CC>Обычно руководство разумеется не хочет чтобы люди уходили. Но бывает что при этом никаких существенных попыток исправить ситуацию не предпринимает.
Пустой треп без реальных действий при вышеуказанных условиях должен расцениваться как отказ. Определить пустой треп или не пустой можно по месту
CC>>>Профессионал это тот, кто получив задание выдает результат невзирая ни на какие привходящие обстоятельства. (С) CC>>>С этим я согласен. CC>>>Другой момент, что подобных профи-терминаторов, которые будут работать в любых условиях очень мало. Да и какой дурак будет работать, если ему надо будет для выполнения задания обходить искусственно созданные препятствия? Будет как в анекдоте: L_S>>А какой интерес работать, если препятствий нет ? Нет сложностей, нет опыта — нет опыта, нет роста. CC>Ты анекдот читал? Какая польза проекту если часть времени тратится не на решение задачи а на борьбу с маразмами собственного руководства? CC>По мне так это пустая трата времени.
А на любом проекте время тратится на борьбу с рисками и этот ничем не хуже... Успеха то должна добиваться команда и от ее руководителя много зависит, но и от разработчиков не меньше. Так что я не соглашусь, что это пустая трата времени. В граничном случае описанном выше — да, в подавляющем большинстве — нет.
L_S>> Завершение проекта это не только техническая задача, так почему бы и не набраться опыта в организационной части и не попробовать нивелировать недостатки руководства. CC>В таком случае надо переквалифицироваться из разработчика в менеджеры.
На любой позиции кроме кодера придется заниматься организационной работой.
L_S>> Я к чему речь то веду — если человек профи в какой-то области и ему интересно расти дальше не только в технической области одиночкой, а работать в коллективе (любая техническая позиция начиная со старшего разработчика уже связана с организационными обязанностями и чем выше, тем больше), то надо набираться опыта. CC>Оно то да, но сперва не мешало бы получить опыт успешного ведения организационных обязанностей а потом уж получать опыт бодания с вышестоящими. Или наоборот. В любом случае лучше раздельно, т.к. получать и тот и другой опыт сложнее и соотвественно менее эффективно. А если при этом еще и девелопить...
Ну это уж индивидуально — кто-то в параллель переключаясь смогет, а кто-то вообще не смогет...
L_S>> Кстати, если человек очень сильный технический профи влияющий на ход проекта, то интриги его скорее всего обойдут стороной. CC>Как сказать. Жизнь сложная штука, и происходящее в ней не всегда поддается логике.
CC>>>Мы все люди со своими человеческими заморочками. Да и задания у программерского состава не звучат как "закончить проект" — это задания менеджменту. Программер профи в случае если его не устраивает сложившаяся ситуация и он не видит устраивающих его путей решения — закончит все свои открытые таски, не будет брать новые и уволится. И правильно сделает — потому как если он осознает что работа тут "через немогу" то от того, что он будет себя заставлять плохо будет и проекту и ему. L_S>>Опять же без конкретной ситуации сложно оценить, но в любой ситуации есть варианты кроме как прятать голову в песок или уходить... CC>Ну, уход это подведение черты: "здесь улучшения не предвидится". Это последняя стадия конфликта. CC>Разумеется до ухода есть смысл попытаться исправить проблему со своей стороны, попинав менеджмент. Но если там все глухо — не стоит тратить силы на метание бисера.
В крайнем случае описанном выше — согласен...
CC>>>Трудно интриговать будучи не на позиции менеджера а программером. L_S>>Понятно, что ПМ-у интриговать против программера легко, но во первых с какой-то целью он это делает (ведь по иерархии он выше следовательно и цель должна быть существенной), а во вторых программер и опыта больше наработает при решении таких проблем CC>Опыт штука полезная. Но опять таки, если тебе нужен опыт такого рода. CC>У меня подобный опыт уже есть — больше как то не хочется. CC>И вынес я из этого опыта то, что такие ситуации надо прекращать как можно раньше. CC>Потому как: CC>1) я теряю время на бодания вместо того чтобы потратить время на полезную деятельность CC>2) опыт в моей специальности идет при этом гораздо медленее CC>3) нервы — мои, мне за них не платят и запасные не выдают CC>4) денег в таких конторах платят обычно меньше рыночных
Ну что я могу сказать — это твой личный выбор. Я изложил свое видение и его обоснование
Здравствуйте, mrozov, Вы писали:
CC>>Как в таком случае не нарушая субординации и действуя в рамках "мужского поведения" профи должен действовать для того, чтобы несмотря на соплю-менеджера вести компанию к светлому будущему? M>Он должен делать свое дело. Этого достаточно.
Ответ не принимается. В развернутом виде плз.
CC>>Из жизни контрпример: стабилизация так и не наступила... M>У любой истории есть свой конец. Просто он не обязательно счастливый.
Ваши действия в этой ситуации?
CC>>Является ли саботажем отстаивание своей точки зрения, основанной на опыте, учитывая что то, что требует менеджер противоречит здравому смыслу? M>Нет. Проведено совещание, все заинтересованные лица высказали свою точку зрения. Менеджер остался при своих. M>Можно эскалировать проблему выше. Высшая инстанция на сторону разработчика НЕ ВСТАЛА. M>С этого момента нужно работать, а не партизанить.
Т.е. заткнулись рабы и работать?
CC>>Профи отличается от кодера тем, что имеет достаточный опыт, чтобы высказывать свое мнение и вести диалог и обсуждение. M>Профи отличается от не профи тем, что работает за деньги и деньги эти честно отрабатывает.
Я о другом.
M>>>В любой жизненной ситуации есть достойный выход. Иногда нужно проявить мужество — не без этого. Не всегда на это хватает сил. CC>>Эмоции — в сторону. Призывы и лозунги — фтопку! M>Гы.... ну правильно. Лозунг — "Это должен делать менеджер" — это счастливое исключение из правила.
Каждый должен делать свою работу.
CC>>За последний год я куда чаще сталкивался с вопиющей некомпетентностью топ-менеджмента нежели разработчиков. M>Я думаю, что это вам так просто кажется.
Отнюдь
M>Попробуйте как-нибудь сами побыть на месте руководства.
Здравствуйте, mrozov, Вы писали:
M>>>>Я не буду саботировать работу даже в том случае, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников. Пример взят из жизни. Я продолжу работу над проектом. После стабилизации ситуации — сменю место работы. M>>>И потом — мне именно за это и платят деньги. Деньги я беру, а работать не буду? CC>>Деньги платят за выполненную работу а не за разрыв %опы. Часто за лояльность конторы награждают такой подачкой, что лучше бы вообще ничего не дали — результат не такой разрушительный был бы. Впрочем бывают и исключения, но редко. M>Если честное выполнение своей работы за заранее оговоренные деньги в рамках стандартного рабочего времени для вас "разрыв %опы", значит вы не только не являетесь профессионалом, но даже и не имеете ни малейшего понятия о том, что это такое.
Эмоции — в сторону!
Разрыв %опы в моем понимании — работа в ненормальной обстановке "случая, если мой непосредственный начальник интригует против меня, настраивает против меня руководство фирмы и моих сотрудников".
M>На этом — все.
Попутного ветра и поменьше эмоций — они вам мешают.
Здравствуйте, Laughing_Silencer, Вы писали:
L_S>>> Завершение проекта это не только техническая задача, так почему бы и не набраться опыта в организационной части и не попробовать нивелировать недостатки руководства. CC>>В таком случае надо переквалифицироваться из разработчика в менеджеры. L_S>На любой позиции кроме кодера придется заниматься организационной работой.
Ну, по мне так та организационная работа которой занимается senior уже как что то само собой разумеющееся
L_S>
2х камрад!
V>Еще, кстати, интересно — какой процент народу из ПМно-ТЛного менеджмента действительно "работает над собой" ?
Хм... В отличие от разработчиков ТЛам и ПМам это необходимо, т.к. без этого они не смогут нормально работать. Это все равно, что спросить: "Каков процент разработчиков действительно изучает новые фичи в новой платформе?"
VGn>В действительности: VGn>испытательный срок не сокращают НИКОГДА,
Кхе-кхе... Мне сократили на треть. Вместо 3-х сделали 2. Но с условием запуска проекта за эти два месяца. И ведь запустил...
VGn>повышения зарплаты надо требовать,
Здесь — да. Даже если существует ежегодное повышение з/п, получить что-либо большее можно только через требования.
VGn>увольнение только пинком под зад,
Опять-же не везде. Кое-где даже дают выходное пособие. Особенно можно поартачиться там, где белое оформление сотрудников по ТК. Вот тут, если ничего не нарушаешь простор для фантаззи громадный. В таком случае — проще работодателю дать тебе выходное пособие, чтобы ты не мучил ни команду ни компанию.
VGn>про советы начальству здесь уже было — фактически менеджеры чаще менее лояльны, чем разработчики.
Про лояльность уже столько копий сломано... Обычно Компания требует лояльности от сотрудников, ничего не давая им взамен, а только ужесточая положение... Как в такой ситуации быть лояльным? Да еще и когда у нас усиленно насаждается культ денег. Т.е. в первую очередь важно, сколько ты зарабатываешь, на чем ты ездишь, где отдыхаешь и т.п. В такое время лояльность только покупается. А всем известно, что во все времена наемников (т.е. тех людей, лояльность которых покупалась за деньги) недолюбливали и им особенно не доверяли.
Здравствуйте, CreatorCray, Вы писали:
L_S>> Я к чему речь то веду — если человек профи в какой-то области и ему интересно расти дальше не только в технической области одиночкой, а работать в коллективе (любая техническая позиция начиная со старшего разработчика уже связана с организационными обязанностями и чем выше, тем больше), то надо набираться опыта. CC>Оно то да, но сперва не мешало бы получить опыт успешного ведения организационных обязанностей а потом уж получать опыт бодания с вышестоящими. Или наоборот. В любом случае лучше раздельно, т.к. получать и тот и другой опыт сложнее и соотвественно менее эффективно. А если при этом еще и девелопить...
Согласен со всеми. Совсем недавно пришлось оказаться внутри "баданий" и внутриофисной политики. Конечно это было очень неприятно. Конечно профессиональный рост как девелопера замедлился, Но зато я сильно вырос как командный игрок: научился правильно подбирать слова в нужное место и в нужное время, научился правильно относиться к критике руководства, научился понимать их точку зрения и искать компросимы устраивающие обе стороны. Мне кажется для больших IT проектов это очень очень очень важно. И кадждый действительно профессиональный девелопер, желающий занимать верхние позиции в проекте, должен обладать неслабыми политическими способностями. Особенно это касается ситуаций, когда в процее проектирования пересекаются интересы двух разработчиков или двух команд разработчиков. А такой опыт общения с людьми легко не дается. Увы. Ну, по крайней мере я не знаю как можно такой опыт получить кроме как в учавствуя в спорах и конфликтах с более сильными и опытными оппонентами. Тяжело в учении — лекго в бою. И это очень важно, и я очень ценю то, что со мной происходило.
Но когда ситуация доходит до маразма, когда вопросы решаются по принципу "мы подумали и Я решил", и бороться с этим нету никаких возможностей — лучше поберечь свою шкуру. Если нет возможности спасти корабль, направленный на скалы — лучше убежать. Тем более такие жесткие условия могут раздавить неокрепших разработчиков (с 1-2 годами исключительно программерского опыта). Человек привыкнет сидеть в углу и бесприкословно слушаться своего "капитана". А ведь такое сидение сильно повредит его будущей карьере. Поэтому я уж лучше убегу от ситуации которая явно мне не по зубам, но останусь жив, чем попытаюсь бороться с начальством и потеряю в зарплате/премии/настоящей и будущей карьере. Можно остать, и тогда возможны 2 варианта: Вы победите, ваша зарплата и опыт вырастут в разы а Ваше влияние в компании будет ошеломляющим. Или вы проиграите, вас раздавят морально, долго будет депрессия и период восстановления личности, зарплата уменьшится/останется на уровне, опыт увеличится совсем немного.
CC>И не придет он жаловаться что у него не получается и проситься на тот проект, который он умеет. Потому как устроен он так.
Хмм. Сам такой. Зато каков вкус победы!!!
[...]
M>Как результат — есть множество книг и статей, в которых менеджерам рассказывают о том, как они должны приспосабливаться к психологическим особенностям (а часто — просто капризам) своих разработчиков, но я не знаю ни одной серьезной работы на тему — как программист должен работать над собой, чтобы не создавать проблем своим собственным неконструктивным поведением. Очевидно, что именно менеджерам в силу положения (и как правило возраста и опыта) и полагается нести основную ответственность за психологический климат, но ведь многие вообще отрицают какую-либо ответственность исполнителей.
The Core Commitments
1. Engage when present.
* Know and disclose
o what I want,
o what I think, and
o what I feel.
* Always seek effective help.
* Decline to offer and refuse to accept incoherent emotional transmissions.
* When I have or hear a better idea than the currently prevailing idea, I will immediately either i)
* propose it for decisive acceptance or rejection, and/or ii) explicitly seek its improvement. Personally support the best idea i) regardless of its source, ii) however much I hope an even better idea may later arise, and iii) when I have no superior alternative idea.
2. Seek to perceive more than I seek to be perceived.
3. Use teams, especially when undertaking difficult tasks.
4. Speak always and only when I believe it will improve the general results/effort ratio.
5. Offer and accept only rational, results-oriented behavior and communication.
6. Disengage from less productive situations
* When I cannot keep these commitments,
* When it is more important that I engage elsewhere.
7. Do now what must be done eventually and can effectively be done now.
8. Seek to move forward toward a particular goal, by biasing my behavior toward action.
9. Use the Core Protocols (or better) when applicable.
* Offer and accept timely and proper use of the Protocol Check protocol without prejudice.
10. Neither harm—nor tolerate the harming of—anyone for his or her fidelity to these commitments.
11. Never do anything dumb on purpose.
Здравствуйте, VGn, Вы писали:
CC>>И не придет он жаловаться что у него не получается и проситься на тот проект, который он умеет. Потому как устроен он так. VGn>Хмм. Сам такой. Зато каков вкус победы!!!
"Добро опять победило зло. Но у победы какой то странный вкус" (С)
Здравствуйте, mrozov, Вы писали:
M>Ладно, ладно, я загнул — для красного словца. Действительно, кое-что есть (про Code Complete я даже помню). Вот только программисты тщательно читают главы про ООД и рефакторинг и часто скипают все про персональную ответственность.
M>Но паттерны-то и хардкорные методы оптимизации они разучивают? Интерес к саморазвитию есть, причем огромный, вот только направленность у него узко-специфическая. А за что платят деньги — это очень спорно.
[Переставил абзацы, поскольку ответ на них один и тот же] Скажем так, применяемые в большинстве случаев методы измерения длины, пардон, пиписьки программиста включают количество знаемых алгоритмов / паттернов и т.д. и т.п., и никак не задевают подготовленность оного к работе в команде / сотрудничеству с начальством. Вот, на всех собеседованиях, в которых я участвовал в роли собеседуемого (их, конечно, было не очень много, но все же), спрашивают всякую ерунду вроде виртуального наследования или каких-то алгоритмов — но никто не спрашивает, к примеру, при каком стиле работы / на каких задачах / в какой командной роли я показываю наибольшую эффективность (я за собой наблюдал различие на порядки). Или же, если предыдущий вопрос слишком глупый, хотя б чего-то из серии методов оценки сроков и т.д. Между собой, кстати, программисты обычно тоже "меряются" количеством технических знаний — оно как бы на ладони, чего проще, спросил, мол, а знаешь-ка ты, друг Вася... Вот и разучивают программисты паттерны и рефакторинг. В общем, был бы explicit спрос на саморазвитие в нужном направлении...
Здравствуйте, craft-brother, Вы писали:
CB>имею честь представить вам свой скромный труд «Руководство командой разработчиков программного обеспечения. Прикладные мысли». Читать здесь.
Во-первых, огромное спасибо за книгу. Очень ценный материал. Редко встретишь подобный опыт, изложенный связно, да ещё и в свободном доступе.
Ещё немного не дочитал, но если позволите — пару слов про возможности улучшения.
По оформлению. Стоило бы прогнать через корректуру — есть ряд мелких ошибок. Как вариант — можно отдать на вычитку команде RSDN, по своему опыту знаю что они это делают грамотно. Стоило бы оформить ближе к "книжному" стилю — шрифты, переносы, типографика итп.
По содержанию. Серые вставки — примеры из жизни — лучше было сделать в стиле изложения, отличающемся от основной нити, от лица живого человека, пусть и с бОльшим количеством воды. Тогда на них читатель бы "отдыхал". Сейчас изложение идёт довольно плотно, местами воспринимается тяжело.
Тем не менее, несмотря на мелкие недостатки — просто отличная вещь. Ещё раз спасибо!..
Здравствуйте, s_tarassov, Вы писали:
_>Здравствуйте, craft-brother
_>Читать рецензию здесь.
[quote]Я пройдусь немного по цитатам в начале книги, чтобы вам было легче решить, надо ли читать книгу дальше или не стоит. Я не стал, но по другой причине: практические аспекты управления командами в данный момент времени меня не интересуют.[/quote]
-1
Много аргументов почему не стоит читать книгу. Ни одного аргумента почему стоит. Можно было бы хоть немного внимания уделить интересным моментам книги. Я не читал всю книгу, только отдельные главы, но нашел для себя достаточно интересных мыслей, ради которых стоит прочитать эту книгу.
Здравствуйте, vb-develop, Вы писали:
VD>Здравствуйте, s_tarassov, Вы писали:
_>>Здравствуйте, craft-brother
_>>Читать рецензию здесь.
VD>[quote]Я пройдусь немного по цитатам в начале книги, чтобы вам было легче решить, надо ли читать книгу дальше или не стоит. Я не стал, но по другой причине: практические аспекты управления командами в данный момент времени меня не интересуют.[/quote] VD>-1 VD>Много аргументов почему не стоит читать книгу. Ни одного аргумента почему стоит. Можно было бы хоть немного внимания уделить интересным моментам книги. Я не читал всю книгу, только отдельные главы, но нашел для себя достаточно интересных мыслей, ради которых стоит прочитать эту книгу.
Здравствуйте, s_tarassov, Вы писали:
_>Здравствуйте, craft-brother
_>Читать рецензию здесь.
ИМХО, отвратительная рецензия. Я таке рецензировал эту книгу, в приватном порядке, бегло (каюсь) просмотрев ее от начала до конца, но все таки от начала и до конца, и могу сказать, что к существу вопросов, поднимаемых книгой, ваша рецензия никак не относится. То есть — совсем. В принципе никак, близко не лежит.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, s_tarassov, Вы писали:
_>>Здравствуйте, craft-brother
_>>Читать рецензию здесь.
G>ИМХО, отвратительная рецензия. Я таке рецензировал эту книгу, в приватном порядке, бегло (каюсь) просмотрев ее от начала до конца, но все таки от начала и до конца, и могу сказать, что к существу вопросов, поднимаемых книгой, ваша рецензия никак не относится. То есть — совсем. В принципе никак, близко не лежит.
Это при том, что автор не даст соврать — я в целом дал отрицательную рецензию, во многом потому, что с сомнением отношусь к психотипам. Но, знаете-ли,
1) Это дискуссионное возражение, можно успешно аргументировать и за и против
2) я при этом не берусь говорить, что книгу не стоит читать. Это глупость. Пусть читатели решают сами, черт возьми, нравится она им, или нет.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, s_tarassov, Вы писали:
_>>>Здравствуйте, craft-brother
_>>>Читать рецензию здесь.
G>>ИМХО, отвратительная рецензия. Я таке рецензировал эту книгу, в приватном порядке, бегло (каюсь) просмотрев ее от начала до конца, но все таки от начала и до конца, и могу сказать, что к существу вопросов, поднимаемых книгой, ваша рецензия никак не относится. То есть — совсем. В принципе никак, близко не лежит.
G>Это при том, что автор не даст соврать — я в целом дал отрицательную рецензию, во многом потому, что с сомнением отношусь к психотипам. Но, знаете-ли, G>1) Это дискуссионное возражение, можно успешно аргументировать и за и против G>2) я при этом не берусь говорить, что книгу не стоит читать. Это глупость. Пусть читатели решают сами, черт возьми, нравится она им, или нет.
По-моему, вы либо "почтирецензию" не читали дальше одного абзаца, либо к кому-то другому обращаетесь
"Пусть читатели решают сами" — я 2 раза об этом написал, как и о том, что практические аспекты управления командами меня в настоящий момент не интересуют.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, vb-develop, Вы писали:
VD>>Много аргументов почему не стоит читать книгу. Ни одного аргумента почему стоит. Можно было бы хоть немного внимания уделить интересным моментам книги. Я не читал всю книгу, только отдельные главы, но нашел для себя достаточно интересных мыслей, ради которых стоит прочитать эту книгу.
G>Назовите их здесь, в противовес. Обсудим.
Что с ходу нашел
Сегодня наши знания устаревают быстрее, чем мы успеваем отпраздновать окончание учебного
заведения. Обучение – это процесс, который длится теперь всю жизнь. Жизнь — это вереница
проектов и великих начинаний. Чем эффективней этот процесс, тем более счастлив человек.
Абрахамсон Маслоу один из основоположников гуманистической психологии утверждает [7], что
«каждый из нас имеет импульс к самосовершенствованию, к более полному воплощению наших
возможностей в действительность, к самоактуализации, или к полной человечности, или к
самоосуществлению». Более того, он уверен в том, что сегодня только самоактуализирующиеся
люди могут считаться полностью психологически здоровыми. Эйнштейн как-то заметил, что тот,
кто ощущает свою жизнь, лишенной смысла, не только несчастлив, но и вряд ли жизнеспособен.
Постиндустриальное общество – это в первую очередь эпоха возможностей. Сегодня поступки и
жизнь человека определяют не внешние обстоятельства, как учили психологи-бихевиористы, и не
биологические потребности, из которых психоаналитики основное внимание уделяли сексуальной
потребности. Жизнь современного человека управляется «экзистенциальными потребностями»
[8]. Стремление к поиску и реализации человеком смысла своей жизни В. Франкл считает
врожденной мотивационной тенденцией, присущей всем людям и являющейся основным
двигателем развития личности. «Не человек ставит вопрос о смысле своей жизни — жизнь ставит
этот вопрос перед ним, и человеку приходится ежедневно и ежечасно отвечать на него — не
словами, а действиями. Смысл не субъективен, человек не изобретает его, а находит в мире, в
объективной действительности, именно поэтому он выступает для человека как императив,
требующий своей реализации!»
Часто приходилось сталкиваться с ситуацией, когда коллега настойчиво отстаивает решение,
которое на моей практике уже показало свою неэффективность. Исходя из соображений
сиюминутной выгоды, очень хочется настоять на своем подходе, но в творческой деятельности
обязательным элементом ответственности является свобода выбора пути решения стоящей
проблемы. Даже если вы уверены в существовании более правильного решения, вы не вправе
настаивать на нем, вы можете высказать свое мнение только в виде рекомендации. Если вы, все-
таки, окажитесь правы, это обеспечит вам дополнительный прирост результата в формуле
эффективности – увеличит капитал доверия. «Продавливание» своего решения приведет к
невосполнимым потерям в доверии между вами и другими участниками проекта. Впрочем, вы ведь
тоже можете ошибаться.
Недостаточное количество коммуникаций свидетельствует, как правило, об отсутствии команды,
каждый углублен в свою задачу и не интересуется, что делают его коллеги. В результате будет
сделано не то, что нужно, а то, что будет сделано, вряд ли удастся интегрировать в единую
систему. Если через день после получения недельного задания у программиста не возникло
уточняющих вопросов, жди беды. Скорее всего, он с головой ушел в «проектирование дома, забыв
уточнить, для чего он предназначен» [23]. Учитывая интроверсию большинства программистов и
несклонность их к общению, менеджеру требуется прилагать значительные усилия для того, чтобы
мотивировать необходимый уровень коммуникаций в проекте.
Отдельно остановлюсь на тестах и практических заданиях по специальности. Относительно их
необходимости у меня имеются большие сомнения. Как правило, технические тесты
ориентированы на проверку узкоспециальных знаний: структур данных, алгоритмов, конкретных
стандартов и API, и т.д. Правильный/неправильный ответ на вопрос: «i=1; i = i++ + ++i; чему равно
i?», — мало о чем свидетельствует. Попытки давать кандидатам олимпиадные задачки по
программированию, или задачки из книжки «Математические головоломки», у меня, как правило,
ассоциируются со стремлением, возможно, не очень успешных вчерашних студентов к
самоутверждению или с желанием продемонстрировать кандидату его несостоятельность, чтобы
затем снизить предложение по зарплате. Я применял тесты по специальности — несколько
десятков простых вопросов на 15-20 минут по базовым понятиям стека технологий J2EE таких,
которые просто невозможно не знать, если ты имеешь практический опыт в данной области.
Результаты этого теста использовались только для того, чтобы выяснить, в какой области
кандидат более уверенно ориентируется и адекватнее позиционировать его среди имеющихся
направлений разработки.
Кстати по поводу последней цитаты. Как-то на собеседовании меня попросили реализовать сортировку за O(n log n). Даже не знаю что и думать про тех, кто такие вопросы на собеседованиях задает.
Здравствуйте, Gaperton, Вы писали:
G>Это при том, что автор не даст соврать — я в целом дал отрицательную рецензию, во многом потому, что с сомнением отношусь к психотипам. Но, знаете-ли, G>1) Это дискуссионное возражение, можно успешно аргументировать и за и против G>2) я при этом не берусь говорить, что книгу не стоит читать. Это глупость. Пусть читатели решают сами, черт возьми, нравится она им, или нет.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, s_tarassov, Вы писали:
_>>По поводу психотипов есть такая заметка CC>Безнадежно устарело. Надо пересматривать.
Это голословное утверждение
К типизации по психологическим признакам всегда надо относиться с долей здорового юмора.
Здравствуйте, s_tarassov, Вы писали:
_>>>По поводу психотипов есть такая заметка CC>>Безнадежно устарело. Надо пересматривать. _>Это голословное утверждение _>К типизации по психологическим признакам всегда надо относиться с долей здорового юмора.
Я вообще то про то, что описание слишком узкое в сравнении с теми типами, что попадаются в современном мире.
Расширять и осовременивать надо.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, s_tarassov, Вы писали:
_>>>>По поводу психотипов есть такая заметка CC>>>Безнадежно устарело. Надо пересматривать. _>>Это голословное утверждение _>>К типизации по психологическим признакам всегда надо относиться с долей здорового юмора. CC>Я вообще то про то, что описание слишком узкое в сравнении с теми типами, что попадаются в современном мире. CC>Расширять и осовременивать надо.
Не думаю, что надо
Есть люди — психологи по призванию, а есть — по недоразумению. Вот те, кто по призванию вполне справятся с управлением командой. Без каких-либо описаний (себя к ним не отношу).
Остальным можно прочесть тома учебников, а толку все равно будет ноль или почти ноль.
Поэтому все эти описания м огут представлять либо академический интерес (тогда их уровень долюен быть соответсвующий), либо анекдотическо-развлекательный. В книге и по моей ссылке используется вторая ипостась. Это не хорошо и не плохо — ведь масса людей, например, с удовольствием читает гороскопы в пятничных газетах
Здравствуйте, s_tarassov, Вы писали:
_>Поэтому все эти описания м огут представлять либо академический интерес (тогда их уровень долюен быть соответсвующий), либо анекдотическо-развлекательный. В книге и по моей ссылке используется вторая ипостась.
Ну я про такое применение и говорил. Мне было бы забавно почитать осовремененную и расширенную версию и поржать над описаниями.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, mrozov, Вы писали: CC>>>Является ли саботажем отстаивание своей точки зрения, основанной на опыте, учитывая что то, что требует менеджер противоречит здравому смыслу? M>>Нет. Проведено совещание, все заинтересованные лица высказали свою точку зрения. Менеджер остался при своих. M>>Можно эскалировать проблему выше. Высшая инстанция на сторону разработчика НЕ ВСТАЛА. M>>С этого момента нужно работать, а не партизанить. CC>Т.е. заткнулись рабы и работать?
при чем здесь это? сначала тебе платили за анализ ситуации, потом за доказательство своей точки зрения, ты ее не доказал, теперь тебе платят за реализацию точки зрения отличной от твоей. При чем здесь рабство? Если ты не хочешь работать, уходи. а не становись в позу. Считаешь себя профи? вот и веди себя как профи, а не как маленький и избалованный мальчик.
Здравствуйте, ironwit, Вы писали:
CC>>Здравствуйте, mrozov, Вы писали: CC>>>>Является ли саботажем отстаивание своей точки зрения, основанной на опыте, учитывая что то, что требует менеджер противоречит здравому смыслу? M>>>Нет. Проведено совещание, все заинтересованные лица высказали свою точку зрения. Менеджер остался при своих. M>>>Можно эскалировать проблему выше. Высшая инстанция на сторону разработчика НЕ ВСТАЛА. M>>>С этого момента нужно работать, а не партизанить. CC>>Т.е. заткнулись рабы и работать?
I>при чем здесь это? сначала тебе платили за анализ ситуации, потом за доказательство своей точки зрения, ты ее не доказал, теперь тебе платят за реализацию точки зрения отличной от твоей.
Ты вообще ветку читал? Речь то там вообще не обо мне.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, ironwit, Вы писали:
CC>>>Здравствуйте, mrozov, Вы писали: CC>>>>>Является ли саботажем отстаивание своей точки зрения, основанной на опыте, учитывая что то, что требует менеджер противоречит здравому смыслу? M>>>>Нет. Проведено совещание, все заинтересованные лица высказали свою точку зрения. Менеджер остался при своих. M>>>>Можно эскалировать проблему выше. Высшая инстанция на сторону разработчика НЕ ВСТАЛА. M>>>>С этого момента нужно работать, а не партизанить. CC>>>Т.е. заткнулись рабы и работать?
I>>при чем здесь это? сначала тебе платили за анализ ситуации, потом за доказательство своей точки зрения, ты ее не доказал, теперь тебе платят за реализацию точки зрения отличной от твоей. CC>Ты вообще ветку читал? Речь то там вообще не обо мне. я отвечал только на твое высказываение. что если не смог доказать свою точку зрения и тебе говорят кодировать чужую, то это не рабство а работа.
Здравствуйте, ironwit, Вы писали:
I>я отвечал только на твое высказываение. что если не смог доказать свою точку зрения и тебе говорят кодировать чужую, то это не рабство а работа.
Ты меня видимо там неверно понял.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, ironwit, Вы писали:
I>>я отвечал только на твое высказываение. что если не смог доказать свою точку зрения и тебе говорят кодировать чужую, то это не рабство а работа. CC>Ты меня видимо там неверно понял.
тогда ты не мог бы уточнить тот пункт о рабстве более подробно?
заранее спасибо.
Здравствуйте, ironwit, Вы писали:
I>>>я отвечал только на твое высказываение. что если не смог доказать свою точку зрения и тебе говорят кодировать чужую, то это не рабство а работа. CC>>Ты меня видимо там неверно понял. I>тогда ты не мог бы уточнить тот пункт о рабстве более подробно?
Сейчас нет времени расписывать. Перечитай ветку, там вроде из контекста становилось понятно что к чему.
Попробую, если вдруг окажется интересным, кратко описать свои ощущения.
Pro:
Замечательный справочник по наиболее популярным "моделям" работы с командой (и прочему микроменеджменту).
Почти каждый найдет хоть что-нибудь ранее не знакомое.
Contra:
Изложение весьма бессистемное, выглядит компиляцией известных текстов без особой проработки.
Модели/классификации/рекомендации изложены поверхностно, не указаны ни рамки использования, ни показания к применению, ни место в общем контексте.
По каждой из тем, увы, выбраны наиболее примитивные и "попсовые" модели (по крайней мере почти всюду я могу указать модель или книгу, дающую более глубокое описание проблемы), не чувствуется глубокое практическое знание материала автором.
Очень многие модели и советы весьма далеки от текущих российских реалий, увы.
Т.е. для программиста, которого внезапно сделали тимлидом на новом проекте и предложили создавать команду — книга крайне полезная. В первую очередь тем, что показывает спектр возможного развития. Для профессионала, понятное дело, пользы гораздо меньше — он большую часть библиографии и так прочитал.
Было бы очень приятно видеть в конце каждой главки отдельную библиографию в десяток-два названий с комментариями (и, кстати, список популярных тренингов — зачастую это гораздо полезнее, нежели куча книг) — тогда пользы от книги было бы гораздо больше.
P.S. Про применимость типизаций к управлению командой я согласен с Гапертоном (хотя и сам отдал соционике немало сил и времени).
Здравствуйте, Gaperton, Вы писали:
G>Это при том, что автор не даст соврать — я в целом дал отрицательную рецензию, во многом потому, что с сомнением отношусь к психотипам.
О, использование различных (психо)типологий — это очень забавная проблема.
С одной стороны, понятно, что классификации всегда убоги, особенно же те, что не несут внутри какой-нибудь достаточно интересной и сложной модели человека/явления вообще (кстати, в оригинальной соционике от Аушуры такая модель была, сейчас ее, увы, позабыли и заменили на соционические гороскопы).
С другой, во многих конкретных случаях классификация позволяет указать базовые сценарии развития системы (человека, акта коммуникации и т.п.).
С третьей, без типологий о некоторых вещах просто сложно рассуждать (если нет языка, то выразить собственное ощущение и передать его другому практически не возможно).
Т.е., если понимать, зачем нужна конкретная типология, как она построена, для чего ее можно использовать, как ее использовать — то типологии полезны (причем любые, есть куча применений, где астрология гораздо удобнее НЛП). Но увы, для эффективного использования типологий необходимо научиться многим гораздо более сложным вещам (теория систем оказывается очень в тему, даже в простейших изложениях. Или сложные модели психики).
V>Вот, на всех собеседованиях, в которых я участвовал в роли собеседуемого никто не спрашивает, к примеру, при каком стиле работы / на каких задачах / в какой командной роли я показываю наибольшую эффективность
О, спасибо, возьму на вооружение. Хорошо показывает, насколько разработчик рефлексивен...
Здравствуйте, craft-brother, Вы писали:
CB>Уважаемые коллеги,
CB>имею честь представить вам свой скромный труд «Руководство командой разработчиков программного обеспечения. Прикладные мысли». Читать здесь.
прочитал пока до 12 страницы. пока только вода и гимны некоему "постиндустриальному" обществу, существующему только в голове либеральных идеологов, никоим образом к программированию не имеющих отношения.
также прослеживается пережевывание идеи, что программирование — суть искусство, и ему архитекторы не нужны, кодеры не нужны, стадийность, иерархия, и роли в проекте — изобретение злого бюрократического ума, упрямо мешающего развернуться интеллектуалам(случайно отловленным неусыпными рекрутерами на рынке безработных программистов и выпускников-недоучек), во всю ширь их неохватных мозгов.
правда над этой мощью высится фигура некоего правильного менеджера, типа тренера, раздающего пинки и награды за планово забитый програмисткий гол.
чушь полная...
но будем читать дальше...
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>С одной стороны, понятно, что классификации всегда убоги, особенно же те, что не несут внутри какой-нибудь достаточно интересной и сложной модели человека/явления вообще (кстати, в оригинальной соционике от Аушуры такая модель была, сейчас ее, увы, позабыли и заменили на соционические гороскопы).
ДФ>С другой, во многих конкретных случаях классификация позволяет указать базовые сценарии развития системы (человека, акта коммуникации и т.п.).
Реальная проблема с практическим применением "психотипов" — то, что в рабочем контексте ты не имеешь возможности их корректно отдиагностировать. Более того. Менеджер — сам тоже человек, со своими тараканами, и манипулируя "типами" превращает эти типы и людей в превосходный экран для собственных психопроекций, смещая акцент с понимания причин поведения людей в конуретных ситуациях на подбор "шаблона" для них, который якобы является причиной поведения.
То есть, в реальном рабочем контексте от применения психотипов будет чистый вред. Подробное объяснение — по ссылке (была подробная дискуссия на эту тему).
В целом, при трактовке ситуации я исхожу из базиса гештальт-терапии, хоть это и не так просто проследить по данному посту. "Психопроекция" — это гештальтистский термин, замечательная штука. Именно в эту игру и начнет на самом деле играть менеджер, пытаясь оперировать психотипами, и до добра это не доведет, только усугубит разрыв с действительностью.
Далее. Полезность психотипов при _объяснении_ некоторых эффектов также более чем сомнительна. Психотипы — это не объективно существующее понятие, а абстрактное, существующее только в нашем воображении. Человек ВСЕГДА имеет веские ПРИЧИНЫ для каждого своего поступка, и поступает по совокупности своего устройства оптимально для себя в каждой ситуации. Исключая, разумеется, ситуации наркотического и алкогольного опьянения, которые нарушают естественную биохимию систему "грузиков и противовесиков" — скажем, алкоголь отключает тормозные рефлексы . Использовать психотипы при объяснении поведенческих реакций — самообман, подмена истинной причины.
ДФ>>С другой, во многих конкретных случаях классификация позволяет указать базовые сценарии развития системы (человека, акта коммуникации и т.п.).
G>Реальная проблема с практическим применением "психотипов" — то, что в рабочем контексте ты не имеешь возможности их корректно отдиагностировать. Более того. Менеджер — сам тоже человек, со своими тараканами, и манипулируя "типами" превращает эти типы и людей в превосходный экран для собственных психопроекций, смещая акцент с понимания причин поведения людей в конуретных ситуациях на подбор "шаблона" для них, который якобы является причиной поведения.
Я, вообще-то, не столько о психотипах (я не отношусь к верующим, что психотип может быть определен в реальных условиях и при этом определяет поведение — фигушки), а о типологиях вообще — благо попадаются они везде, от НЛП или Юнга до астрологии. Есть ли в гештальт-терапии — не помню.
G>Далее. Полезность психотипов при _объяснении_ некоторых эффектов также более чем сомнительна.
Я опять не о том — я о полезности использования типологий при _обсуждении" поведения. Так как какими-то словами пользоваться все-таки надо...
В особенности если истинные причины нерациональны
А про "психотипы" — согласен. Хотя и видел практическое применение "психотипов" в менеджменте, во всех конкретных случаях просто интерес к людам помог бы не меньше.
(P.S. Есть еще одна польза для менеджера от поверхностного изучения "психотипов" — понимание, что люди, ой, разные... Я видел кучу людей, считавших, что все думают так же, как и он (не о выводах, а о самом процессе). Соприкосновения с реальностью было больным.
А кнут демотивирует не потому, что примадонны мы все нежные.
А потому, что применение кнута мотивирует на то, _как бы люлей не получить_. Вплоть до умышленной практики сокрытия недостатков и заметания их под ковер, только бы не вылезло и не огрести, а подковерную кучу как-нить по ходу втихаря разгребем. Мотивация "не огрести" пересиливать мотивацию хорошо работать.
Если же кучу не разгребли потом — то могучий, громкий провал, люлей получат все, но боссу это не в радость будет — проект _провален_.
А еще активное применение кнута мотивирует на то, чтоб спрашивать разрешения у начальства на каждый свой шаг.
А еще оно мотивирует ко всему относиться формально. Если заставить людей приходить на работу ровно в 9 — как клеркесс в Ингосстрахе — то ровно в 18 все ломанутся из офиса, в дверях будет толпа, как в метро. Никто не будет задерживаться ни на секунду.
Зрелый адекватный человек еще со времен СССР знает, как жить в условиях мотивации наказанием.
N_C>Про лояльность уже столько копий сломано... Обычно Компания требует лояльности от сотрудников, ничего не давая им взамен, а только ужесточая положение... Как в такой ситуации быть лояльным? Да еще и когда у нас усиленно насаждается культ денег. Т.е. в первую очередь важно, сколько ты зарабатываешь, на чем ты ездишь, где отдыхаешь и т.п. В такое время лояльность только покупается. А всем известно, что во все времена наемников (т.е. тех людей, лояльность которых покупалась за деньги) недолюбливали и им особенно не доверяли.
Лоялен тот, кому в компании _хорошо_. Особенно если он боится это "хорошо" потерять. Примадонна может быть на 100% лояльна (пока начальство не начнет мероприятия по приведению примадонны к ногтю).
Лояльность да, покупается. Нелюбовь к этому — это какой-то бусидошно-самурайский феодализм, сейчас общество не то. Например, уволиться легко
Еще надо понимать, что с покупкой лояльности не покупается производительность.
N_C>Хе-хе... Это пока есть куда идти — т.е. есть голод рынка по профессионалам. Как только голода не будет — опять начнется тоже самое — принуждение и грубая физическая сила (ну будет она в виде ора, например)...
В 90ые особого голода не было, а из таких контор все равно бежали, причем, конечно, бежали в самый разгар проекта и внезапно. Люди не ощущают никаких обязательств перед таким руководством.
MSS>В 90ые особого голода не было, а из таких контор все равно бежали, причем, конечно, бежали в самый разгар проекта и внезапно. Люди не ощущают никаких обязательств перед таким руководством.
Хм... Максим, можно долго спорить о том, что можно бежать или нет. Но. Если Вы будете обременены разными обязательствами (жена, дети, кредиты, лечение и пр.) Вы уже не будете так легко расбрасываться работой. Это конечно хорошо — иметь mvp и имя в среде разработчиков — это позволяет на всех глядеть свысока. Однако не все такие как Вы. И говорить за всех — по меньшей мере неправильно, если не сказать хуже.
Так что, имея имя и репутацию, можно выеживаться и говорить, что это не так и то не этак. А не имея ничего этого — приходится выкручиваться с тем что есть.
MSS>Лояльность да, покупается. Нелюбовь к этому — это какой-то бусидошно-самурайский феодализм, сейчас общество не то.
В этом то и проблема. Лояльность, которая покупается, так-же хорошо и продается на сторону. Как с войсками, с одной стороны наемники, лояльность которых куплена — это хорошо, но куда дешевле лояльность своих войск. В этом то и загвоздка, что сейчас культивируется покупная лояльность. Точнее даже не покупная, а сиюминутная лояльность. Даже HR-ам проще купить чела на пару лет, выжать его как лимон и выбросить на улицу при малейшем неповиновении. ИМХО — это не совсем правильно. Мне больше нравится то, что существовало раньше — ты знал, что приходя в компанию, ты приходишь в семью. Знаю — это мои проблемы, но мне все-равно так больше нравится.
PS
А общество всегда одинаковое — мы недалеко ушли от средних веков, как показывает практика.
