Эту дискуссию можно продолжать долго, но проблема в том, что вы иначе представляете себе роль ПМа, чем я. Для меня ПМ — это в первую очередь управляющий. В понимании Друкера, Листера, ДеМарко, Голдратта и пр. (если вы вдруг не читали, то почитайте, может им вы поверите больше, чем неизвестному мне). ПМ — это человек, отвественный в первую очередь за процессы, и имеющий соответствующие навыки и знания (количество поддисциплин здесь огромное). Ни один из этих навыков не связан с написанием кода напрямую.
Предметная область в данном случае — знание процессов и нюансов разработки ПО. Знание ООП совершенно не обязательно, поскольку за техничесие вопросы отвечает Тимлид, а не ПМ. Поскольку вы мне снова не поверите, то здесь для примера сошлюсь на PMBOK, который описывает все области знаний, необходимые ПМу.
По своему опыту считаю, что на практике навыки программирования часто мешают ПМу, поскольку у него есть огромный соблазн диктовать Тимлиду, что и как надо делать. Из-за этого легко возникает скрытый конфликт между ними.
> Это не принципиально другая деятельность, это смещение в сторону от текущей.
ПМ-ство — это принципиально другая деятельность, требующая совершенно других знаний и навыков. Видно, из-за разного понимания деятельности ПМа и сыр бор. Я согласен, что для небольших команд на практике разница не столь заметна, чтобы об этом говорить вслух, но она все же есть, и она принципиальная. Иначе получается, что руководителем человек становится просто за счет опыта в другой области (программировании). Это не так, и никогда не было и не будет по-настоящему успешных руководителей, которые считают, что управление проектами это не отдельная дисциплина, а просто что-то само собой приходящее.
> Как вы себе представляете руководителя ИТ команды, хорошего, который никогда не программировал?
Судя по всему вы не в курсе, что кроме собственно программистов ИТ включает еще ряд смежных профессий. Так вот, они есть и люди из их числа с не меньшим успехом могут стать ПМами.
> Вы думаете программисту или тем более тимлиду менее понятны результаты внедрения методологии, чем руководителю проекта?
Разумеется, руководителю результаты более понятны, потому что это его единственная задача — руководить. А программист в гробу видел все эти методологии, лишь бы дали спокойно работать. Тимлид в зависимости от ситуации может близко к руководителю понимать полный процесс разработки, но от него это опять таки не требуется в такой мере, как от руководителя.
Но даже тимлид остается программистом, главная задача кооторого создавать качественный продукт, а не руководить в полном смысле этого слова. Поэтому от тимлида не требуется тех знаний и просто черт характера, необходимых руководителю. Как следствие, далеко не всякий тимлид может стать хорошим ПМом. А если он все-таки идет в ПМы, то тут-то и начинается обучение с нуля, когда начинаешь смотреть на все под другим углом. И далеко не для всех это безболезненный процесс.
Чтобы руководить ИТ командой нужно понимание предметной области, но это не означает обязательный опыт непосредственно программирования. И даже если он есть, то он ничего не гарантирует.
> И по этому опытных руководителей берут не из неопытных руководителей, а из опытных программистов, или других специалистов, но тоже не менее опытных.
Вы здесь противоречия не видите? Опытный человек в другой области не обязан обладать практическими навыками в разных методологиях. Теоретическими сколько угодно, он мог даже участвовать в проектах, построенных на той или иной методологии и иметь некоторую практику в этом. Но роль руководителя подразумевает понимание не отдельных элементов, а всей методологии в целом. Опытный не-руководитель такого опыта иметь не может в принципе. Поэтому ему жизненно необходимо такой опыт зарабатывать, а другого варианта кроме как применять стандартное решение поначалу у него просто нет.
С четвертым абзацем согласен — методология не панацея и не оправдание провалу.
> Руководителем должен быть опытный человек, который уже порядком насмотрелся на то как делать надо, а как не надо и выработал свое понимание рабочих процессов.
Судя по всему, свои знания он получил с потолка, просто за счет т.н. опыта. То есть когда программист растет и изучает стандартные подходы к разработке — это нормально. А если руководитель начнет делать то же самое, значит он несостоятельный? Откуда же тогда возьмутся опытные руководители, если не будут проходить тот же самый путь СУХАРИ? Как вышестоящий руководитель сможет ему помочь расти? Поделится своим опытом и подчиненный внезапно подрастет?
Для того и нужны стандарты, чтобы на них оттачивать свои умения.
И насчет сравнения с методами сортировки. Разве кому-то удалось обойти безболезненно шаг обучения тривиальным вещам? Разумеется только с их помощью ничего путнего не получится, но в то же время надо уметь ими пользоватся, чтобы не изобретать велосипед каждый раз. А если человек только читал про методологию, но даже не пробовал применять ее на практике, потому что это все равно не сработает, то толку от такого знания? Ну может повыпендриваться на Хабре, рассказывая, что SCRUM это тупой шаблон, и мне гениальному опытному его маловато будет. А когда возникнет реальный проблема и придется искать ее решение, то практического скрамовского опыта ему как раз и не хватит. Возможно, СКРАМ предоставил бы ему технику решения конкретной проблемы, но человек не удосужился ее опробовать раньше или вообще ее не знает. В итоге страдает в первую очередь он сам. Зато у него всегда будет оправдание, что если даже я такой опытный руководитель не справился, то какой-то там СКРАМ и подавно не потянул бы.
Может вначале надо было бы определить, что должно войти в Readme файл, а потом уже призывать заменить им документацию? В процессе определения может выясниться, что это та же самая дока, только собранная в одном файле, и на самом деле мы имеем дело с таким себе спецификационным аналогом универсального метода «сделать все зашибись».
Насколько я понял из комментариев в данном случае менеджер является одновременно менеджером, тим-лидом, бизнес-аналитиком, воспитателем и отцом родным. В вопросе точно имелся ввиду проджект-менеджер? Потому что судя по мнению большей части комментариев речь идет все-таки о тим-лиде, а не менеджере. Ну или о настолько маленькой фирме, что один человек вынужден выполнять все эти роли. Если это именно такой случай, то непонятны претензии программистов, которые требуют от одного человека выполнить роль 10 человек, а если человек не справляется, то называют его плохим менеджером.
Если же вернуться к постановке вопроса, то для меня больше смысла имела бы формулировка о времени потраченном впустую на совещаниях, которые организовывает ПМ. Это более понятная и жизненная проблема.
> Вообще, доказано (и нам на Scrum тренингах демонстрировали), что человек в принципе не умеет оценивать задачи.
Слишком суровое утверждение. Умению оценивать надо учиться и можно выучиться оценивать. У человека есть все необходимые данные, чтобы оценивать с разумной точностью. Доказать обратное попросту невозможно. На тренингах могли демонстрировать сложность оценивания для неподготовленного человека, не больше.
Уже не один десяток лет ведется работа над проблемой оценивания, и существует много методов и техник, успешно применяемых на практике. А вы пишете, что будто бы доказано обратное. Источником информации поделитесь?
А еще целые стопки баянов стоят у большинства на книжных полках. Давайте их выкинем и будем педалить не думая, включая моск только по праздникам :)
А актуальность темы подтверждается количеством каментов.
Введение платных услуг может послужить еще большей популяризации сети.
Ведь запретный (платный) плод всегда сладок. К тому же при наличии толстого кошелька есть возможность повыпендриваться перед знакомыми - типа, я могу себе это позволить, а вы - нет.
Почему в топике "О том, как гипербола помогла придумать новую систему рейтингов" ничего не сказано о том, как гипербола помогла придумать новую систему рейтингов?
Невозможно придумать гиперболу, которая дала бы предлагаемую последовательность чисел (если даже оставить только положительные числа): 1, 1/2, 1/4, ...
Если же рассматривать такие последовательности, то куда полезнее было бы смотреть не на теорию кривых второго порядка, а на теорию рядов.
В данном случае получается 2 ряда с общими элементами ряда вида a_n = 1/(2^n) и b_n = -1/(2^n). Здесь скорее полезно было бы рассмотреть вопрос о сходимости суммы таких рядов.
Дело в том, что свободное время тратится не на поездки не потому, что денег нет, а потому, что есть дом, семья, дети. Отсюда - ремонт, дача, огород и прочее.
Кроме того, как работник в том числе и сферы образования я могу добавить, что свободное время так же тратится на подготовку к новому учебному году, написание лекций, тестов, статей.
В общем у старшего поколения гораздо меньше свободного времени, чем у молодежи.
Я себе с трудом представляю возрастную аудиторию, которой нечем заняться в отпуске. Зато я готов поверить, что именно так думает та самая прогрессивная молодежь, которая не доросла еще до создания семьи и не знает куда потратить свои летние 2 месяца.
Сами создаем страшную жизнь, чтобы потом выглядеть в ней героями.
Только человек, пересмотревшийся голивудских фильмов про крутых героев, может сделать вывод, что сваливать рано. Надо или сваливать или все менять, но разве не очевидно, что ситуация НЕНОРМАЛЬНАЯ?
Идея конечно классная. Я думаю, что в ближайшее время все к этому придет, потому что это естественно. и системы голосования будут иметь несколько параметров.
Другое дело, что в инете реализовывается модель отношений, а не сами отношения. Человеческий фактор смоделировать невозможно. Поэтому единственный выход сделать простую и удобную систему. Нынешняя система френдов простая, но неудобная. Описанная в этом посте - удобная, но не простая. Я уверен, что любое отклонение от бинарного "френд/нефренд", "за/против" грозит скандалами и разборками. Потому, что с оттенками все гораздо сложнее, чем с черно-белой картинкой.
Кому-то обязательно не хватит перечисленных отношений, он захочет новые. Еще один захочет новые. И в итоге придем к тому, что у каждого будут свои отношения, не вписывающиеся в общую картину.
Картину я нарисовал апокалиптическую, и искренне надеюсь, что выход будет найден :)
Предметная область в данном случае — знание процессов и нюансов разработки ПО. Знание ООП совершенно не обязательно, поскольку за техничесие вопросы отвечает Тимлид, а не ПМ. Поскольку вы мне снова не поверите, то здесь для примера сошлюсь на PMBOK, который описывает все области знаний, необходимые ПМу.
По своему опыту считаю, что на практике навыки программирования часто мешают ПМу, поскольку у него есть огромный соблазн диктовать Тимлиду, что и как надо делать. Из-за этого легко возникает скрытый конфликт между ними.
ПМ-ство — это принципиально другая деятельность, требующая совершенно других знаний и навыков. Видно, из-за разного понимания деятельности ПМа и сыр бор. Я согласен, что для небольших команд на практике разница не столь заметна, чтобы об этом говорить вслух, но она все же есть, и она принципиальная. Иначе получается, что руководителем человек становится просто за счет опыта в другой области (программировании). Это не так, и никогда не было и не будет по-настоящему успешных руководителей, которые считают, что управление проектами это не отдельная дисциплина, а просто что-то само собой приходящее.
> Как вы себе представляете руководителя ИТ команды, хорошего, который никогда не программировал?
Судя по всему вы не в курсе, что кроме собственно программистов ИТ включает еще ряд смежных профессий. Так вот, они есть и люди из их числа с не меньшим успехом могут стать ПМами.
И еще вопрос: зачем ПМу знание ООП?
Разумеется, руководителю результаты более понятны, потому что это его единственная задача — руководить. А программист в гробу видел все эти методологии, лишь бы дали спокойно работать. Тимлид в зависимости от ситуации может близко к руководителю понимать полный процесс разработки, но от него это опять таки не требуется в такой мере, как от руководителя.
Но даже тимлид остается программистом, главная задача кооторого создавать качественный продукт, а не руководить в полном смысле этого слова. Поэтому от тимлида не требуется тех знаний и просто черт характера, необходимых руководителю. Как следствие, далеко не всякий тимлид может стать хорошим ПМом. А если он все-таки идет в ПМы, то тут-то и начинается обучение с нуля, когда начинаешь смотреть на все под другим углом. И далеко не для всех это безболезненный процесс.
Чтобы руководить ИТ командой нужно понимание предметной области, но это не означает обязательный опыт непосредственно программирования. И даже если он есть, то он ничего не гарантирует.
Вы здесь противоречия не видите? Опытный человек в другой области не обязан обладать практическими навыками в разных методологиях. Теоретическими сколько угодно, он мог даже участвовать в проектах, построенных на той или иной методологии и иметь некоторую практику в этом. Но роль руководителя подразумевает понимание не отдельных элементов, а всей методологии в целом. Опытный не-руководитель такого опыта иметь не может в принципе. Поэтому ему жизненно необходимо такой опыт зарабатывать, а другого варианта кроме как применять стандартное решение поначалу у него просто нет.
С четвертым абзацем согласен — методология не панацея и не оправдание провалу.
Судя по всему, свои знания он получил с потолка, просто за счет т.н. опыта. То есть когда программист растет и изучает стандартные подходы к разработке — это нормально. А если руководитель начнет делать то же самое, значит он несостоятельный? Откуда же тогда возьмутся опытные руководители, если не будут проходить тот же самый путь СУХАРИ? Как вышестоящий руководитель сможет ему помочь расти? Поделится своим опытом и подчиненный внезапно подрастет?
Для того и нужны стандарты, чтобы на них оттачивать свои умения.
И насчет сравнения с методами сортировки. Разве кому-то удалось обойти безболезненно шаг обучения тривиальным вещам? Разумеется только с их помощью ничего путнего не получится, но в то же время надо уметь ими пользоватся, чтобы не изобретать велосипед каждый раз. А если человек только читал про методологию, но даже не пробовал применять ее на практике, потому что это все равно не сработает, то толку от такого знания? Ну может повыпендриваться на Хабре, рассказывая, что SCRUM это тупой шаблон, и мне
гениальномуопытному его маловато будет. А когда возникнет реальный проблема и придется искать ее решение, то практического скрамовского опыта ему как раз и не хватит. Возможно, СКРАМ предоставил бы ему технику решения конкретной проблемы, но человек не удосужился ее опробовать раньше или вообще ее не знает. В итоге страдает в первую очередь он сам. Зато у него всегда будет оправдание, что если даже я такой опытный руководитель не справился, то какой-то там СКРАМ и подавно не потянул бы.Если же вернуться к постановке вопроса, то для меня больше смысла имела бы формулировка о времени потраченном впустую на совещаниях, которые организовывает ПМ. Это более понятная и жизненная проблема.
Слишком суровое утверждение. Умению оценивать надо учиться и можно выучиться оценивать. У человека есть все необходимые данные, чтобы оценивать с разумной точностью. Доказать обратное попросту невозможно. На тренингах могли демонстрировать сложность оценивания для неподготовленного человека, не больше.
Уже не один десяток лет ведется работа над проблемой оценивания, и существует много методов и техник, успешно применяемых на практике. А вы пишете, что будто бы доказано обратное. Источником информации поделитесь?
А актуальность темы подтверждается количеством каментов.
Ведь запретный (платный) плод всегда сладок. К тому же при наличии толстого кошелька есть возможность повыпендриваться перед знакомыми - типа, я могу себе это позволить, а вы - нет.
Невозможно придумать гиперболу, которая дала бы предлагаемую последовательность чисел (если даже оставить только положительные числа): 1, 1/2, 1/4, ...
Если же рассматривать такие последовательности, то куда полезнее было бы смотреть не на теорию кривых второго порядка, а на теорию рядов.
В данном случае получается 2 ряда с общими элементами ряда вида a_n = 1/(2^n) и b_n = -1/(2^n). Здесь скорее полезно было бы рассмотреть вопрос о сходимости суммы таких рядов.
Кроме того, как работник в том числе и сферы образования я могу добавить, что свободное время так же тратится на подготовку к новому учебному году, написание лекций, тестов, статей.
В общем у старшего поколения гораздо меньше свободного времени, чем у молодежи.
Только человек, пересмотревшийся голивудских фильмов про крутых героев, может сделать вывод, что сваливать рано. Надо или сваливать или все менять, но разве не очевидно, что ситуация НЕНОРМАЛЬНАЯ?
Другое дело, что в инете реализовывается модель отношений, а не сами отношения. Человеческий фактор смоделировать невозможно. Поэтому единственный выход сделать простую и удобную систему. Нынешняя система френдов простая, но неудобная. Описанная в этом посте - удобная, но не простая. Я уверен, что любое отклонение от бинарного "френд/нефренд", "за/против" грозит скандалами и разборками. Потому, что с оттенками все гораздо сложнее, чем с черно-белой картинкой.
Кому-то обязательно не хватит перечисленных отношений, он захочет новые. Еще один захочет новые. И в итоге придем к тому, что у каждого будут свои отношения, не вписывающиеся в общую картину.
Картину я нарисовал апокалиптическую, и искренне надеюсь, что выход будет найден :)