Здравствуйте, 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>Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
