Reward the best ?

[rzen]

Если начальник и сам понимает что митинги с ним отнимают время (но может полезны для чего-то), то все нормально и отлично. Если он сам отнимает время, а потом предъявляет что мало сделано - завести джиру типа "meetings with boss", и каждую неделю в нее чаржить определенное число часов. Раз в месяц показывать начальнику (а лучше его начальнику), сколько его болтовня стоит компании

По моему опыту, в скраме оперировать часами вместо story points - занятие опасное и неблагодарное. Я не знаю, как в стартапах, а в крупных компаниях overhead часто может достигать диких значений типа 40-50%. Одно дело, когда ваша команда делает "20 story points per 2 week sprint" (оверхед учтён при item sizing), другое дело, когда она же делает "250 hours per 2 week sprint". Любой умник, что умеет 250 разделить на 5 девелоперов, заключает, что один девелопер "работает" 5 часов в день. Значит есть резервы. Далее, если этот же умник видит item с estimation=10 hours, считает, что если очень надо, ему ЭТО сделают за один рабочий день. Просто надо на один день весь оверхед задвинуть. И так повторить 10 раз. Профит.

Напомнило отличную аналогию АццкоМото про марафон - "если разделить марафон на 422 спринта и экстраполировать, окажется, что его можно на самом деле пробежать за час, а не за два"

У нас эстимейтят все в часах, но с всем известной оговоркой, что сотрудник "работает" 6 часов в день (остальное - оверхед). Пока нормально.

а мы вообще эстимейты не ставим. я доверяю каждому из своих ребят, если (устно) говорит +- обернусь тогда то (это не на одну жиру а на всю итерацию), а на деле оказывается чуть раньше или чуть позже, ну значит так получилось. у нас твёрдый договор, халтуру не делать, всё остальное negotiable. и никаких пилюль за "срыв сроков" не предусмотрено. если что то не укладывается в задуманные сроки, совместно думаем чем жертвовать. иными словами о сроках голова болит не у разработчиков, а у меня.

не знаю может у нас это возможно потому что команда небольшая, но имхо получается неплохо. и нервные клетки на месте

[Zorkus]

Подводили итоги очередного спринта ( мне проще говорить итерации). И как обычно во всяких Jira-ах видно кто сколько часов вложил, багов починил, написал новых фич. Точнее это и так видно без джиры, но с ней на порядки нагляднее.
Сказала полу в шутку, полу всерьез что надо бы нам как то reward the best. Начальник тут же подскочил и сказал что он категорически против . Это при том что он у нас сам пашет как вол.
Интересно какой у вас взгляд на это дело ?

Начальник, скорее всего сразу просек, что при таком подходе ему отнюдь не лучших придеться награждать. У меня в группе, например, тем, кто послабее и задания давались попроще: типа " бери больше, бросай дальше". И они, конечно, их делали их "на автомате" десятками в день. Большинство получало задания обычной сложности и делало их десяток-другой. А парочке сильных специалистов доставались каверзные, сложные, кем-то запоротые задания. Иной день они только 1-2 могли закончить. Но кроме них с этими заданиями не справился бы никто другой. А они любые другие задания могли без проблем сделать. "Дак кто ж им даст?"(с) Потому как их помощь со сложными заданиями была важнее. Угадайте с 3-х раз, кого при раздаче слонов я за " best" считала?

P.S. Кстати, подходил ко мне как-то один из " высокопроизводительных" работников с претензией "а почему Джону, который только пару заданий в день делает, дали нечто, а ему, с 25-ю заданиями - нет". Я предложила ему местами с Джоном поменяться. А он говорит: " не-а, у Дюона задания трудные". Ну я ему и сказала: "Вот потому Джону премию и дали". Больше он мне таких вопросов не задавал...

Вау. Что это за "трудные задания", которые можно делать по два в день? Если считать (из предыдущих реплик), что мы работаем 6 часов, то это 3 часа работы? А "лёгкие задания", по полчаса на каждое, от начала до конца? Не очень ли мелко вы их нарезаете?

Для себя когда определяю, делю так - простые задания это те, которые я могу проэстимейтить точно и сделать за день-два, средние это те, которые я могу проэстимейтить примерно и сделать за дней 3-5, сложные - это те, где мне надо посидеть день-два,почитать мейл листы, бегтрекеры внешний библиотек, исходники, над дебаггером чтобы понять, как это делать и можно ли сделать приемлимым способом за приемлемое время. За последнее время чаще всего последние - это задачи, когда есть баг или пропущенная фича в 3P библиотеке, с которйо интегрируемся, и решения сходу или нет или оно есть в виде "первая версия патча приложена к джире и ее кто-то тестирует".

