Комментарии 32
Интересный материал.
В каких пределах устанавливается цена кармы? Не берет же человек цифру с потолка.
Чтобы взять задачу на реализацию из очереди сотрудники сами проводят техническую оценку, определяют за сколько времени и каким составом может быть выполнена задача, а так же озвучивают желаемую цену в карме.
В каких пределах устанавливается цена кармы? Не берет же человек цифру с потолка.
Если не секрет — сколько у вас разработчиков, сколько менеджеров и т.п.?
Как перешли на карму, четко выделенных ролей не стало. Есть компетенции и люди, которые ими владеют в разной степени. Так из 17 человек 14 пишут код, 6-7 активно общаются с бизнесом на предмет составления планов, анализом занимаются практически все, то же самое с тестированием и составлением документации.
А сколько проектов в работе одновременно?
Смотря что под проектом понимать.
Мы у себя приняли следующую терминологию:
Проект — это то, что относится к сфере бизнеса.
Продукт — программное обеспечение.
Дело в том, что бизнес-проект может затрагивать сразу несколько программных продуктов или ни одного.
Наша команда ведет 8 продуктов.
Мы у себя приняли следующую терминологию:
Проект — это то, что относится к сфере бизнеса.
Продукт — программное обеспечение.
Дело в том, что бизнес-проект может затрагивать сразу несколько программных продуктов или ни одного.
Наша команда ведет 8 продуктов.
и как решается вопрос приоритетов?
То есть под задачу народ кучкуется в группы, которые участвуют в тендере на её исполнение?
P.S. А в чём нарисована диаграмма? Пробовал draw.io, но там тупо нед подписи к стрелке.
P.S. А в чём нарисована диаграмма? Пробовал draw.io, но там тупо нед подписи к стрелке.
А если поступила задача (Задача решаема и это всем известно) и за нее ни кто не хочет браться? Все отказались.
Или скажем можно с учетом карма*10 =)
Или скажем можно с учетом карма*10 =)
Это разруливается принципами Kanban, который взят за основу. Задачи нужно брать сверху очереди (самые приоритетные), можно пропустить только если компетенций для решения не хватает.
Канбан очень древний процесс. Главная его проблема — ожидание готовности предварительных итераций. То, что замечательно подходит японским автомобильным гигантам, хуже применимо к разработке софта.
RUP (OpenUP) в этом отношении эффективнее. Он организует параллельную работу казалось бы жёстко обусловленных активностей.
RUP (OpenUP) в этом отношении эффективнее. Он организует параллельную работу казалось бы жёстко обусловленных активностей.
Спорное утверждение. Kanban в ИТ набирает популярность, можно убедиться побывав на Agile тусовках.
Спорить особого смысла нет. Проекты и команды очень разные.
MSF хорошо подходит для тиражируемого продукта,
XP и Scrum — для мелких проектов, мелких команд и мелких клиентов,
Канбан, наверное, для проектов, хорошо разбиваемых на мелкие части (какая-нибудь ERP с тысячами формочек)
OpenUP и подобные — для крупных и сложных проектов.
Ещё процесс зависит от формы финансирования и графика приёмки.
MSF хорошо подходит для тиражируемого продукта,
XP и Scrum — для мелких проектов, мелких команд и мелких клиентов,
Канбан, наверное, для проектов, хорошо разбиваемых на мелкие части (какая-нибудь ERP с тысячами формочек)
OpenUP и подобные — для крупных и сложных проектов.
Ещё процесс зависит от формы финансирования и графика приёмки.
Вы за месяц выявляете ненужных людей?!
Я в шоке. напишите продолжение поста через полгода, с честным описанием возникших завалов в работе. И да, напишите, сколько человек ушло сами, а скольких вы «ушли» по кармическим принципам. Мне кажется, первая цифра будет намного больше.
В целом — удачи, как говорится. она вам понадобится
Эффект кадровой санитарии — выявляются ненужные люди, с которыми никто не хочет работать;
Я в шоке. напишите продолжение поста через полгода, с честным описанием возникших завалов в работе. И да, напишите, сколько человек ушло сами, а скольких вы «ушли» по кармическим принципам. Мне кажется, первая цифра будет намного больше.
В целом — удачи, как говорится. она вам понадобится
Вы за месяц выявляете ненужных людей?!
Раньше мнение о человеке было на уровне «я не доверяю», сейчас на уровне конкретных цифр. Напомню, что показатели общедоступные.
Кроме того это стало очевидно для всей команды благодаря пришедшему вместе с кармой кросс-тестированию, обзору кода и т.п. Раньше эти методики не принимались и не применялись, сейчас очень даже используются.
Как будет о чем рассказать еще, обязательно напишу.
Вы за месяц выявляете ненужных людей?
Вы путаете ненужных и, так скажем, «нелюбимых». Ну и сроки неправильно поняли. За месяц определяем просто кто больше сделал. Репрессивные методы не применяются. Накопительный показатель — пока не накопили. Ожидаем, что он будет показывать заинтересованность людей в том, чтобы активно брать задачи и решать их. Стало невыгодно затягивать срок сдачи решения, просматривая котиков в интернетах. Отставание от кармы коллег становится заметным.
Какое хитрое делегирование ответственности ;)
Работник, несущий бОльшую ответственность должен иметь бОльшую зарплату. В том числе и потому что на него перекладываются задачи менеджера (по планированию) и аналитика (по оценке рисков). И объёмы должны быть меньше, потому что аналитика — это тоже работа.
Работник, несущий бОльшую ответственность должен иметь бОльшую зарплату. В том числе и потому что на него перекладываются задачи менеджера (по планированию) и аналитика (по оценке рисков). И объёмы должны быть меньше, потому что аналитика — это тоже работа.
Тут уж вопрос, а что вы вкладываете в понятие ответственности?
Есть такое определение:
Таким образом, ответственность возникает ДО того как что-то было сделано или не сделано. Мы всего лишь хотим, чтобы сотрудники ответственно относились к своим обязанностям и ничего больше.
Задачи менеджера не перекладываются, сотрудник сам принимает решение о том, над какими задачами он будет работать, и ответственность за его своевременное и качественное выполнение.
Сотрудник получает карму за любую работу, которую он выполняет.
Есть такое определение:
Ответственность — личностная характеристика человека, описывающая его способность обстоятельно анализировать ситуацию, заранее прогнозировать последствия (весь комплекс следствий) своих действий или бездействий в данной ситуации и делать выбор формы своих поступков с готовностью принять последствия выбора, как неизбежные свершившиеся факты.
Таким образом, ответственность возникает ДО того как что-то было сделано или не сделано. Мы всего лишь хотим, чтобы сотрудники ответственно относились к своим обязанностям и ничего больше.
Задачи менеджера не перекладываются, сотрудник сам принимает решение о том, над какими задачами он будет работать, и ответственность за его своевременное и качественное выполнение.
И объёмы должны быть меньше, потому что аналитика — это тоже работа.
Сотрудник получает карму за любую работу, которую он выполняет.
Я говорю об ответственности не как о личном качестве, а как о разновидности рабочей активности. Мы же тут не лютики-цветочки нюхаем.
Ответственность с точки зрения управления — это способность принимать необходимые решения на основе анализа ситуации и отвечать за их последствия. За это обычно платят.
Не все способны или хотят нести ответственность в рамках всего проекта. Бывают просто рабочие пчёлки отвечающие только за порученную им задачу. Они тоже нужны.
Ответственность с точки зрения управления — это способность принимать необходимые решения на основе анализа ситуации и отвечать за их последствия. За это обычно платят.
Не все способны или хотят нести ответственность в рамках всего проекта. Бывают просто рабочие пчёлки отвечающие только за порученную им задачу. Они тоже нужны.
В нашей реальности начальники часто сами не хотят знать реальные оценки. Чаще всего им надо семь шапок из овцы. А несогласие считается «негативным отношением».
Общительные и компанейские люди не всегда самые ценные в плане отдачи. Более того, есть риск, что они будут формировать кланы.
Ценность в плане отдачи обеспечивается накопленной кармой за месяц. Если человек взявший на себя лидерство не привел к результату, за ним больше не пойдут.
Клан я интерпретировал как команду, не знаю насколько я вас правильно понял. Если сформируется относительно фиксированная и, при этом, эффективная команда, то я не вижу в этом проблемы.
Клан я интерпретировал как команду, не знаю насколько я вас правильно понял. Если сформируется относительно фиксированная и, при этом, эффективная команда, то я не вижу в этом проблемы.
Скажите, а какую цель вы преследовали, когда начали внедрять agile? Какие проблемы пытаетесь решить с помощью кармы?
Основная проблематика, освещенная в докладе, заключается в том, что многие сотрудники просто проводят время на работе, мало у кого есть чувство ответственности. Тем более нет командной ответственности, зато есть отговорки, много отговорок. Тут появляются проблемы с эффективностью, качеством, требуется постоянный контроль над сотрудниками. Всех все устраивает, нет желания меняться.
Проблема была та же самая. Думали, что Agile поможет повысить качество и скорость разработки. Не помог. На помощь пришла карма. Забавно, что при этом Agile практики сами как то начали применяться.
Это только вопрос мотивации. Бесплатная ответственность — это какая-то глупость. Нормальный человек не будет просто так без планируемой выгоды брать на себя лишнюю ответственность или, как в вашем случае, не будет лишний раз напрягаться. Когда результативность оценивается монетарно или карьерно, совсем другой разговор.
У вас получилась среда, более близкая к свободному рынку, чем ранее.
Фактически фирма предлагает разработчикам гарантию оплаты заказчиком в количестве «карм» за задачу.
Рекомендую снижать фиксированную ставку и повышать премиальную долю зарплаты.
Ну или вообще, к черту мансы и человеко часы — в задачах так и писать сколько денег полагается за решение задачи в срок, и каков размер неустойки. Ставку убрать вообще.
Такой внутренний фриланс рынок, сколько наработал столько и получил.
Тендеры\аукционы еще ввести, чтоб на переоцененные руководством задачи цена автосбивалась теми кто готов взяться. Хотя для этого — коллектив еще маловат мне кажется.
А карма бы показывала надежность сделок заключеных сотрудником (% когда выполнено все как надо и в срок).
Еще вы упомянули, что следите чтоб разработчики не перетруждались.
Потолок производительности у людей очень разный, и у одного и того же человека разный в разные периоды.
Какие у вас механизмы, за какой временной промежуток оценивается показатель?
Фактически фирма предлагает разработчикам гарантию оплаты заказчиком в количестве «карм» за задачу.
Рекомендую снижать фиксированную ставку и повышать премиальную долю зарплаты.
Ну или вообще, к черту мансы и человеко часы — в задачах так и писать сколько денег полагается за решение задачи в срок, и каков размер неустойки. Ставку убрать вообще.
Такой внутренний фриланс рынок, сколько наработал столько и получил.
Тендеры\аукционы еще ввести, чтоб на переоцененные руководством задачи цена автосбивалась теми кто готов взяться. Хотя для этого — коллектив еще маловат мне кажется.
А карма бы показывала надежность сделок заключеных сотрудником (% когда выполнено все как надо и в срок).
Еще вы упомянули, что следите чтоб разработчики не перетруждались.
Потолок производительности у людей очень разный, и у одного и того же человека разный в разные периоды.
Какие у вас механизмы, за какой временной промежуток оценивается показатель?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Karma Driven Development (KDD)