Корректировочка. Вопрос написан с большой идеологической ошибкой. Правильный вариант таблетки: Взять за шкирку лида и заставить его задавать ТЕБЕ 5 раз вопрос „почему?“
Могу выписать такую таблетку по этой ситуации: «Взять за шкирку лида и заставить его задавать 5 раз вопрос „почему?“. Пусть мучается и всё узнаёт, что следует ему знать.»
Смысл эмоций, согласно умным книжкам, заключается в подсказывании сознанию о каких-то моментах. Эмоции — это профессионально развитая интуиция. Как только ощущаете эмоции — это индикатор, что что-то ни так, или наоборот всё так.
В правильных командах делают так: эмоция -> задуматься о её причине -> поделиться с ближайшим. Такой магический цикл из трёх шагов приводит не только к пониманию многих вещей, а заключительный шаг начинает творить чудеса в команде.
Лечить нужно голову (в данном контексте, я подразумеваю руководителя команды). Автор неоднократно подчеркивает — ищу суперменов. А инструмент поиска — отсеивать неудачников прекрываясь абстрактными понятиями «оценки производительности».
Предлагаю отличать процесс разработки в ИТ от глобальных изменений.
То что, кто-то выдаёт меньше кода говорит лишь о пробелах знаний в контекте проекта. И совершенно никак не характеризуют личность. Оценка производительности — это попытка посчитать личность, а отсюда — привет мотивации, так как в команде кто-то будет лучше, кто-то хуже. Мы создаём оценкой «внутренний», совершенно невидимый и неосозноваемый конфликт на ровном месте. Кстати, крики оппонентов, что такого конфликта нет лишь доказывает, что этот конфликт очень скрыт. И не каждый его просто так расскроет во враждебной для себя команде (где меряют и потом ещё и начинают давить — мол повышай производительность).
Можно это интерпретировать как «сам дурак» (что часто делается) и плюс навешать ярлык «мы оценили твою эффективность — ты лузер». А можно задаться вопросом — почему? В ИТ за десятилетия выработаны разнообразные практики как улучшать культуру разработки, которая приводит к выравниванию производительности инженеров в любом проекте. Конечно, некоторые навыки требуют практики, чтобы их получить — но это стратегичекий шаг и здравствуй ситуационный менеджмент, коучинг, менторство, парное программирование и Agile.
Не работника лечить нужно через «оценку эффективности», а процесс. Если много ошибок — значить среда создана соответствующая. И не руки рубить нужно — а голову лечить :)
На эту тему туча информации есть у HR отделов. Правда на российском ИТ-рынке эта тема ещё пока в зародыше.
Кратко оценка происходит через
1) должностные инструкции — которые регулярно пересматриваются и являются договором между фирмой и работником — выполняются они или нет
2) профессиональный профиль — это очень большая тема ранжировки навыков и по ней отслеживают уровень и эффективность
3) компетенции — профилево-независимые навыки
Это система с большим количеством букв, но по ней лихо можно показать ожидания фирмы от сотрудника, и померять его эффективность. И нужно помнить, что эффективность определяется не абстрактными характеристиками, а соответствием (как это не банально звучит) занимаемой должности. А должность определяется фирмой, которая выстраивает определенные ожидания. Если человек удовлетворяет ожиданиям фирмы в этой определенной должности — эффективность хорошая, если больше или меньше — тут вступают механизмы как это поправить (для первого случая повышение, для второго — дополнительное обучение или пинка под попу).
Но самое главное в этом. Что есть самый главный хак — быть contributor'ом в систему/фирму, а остальное приложится :) что это означает? Это означает — интересовать об ожиданиях фирмы по отношению к себе, стремиться 100% их оправдать. Как механизм роста — это расширение своего impact («влияние»… по русски оттенок получается не очень). Но это тоже тема отдельного разговора.
Вот в общем, где-то так. Книг не знаю, ссылок тоже. Только на опыте. Если интересно, могу поднять эту тему в «аджайл подкасте» (agilepod.ru), если интресно — можно обсудить (стучитесь — skype:denis_miller)
С подключением тебя будет 2 пары противоборствующих программистов!!! Мы сейчас с Денисом здесь agilepod.ru/?p=115 устроили разбор полётов. И явно не находим общих точек соприкосновения. Он так же как и ты не очень разделил наше решение.
Получается двое на двоё. А это значит можно выбрать какую-нить задачу и попробовать её забороть. Правда это звучит глупо, ведь чтобы нормально задачу решать нужно ооочень сильно формализовать требования, чтобы обе стороны её однозначно трактовали. Это минус.
Зато можно просто потрындеть — хотя это менее полезно.
В Agile, если в продукте сделано только «А», то это можно использовать сразу после поставки и получать прибыль. Даже если проект закроют. В этом координальное отличие Аджайл от других процессов так же. Для примера с велосипедом Аджайлисты первым делом заделали бы колесо без спиц, и возможно велик бы походил на тележку. Но которую можно уже прям сейчас использовать. Когда продукт начал использоваться его начнут развивать, добавляя «Б» (второе колесо и возможно добавят спицы и покрышку на колеса).
Судя по твоему описанию, чтобы продукт заработал нужно собрать части в конце. То есть клиент не сможет работать, пока не долждётся всех частей плюс не будет выполнена работа по интеграции их.
Странно, почему PRINCE2 ставят на одну ступеньку с Agile. Ключевой фактор в Agile не строгость процессам и артефактам (backlog и т.п.), а ориентация на человеческий фактор и командное взаимодействие. Кстати, почему-то многие, кто сравнивает Agile с другими методологиями намеренно пропускают эту ключевую составляющую Agile.
Почему человеческий фактор — важная составляющая? Ответ простой — у аджайлист всего лишь 4 убеждения, которые отличают его от других работников умственного труда. И слова «коммуникация», «индвидуальность» и «взаимодействие» как раз в ядре этой методологии заложены.
согласен про применимость… мне тоже все это подозрительно… но я не теряю надежды достать из него/них полезное. не глупые люди ведь придумали это все дело, грех не воспользоваться результатами.
Кстати, аджайл датируется 2001 годом, а вот Lean уходит в средневековье 20 века :)
Взять за шкирку лида и заставить его задавать ТЕБЕ 5 раз вопрос „почему?“
Смысл эмоций, согласно умным книжкам, заключается в подсказывании сознанию о каких-то моментах. Эмоции — это профессионально развитая интуиция. Как только ощущаете эмоции — это индикатор, что что-то ни так, или наоборот всё так.
В правильных командах делают так: эмоция -> задуматься о её причине -> поделиться с ближайшим. Такой магический цикл из трёх шагов приводит не только к пониманию многих вещей, а заключительный шаг начинает творить чудеса в команде.
Лечить нужно голову (в данном контексте, я подразумеваю руководителя команды). Автор неоднократно подчеркивает — ищу суперменов. А инструмент поиска — отсеивать неудачников прекрываясь абстрактными понятиями «оценки производительности».
То что, кто-то выдаёт меньше кода говорит лишь о пробелах знаний в контекте проекта. И совершенно никак не характеризуют личность. Оценка производительности — это попытка посчитать личность, а отсюда — привет мотивации, так как в команде кто-то будет лучше, кто-то хуже. Мы создаём оценкой «внутренний», совершенно невидимый и неосозноваемый конфликт на ровном месте. Кстати, крики оппонентов, что такого конфликта нет лишь доказывает, что этот конфликт очень скрыт. И не каждый его просто так расскроет во враждебной для себя команде (где меряют и потом ещё и начинают давить — мол повышай производительность).
Можно это интерпретировать как «сам дурак» (что часто делается) и плюс навешать ярлык «мы оценили твою эффективность — ты лузер». А можно задаться вопросом — почему? В ИТ за десятилетия выработаны разнообразные практики как улучшать культуру разработки, которая приводит к выравниванию производительности инженеров в любом проекте. Конечно, некоторые навыки требуют практики, чтобы их получить — но это стратегичекий шаг и здравствуй ситуационный менеджмент, коучинг, менторство, парное программирование и Agile.
Кратко оценка происходит через
1) должностные инструкции — которые регулярно пересматриваются и являются договором между фирмой и работником — выполняются они или нет
2) профессиональный профиль — это очень большая тема ранжировки навыков и по ней отслеживают уровень и эффективность
3) компетенции — профилево-независимые навыки
Это система с большим количеством букв, но по ней лихо можно показать ожидания фирмы от сотрудника, и померять его эффективность. И нужно помнить, что эффективность определяется не абстрактными характеристиками, а соответствием (как это не банально звучит) занимаемой должности. А должность определяется фирмой, которая выстраивает определенные ожидания. Если человек удовлетворяет ожиданиям фирмы в этой определенной должности — эффективность хорошая, если больше или меньше — тут вступают механизмы как это поправить (для первого случая повышение, для второго — дополнительное обучение или пинка под попу).
Но самое главное в этом. Что есть самый главный хак — быть contributor'ом в систему/фирму, а остальное приложится :) что это означает? Это означает — интересовать об ожиданиях фирмы по отношению к себе, стремиться 100% их оправдать. Как механизм роста — это расширение своего impact («влияние»… по русски оттенок получается не очень). Но это тоже тема отдельного разговора.
Вот в общем, где-то так. Книг не знаю, ссылок тоже. Только на опыте. Если интересно, могу поднять эту тему в «аджайл подкасте» (agilepod.ru), если интресно — можно обсудить (стучитесь — skype:denis_miller)
С подключением тебя будет 2 пары противоборствующих программистов!!! Мы сейчас с Денисом здесь agilepod.ru/?p=115 устроили разбор полётов. И явно не находим общих точек соприкосновения. Он так же как и ты не очень разделил наше решение.
Получается двое на двоё. А это значит можно выбрать какую-нить задачу и попробовать её забороть. Правда это звучит глупо, ведь чтобы нормально задачу решать нужно ооочень сильно формализовать требования, чтобы обе стороны её однозначно трактовали. Это минус.
Зато можно просто потрындеть — хотя это менее полезно.
Подключишься к обсуждениям в студии?
Буду делать только в моно.
Судя по твоему описанию, чтобы продукт заработал нужно собрать части в конце. То есть клиент не сможет работать, пока не долждётся всех частей плюс не будет выполнена работа по интеграции их.
Почему человеческий фактор — важная составляющая? Ответ простой — у аджайлист всего лишь 4 убеждения, которые отличают его от других работников умственного труда. И слова «коммуникация», «индвидуальность» и «взаимодействие» как раз в ядре этой методологии заложены.
Подробнее я писал в Agile = 4 + 12
Кстати, аджайл датируется 2001 годом, а вот Lean уходит в средневековье 20 века :)
PS. Открыл.