[X37WAL!^]

Для себя когда определяю, делю так - простые задания это те, которые я могу проэстимейтить точно и сделать за день-два, средние это те, которые я могу проэстимейтить примерно и сделать за дней 3-5, сложные - это те, где мне надо посидеть день-два,почитать мейл листы, бегтрекеры внешний библиотек, исходники, над дебаггером чтобы понять, как это делать и можно ли сделать приемлимым способом за приемлемое время. За последнее время чаще всего последние - это задачи, когда есть баг или пропущенная фича в 3P библиотеке, с которйо интегрируемся, и решения сходу или нет или оно есть в виде "первая версия патча приложена к джире и ее кто-то тестирует".

Да мне вот тоже кажется, что простые - день-два, сложные - чуть меньше одного человека-спринта. А то, что можно десятками в день делать - надо объединять в items типа "ongoing cleanup/tuning/whatever", чтобы не плодить сущности и не создавать иллюзии "я делаю десятки важных вещей ежедневно".

[Сабина]

Чтобы определять лучших - надо найти справедливую метрику. В кнопкодавительном деле оной, насколько мне известно, нет и не предвидится, так что идей обнаружения "лучших" - обречена.

ЗЫ Пример из реала - один чувак написал большую фичу, в которой нашли 900 багов, которые автором и были пофикшены. Другой написал тоже большую фичу, в которой нашли 90 багов, тоже пофикс. Кому давать печеньку - вот в чем вопрос...

Кстати это мы успешно решали еще в AT&T, там была метрика не больше n багов per new feature. Конечно эти все метрики условные потому что у того кто больше работы делает у того и будет больше багов. Но суть не важна как, вопрос изначальный в том выделять ли лучшего. Я для себя его давно решила - НАДО! В каждом тиме где я работала был костяк из одного двух людей которые на себе тащили практически все. А остальные так себе - делали все остальное неспеша. Я считаю это несправедливо что костяк ничем не выделяется от прочих. А человеку иногда хорошее слово как и кошке приятно. Оно на ревью может вылиться в нечто большее чем просто хорошее слово. И это всяко лучше чем начальник который иногда про тим и не знает ничего решает кому чего добавить

[Сабина]

а мы вообще эстимейты не ставим. я доверяю каждому из своих ребят, если (устно) говорит +- обернусь тогда то (это не на одну жиру а на всю итерацию), а на деле оказывается чуть раньше или чуть позже, ну значит так получилось. у нас твёрдый договор, халтуру не делать, всё остальное negotiable. и никаких пилюль за "срыв сроков" не предусмотрено. если что то не укладывается в задуманные сроки, совместно думаем чем жертвовать. иными словами о сроках голова болит не у разработчиков, а у меня.

не знаю может у нас это возможно потому что команда небольшая, но имхо получается неплохо. и нервные клетки на месте

Интересно. По идее почему бы и нет если работает. Мне только хотелось бы прояснить как там дальше идет отчетность. В тиме как понимаю все отчитаются тебе. Ну допустим вы решили что-то trade in . А что твой начальник по этому поводу думает ? А что делаете если эту trade in feature кто-то наверху пообещал важному кастомеру "мол будет кровь из носа в этом релизе " ?

[Сабина]

Согласна, что идея "измерения производительности в багах" совершенно дурацкая, и вообще лишняя трата времени. Ну кроме как позагибать пальцы. Надо бы тогда еще считать кто сколько багов наделал и кто их фиксил, и вычитать для идеального пальцеуказательства и бухгалтерии.

Вообще, приоритеты в разное время и с разными вещами могут быть разные. Иногда - писать быстро-быстро. Иногда - потратить время на продумывание дизайна.

Но никак не по тому, как выявить лучших

И что делать с этими лучшими? Дать значок "пофиксен сотый баг"? Да и менеджера можно понять, развивать дух competitiveness в собственной команде отвратная идея.

От метрик увы никуда не денешься. Очень нередко менеджмент обязан предоставить информацию о том как работает тим, и далеко не каждый из них сидит с девелоперами за соседним столом. Метрики - это та призма через которое начальство судит о вас. Я не вижу в них ничего страшного и считаю что девелопера шарахающиеся от скрама и проклинающие метрики роют себе медленно могилу. Куда интереснее в это все вникнуть и делать по уму - тогда и метрики начнут на вас работать. Если вы и правда молодец который заслужил много чего - это все станет прозрачно если метрики грамотные, а грамотными из никто кроме нас с вами не сделает

