Comments 11
Ну да, конечно, если человека заботит не только КАРЬЕРА, то он «разочарован в своей профессии», не может являться ценным сотрудником, и надо от него избавиться или хотя бы переучить, показав настоящие жизненные ценности.
«Все люди хотят иметь власть или возвышаться над кем-то». Это вообще мощно. Вы из своих желаний и стремлений сделали такое обобщение?
Лично мне не хотелось бы работать с менеджером, придерживающимся подобных убеждений.
«Все люди хотят иметь власть или возвышаться над кем-то». Это вообще мощно. Вы из своих желаний и стремлений сделали такое обобщение?
Лично мне не хотелось бы работать с менеджером, придерживающимся подобных убеждений.
Чё-то у нас мухи с котлетами прямо. Я основную мысль так и не уловил. ТС, что мы хотим понять в итоге?
Японцы считают, что если выбирать между средним по способностям, но преданным делу сотрудником, и талантливым, но не преданным делу, то лучше иметь заинтересованного в конечном результате члена команды, чем выгадывающего только свой интерес гения. Просто от него будет большая польза. Дело в том, что идея — это только 10% успеха, а вот 90% — это упорный, скучный, тяжелый труд по ее шлифовке.
Спорный момент для наукоемких областей. Если делать что-то простое, например штамповать типовые сайты или внедрять типовую ERP систему с нуля — да, можно обойтись командой ребят «со средними способностями». Но если разрабатывается что-то новое (мы же про IT говорим?), то часто встают вопросы на гране изученного и за этой гранью. Мой небольшой пятнадцатилетний опыт показывает, что несколько ребят среднего уровня для выяснение вопроса «а почему это на Windows 8 странно работает API, который раньше работал нормально?» может занять неделю и ничего не получится, тогда как один гуру, хорошо разбирающийся в устройстве кернела, системы безопасности и владеющий windbg способен получить ответ за пару часов, существенно облегчив жизнь остальной команде. Про то, что работать надо у порно я согласен — но если в команде нет ни одного чудотворца, то что будет делать такая команда, когда возникнет техническая необходимость в чуде? Чудеса на пустом месте упорным трудом не сделаешь, для их манифестации требуется очень большой опыт, знания и специфический склад ума :(.
Плюс управление рисками. Я в целом согласен с тем, что выбирать технологии и решения надо с минимальными рисками. Но ведь часто деньги платят не за то, чтобы сделать десятый типовой проект по накатанной, а как раз за что-то новое, чего до этого никто не делал. В IT это сплошь да рядом. Вышла Windows 8 — вынь да положь ARM. И никого не беспокоит, что у «середнячка» будут очень большие проблемы портировать унаследованный С++ код с ассемблерными вставками и давно почившими библиотеками.
Что вы по этому поводу скажете?
Хотелось бы почитать доходчивый текст про управление рисками, желательно с примерами… Что посоветуете? Или может, поделитесь?
Если считаете что менеджемент в IT мало отличается от менеджметна «в целом» — почитайте pmbok, там неплохо описаны классические подходы. Сам я так не считаю, и хороших, на мой взгляд, материалов пока не видел. Поделиться — может и поделюсь, когда сам хорошо владеть буду. Я пока только 5 лет разработкой управляю, и мне еще тренироваться и тренироваться :(.
> pmbok
Уж послали, так послали ;) Спасибо, тем не менее.
Хотел услышать про реальный опыт. Может кто-то еще поделится?
Уж послали, так послали ;) Спасибо, тем не менее.
Хотел услышать про реальный опыт. Может кто-то еще поделится?
Only those users with full accounts are able to leave comments. Log in, please.
Level Up в проект менеджменте