Здравствуйте, Vzhyk, Вы писали:
V>De-Bill пишет: >> О>Следить за временем прихода/ухода...просто скукатища. >> Следить за временем прихода/ухода — вообще бред. Это все и всегда говорили. V>Тем ни менее есть куча манагеров, которые считают оное своей основной V>функцией.
за 10 лет работы в IT не встретил ни одного такого. Либо я везучий, либы вы невезучий.
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Огнеплюх, Вы писали:
О>>Любой здравомыслящий заказчик понимает что и кто делает. Что есть программисты которые собственно будут создавать его детище, а есть промокашка которая будет впитывать его время при этом особо ничего не производя. Поэтому он впервую очередь заинтересован чтобы там были хорошие специалисты.
G>Любой здравомыслящий заказчик понимает, что без хорошего управления написать хороший сложный продукт нереально. G>Чтобы обеспечить нормальное взаимодействие в командах, между командами, между отделами и прочие детали рабочего процесса нужен хороший менеджер.
Нет это вы не про здравомыслящего, а про сферического в вакууме.
Здравомыслящий заказчик понимает нашу российскую ситуацию и то что у нас нет хороших управленцев — нет институтов. Поэтому практически любой начальник/менеджер в 99% случаев это такой же управленец , как студент архитектор или обезьяна с гранатой. Изредка занимающийся самообразованием.
Поэтому ему важно выбрать "врача" или разработчика лично. Точнее его будет в первую очередь интересовать какого уровня специалисты работают. Вы когда в автосервис прийдете вы предпочтете с начальником обсудить детали ремонта или непосредственно поговорить с тем кто будет делать вашу машину, приглядется к нему понять равшан это или джумшут.
О>Менеджер проекта не принимает никаких решений по архитектуре — это делает архитектор. Менеджер просто спросит у него — какую архитектуру делать ? Тот ему ответит. И все , все что произвел менеджер — это вопрос.
Там, где работаю я, это не так. Архитектор может предложить архитектуру и озвучить риски, связанные с использованием той или иной стратегии. Именно менеджер решает, какие риски допустимы для данного проекта, а какие — нет и принимает окончательное решение. Процесс не простой, и он требует большого внимания и опыта.
О>Менеджер не составляет ТЗ — тз составляет аналитик, менеджер только ставит задачу.
Аналитик составляет ТЗ на основании требований заказчика, написанное на человеческом языке. Менеджер должен это прочитать и перевести эти требования в требования, которые будут ясны программистам.
О>Обеспечивает взаимодействие = промокашка. Любой заказчик или бизнес-аналитик как правило стремится напрямую общаться с разработчиком, а промежуточные звенья которые только вносят искажения в информацию им не интересны.
Ничего подобного! Ни в одной компании не видела, чтобы заказчик звонил программистам и говорил, что он хочет. У программистов совсем другая работа, они не должны слушать капризы, требования и т.п., они должны читать ТЗ и составлять алгоритмы, которые это реализуют. Судя по вашим словам, у меня сложилось ощущение, что вы работаете в компаниях, где бизнес-процессы не определены и отсюда вот такой хаус и смешение обязанностей.
О>Опять же у менеджера нет никакого выбора — выбор за заказчиком и профи, за специалистами. Менеджер на поводу у заказчика, архитектора и других специалистов — что они скажут/сделают так и придется это воспринимать. Менеджер не может/не имеет профессиональной компетенции оспорить мнение архитектора о том какая должна быть архитектура.
То есть архитектор у вас — это типа бог, который может разработать архитектуру на миллион долларов для простейшего приложения, и менеджер ничего не может возразить? Это несерьезно! Менеджер как раз должен выслушать архитектора и оспорить архитектуру, если она недопустима по каким-либо причинам.
Опять же — если один разработчик скажет, что он будет кодить в Visual Stodio 6.0, а другой — Visual Studio 2005, менеджер должен промолчать? А вы в курсе, что во всех нормальных компаниях лицензии закупаются на определенные линейки продуктов и не разработчикам решить, в какой версии студии они будут кодить!
Здравствуйте, De-Bill, Вы писали:
DB>5. Меньше сложной и напряжённой работы (например, разобраться почему какая-то хрень работает не так как должна) и больше несложной и ненапряжённой (составить план, обсудить задачи, обсудить перспективы и высказать своё мнение и т.д.).
Эта работа довольно сложная и напряжная. По крайней мере, если стоит задача:
— составить план, который будет выполнен
— обсудить задачу с целью понять точно, что требуеться сделать
— определить перспективное направление, которое останеться пермпективным не до следующего митинга, а некое длительное время.
Те немногие планы, задачи и перпективы которые проходили через меня, всегда давали отдачу. Но труда и энергии сьедали очень хорошо.
Здравствуйте, Огнеплюх, Вы писали:
О>Здравомыслящий заказчик понимает нашу российскую ситуацию и то что у нас нет хороших управленцев — нет институтов. Поэтому практически любой начальник/менеджер в 99% случаев это такой же управленец , как студент архитектор или обезьяна с гранатой. Изредка занимающийся самообразованием. О>Поэтому ему важно выбрать "врача" или разработчика лично.
Хм, забавно... вот я работаю в компании, где имеется около сотни крупных клиентов, которые пользуются продуктом... Вы считаете нормальным, если каждый из этих людей придет к нам в офис выбирать программистов, которые буду фиксить баги в этом ПО?
Здравствуйте, Vzhyk, Вы писали:
V>И соотвественно все его обязанности, отследить, чтобы народ не сильно V>сачковал работу, обеспечить разработчиков кофе и чаем и т.п.?
я понял. это называется оффис-менеджер. у нас тоже такой есть, на ресепшене стоит
О>Насколько я знаю не еруда, во первых нужно еще очень хорошо обосновать ген.диру необходимость выделения этих денег, а иногда бюджет утвержден на весь проект и ни копейки туда больше не дадут, а инструмент будет критичен.
Можно сразу примеры? Что за инструмент-то такой?
О>Ну так и есть, главнокомандующий дает приказ — начать освобождение северной осетии , и все по цепочке спускают этот приказ до солдат.
Ну... если тебе так нравится, то называй это так... Хотя, мне интересно, видишь ли ты какие-нибудь преимущества в том, чтобы быть генералом, а не солдатом, или нет?
О>Ну скажи вот куда ты вырастешь как руководитель — допустим ты начальник отдела, куда рости ? начальник начальника отдела , а потом начальник начальника всех начальников ? как правило такой роскоши нет, максимум начальник отдела и над ним ген.дир, а ген.дир тебе свою вакансию не уступит.
Рост моего отдела будет и моим ростом тоже — больше "ответственности", больше манёвра для принятия управленчиских решений, больше вес и значимость в компании. Перспективы роста моего отдела — основные перспективы моего личного роста. Это точно также как и у ген.директора, над ним никого нет (кроме владельцев компании, которые, по-факту, им не управляют), расти ему некуда, единственная возможность его роста — рост компании вцелом.
О>А у программиста есть хотябы ступенька — архитектор, не говоря уже о промежуточных старший программист, младший и т.п.
А дальше что? Прошёл я эти все ступеньки за несколько лет. Кроме архитектора, но у нас в компании такой должности никогда и не выделялось, что теперь, бежать искать компанию в которой должность архитектора присутствует?
О>Ну вот я о том же — не понимаю что приятного в том что смотреть как другие проявляют себя свои профессиональные качества. И совсем не понимаю как можно их достижения приписывать на свой счет. Почему считаешь что команда без тебя бы не справилась?
Здесь речь идёт скорее не о "приписывании результата на свой счёт"... Ты никогда не замечал, что программисты практически никогда не говорят "мы", "команда" и т.д.? ну, по крайней мере я никогда не говорил... а менеджеры говорят, и чем дальше, тем больше. Короче говоря, менеджеры начинают чувствовать себя частью чего-то (компании, команды, отдела и т.д.). И здесь речь идёт о приписывании результата, а о том, что менеджер чувствует, что результат работы программиста — это и его результат тоже. По крайней мере я это чувствую .
О>Но подписывает он, HR-ка заявление на отпуск не имеет право подписать чужое.
Ок, скажем так. Я не подписываю, кто это делает — не знаю.
О>Ну в любом случае это как правило поручения которые надо транслировать , в каком тоне они бы не звучали, хоть он там сексом по телефону будет заниматсья.
Опять же... хочешь называть это так — называй... В-принципе, можно сказать, что почти все программисты пишут прокладки между пользователем и процессором/жёстким диском/оперативной памятью. Но не всё так просто.
О>Хорошо , вот один из специалистов вдруг не появился на работе во время, или ушел сразу после обеда, кто должен ему выговор или замечание сделать ? Откуда этот человек узнает о том что это нужно сделать если у него нет механизма отслеживания прихода/ухода.
Если специалист при этом выдаёт нужный и качественный результат — честь ему и хвала. Если он результат не выдаёт, то какой же это специалист? Он же и под определение специалиста-то не подходит... Да и вообще, что за детский сад с выговороми за ранний уход и опоздания?
О>з.п. бывает как выше так и ниже и в среднем не сильно отличается от з.п. специалиста.
Хочешь так думать — думай .
О>да уж сказки какие — все заказчики приятные ) в любом случае общаться заказчик захочет со специалистом и тебе придется его с собой брать ибо кроме как поговорить о погоде и о том какая же классная у вас фирма ты не сможешь, остальное может знать только специалист ( как , сколько и когда чего нужно и что будет сделано ).
Может придётся, может — не придётся... в любом случае, я написал лишь то, что общения становится больше.
О>Только кто потом плоды этой работы использует ? План через пару дней уйдет на помойку т.к. окажется что что-то пошло не так и его нужно будет переделывать. Обсудить задачи и перспективы, высказать мнение это бла-бла которое никому не нужно , кроме самого начальника чтобы хоть как-то проявить себя ,а то забудут о его существовании.
Здесь у тебя какие-то непонятные слова, которые комментировать не хочется...
О>А вот разобраться почему хрень не работает — это как раз очень интересно. Я например буду больше уважать человека который разобрался с хренью почему она не работает, чем человека который нарисовал сферического коня в вакууме ( план ) или произнес торжественную речь о том какие же все крутые и что у нас куча перспектив.).
Пусть убеждение, что план=сферический конь в вакууме у тебя и останется, у меня нет желания тебя переубеждать. Торжественные речи произносятся крайне редко, думаю, что в нашей компании торжественную речь произносит только ген.директор на новогоднем корпоративе...
Про "разобраться почему хрень не работает — это как раз очень интересно" — спорить не буду. Я утверждал только то, что зачастую это бывает очень сложно и напряжённо. Бывает так, что это вытягивает все твои моральные силы, бывает, что после решения такой проблемы наступает полнейшая аппатия... а бывает и так, что после решения не чувствуешь никакого удовлетворения... У менеджера такой работы (сложной и напряжённой) — меньше. Лёгкой и ненапряжённой — больше.
E>ИМХО в будующем количество начальства сведется к минимуму, и такой иерархии и такого количества начальства как сейчас не будет. ИМХО будет один человек — заказчик, который определяет что и как он хочет, а все распределение задачь, контроль и т.д. возможно будет неплохо автоматизировано. Тогда наступит счастье, есть проекты, в которых все делается подобным образом, когда роли меняются, нет выделенного главного, вроде такое работает довольно успешно.
ребята, вы из какой паралельной вселенной нам пишите?
Здравствуйте, Огнеплюх, Вы писали:
О>А начальник что, сидеть ждать когда же тебе кто-то зайдет в кабинет чтобы расставить росчерк на заявлении об отпуске/увольнении.
Странно что у вас начальники только сидят и ждуть когда же к ним кто-то зайдет в кабинет чтобы расставить росчерк И странно, что у вас такие представления о всех начальниках.
DB> Если повезло работать с классными специалистами и людьми, то вообще всё замечательно.
ох, твои б слова да богу в уши Если повезло.. что-то по моим наблюдениеям с этим как правило не очень везёт. А ещё и так что б и специалисты класные и люди вменяемые в одном флаконе
M>Те немногие планы, задачи и перпективы которые проходили через меня, всегда давали отдачу. Но труда и энергии сьедали очень хорошо.
С этим сложно поспорить. У всех бывают сложные задачи. Просто вспоминаю некоторые свои программерские задачи:
1. Разобраться почему серверная часть системы(миллионы строк кода, написанные совершенно незнакомыми людьми, живущими на другом континенте), работающей с сложном многопоточном и многопроцессном окружении, переодически непредсказуемо и непрогнозируемо падает. Когда нужно перерабатывать не только эти миллионы строк кода, но и исходники .NET Framework.
2. Разобраться, почему система оценки производных финансовых инструментов работает в 5 раз дольше предполагаемого. Тоже миллионы строк кода, многопоточное и многопроцессное окружение, несколько языков программирования, включая VB6 и т.д.
Короче говоря, сидишь по 10 часов в день в течении месяца, в голове всё плывёт, ночами всё это снится как в бреду... а главное, практически никакого удовлетворения от решения. Большие дядьки где-то через океан приехали на мининг на крутых машинах, произнесли речи, попожимали друг другу руки, подписали договоры о сотрудничестве... а тебя по плечу похлопал ген.директор и сказал — "Молодец!" .
Здравствуйте, Огнеплюх, Вы писали:
О>Ну так и есть, главнокомандующий дает приказ — начать освобождение северной осетии , и все по цепочке спускают этот приказ до солдат.
Ничего подобного.
По цепочке надо будет детализировать приказ о "начале освобождения северной осетии".
А иначе до солдата вообще будут доходить только политические решения
и он будет их игнорировать, что и будет верной реакцией.
Здравствуйте, Огнеплюх, Вы писали:
О>Здравомыслящий заказчик понимает нашу российскую ситуацию и то что у нас нет хороших управленцев — нет институтов. Поэтому практически любой начальник/менеджер в 99% случаев это такой же управленец , как студент архитектор или обезьяна с гранатой. Изредка занимающийся самообразованием.
Может это звучит парадоксально, но большая команда даже с плохим менеджером будет работать успешнее, чем вообще без него.
О>Поэтому ему важно выбрать "врача" или разработчика лично. Точнее его будет в первую очередь интересовать какого уровня специалисты работают. Вы когда в автосервис прийдете вы предпочтете с начальником обсудить детали ремонта или непосредственно поговорить с тем кто будет делать вашу машину, приглядется к нему понять равшан это или джумшут.
В автосервисе над моей машиной будет работать один, ну может два-три механика. Тут действительно важнее роль исполнителя. Но как только команда становится больше роль управления возрастает. НАпример машину какого завода ты предпочтешь, с хорошим менеджменотом или где каждый механик гений, но сам по себе?
Здравствуйте, Огнеплюх, Вы писали:
О>Не знаю как у вас , но в нашей многонациональной стране что аналитик , что архитектор говорят на русском и очень хорошо друг друга понимают. Менеджеру на совещании остается только хлопать глазами и записывать на листочке что они обсуждают, и кивать иногда.
Они говорят на разных уровнях абстракции.
Программист мыслит в терминах кода. — дизайна, архитектуры, конкретных классов.
Аналитик мыслит в терминах бизнес-логики и use-case-ов.
Клиент мыслит в терминах например маркетинга.
В задачи начальника как раз и входит обеспечение продуктивной и бесперебойной работы программистов, планирование задач, выбор оптимального пути развития продукта.
Просто человек понимает, что его призвание — стратегия, планирование и управление, и идёт в начальники. А там работа тоже достаточно интеллектуальная, плюс ко всему нужно профессиональное чутьё и интуиция.
Здравствуйте, Огнеплюх, Вы писали:
О>Мне кажется единственный интерес быть начальником/ген.директором — это собственный бизнес, там совсем наверху уж никто тебе не указ и можно действовать по своим убеждениям и принципам, реализовывать свои идеи, а не быть промокашкой которая только транслирует посылы ген.директора. О>Но для своего бизнеса нужно очень много денег и куча других качеств.
Наверху клиенты и им нужно регулярно от...ть :D Особенно это касается молодого бизнеса.
Здравствуйте, Огнеплюх, Вы писали:
О>Насчет увольнений — во время кризиса в нашей компании в основном порезали вакансии начальников, уволили 50% менеджеров. При этом разработчиков не тронули.
Это означает, что не начальники они, а лошье позорное. Потому как не смогли убедительно втереть гене про свою важность. Короче, это их факап по линии people skills.
Здравствуйте, Огнеплюх, Вы писали:
О>Что интересного там находят — сидеть смотреть как другие работают, быть официантом , когда приходит программист и говорит что ему нужна такая-то железка или программа. Быть прокладкой между ген.директором и разработчиками. При этом зарплата не намного выше, а иногда у менеджеров даже меньше или равна зарплате программиста.
О>Программисту конечно тоже не сахар в плане свободы действий, но хотя бы эта деятельность она более интелектуальна и интересна, а главное что мне больше всего в ней нравится — это то что руками программиста создается результат, продукт.
Странно, что никто этого не отметил, но некоторым людям управленческая деятельность более интересна и, соответственно, больше подходит, чем деятельность инженерная. Работа управленца — это тоже работа, со своими интересными задачами. И кому-то изготовление кода кажется скукой неземной, а работа ПМа, наоборот, вдохновляет.
Здравствуйте, sunsquirel, Вы писали: О>Менеджер проекта не принимает никаких решений по архитектуре — это делает архитектор. Менеджер просто спросит у него — какую архитектуру делать ? Тот ему ответит. И все , все что произвел менеджер — это вопрос.
Там, где работаю я, это не так. Архитектор может предложить архитектуру и озвучить риски, связанные с использованием той или иной стратегии. Именно менеджер решает, какие риски допустимы для данного проекта, а какие — нет и принимает окончательное решение. Процесс не простой, и он требует большого внимания и опыта.
Ничего он не решает, решает архитектор какие риски и их вес. Все что делает менеджер это сравнивает цифру называнную архитектором с допустимой. Например вес риска 0.5 значит не подходит. То есть банальная операция сравнения. А решает какие риски и их вес определяет тот у кого есть знания.
О>>Менеджер не составляет ТЗ — тз составляет аналитик, менеджер только ставит задачу. S>Аналитик составляет ТЗ на основании требований заказчика, написанное на человеческом языке. Менеджер должен это прочитать и перевести эти требования в требования, которые будут ясны программистам.
Такое ощущение что программисты идиоты , хорошо если программисты идиоты то почему они вдруг решают стать менеджерами ? то есть получается что измени должность с программист на менеджер — сразу откроется понимание. Любой программист легко поймет требования заказчика и сможет говорить на одном языке. Программист сам может являться заказчиком, все мы одни и те же люди что программист , что заказчик и легко можем понять друг друга. Для этого менеджер не нужен особо.
О>>Обеспечивает взаимодействие = промокашка. Любой заказчик или бизнес-аналитик как правило стремится напрямую общаться с разработчиком, а промежуточные звенья которые только вносят искажения в информацию им не интересны. S>Ничего подобного! Ни в одной компании не видела, чтобы заказчик звонил программистам и говорил, что он хочет. У программистов совсем другая работа, они не должны слушать капризы, требования и т.п., они должны читать ТЗ и составлять алгоритмы, которые это реализуют. Судя по вашим словам, у меня сложилось ощущение, что вы работаете в компаниях, где бизнес-процессы не определены и отсюда вот такой хаус и смешение обязанностей.
Я не говорю что в каждой компании есть такая возможность. Я говорю о том что заказчик бы предпочел взаимодействовать напрямую с людьми которые работают над его детищем — минуя всякие передаточные звенья. Вы играли в детсвте в игру называется "испорченный телефон" ? Если играли думаю будет понятно почему хочется работать напрямую.
О>>Опять же у менеджера нет никакого выбора — выбор за заказчиком и профи, за специалистами. Менеджер на поводу у заказчика, архитектора и других специалистов — что они скажут/сделают так и придется это воспринимать. Менеджер не может/не имеет профессиональной компетенции оспорить мнение архитектора о том какая должна быть архитектура. S>То есть архитектор у вас — это типа бог, который может разработать архитектуру на миллион долларов для простейшего приложения, и менеджер ничего не может возразить? Это несерьезно! Менеджер как раз должен выслушать архитектора и оспорить архитектуру, если она недопустима по каким-либо причинам.
Все что может менеджер это сравнить две цифры — провести арифметическую операцию доступную для школьника. А именно сравнить цифру которую назвал архитектор с цифрой которую ему спустили сверху и выдать результат. Если цифра архитектора > цифры руководства то "нет", если меньше то выдать "да".
Менеджер не может разбираться в архитектуре лучше архитектора , иначе он не менеджер а архитектор. И не может решать какая архитектура лучше с точки зрения технологий и мастабируемости. Как архитектор скажет так и будет, менеджер только может сравнив 2 цифры сказать да укладываемся или нет не укладываемся в ресурсы и все. Но это может делать любой человек со средним образованием — зачем ему платить больше разработчика.
S>Опять же — если один разработчик скажет, что он будет кодить в Visual Stodio 6.0, а другой — Visual Studio 2005, менеджер должен промолчать? А вы в курсе, что во всех нормальных компаниях лицензии закупаются на определенные линейки продуктов и не разработчикам решить, в какой версии студии они будут кодить!
Именно разработчики решают какие инструменты нужны. А задача менеджера это сбегать с кошелкой в магазин и прикупить то что нужно для работы. Специалист лучше знает как закатывать цемент и больше ньюансов и деталей. Если менеджер начнет подбирать инструменты для разработки то его пошлют подалльше и разрабатывать он будет в этом случае один самостоятельно.
DB>Рост моего отдела будет и моим ростом тоже — больше "ответственности", больше манёвра для принятия управленчиских решений, больше вес и значимость в компании. Перспективы роста моего отдела — основные перспективы моего личного роста. Это точно также как и у ген.директора, над ним никого нет (кроме владельцев компании, которые, по-факту, им не управляют), расти ему некуда, единственная возможность его роста — рост компании вцелом.
О>>А у программиста есть хотябы ступенька — архитектор, не говоря уже о промежуточных старший программист, младший и т.п.
DB>А дальше что? Прошёл я эти все ступеньки за несколько лет. Кроме архитектора, но у нас в компании такой должности никогда и не выделялось, что теперь, бежать искать компанию в которой должность архитектора присутствует?
Ну если также подходить — то у программиста растет количество его проектов и тем ценнее он для компании.
О>>Ну вот я о том же — не понимаю что приятного в том что смотреть как другие проявляют себя свои профессиональные качества. И совсем не понимаю как можно их достижения приписывать на свой счет. Почему считаешь что команда без тебя бы не справилась?
DB>Здесь речь идёт скорее не о "приписывании результата на свой счёт"... Ты никогда не замечал, что программисты практически никогда не говорят "мы", "команда" и т.д.? ну, по крайней мере я никогда не говорил... а менеджеры говорят, и чем дальше, тем больше. Короче говоря, менеджеры начинают чувствовать себя частью чего-то (компании, команды, отдела и т.д.). И здесь речь идёт о приписывании результата, а о том, что менеджер чувствует, что результат работы программиста — это и его результат тоже. По крайней мере я это чувствую .
Ну это понятно что любой болельшик размахивая шарфом на трибуне считает что забитый гол только благодяря ему и он явяется частью этого достижения. Иначе бы от так не орал и не размахивал, а по сути толку от него особого нет.
О>>Но подписывает он, HR-ка заявление на отпуск не имеет право подписать чужое. DB>Ок, скажем так. Я не подписываю, кто это делает — не знаю.
Странные у вас порядки, менеджер не знает кто подписывает заявление на отпуск. Получается может получится что программист может уйти в отпуск без ведома менеджера. На бумаге визы менеджера не будет — хорошая отвественность менеджера за проект. Или вы им плюшки с чаем разносите ? тогда понятно почему виза не нужна.
О>>Ну в любом случае это как правило поручения которые надо транслировать , в каком тоне они бы не звучали, хоть он там сексом по телефону будет заниматсья.
DB>Опять же... хочешь называть это так — называй... В-принципе, можно сказать, что почти все программисты пишут прокладки между пользователем и процессором/жёстким диском/оперативной памятью. Но не всё так просто.
О>>Хорошо , вот один из специалистов вдруг не появился на работе во время, или ушел сразу после обеда, кто должен ему выговор или замечание сделать ? Откуда этот человек узнает о том что это нужно сделать если у него нет механизма отслеживания прихода/ухода.
DB>Если специалист при этом выдаёт нужный и качественный результат — честь ему и хвала. Если он результат не выдаёт, то какой же это специалист? Он же и под определение специалиста-то не подходит... Да и вообще, что за детский сад с выговороми за ранний уход и опоздания?
Ну я не видел еще компании где можно было бы просто уйти в обед с работы и ничего за это бы небыло. Точнее чтоб никто этого не заметил.
О>>з.п. бывает как выше так и ниже и в среднем не сильно отличается от з.п. специалиста.
DB>Хочешь так думать — думай .
Хочешь думать по другому — покажи вакансию компании где менеджеру платят намного больше спеца.
О>>А вот разобраться почему хрень не работает — это как раз очень интересно. Я например буду больше уважать человека который разобрался с хренью почему она не работает, чем человека который нарисовал сферического коня в вакууме ( план ) или произнес торжественную речь о том какие же все крутые и что у нас куча перспектив.).
DB>Пусть убеждение, что план=сферический конь в вакууме у тебя и останется, у меня нет желания тебя переубеждать. Торжественные речи произносятся крайне редко, думаю, что в нашей компании торжественную речь произносит только ген.директор на новогоднем корпоративе... DB>Про "разобраться почему хрень не работает — это как раз очень интересно" — спорить не буду. Я утверждал только то, что зачастую это бывает очень сложно и напряжённо. Бывает так, что это вытягивает все твои моральные силы, бывает, что после решения такой проблемы наступает полнейшая аппатия... а бывает и так, что после решения не чувствуешь никакого удовлетворения... У менеджера такой работы (сложной и напряжённой) — меньше. Лёгкой и ненапряжённой — больше.
Ну я о том же что если слабо решать сложные задачи и после них возникает аппатия то ничего не остается как идти в грузчики, продавцы, уборщики, официанты, менеджеры где напрягов особо нет. Я не спорю что менеджер не перенапрегается, соотвественно и з.п. меньше и авторитет — зачем тому кто меньше напрягается платить больше.