[Zorkus]

Так я значит рою себе могилу, причем не медленно а быстро Хотя нет, одну метрику (хотя знаю что она кривая), я иногда использую сам для себя, втихую. git shortlog -s -n.

[Сабина]

Если начальник и сам понимает что митинги с ним отнимают время (но может полезны для чего-то), то все нормально и отлично. Если он сам отнимает время, а потом предъявляет что мало сделано - завести джиру типа "meetings with boss", и каждую неделю в нее чаржить определенное число часов. Раз в месяц показывать начальнику (а лучше его начальнику), сколько его болтовня стоит компании

Из моего опыта время в основном отнимают team mates . Норовят обсуждать в детялях вещи на тех митингах которые предназначены совершенно для другого. Все стонут про длинные stand ups . А кто их делает длинными то ? Не надо пытаться на стендапах решать конкретные вопросы, только то что нужно обсудить всем тимом, для всего прочего - договорись отдельно. Стендап нужен для того чтобы сообщить нудному человеку о dependency или help needed чтобы потом забить стрелку и обсуждать детали узким кругом а не отнимая время у всего тима.
То же самое с кикофами, на новом месте менеджер норовит объединить их с architectural discussions. А на фига весь тим держать два часа на митинге для этого дела ? Обсуди это заранее с теми кем нужно и напиши use case или wiki page с деталями new feature, а на кикофе просто выбрать остается кому это делать .

[Poryadok]

А я считаю, бонуса нужно давать не за перфоманс (за плохой нужно просто увольнять), а за проджект овнершип. отечаешь за большой проект, раздаешь задания команде, бегаешь разбираешься со стейкхолдерами, продумываешь что где завтра может повалиться - вот тебе большой постоянный бонус. Отвечаешь за пооект из одного человека, который сам и пишешь - вот тебе бонус поменьше. Вобщем, бонус за ответственность.

[Сабина]

Да мне вот тоже кажется, что простые - день-два, сложные - чуть меньше одного человека-спринта. А то, что можно десятками в день делать - надо объединять в items типа "ongoing cleanup/tuning/whatever", чтобы не плодить сущности и не создавать иллюзии "я делаю десятки важных вещей ежедневно".

Очень интересно. У нас есть technical debt , но там обычно помощь другим тимам тракается. Можно пример ongoing cleanup/tuning ? У меня например есть недостаток который в целом превращает меня в жуткую копушу. Если я делаю одно но при этом использую другое и вижу что другое "сделано через зад" я и это другое начинаю переделывать (если конечно не совсем полный перепис). В баг или стори обычно добавляют этимейт приписывая "need to refactor bla-bla because". Допускаю что это не совсем эффективный способ, точнее уверена что начальство меня в такие моменты может всякими разными словами называет , но пока я от этого не сильно страдаю и делаю как могу.
Из вашего поста получается что вы делаете какую- то ongoing background maintenance. А можно пример ? Это какие то вещи из списка "надо сделать то-то" ? Или вещи с которыми люди сталкиваются в процессе работы над чем то другим ?

[Сабина]

А я считаю, бонуса нужно давать не за перфоманс (за плохой нужно просто увольнять), а за проджект овнершип. отечаешь за большой проект, раздаешь задания команде, бегаешь разбираешься со стейкхолдерами, продумываешь что где завтра может повалиться - вот тебе большой постоянный бонус. Отвечаешь за пооект из одного человека, который сам и пишешь - вот тебе бонус поменьше. Вобщем, бонус за ответственность.

Даже если ты эту ответственность просрал по полной ?
У нас так построена иерархия что отвечает за все менеджер, тиммейт не может при всем желании. Подозреваю что не у нас одних так

[rzen]

а мы вообще эстимейты не ставим. я доверяю каждому из своих ребят, если (устно) говорит +- обернусь тогда то (это не на одну жиру а на всю итерацию), а на деле оказывается чуть раньше или чуть позже, ну значит так получилось. у нас твёрдый договор, халтуру не делать, всё остальное negotiable. и никаких пилюль за "срыв сроков" не предусмотрено. если что то не укладывается в задуманные сроки, совместно думаем чем жертвовать. иными словами о сроках голова болит не у разработчиков, а у меня.

не знаю может у нас это возможно потому что команда небольшая, но имхо получается неплохо. и нервные клетки на месте

