Comments 17
В данных «заблуждениях» просматриваются слёзы надежды…
Сразу видно что те кто высказывал такие опасения либо встречались с «не очень» хорошими командами, и успеха не достигли. Теперь надеются что подобные методы кто-то опробует, а они тем временем посмотрят на успехи. На практике сомневаюсь что хоть кто-то из высказавших проверял или даже желал бы проверить эти мифы на прочность.
Сразу видно что те кто высказывал такие опасения либо встречались с «не очень» хорошими командами, и успеха не достигли. Теперь надеются что подобные методы кто-то опробует, а они тем временем посмотрят на успехи. На практике сомневаюсь что хоть кто-то из высказавших проверял или даже желал бы проверить эти мифы на прочность.
Для самоорганизации (да еще и в нужном направлении) нужно создать и поддерживать определенные условия. Это то, чем и должен заниматься руководитель.
Полностью согласен с тем, что «просто так» само ничего не сделается. Этот тезис поддерживают те, кто либо о руководстве, как знании (менеджменту в отрыве от процесса научиться невозможно, а у нас таких руководителей — пруд пруди), нифига не знают, либо лентяи)
Полностью согласен с тем, что «просто так» само ничего не сделается. Этот тезис поддерживают те, кто либо о руководстве, как знании (менеджменту в отрыве от процесса научиться невозможно, а у нас таких руководителей — пруд пруди), нифига не знают, либо лентяи)
Главное, что нужно понять — Agile методики эффективны только если у вас в команде работают мотивированные, адекватные профессионалы (или покрайней мере стремящиеся стать таковыми). Короче говоря, если люди нормальные — они самоорганизуются и будут работать, иерархия и распределение полномочий построется само собой.
А вот если человек работать не хочет, то он и не будет. Т.е. если проблемы другого рода — у команды нет мотивации работать сверх минимального необходимого объёма работы, чтобы не уволили, либо люди просто неквалифицироны и даже не пытаются — такой команде никакая методология не поможет (за исключением «кнута и пряника» разве что).
А вот если человек работать не хочет, то он и не будет. Т.е. если проблемы другого рода — у команды нет мотивации работать сверх минимального необходимого объёма работы, чтобы не уволили, либо люди просто неквалифицироны и даже не пытаются — такой команде никакая методология не поможет (за исключением «кнута и пряника» разве что).
«А вот если человек работать не хочет, то он и не будет.»
Плавно переходим к мысли что вопрос на собеседовании «Почему вы хотите работать у нас» (и ответ на него) — уже не кажется праздной болтавней)
А так же задаёмся вопросом — что делать и где брать людей, если у нас не яндекс/гугл/мейлрушечка — и вся наша разработка это далеко не rocket science, а просто переливание данных между СУБД и браузером + изучение заблуждений и ошибок тех кто творил это раньше. Предположу что варианта только 1: заманивать взрослых дядей с семьей и ипотекой зарплатой выше рынка + усиливать их джуниорами.
Плавно переходим к мысли что вопрос на собеседовании «Почему вы хотите работать у нас» (и ответ на него) — уже не кажется праздной болтавней)
А так же задаёмся вопросом — что делать и где брать людей, если у нас не яндекс/гугл/мейлрушечка — и вся наша разработка это далеко не rocket science, а просто переливание данных между СУБД и браузером + изучение заблуждений и ошибок тех кто творил это раньше. Предположу что варианта только 1: заманивать взрослых дядей с семьей и ипотекой зарплатой выше рынка + усиливать их джуниорами.
Мне кажется, что в этой статье несколько академично излагается простая мысль о том, что команда (будем понимать под командой группу людей, эффективность которой больше, чем сумма эффективностей её членов) не образуется сама по себе. Она требует кропотливого ухода за собой. Её надо мотивировать, перед ней надо ставить цели, убирать препятствия с её пути, заботиться о её членах и т.п. И без хорошего руководителя не будет команды.
У великих спортивных команд великие тренеры. А вот о самоорганизующейся футбольной команде вряд ли кто слышал.
У великих спортивных команд великие тренеры. А вот о самоорганизующейся футбольной команде вряд ли кто слышал.
Эффектность команды не может быть выше, чем сумма эффективностей ее членов, к сожалению :)
Так и есть. Однако, надо понимать, что группа профессионалов-индивидуалов — не есть команда. Это раз. Развитие команды происходит быстрее, чем индивидуалов по-отдельности. Это два. Проверено собственной практикой.
Может :)
Не хочется углубляться в химию команды разработчиков программ, поэтому попробую привести аналогию.
Один, даже самый здоровый грузчик не дотащит пианино на 10-ый этаж. И двое по схеме: один с 1-го до 5-го, а второй с 5-го по 10-ый, тоже не смогут. А вот двое одновременно на ремнях тащат замечательно. Сам наблюдал. :)
Не хочется углубляться в химию команды разработчиков программ, поэтому попробую привести аналогию.
Один, даже самый здоровый грузчик не дотащит пианино на 10-ый этаж. И двое по схеме: один с 1-го до 5-го, а второй с 5-го по 10-ый, тоже не смогут. А вот двое одновременно на ремнях тащат замечательно. Сам наблюдал. :)
На самом деле причины этого хорошо описаны в книгах «Мифический человеко-месяц» Брукса и «Deadline. Роман об управлении проектами» ДеМарко. Если не знакомы, очень рекомендую к прочтению, особенно последнюю.
Что-то не припомню, чтобы ДеМарко или Брукс спорили с тем, что команда эффективнее группы одиночек. Они, насколько я помню, говорили, что в команде есть потери на коммуникацию. И чем больше команда, тем больше эти потери. Но синергический эффект покрывает эти потери в команде.
Брукс, кстати, отмечает эффект снижения эффективности команды в целом для проекта от её быстрого роста. Добавляя людей в проект, вы только его замедлите. Однако, разумный и управляемый рост вполне допустим и оправдан. Это абсолютно не противоречит тому, что пишет Эстер.
Могу вам напомнить :) В дедлайте этому посвящена, в частности, глава 12.
— Предположим, что команда из десяти человек может разработать за год приложение величиной в тысячу единиц (каких единиц, я пока не знаю, их еще не изобрели, но пусть это будут некие условные единицы). Так вот, если десять человек за год вырабатывают тысячу единиц, то сколько единиц сделает за полгода команда из двадцати человек, предположительно такой же квалификации?
— Меньше, чем тысячу.
— А насколько меньше?
— Намного!
— Намного — это на сколько?
— Очень много.
…
— Иными словами, «чистая производительность» четырех человек, работающих в одной команде, будет приблизительно на треть меньше, чем «производительная мощность» человека, работающего над проектом в одиночку, помноженная на четыре?
Мистер Томпкинс пожал плечами.
— Разумеется, я не могу говорить с полной уверенностью, но мне кажется, так оно и есть.
ну и дальше в том же духе.
— Предположим, что команда из десяти человек может разработать за год приложение величиной в тысячу единиц (каких единиц, я пока не знаю, их еще не изобрели, но пусть это будут некие условные единицы). Так вот, если десять человек за год вырабатывают тысячу единиц, то сколько единиц сделает за полгода команда из двадцати человек, предположительно такой же квалификации?
— Меньше, чем тысячу.
— А насколько меньше?
— Намного!
— Намного — это на сколько?
— Очень много.
…
— Иными словами, «чистая производительность» четырех человек, работающих в одной команде, будет приблизительно на треть меньше, чем «производительная мощность» человека, работающего над проектом в одиночку, помноженная на четыре?
Мистер Томпкинс пожал плечами.
— Разумеется, я не могу говорить с полной уверенностью, но мне кажется, так оно и есть.
ну и дальше в том же духе.
Абсолютно согласен. Человек оцениват команду, а не Команду из моего определения. Для абстракных людей я бы так же оценивал. Тут лучше перебдеть, чем недобдеть. :)
И потом, я ж не говорю, что Команды часто встречаются. Может в IT-сфере и существуют такие из 20-ти человек, но мне не попадались. Обычно людей в них немного.
P.S. Спасибо за цитату. Я эту книжку когда-то на английском читал, русский вариант не видел.
И потом, я ж не говорю, что Команды часто встречаются. Может в IT-сфере и существуют такие из 20-ти человек, но мне не попадались. Обычно людей в них немного.
P.S. Спасибо за цитату. Я эту книжку когда-то на английском читал, русский вариант не видел.
Внесу некоторое уточнение: затронутая вами тема это не одна тема, а сразу две темы (причем две темы разной природы):
Первая тема — это мотивация сотрудника работающего в комманде/в проекте.
А вторая тема — взаимодействие комманды с проектом над которым работает эта комманда.
Поэтому, если увидеть один раз что это две разных темы и два разных вопроса, разбираться (причем разбираться не в теории а в реальной практической жизни) с этими «заблуждениями» будет намного легче.
Почему я выделил отдельным вопросом взаимодействие проекта и комманды в виде отдельного вопроса? Очень просто: если мы посмотрим «истории успеха» когда «все само собой самоорганизовывалось», то мы увидим, что большинство из них «самоорганизовывалось» по одному из двух сценариев:
* Сценарий первый: Интересный проект сам собирает и выкристализовывает вокруг себя заинтересованную сильную комманду профессионалов.
* Сценарий второй: Сильная комманда талантливых профессионалов сама начинает кристализовать и реализовывать интересные проекты.
Отсюда вопрос: когда мы рассматриваем вполне конкретный случай, у нас какой из сценариев взаимодействия комманда<->проект? — первый или второй? если не первый и не второй, то какие еще вопросы?
Но, несмотря на все вышеописанное при этом «мотивация сотрудника» существует в отдельной плоскости, которая проекцируется на плоскость «взаимодействие комманды и проекта». Это выражается так: каждый индивидуально рассмотренный сотрудник имеет свою мотивацию как по отношению к комманде так и по отношению к проекту. И вот тут-то как раз использованные методики управления проектом и работы с сотрудником могут оказать существенное влияние: любой, даже замечательный проект к которому привлечены талантливейшие люди можно легко загубить «комсомольско-армейскими» методами project managementа, так и тонкая работа с мотивацией способна помочь раскрыться таланту даже у многих самых «невзрачненьких» сотрудников работающих над заурядным проектом.
Первая тема — это мотивация сотрудника работающего в комманде/в проекте.
А вторая тема — взаимодействие комманды с проектом над которым работает эта комманда.
Поэтому, если увидеть один раз что это две разных темы и два разных вопроса, разбираться (причем разбираться не в теории а в реальной практической жизни) с этими «заблуждениями» будет намного легче.
Почему я выделил отдельным вопросом взаимодействие проекта и комманды в виде отдельного вопроса? Очень просто: если мы посмотрим «истории успеха» когда «все само собой самоорганизовывалось», то мы увидим, что большинство из них «самоорганизовывалось» по одному из двух сценариев:
* Сценарий первый: Интересный проект сам собирает и выкристализовывает вокруг себя заинтересованную сильную комманду профессионалов.
* Сценарий второй: Сильная комманда талантливых профессионалов сама начинает кристализовать и реализовывать интересные проекты.
Отсюда вопрос: когда мы рассматриваем вполне конкретный случай, у нас какой из сценариев взаимодействия комманда<->проект? — первый или второй? если не первый и не второй, то какие еще вопросы?
Но, несмотря на все вышеописанное при этом «мотивация сотрудника» существует в отдельной плоскости, которая проекцируется на плоскость «взаимодействие комманды и проекта». Это выражается так: каждый индивидуально рассмотренный сотрудник имеет свою мотивацию как по отношению к комманде так и по отношению к проекту. И вот тут-то как раз использованные методики управления проектом и работы с сотрудником могут оказать существенное влияние: любой, даже замечательный проект к которому привлечены талантливейшие люди можно легко загубить «комсомольско-армейскими» методами project managementа, так и тонкая работа с мотивацией способна помочь раскрыться таланту даже у многих самых «невзрачненьких» сотрудников работающих над заурядным проектом.
«Вы не можете просто так взять и дать волю людям, и предоставитьи команде всё решать самой. Они же всё испортят! Да, и к тому же, все эти Scrum-мастера, тренеры и самоорганизующиеся команды похоже могут оставить меня без работы»
Непонятно данное уважение. В agile существует product owner который формирует product backlog и расставляет приоритеты. Команда же решает, как эту функциональность реализовать.
Непонятно данное уважение. В agile существует product owner который формирует product backlog и расставляет приоритеты. Команда же решает, как эту функциональность реализовать.
Sign up to leave a comment.
Заблуждения о самоорганизующихся командах