Комментарии 10
Попытки построить процесс разработки по классической схеме с использованием гибких методологий обычно терпят фиаско, и видя это многие руководители проектов в угоду своих “мегацелей” или просто автоматически следуя основополагающему принципу “разделяй и властвуй” отказываются от применения современных знаний управления проектами на практике.«Обычно терпят фиаско» — это эмоции или выводы на основе даты?
Если вывод на основе даты — то дайте дату пощупать?
руководители проектов в угоду своих «бездатная причина 1» или просто «бездатная прична 2» отказываются от применения современных знаний управления проектами на практикебезотносительно причин, опять возникает вопрос — о руководителях каких проектов говорит автор? Это выборка? Или экстраполяция личного опыта?
По одноранговым/самоорганизующимся командам, хочу выразить собственное мнение — это не система. Нету повторяемости и масштабируемости. Каждая команда это уникальное сочетание качеств и недостатков.
Самосознание данной социальной единицы не является устойчивым (мотивация к качественному результату команды в целом). Коллективная ответственность воспринимается человеком как менее значащая, чем персональная. А текучка в персонале членов команды сводит ее на 0.
Даже у сверхорганизованных, сверхмотивированных олимпийских чемпионов есть люди, которые их толкают (тренеры).
В любой команде (группе человек) рано или поздно выявляется лидер.
Даже если он официально не назначен, он уже выполняет эти функции когда просто высказывается без цели что-то менять.
Не каждый лидер становиться руководителем потому, что очень часто лидерами становятся те кто ни с кем не имеет конфликтов. Отсутствие конфликтов это или стратегия поведения(договорная) или результат отсутствия потребности с кем то пересекаться в интересах (индивидуалисты, самодостаточные сотрудники). При этом социальное лидерство не гарантирует наличие способностей привести команду к успеху. В отсутствии назначенного руководителя лидерство может поделиться на две и более группы и привести к нерегламентированным отношениям, негативно сказывающимся на результате команды.
Цитата… Я не цепляюсь к конкретным словам, я прочел статью и понял, что это основная мысль если что поправьте.
> это решит? Если никто не возьмется делать такую задачу, за кем слово?
Хорошо бы иметь конкретный пример того, что такое непопулярная задача, а то ведь то, что не интересно одному — очень нравится другому. И в конечном итоге все сводится к грамотному подбору кадров.
> По одноранговым/самоорганизующимся командам, хочу выразить собственное мнение —
это
> не система. Нету повторяемости и масштабируемости. Каждая команда это уникальное
> сочетание качеств и недостатков.
Именно. Но и не только каждая комманда, а каждая комманда в определенный временной промежуток (т.к. изменение состава комманды или условий работы — требует подстройки всей остальной системы). Но возраженние будет справедливо и для классических не гибких процессов на уровне индивидуальных исполнителей. Люди — не машины, как бы кому-то не хотелось.
> Коллективная ответственность воспринимается человеком как менее значащая, чем
> персональная.
Потому ответственность в гибких методологиях и не коллективная на уровне отдельных задач.
Никакие социальные штуки для самоорганизующихся комманд не чужды, а вот зато требования к персоналу (а значит и к отбору оного) значительно выше.
ну не популярной задачей я бы назвал рутиную работу по типу заполнить базу, набить параметры.
вы может сами назвать то что не нравиться делать Вам и таких как вы в команде может быть… все.
подбор персонала должен как раз выполнять руководитель, который знает каких у него уже достаточно.
в целом я не верю, что все задачи разберут с одинаковым удовольствием.
уникальность команды наверное может быть и плюсом если проект не масштабируется, к сожалению я с такими задачами не работаю и не могу указать на эти плюсы, но минусы в крупных проектах очевидны из-за зоопарка подходов в таких командах при сведении в общее решение.
«социальные штуки» действительно не нужны там где не предполагается общения между людьми.
если вы работаете в одном помещении и у вас есть возможность влиять на климат, то конфликты предсказуемы.
различающаяся загрузка между членами команды также может стать причиной общения.
> параметры.
Наличие такой задачи — повод задуматься о эффективности решения. Может быть стоит сменить подход.
Но, кстати, у меня было несколько разработчиков, которых никак не расскачать на то, чтобы эксперементировать или делать что-то необычное, а вот рутинные задачи (на мой взгляд) они любили.
> подбор персонала должен как раз выполнять руководитель, который знает каких у
> него уже достаточно.
Я не очень понимаю в чем загвоздка. Наличие руководителя (который минимально вмешивается в ежедневную работу комманды) как мне кажется ничему не противоречит. Комманда выполняет нормальную работу, руководитель разрешает проблемы, которые комманда напрямую не может разрешить. Обычно руководитель не требуется для каждой комманды, достаточно одного на 2-3 комманды (если проблемы возникают слишком часто, значит требуется пересмотр подхода к работе).
> в целом я не верю, что все задачи разберут с одинаковым удовольствием.
Задачи разные и люди разные. Одним одно — другим другое.
> но минусы в крупных проектах очевидны из-за зоопарка подходов в таких командах
> при сведении в общее решение.
Есть два подхода. Один премодерация, другой — постмодерация. Премодерация — это детальная архитектура сверху вниз. Постмодерация — постоянный рефакторинг и emerging architecture. У каждого подхода есть свои сильные и слабые стороны. Ни один из них не лучше чем другой — каждый подходит лучше для определенных условий.
Есть правда еще третий способ — это хаос и забивание на все, но это же не то, к чему надо стремиться, так?
> «социальные штуки» действительно не нужны там где не предполагается общения
> между людьми.
> если вы работаете в одном помещении и у вас есть возможность влиять на климат, то
> конфликты предсказуемы.
Вы говорите о простой ситуации. Сделать так, чтобы все работало в такой конфигурации — просто. Вот мне довелось выстраивать работу тогда, когда комманда находится в разных часовых поясах 12 ч разницы. Сделать так, чтобы все работало возможно, хотя и намного труднее, но возможно.
> то конфликты предсказуемы. различающаяся загрузка между членами команды также
> может стать причиной общения.
Разумеется. Опять же люди — не машины. Как бы кому-то не хотелось обратного.
Ходим кругами…
Наличие руководителя противоречит одноранговости команды.
Я о такой команде писал в комментарии.
Если есть организатор, то команда также и не самоорганизующаяся.
Возможно, я просто пытаюсь понять — это ваше предложение для доработки или попытка разобраться?
Одноранговые — разумеется противоречат. Не могли бы вы приветси ссылку на какой-нибудь из Agile фреймворков, где эта терминология применяется? И в каком контексте.
Самоорганизующиеся — не противоречат. Тут не экстремум, а смещение ответственности в сторону комманды. Оптимизация передачи информации между узлами, за счет усложнения узлов. Комманда остается частью организации, но значительная часть полномочий которые были у управляющего передаются в комманду. Несколько отличается от довольно радикального подхода где структура упраздняется как таковая
см:.
Другими словами: “завалить команду рутинной работой”Даже в условиях менее прозрачной водопадной методологии это весьма сложно. Большинство членов рабочей команды все таки читает ТЗ, на основе которого будет создан продукт и вполне способны дать приблизительную оценку времени и трудоемкости.
Agile не панацея, есть проекты в которых классические каскадные методологии предпочтительнее, так как поставлены конкретные достижимые цели и легче управлять бюджетом.
«Боссы-кровососы» вне контекста или почему они всегда терпят фиаско