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