Интересно. По идее почему бы и нет если работает. Мне только хотелось бы прояснить как там дальше идет отчетность. В тиме как понимаю все отчитаются тебе. Ну допустим вы решили что-то trade in . А что твой начальник по этому поводу думает ? А что делаете если эту trade in feature кто-то наверху пообещал важному кастомеру "мол будет кровь из носа в этом релизе " ?

бывает и "кровь из носу". тогда авралим, а что делать.

мне с начальником повезло, полностью hands off. например мой последний update ему был месяца два назад как раз об авральном проекте (дословно) "it's going to be tight but we'll make it".

так и живём

[Poryadok]

А я считаю, бонуса нужно давать не за перфоманс (за плохой нужно просто увольнять), а за проджект овнершип. отечаешь за большой проект, раздаешь задания команде, бегаешь разбираешься со стейкхолдерами, продумываешь что где завтра может повалиться - вот тебе большой постоянный бонус. Отвечаешь за пооект из одного человека, который сам и пишешь - вот тебе бонус поменьше. Вобщем, бонус за ответственность.

Даже если ты эту ответственность просрал по полной ?
У нас так построена иерархия что отвечает за все менеджер, тиммейт не может при всем желании. Подозреваю что не у нас одних так

Если просрал проект, так просрал и бонус

Мне кажется, если человек будет понимать, что если он просрет, то у него заберут проект, и с ним бонус, и нового не дадут, он будет стараться.

[Сабина]

бывает и "кровь из носу". тогда авралим, а что делать.

мне с начальником повезло, полностью hands off. например мой последний update ему был месяца два назад как раз об авральном проекте (дословно) "it's going to be tight but we'll make it".

так и живём

ну так получается не вы тимом решаете про trade off по большому счету ?

[Сабина]

Если просрал проект, так просрал и бонус

Мне кажется, если человек будет понимать, что если он просрет, то у него заберут проект, и с ним бонус, и нового не дадут, он будет стараться.

Ну хорошо пусть в тиме 5 человек. Надо сделать три новые фичи и пофиксить критические баги. Двое пахали как кони и добавили новые фичи, третий написал тихий ужас. Из критических багов треть не пофиксены. Начальство спрашивает с менеджера а не с людей индивидуально. Премии будут ? Нет ? Кому ?

[rzen]

бывает и "кровь из носу". тогда авралим, а что делать.

мне с начальником повезло, полностью hands off. например мой последний update ему был месяца два назад как раз об авральном проекте (дословно) "it's going to be tight but we'll make it".

так и живём

ну так получается не вы тимом решаете про trade off по большому счету ?

у нас структура не совсем иерархическая, trade offs решаются частично тимом (в смысле оценки что возможно) частично клиентом (в смысле что приемлимо). у нас правда клиенты все внутренние, это наверное попроще чем в других конторах.

[Zorkus]

Если начальник и сам понимает что митинги с ним отнимают время (но может полезны для чего-то), то все нормально и отлично. Если он сам отнимает время, а потом предъявляет что мало сделано - завести джиру типа "meetings with boss", и каждую неделю в нее чаржить определенное число часов. Раз в месяц показывать начальнику (а лучше его начальнику), сколько его болтовня стоит компании

Из моего опыта время в основном отнимают team mates . Норовят обсуждать в детялях вещи на тех митингах которые предназначены совершенно для другого. Все стонут про длинные stand ups . А кто их делает длинными то ? Не надо пытаться на стендапах решать конкретные вопросы, только то что нужно обсудить всем тимом, для всего прочего - договорись отдельно. Стендап нужен для того чтобы сообщить нудному человеку о dependency или help needed чтобы потом забить стрелку и обсуждать детали узким кругом а не отнимая время у всего тима.
То же самое с кикофами, на новом месте менеджер норовит объединить их с architectural discussions. А на фига весь тим держать два часа на митинге для этого дела ? Обсуди это заранее с теми кем нужно и напиши use case или wiki page с деталями new feature, а на кикофе просто выбрать остается кому это делать .

Ты совершенно права Но я просто иду дальше, и на поверку оказывается, что вопросов которые нужно каждый день (daily stand up?) обсуждать всей командой - нету. Мне нужна помощь - я не буду ждать стендапа, я подойду и спрошу Надо что-то объяснить ? Пишу письмо (тут некоторые помню приводили довод, что мол народ не читает письма, вот это не аргумент, это совершенно реальная проблема - если человек не читает почту вовремя).

Кстати, мой первый ПМ еще в Самаре мне (тогда я еще был в аутсорсинговой команде) говорил - если есть какая зависимость, чем-то заблокирован - пиши письмо. Если потом окажется, что из за этой задаржки твоя часть, это то, что держит релиз - у тебя будет письмо (документ), а не отговорки мол -"да это мы еще недели две назад обсуждали с Ивановым и не договорились"

