Comments 56
Под данной статьёй хочется написать только
«Да, это так!»
«Спасибо кэп»
«А что, бывает иначе?»
В общем всё «как в книжке написано»
«Да, это так!»
«Спасибо кэп»
«А что, бывает иначе?»
В общем всё «как в книжке написано»
Спасибо, кэп :) А что за книжка, кстати?
Скажу ещё, что когда команда вырастает из 3х до 120 человек, то становится ещё веселее :):):)
но никогда не надо забывать, про светлую сторону… надо оставаться человеком. Хотя это часто может вредить работе и бизнесу.
но никогда не надо забывать, про светлую сторону… надо оставаться человеком. Хотя это часто может вредить работе и бизнесу.
Когда команда 120 человек — появляются те самые ПМы, которые (в идеале) на светлой стороне, поэтому работа идёт именно с ними (а у них — карма такая, чтобы на них бизнес наезжал).
Конечно появляются. Нельзя допускать саморегулирующейся системы. Даже с 3-мя программистами. С 10 тем более.
Я как-то отчитал мини лекцию про кадры и процессы в стартапах вот тут sp-ic.ru/program/details.php?ID=955 там презентаха есть. Хорошо тогда поговорили про горизонтальные масштабирование и про стороны силы :). И кстати по поводу ПМов — очень большая разница между продуктовой и сервисной конторой — там ПМы разные люди.А ведь есть ещё акканут-Манагеры :). Вот те люди, которые должны вершить добро любой ценой :)
Я как-то отчитал мини лекцию про кадры и процессы в стартапах вот тут sp-ic.ru/program/details.php?ID=955 там презентаха есть. Хорошо тогда поговорили про горизонтальные масштабирование и про стороны силы :). И кстати по поводу ПМов — очень большая разница между продуктовой и сервисной конторой — там ПМы разные люди.А ведь есть ещё акканут-Манагеры :). Вот те люди, которые должны вершить добро любой ценой :)
Слайды не скачиваются :( — требует авторизации
Про то, что не бывает «саморегулирующейся системы», согласен на 146%.
А вот насчёт разных ПМов (если, конечно, имеется в виду именно руководитель проекта, который отвечает за бюджет, сроки и скоуп) не соглашусь. Функции одни и те же, на самом деле. Другое дело, если на ПМа «взвалить» ещё управление продуктами (а то и маркетинг) — вот тогда — да. Есть разница.
Про то, что не бывает «саморегулирующейся системы», согласен на 146%.
А вот насчёт разных ПМов (если, конечно, имеется в виду именно руководитель проекта, который отвечает за бюджет, сроки и скоуп) не соглашусь. Функции одни и те же, на самом деле. Другое дело, если на ПМа «взвалить» ещё управление продуктами (а то и маркетинг) — вот тогда — да. Есть разница.
Извините что влажу в беседу. Я периодически наблюдаю на этом ресурсе как люди делятся на два лагеря: первые, которые себя считают просветленными и пропагандируют Agile методологии разработки (назовем их «авантюристами») и вторые, которые придерживаются консервативных методов построения команд и управления ими (назовем их «консерваторами»). Первые про вторых знают, потому что скорее всего были ими раньше. Вторые первых упорно не замечают :-) Себя отношу скорее к первым, но смотрю открыто и в сторону консервативных методик. Вот тут (в этом треде) похоже собрались в основном «консерваторы». Поэтому мне хочется позадовать вопросов:
1) Вот вы говорите что саморегулирующихся систем не бывает (кто то выше более категорично пишет что этого нельзя допускать). Мой личный опыт построения компании (маленькой пока) говорит об обратном. Опыт полученный от знакомства с некоторыми компаниями в Штатах тоже говорит об обратном. Я смею утверждать что небольшим группам (до 5-7 человек) программистов может быть не нужен ПМ в классическом его понимании. При соответствующей квалификации сотрудников и мотивации они сами прекрасно справляются. Скрам мастер нужен, да. Не могли бы Вы на каких то примерах обосновать свои заявления, а то звучит как догма.
2) Как вы считаете, насколько пагубно влияет на разработчика наличие дополнительной прокладки в виде ПМа, который к нему приставлен для того чтобы его контролировать, ставить ему задачи, отвечать за его результаты, выяснять интересующие его вопросы у заказчика. (Мы ведь хотим в видеть в разработчике личность, инженера, человека высокоинтеллектуальной профессии. А не серую личность в противогазе, которую можно легко заменить на другую). Если пагубно, то как уменьшить это влияние?
3) Какой оптимальный размер команды которой может управлять один ПМ?
Прошу не искать в моих вопросах сарказма и троллинга, действительно интересно узнать Ваше мнение.
Спасибо.
1) Вот вы говорите что саморегулирующихся систем не бывает (кто то выше более категорично пишет что этого нельзя допускать). Мой личный опыт построения компании (маленькой пока) говорит об обратном. Опыт полученный от знакомства с некоторыми компаниями в Штатах тоже говорит об обратном. Я смею утверждать что небольшим группам (до 5-7 человек) программистов может быть не нужен ПМ в классическом его понимании. При соответствующей квалификации сотрудников и мотивации они сами прекрасно справляются. Скрам мастер нужен, да. Не могли бы Вы на каких то примерах обосновать свои заявления, а то звучит как догма.
2) Как вы считаете, насколько пагубно влияет на разработчика наличие дополнительной прокладки в виде ПМа, который к нему приставлен для того чтобы его контролировать, ставить ему задачи, отвечать за его результаты, выяснять интересующие его вопросы у заказчика. (Мы ведь хотим в видеть в разработчике личность, инженера, человека высокоинтеллектуальной профессии. А не серую личность в противогазе, которую можно легко заменить на другую). Если пагубно, то как уменьшить это влияние?
3) Какой оптимальный размер команды которой может управлять один ПМ?
Прошу не искать в моих вопросах сарказма и троллинга, действительно интересно узнать Ваше мнение.
Спасибо.
Вопрос вполне понятен. Честно сказать — ожидал его гораздо раньше :). Очень надеюсь, что доля троллинга тут всё-таки есть, иначе, если вы всё это пишете на полном серьёзе, то мы вряд ли договоримся до чего-то конструктивного ;). Но я попробую всё-таки.
1) Саморегулирующихся систем действительно не бывает, ибо энтропия, как известно, в замкнутой системе не убывает. Другой вопрос в том, что в основу регулирования системы может быть положена либо личность (в плохом случае) либо процесс (в хорошем). Я как раз на эту тему написал постскриптум. Т.е. не команда сама по себе организуется (второй закон термодинамики нам это не позволит), а команда организуется с помощью процесса, который пришёл извне и поддерживается силами отдельных личностей (в идеале — всех её членов).
Скрам, как и любой другой аджайл или не-аджайл процесс этому способствует. Например, ежедневные стэндапы есть ни что иное, как регулирование системы.
В частности, скрам-мастер это именно тот, кто блокирует «наезды» со стороны бизнеса, который представляет product owner. Чтобы лучше понять, о чём моя статья, представьте, что product owner и скрам-мастер — одно и то же лицо.
Привожу пример, как вы и просили: Человек собирает 5 программистов и говорит: «сделайте вот эти фичи за два месяца». Как вы думаете, что будет через эти два месяца? Какова вероятность, что они «самосрегулируются» и продукт будет сделан?
2) Вопрос изначально некорректен. Я в ответ могу (конечно, не всерьёз, а для примера) задать вопрос: «как вы думаете, насколько начинает лениться и делать фигню команда при отсутствии руководителя и контроля, при этом прикрываясь непонятным для всех словом „скрам“, о котором не имеют ни малейшего понятия? ;)
А что будет, если все 100 программистов будут выяснять детали у заказчика напрямую?
Сразу разъясню, что задал эти два вопроса в шутку. Всё зависит от процессов и качеств самого ПМа. Если ПМ — дебил, то это не исправить. Впрочем, в случае, если это скрам-мастер или product owner, тоже.
Если ПМ грамотный и процесс соответствует, то практически никаких проблем нет. Тут могу поставить на кон свой опыт разработки, как программистом, так и ПМом. Почитайте статью, на которую я дал ссылку в самом начале поста.
3) Психологи говорят, что 7+-2. Не вижу поводов с ними не согласиться. Если команда больше, то нужно строить иерархию. Если меньше, то можно вести несколько.
Надеюсь, что ответил на ваши вопросы.
1) Саморегулирующихся систем действительно не бывает, ибо энтропия, как известно, в замкнутой системе не убывает. Другой вопрос в том, что в основу регулирования системы может быть положена либо личность (в плохом случае) либо процесс (в хорошем). Я как раз на эту тему написал постскриптум. Т.е. не команда сама по себе организуется (второй закон термодинамики нам это не позволит), а команда организуется с помощью процесса, который пришёл извне и поддерживается силами отдельных личностей (в идеале — всех её членов).
Скрам, как и любой другой аджайл или не-аджайл процесс этому способствует. Например, ежедневные стэндапы есть ни что иное, как регулирование системы.
В частности, скрам-мастер это именно тот, кто блокирует «наезды» со стороны бизнеса, который представляет product owner. Чтобы лучше понять, о чём моя статья, представьте, что product owner и скрам-мастер — одно и то же лицо.
Привожу пример, как вы и просили: Человек собирает 5 программистов и говорит: «сделайте вот эти фичи за два месяца». Как вы думаете, что будет через эти два месяца? Какова вероятность, что они «самосрегулируются» и продукт будет сделан?
2) Вопрос изначально некорректен. Я в ответ могу (конечно, не всерьёз, а для примера) задать вопрос: «как вы думаете, насколько начинает лениться и делать фигню команда при отсутствии руководителя и контроля, при этом прикрываясь непонятным для всех словом „скрам“, о котором не имеют ни малейшего понятия? ;)
А что будет, если все 100 программистов будут выяснять детали у заказчика напрямую?
Сразу разъясню, что задал эти два вопроса в шутку. Всё зависит от процессов и качеств самого ПМа. Если ПМ — дебил, то это не исправить. Впрочем, в случае, если это скрам-мастер или product owner, тоже.
Если ПМ грамотный и процесс соответствует, то практически никаких проблем нет. Тут могу поставить на кон свой опыт разработки, как программистом, так и ПМом. Почитайте статью, на которую я дал ссылку в самом начале поста.
3) Психологи говорят, что 7+-2. Не вижу поводов с ними не согласиться. Если команда больше, то нужно строить иерархию. Если меньше, то можно вести несколько.
Надеюсь, что ответил на ваши вопросы.
> Саморегулирующихся систем действительно не бывает, ибо энтропия, как известно, в замкнутой системе не убывает
Вы не учитываете что энтропия складывается из нескольких составляющих (энтропия команды + энтропия результата их работы). Вот здесь об этом подробно рассказывается: www.slideshare.net/biBIGine/geeks-vs-managers-part-2
Вы не учитываете что энтропия складывается из нескольких составляющих (энтропия команды + энтропия результата их работы). Вот здесь об этом подробно рассказывается: www.slideshare.net/biBIGine/geeks-vs-managers-part-2
Ну вообще-то я писал достаточно серьезно. Мой опыт показывает что тот ПМ про которого вы пишете в статье не всегда нужен. На мой взгляд нельзя все под одну гребенку. Выбор процесса зависит от следующего (все три пункта сильно связаны):
— проекта/продукта: есть баланс между рисками и сроками/качеством. Можно построить такую команду которая сделает что-то быстро и качественно и будет при этом увлечена и счастлива. _Такую_ команду ПМ будет сдерживать и она не раскроет своего потенциала. Есть конечно риски что не сработает :-) и они достаточно велики.
— заказчика (продолжение первого пункта): заказчик сам по себе может быть такой что с ним проще работать по Agile методологии. Ну все ведь на людях основано, а заказчик не последний человек. Ему лично по каким то причинам может подходить одна или другая методология. Его связь с компанией тоже немаловажна. Наличие контрактных обязательств не способствует Agile методологиям. Соответственно, что-то хорошее не сделаешь, только посредственное (немного троллинга, ок :-)).
— кадров/компании: ну конечно все как всегда упирается в кадры. Кого вы можете привлечь и замотивировать. Компания в которой они при этом работают играет не последнюю роль. Широко ведь известно что есть 20% людей которые делают 80% работы. Вот таких звезд и надо стремиться найти. Им не нужны ПМы. Но они способны сделать что-то реально выдающееся. Другое дело что некоторым компаниям это не нужно.
Скрам — это методология (не сказать что я его сильно люблю, кстати) который позволяет создать самоорганизующуюся команду. Процесс естественно есть, это не хаос (хотя легко может им стать) Люди чувствуют больше ответственности, им дают больше свободы. Процесс регулируется скрам мастером. Как вы и пишете. С чем не согласен, так это с тем что вы наделяете скрам мастера ПМскими полномочиями. Это скорее равноправный член команды, у него нет дополнительной власти. За спринт отвечает вся команда, а не скрам мастер.
То, что продукт овнеру вредно быть скрам мастером (про то что вы собственно пишете в статье) я полностью согласен.
Прочитал вашу статью по ссылке. Вы все верно пишете. К сожалению, местами то что считается на западе нормой (уважение к личности, индивидуализм) у нас только начинает проявляться. Единственное с чем не согласен, так это с тем что Вы ставите ПМа на какую то более верхнюю ступеньку развития. Во всем мире это считается бумажной работой, чаще скучной, у нас же это такой микро-бог которому принадлежит команда. Не думаю что программисту приятно так работать (хотя если он другого не видел....)
Спасибо за дискуссию. Увидел что Вы из Барнаула. Соседи выходит. Будете в Новосибирске заходите пообщаться в реале.
— проекта/продукта: есть баланс между рисками и сроками/качеством. Можно построить такую команду которая сделает что-то быстро и качественно и будет при этом увлечена и счастлива. _Такую_ команду ПМ будет сдерживать и она не раскроет своего потенциала. Есть конечно риски что не сработает :-) и они достаточно велики.
— заказчика (продолжение первого пункта): заказчик сам по себе может быть такой что с ним проще работать по Agile методологии. Ну все ведь на людях основано, а заказчик не последний человек. Ему лично по каким то причинам может подходить одна или другая методология. Его связь с компанией тоже немаловажна. Наличие контрактных обязательств не способствует Agile методологиям. Соответственно, что-то хорошее не сделаешь, только посредственное (немного троллинга, ок :-)).
— кадров/компании: ну конечно все как всегда упирается в кадры. Кого вы можете привлечь и замотивировать. Компания в которой они при этом работают играет не последнюю роль. Широко ведь известно что есть 20% людей которые делают 80% работы. Вот таких звезд и надо стремиться найти. Им не нужны ПМы. Но они способны сделать что-то реально выдающееся. Другое дело что некоторым компаниям это не нужно.
Скрам — это методология (не сказать что я его сильно люблю, кстати) который позволяет создать самоорганизующуюся команду. Процесс естественно есть, это не хаос (хотя легко может им стать) Люди чувствуют больше ответственности, им дают больше свободы. Процесс регулируется скрам мастером. Как вы и пишете. С чем не согласен, так это с тем что вы наделяете скрам мастера ПМскими полномочиями. Это скорее равноправный член команды, у него нет дополнительной власти. За спринт отвечает вся команда, а не скрам мастер.
То, что продукт овнеру вредно быть скрам мастером (про то что вы собственно пишете в статье) я полностью согласен.
Прочитал вашу статью по ссылке. Вы все верно пишете. К сожалению, местами то что считается на западе нормой (уважение к личности, индивидуализм) у нас только начинает проявляться. Единственное с чем не согласен, так это с тем что Вы ставите ПМа на какую то более верхнюю ступеньку развития. Во всем мире это считается бумажной работой, чаще скучной, у нас же это такой микро-бог которому принадлежит команда. Не думаю что программисту приятно так работать (хотя если он другого не видел....)
Спасибо за дискуссию. Увидел что Вы из Барнаула. Соседи выходит. Будете в Новосибирске заходите пообщаться в реале.
Вообще, ПМ — не «более высокая ступенька развития». ПМ — это человек, который берёт ответственность за проект, за команду и за нормальное отношение с заказчиком (если нет аккаунта). Поэтому его задача не только «попасть в треугольник проекта», но и сделать так, чтобы при этом все остались довольны. И, заметьте, в случае фэйла, крайним будет (и должен быть) руководитель проекта, а не команда.
Всё-таки на мой взгляд, в проекте главное — команда, и ПМы, которые считают свою работу бумажной, не до конца понимают смысл своей работы. Отличный пост есть у Джоэля Спольски — я ссылку уже кидал ниже.
Всё-таки на мой взгляд, в проекте главное — команда, и ПМы, которые считают свою работу бумажной, не до конца понимают смысл своей работы. Отличный пост есть у Джоэля Спольски — я ссылку уже кидал ниже.
А что по вашему должно произойти в случае фейла? кого то выпороть должны? Мне кажется все участники должны провести анализ неудачи и должны сделать выводы для себя. Для этого в скраме есть такое понятие как Retrospecive Meeting.
А если ПМа выпорют, то что будет. Он сделает для себя выводы, пойдет к обезьянкам разработчикам и научит как им надо теперь жить?
Ну и вообще наверное неправильно затачивать процесс и структуру компании на фейлы :-)
Спасибо за ссылку на пост Джоела. Но в этом посте я увидел свою точку зрения а не Вашу :-) Возможно я зря назвал эту работу бумажной, чем сбил с толку неправильными ассоциациями. Я имел ввиду ровно то о чем пишет Джоел — команда является одним целым, нет специального выделенного человека ответственного за все, решающего за всех и т.д. Есть некоторые административные функции которые нужны для поддержания процесса, их в случае Скрама выполняет скрам мастер.
А если ПМа выпорют, то что будет. Он сделает для себя выводы, пойдет к обезьянкам разработчикам и научит как им надо теперь жить?
Ну и вообще наверное неправильно затачивать процесс и структуру компании на фейлы :-)
Спасибо за ссылку на пост Джоела. Но в этом посте я увидел свою точку зрения а не Вашу :-) Возможно я зря назвал эту работу бумажной, чем сбил с толку неправильными ассоциациями. Я имел ввиду ровно то о чем пишет Джоел — команда является одним целым, нет специального выделенного человека ответственного за все, решающего за всех и т.д. Есть некоторые административные функции которые нужны для поддержания процесса, их в случае Скрама выполняет скрам мастер.
>Нельзя допускать саморегулирующейся системы
Хаха. Забавное замечание. Отрегулируйте пожалуйста весь земной шар.
Хаха. Забавное замечание. Отрегулируйте пожалуйста весь земной шар.
Бывает так, что щит плодит… не особо защищает и перевирает требования, в общем.
Не всем программистам нужна защита, чего (лично мне) не хватает — это корректной частой конструктивной обратной связи от менеджера.
Не всем программистам нужна защита, чего (лично мне) не хватает — это корректной частой конструктивной обратной связи от менеджера.
Тогда это не щит, а шит ;). А, что касается обратной связи — спросить нет возможности?
Если ты руководишь разработчиками — ты проджект-менеджер, а не продакт. Это разные вещи. Более того, тимлид — это такой же программист, как и остальные ребята в команде, он не является менеджером, и полагаться на него в роли проджект-менеджера бессмысленно и беспощадно.
В продуктовой команде по части разработки структура такая: продакт→проджект→команда разработки. Иначе грешно!
В продуктовой команде по части разработки структура такая: продакт→проджект→команда разработки. Иначе грешно!
Правильнее так: «Тёмная сторона Силы. Почему в продуктовой корзине должен быть руководитель проекта»
Как вывод из вашей статьи я бы даже сказал так: программистам для КОМФОРТНОЙ работы нужен защитник. Только продукт в этом случае будет на втором месте и велика вероятность, что он будет посредственным.
Вся проблема в том, что мы пытаемся раздавать места. Этому — первое, тому — второе… Продукт и команда вещи настолько же независимые, насколько и связанные. У плохой команды не получится хороший продукт. У хорошей команды хороший продукт тоже не обязательно получится, но шансов больше. Есть хорошая статья Джоэля Спольски о менеджерах. Я ему верю и считаю очень крутым профессионалом.
+миллиард
В общем-то нет прямой связи между комфортом разработчиков и качеством продукта на выходе. Слишком много иных факторов.
Дык а что именно защитник должен делать? Как-то скомкан конец, вывод не понятен. Если Вы, как новообразованный ПМ, видите требования бизнеса, и Ваша задача — с помощью команды их удовлетворить, что именно Вы должны делать, чтобы оставаться на светлой стороне? Что фактически это значит, «быть щитом»?
UFO just landed and posted this here
Для вас новость, что в каждой профессии свой жаргон?
UFO just landed and posted this here
Не нравится, не употребляйте. Но не надо пытаться всем навязать свою точку зрения. Вас же не заставляют использовать эти слова. Язык необходим людям для того, чтобы передавать информацию друг другу. И не важно как они его используют, главное что собеседники понимают друг друга. К примеру у нас в компании, в процессе тестирования встречались просто феерические фразы между разработчиками и тестерами, аля:
— «Вася, оно всосало одно, а высосало другое!»
— «Лёха, оно подвисло нестандартным образом, вскрывать будешь?»
— «Кора только что выпленулась, свеженькая, кто хочет осязать?»
При этом процесс работы идёт эффективно и все всё понимают в контексте ситуации.
— «Вася, оно всосало одно, а высосало другое!»
— «Лёха, оно подвисло нестандартным образом, вскрывать будешь?»
— «Кора только что выпленулась, свеженькая, кто хочет осязать?»
При этом процесс работы идёт эффективно и все всё понимают в контексте ситуации.
Для «Тимлида» действительно нет хорошей и главное всем понятной аналогии в русском языке. Бригадир наверное ближе всего по смыслу, но не в IT.
Если я ошибаюсь — с удовольствием возьму на вооружение ваш вариант
Если я ошибаюсь — с удовольствием возьму на вооружение ваш вариант
UFO just landed and posted this here
Не совсем. Это Senior Developer. Это не руководитель — просто опытный квалифицированный разработчик. Тимлид — это руководитель. Причем, в отличие от Руководителя проекта, тимлид должен иметь и большой опыт и лидерские качества.
UFO just landed and posted this here
Дык «лидер», «лидер команды» же, не?
Автор прав, но он должен понимать, что чем крупнее ты, как руководитель, тем больше у тебя людей и обязанностей по их подготовке, и тем меньше у тебя непосредственно задач от команды.
Вам надо выбрать кем вы хотите быть: Team leader'ом или Project owner'ом. Эффективно оставаться обоими одновернеменно невозможно, без потерь для производственного процесса.
Вам надо выбрать кем вы хотите быть: Team leader'ом или Project owner'ом. Эффективно оставаться обоими одновернеменно невозможно, без потерь для производственного процесса.
Хороший руководитель должен прежде всего контролировать свои эмоции.
Вы можете орать на подчиненных так чтобы лопались стекла — но с четко определенным расчетом и целью.
Вы можете рассказывать смешные анекдоты, и быть своим рубахой-парнем, когда надо.
Вы можете изображать горькое разочарование, пускать слезу, вызывая в подчиненных острый комплекс вины и желание все срочно исправить
Вы можете быть для сових подчиненных злым Дартом Вейдером или добрым Оби Ваном, но внутри должны оставаться рациональным, расчетливым и холоднокровным, как труп. В этом настоящее искусство руководителя.
Вы можете орать на подчиненных так чтобы лопались стекла — но с четко определенным расчетом и целью.
Вы можете рассказывать смешные анекдоты, и быть своим рубахой-парнем, когда надо.
Вы можете изображать горькое разочарование, пускать слезу, вызывая в подчиненных острый комплекс вины и желание все срочно исправить
Вы можете быть для сових подчиненных злым Дартом Вейдером или добрым Оби Ваном, но внутри должны оставаться рациональным, расчетливым и холоднокровным, как труп. В этом настоящее искусство руководителя.
Просто во второй команде, быть может, вас не принимали за своего. Или вы на 100% не доверяли им. Не надо сбрасывать со счетов личностные отношения. Да и вы можете смотреть в разные стороны — классическая басня про «лебедя, рака и щуку».
Вся проблема в том, что товарищ с ником Tomcat стал руководить проектом на .NET
>> Поэтому, если программисты работают с бизнесом напрямую и получают задачи прямо оттуда, они остаются без щита и получают непрерывный заряд демотивации.
Истина!
Истина!
В софтверной компании не должно быть ПиЭмов. Если они есть — компания так себе. Конечно, отсутствие пиэмов не говорит об обратном.
Sign up to leave a comment.
Тёмная сторона Силы. Почему в продуктовой команде должен быть руководитель проекта