[Сабина]

Реалии увы таковы что емейл легко пропустить а стендап не у всех
Ну хорошо ты сам просишь если тебе что надо, а что если другим что-то надо от тебя ? Иногда бывает непонятно что и от кого нужно пока не состоялось коллективное обсуждение проблемы с которой кто-то stuck.

[Zorkus]

Реалии увы таковы что емейл легко пропустить а стендап не у всех
Ну хорошо ты сам просишь если тебе что надо, а что если другим что-то надо от тебя ? Иногда бывает непонятно что и от кого нужно пока не состоялось коллективное обсуждение проблемы с которой кто-то stuck.

Стандап предполагает что человек должен быть или на месте, или на телефоне именно в это время, что обычно геморройно, так как время обычно назначают неудобное.

А кому что надо от меня - ну или имейл, или смс, или звонок, или пусть сами подходят когда я на месте .

[M. Ridcully]

Ну хорошо пусть в тиме 5 человек. Надо сделать три новые фичи и пофиксить критические баги. Двое пахали как кони и добавили новые фичи, третий написал тихий ужас. Из критических багов треть не пофиксены. Начальство спрашивает с менеджера а не с людей индивидуально. Премии будут ? Нет ? Кому ?

Если "в тиме из 5 человек" менеджер не знает, кто чем занимается, и кто чего стоит - безо всяких метрик - то грош цена этому менеджеру. Те двое, что "пахали как кони" - если своего не получат - просто свалят и компании, и всех делов.

[Zorkus]

Ну хорошо пусть в тиме 5 человек. Надо сделать три новые фичи и пофиксить критические баги. Двое пахали как кони и добавили новые фичи, третий написал тихий ужас. Из критических багов треть не пофиксены. Начальство спрашивает с менеджера а не с людей индивидуально. Премии будут ? Нет ? Кому ?

Если "в тиме из 5 человек" менеджер не знает, кто чем занимается, и кто чего стоит - безо всяких метрик - то грош цена этому менеджеру. Те двое, что "пахали как кони" - если своего не получат - просто свалят и компании, и всех делов.

+1

[rzen]

Ну хорошо пусть в тиме 5 человек. Надо сделать три новые фичи и пофиксить критические баги. Двое пахали как кони и добавили новые фичи, третий написал тихий ужас. Из критических багов треть не пофиксены. Начальство спрашивает с менеджера а не с людей индивидуально. Премии будут ? Нет ? Кому ?

Если "в тиме из 5 человек" менеджер не знает, кто чем занимается, и кто чего стоит - безо всяких метрик - то грош цена этому менеджеру. Те двое, что "пахали как кони" - если своего не получат - просто свалят и компании, и всех делов.

+1

+1

[olis]

У нас как то так: начальник спрашивает сколько тебе времени требуется чтобы сделать это?
Отвечаешь: 6 недель.
А почему так много?
Ну извини, мне столько времени требуется.
Начальник: тогда я найду кого нибудь кто сделает быстрее.
Я: Да ради Бога, ищи конечно.

Ну или HQ спрашивает: можно ли закончить вот это к следующей неделе, а то они там большому боссу хотят показать.
Отвечаешь: ни единого шанса.
Тогда HQ пишет письмо моему начальнику, меня в CC лист не включая: типа такой ответ совершенно не приемлим.
Начальник вызывает, показывает письмо.
Ну и чего? Говоришь: да пошли они нах.

Так вот и живем

[fruit6]

а мы вообще эстимейты не ставим. я доверяю каждому из своих ребят, если (устно) говорит +- обернусь тогда то (это не на одну жиру а на всю итерацию), а на деле оказывается чуть раньше или чуть позже, ну значит так получилось. у нас твёрдый договор, халтуру не делать, всё остальное negotiable. и никаких пилюль за "срыв сроков" не предусмотрено. если что то не укладывается в задуманные сроки, совместно думаем чем жертвовать. иными словами о сроках голова болит не у разработчиков, а у меня.

не знаю может у нас это возможно потому что команда небольшая, но имхо получается неплохо. и нервные клетки на месте :-)

Вы описали подход, основанный на здравом смысле. Он, естественно, бъет любой другой срам бюрократический процесс как бык овцу.

[mynameiszb]

Так вот и живем

Мне лишь интересно, как при таком подходе вас еще не уволили
За явное проявление болтоукладывания на тим-билдинг и пр. бюрократический шит