Я бы сказал, что проблема несколько глубже: а каким образом удовлетворённость или состояние потока относятся к инженерным метрикам? В статье немного смешались метрики, подходы и сферические кони в вакууме. Читатель может потеряться.
Строго говоря, состояние потока - это вообще не метрика. Это "перспектива", с которой нужно смотреть на компанию и её процессы. Одна из осей координат, если угодно. Потому что DevEx сам по себе не методология (когда тебе дают чёткие инструменты), а фреймворк (когда акцент делается на практиках и образе мысли). В статье, кстати, DevEx как раз фреймворком и именуется.
Как это работает? Сначала вы выравниваетесь по тому, что для вашей компании или команды является состоянием потока и каким вы его хотите видеть. Потом выделяете факторы, которые влияют на него в лучшую и в худшую сторону. Затем уже эти факторы некоторым образор оцениваете. И это не обязательно числовые значения, это может быть и "хорошо"-"нормально"-"плохо" и т.п.
Далее, оценив своё текущее положение, вы стараетесь внедрить улучшения в тех областях, которые тянут состояние потока вниз.
Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы
Вот тут ещё попрошу пруфы. В каком из изданий Scrum Guide упоминается Velocity как часть фреймворка? В скрам входит только то, что написано в гайде. Всё остальное, даже то, что создатели могу рассказывать на публичных выступлениях или писать в блогах, не является частями скрама.
Потом окажется, что презентацию по обратной связи делал условный Вася, который получит за этот скилл низкую оценку. И как после этого оценивать влияние его презентации на общий уровень в команде?
Как будто можно было сначала провести оценку, а потом поделить темы в зависимости от уровня навыка и критичности скилла.
Проблема этого подхода заключается в том, что собственно менторинга и оценки качества знаний (компетенции) нет. Один коллега что-то самостоятельно изучил, рассказал другим и... И получил галочку, заполнил ещё одну ячейку матрицы?
Трёх скоростей для путешествия априори мало, я про это говорил. Диапазон узкий, разница между передачами скорее всего значительная. С такой трансмиссией силы будут уходить быстрее.
Мягкое седло - синоним онемевшей промежности. На мягком седле приятно проехать 10км в городе по асфальту. Но даже вот так 100+ км проехать - сначала будет жопка побаливать. А потом по докторам ходить придётся.
Натирание происходит либо от неудобного седла, либо от неправильно подобраной одежды. Широкое седло "диван" и труханы+джинсы - залог натирания, например.
Я рад, что герои статьи успешно финишировали. При этом, скажем так, я бы не рекомендовал повторять их эксперимент один в один. Всё же лучше уделить больше времени изучению теоретической базы. Тогда глядишь и поездка дастся легче.
Очередная статья "делайте хорошо, а плохо не делайте")
Я нанимаю профессионалов (хард скиллы)... Я смотрю на софт скиллы...
Поздравляю, вы проводите обычное собеседование и набираете людей как любой рекрутер с годом работы.
Ещё внимание привлёк пассаж про недоверие к скрам мастеру. А к автору статьи у кандидатов или коллег из других команд врождённое доверие? Доверие можно заслужить и любой опытный специалист, особенно отвечающий на налаживание коммуникации, должен уметь это делать. Да, можно говорить, что со старта к скрам мастеру относятся с недоверием - это будет правдой для большинства случаев. Но дайте человеку хотя бы 2-3 недели, а потом считайте цыплят.
Красивый замок из песка, который нужно успеть показать всем, пока он не рассыпался)
Вопрос, который уже накинули здесь и он остался без ответа, это замена выделенного слота на "ещё одно уведомление, на которое нужно ответить". Раньше у трёх амиго был один одинаковый слот. Сейчас амиго всё равно должны находить время, но теперь уже "кто когда сможет".
Далее, а есть ли смысл в "непрерывной" оценке багов через бота? Что с ними дальше происходит? Разработка может сразу брать их в работу? Или всё же есть некий буфер, он же бэклог, который наполняется и оттуда забираются задачи в замисимости от срочности? Если второе, то в чём выигрыш?
Ещё я не заметил упоминания классического фоксу оценивания: если есть хотя бы две сильно отличающиеся оценки, эта задача/баг оценивается отдельно. Потому что это признак некого понятийного разрыва в команде. А тут просто считается среднее.
И это подводит нас к последней мысли. Шакала от 1 до 100? Серьёзно? Кто-то понимает "в граммах" разницу между 60 и 61? Какие у вас в принципе значения приоритетов в тасктрекере?
Во-первых, пюсую опасениям, что размещение "кипятильников" в мировом океане не способствует здоровью планеты. Да, человеки уже заметно повлияли на экосистемы суши. Значит ли это, что теперь пришло время "выжигать" океан? Уверен, что нет.
Во-вторых, при всей технической эффективности подводных ЦОДов, мне не даёт покоя вот какая мысль: неужто подводные ЦОДы не бэкапятся на сушу? Если руководствоваться правилось территориального разнесения резервных копий, то бэкапы должны храниться на удалённой площадке. Либо такой же подводной, либо наземной. Решитесь ли вы иметь и основную и резервную площадку под водой? Если нет, то поздравляю, вам всё равно нужен традиционный ЦОД. Да, в меньших объёмах, но всё же.
Вы удивитесь, но манагерам* реально не нужно в этом разбираться.
(*) - манагерам высокого порядка.
Условно директор молокозавода не обязан уметь доить. Более того, кроме собственно дойки на молокозаводе происходит очень много всего. Там есть ветеринарная служба, транспортный цех, охрана, какая-то айтишка-аникейщики даже и т.п. По-вашему директор должен уметь вообще во всё это? Ну камон.
Что МТС, что СДЭК - это огромные компании, с кучей компетенций внутри. Не надо применять на них лекало "прораб и пятеро работяг".
Кстати, у меня была похожая история как у штатного сотрудника организации. Для своей конторы я оптимизировал расходы на стационарную и мобильную связь. В масштабах организации это были смешные деньги, но по конкретной статье расходы снизились на треть. И это в принципе была первая оптимизация расходов на связь за предыдущие пять лет, которые я застал - этим просто никто не занимался.
И вот, компания сократила расходы на связь на Х денег каждый месяц, т.е. 12Х в год. Сколько я за это получил? Премию примерно Х/10 один раз, даже меньше своего оклада.
Надо сказать, что тогда это серьёзно подкосило мою и без того просевшую к тому времени мотивацию. Не прошло и года, как я уволился.
Подрядчик сэкономил "много денег", получил оплату по часовой ставке - нехорошо.
Давайте посмотрим на полярно противоположную ситуацию.
Подрядчик сделал какую-то мелочь, стоящую мизер или вообще ничего не стоящую, но требует почасовую оплату, т.к. время затрачено - а это уже нормально?)
В целом ситуация не нова. Нередко организации делают что-то в качестве "жеста доброй воли", но на самом деле ожидают за это конкретное вознаграждение в моменте или в перспективе. Это манипуляция и не стОит обижаться, если её объект не ведётся. Вопросы прежде всего нужно задавать тому, кто решил делать это не озадачившись гарантиями получения выгоды.
Так очевидно же, что MVP - это не конечная точка. Автор умалчивает, пытались ли изобретатели первых ламп улучшать свои изделия, т.е. доводить MVP до полноценного, качественного продукта.
А какую литературу тогда читать? "Ничего не делайте, ждите чуда, упаси Господь попытаться вырасти"?)
Литература бывает разная. Есть профильная обучающая литература, фреймворки и т.п. Есть "истории успеха", когда автор рассказывает про свой путь. Ну и есть откровенная вода, когда автор рассуждает о неких сферических конях в вакууме. Понятное дело, что прокачать навыки проще всего по книгам первого типа. Но кроме навыков, хардскиллов, у человека может быть потребность и в мотивации, уверенности в себе, т.е. софт скиллах. Так почему нет?
Я не говорил, что культура куда-то конкретно может привести. Я говорю, что культура помогает компании действительно двигаться куда-то, в одном направлении. В моём понимании в современном мире и тем более в сфере интеллектуального труда корпоративная культура - важная составляющая эффективной работы компании.
Можно представить себе очень простую культуру а ля "копай от забора до обеда и не задавай лишних вопросов, а то тебя уволят". Если вернуться к тому же примеру с Netflix, их CEO уверен, что компания достигла невероятных результатов во многом благодаря культуре открытости, обратной связи, делегирования решений. Но это культура не для "копателей".
Если говорить про "жёсткое управление", то давайте считать это протиповоложностью культуре из предыдущего абзаца. Не делегирование, а замыкание на себя. Не открытость и вовлеченность, а жесткое ограничение на доступ к информации и участию в обсуждениях. И запрет на любые дискуссии с менеджментов. Но это моё видение. За автора статьи я конечно говорить не буду.
На тему культуры можно почитать книжку о внутрянке Netflix "No Rules Rules". Культура - это сочетание как формальных политик, так и неформальных договорённостей, общего видения. Можно очень сильно упороться и расписать на бумаге вообще все аспекты жизни и работы компании, но в большой компании в головах у разных работников это будет отражаться по-разному. И вот поэтому важно заниматься нарративом, культурой и вот этим вот всем.
Фокус в том, что высокая культура - это абстракция высокого порядка. Она доступна только думающим субъектам. А думающие субъекты не очень благосклонно относятся к "жесткому управлению". Если упростить и сгустить краски, то можно даже сказать, что это вещи взаимоисключающие: казарменные порядки и высокоинтеллектуальная публика. Историческое место их пересечения ГУЛАГ точно не походит на организацию, на которую стоит ориентироваться.
Я бы сказал, что проблема несколько глубже: а каким образом удовлетворённость или состояние потока относятся к инженерным метрикам? В статье немного смешались метрики, подходы и сферические кони в вакууме. Читатель может потеряться.
Строго говоря, состояние потока - это вообще не метрика. Это "перспектива", с которой нужно смотреть на компанию и её процессы. Одна из осей координат, если угодно. Потому что DevEx сам по себе не методология (когда тебе дают чёткие инструменты), а фреймворк (когда акцент делается на практиках и образе мысли). В статье, кстати, DevEx как раз фреймворком и именуется.
Как это работает? Сначала вы выравниваетесь по тому, что для вашей компании или команды является состоянием потока и каким вы его хотите видеть. Потом выделяете факторы, которые влияют на него в лучшую и в худшую сторону. Затем уже эти факторы некоторым образор оцениваете. И это не обязательно числовые значения, это может быть и "хорошо"-"нормально"-"плохо" и т.п.
Далее, оценив своё текущее положение, вы стараетесь внедрить улучшения в тех областях, которые тянут состояние потока вниз.
Такие дела.
Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы
Вот тут ещё попрошу пруфы. В каком из изданий Scrum Guide упоминается Velocity как часть фреймворка? В скрам входит только то, что написано в гайде. Всё остальное, даже то, что создатели могу рассказывать на публичных выступлениях или писать в блогах, не является частями скрама.
Цель инженерных метрик
Цели использования инженерных метрик могут быть разнообразными.
Directed by Robert B. Weide
Потом окажется, что презентацию по обратной связи делал условный Вася, который получит за этот скилл низкую оценку. И как после этого оценивать влияние его презентации на общий уровень в команде?
Как будто можно было сначала провести оценку, а потом поделить темы в зависимости от уровня навыка и критичности скилла.
Проблема этого подхода заключается в том, что собственно менторинга и оценки качества знаний (компетенции) нет. Один коллега что-то самостоятельно изучил, рассказал другим и... И получил галочку, заполнил ещё одну ячейку матрицы?
Трёх скоростей для путешествия априори мало, я про это говорил. Диапазон узкий, разница между передачами скорее всего значительная. С такой трансмиссией силы будут уходить быстрее.
Мягкое седло - синоним онемевшей промежности. На мягком седле приятно проехать 10км в городе по асфальту. Но даже вот так 100+ км проехать - сначала будет жопка побаливать. А потом по докторам ходить придётся.
Натирание происходит либо от неудобного седла, либо от неправильно подобраной одежды. Широкое седло "диван" и труханы+джинсы - залог натирания, например.
Я рад, что герои статьи успешно финишировали. При этом, скажем так, я бы не рекомендовал повторять их эксперимент один в один. Всё же лучше уделить больше времени изучению теоретической базы. Тогда глядишь и поездка дастся легче.
Дя, с т.з. велосипедизма странноватая история. Планетарочка на три скорости для путешествия, "южноафриканская Мерида", мягкое седло на дальняк.
Но за само путешествие - однозначно лайк.
Кайфанул от статьи, большое спасибо!
Спасибо, большинству пунктов одобрительно киваю.
Очередная статья "делайте хорошо, а плохо не делайте")
Я нанимаю профессионалов (хард скиллы)... Я смотрю на софт скиллы...
Поздравляю, вы проводите обычное собеседование и набираете людей как любой рекрутер с годом работы.
Ещё внимание привлёк пассаж про недоверие к скрам мастеру. А к автору статьи у кандидатов или коллег из других команд врождённое доверие? Доверие можно заслужить и любой опытный специалист, особенно отвечающий на налаживание коммуникации, должен уметь это делать. Да, можно говорить, что со старта к скрам мастеру относятся с недоверием - это будет правдой для большинства случаев. Но дайте человеку хотя бы 2-3 недели, а потом считайте цыплят.
Красивый замок из песка, который нужно успеть показать всем, пока он не рассыпался)
Вопрос, который уже накинули здесь и он остался без ответа, это замена выделенного слота на "ещё одно уведомление, на которое нужно ответить". Раньше у трёх амиго был один одинаковый слот. Сейчас амиго всё равно должны находить время, но теперь уже "кто когда сможет".
Далее, а есть ли смысл в "непрерывной" оценке багов через бота? Что с ними дальше происходит? Разработка может сразу брать их в работу? Или всё же есть некий буфер, он же бэклог, который наполняется и оттуда забираются задачи в замисимости от срочности? Если второе, то в чём выигрыш?
Ещё я не заметил упоминания классического фоксу оценивания: если есть хотя бы две сильно отличающиеся оценки, эта задача/баг оценивается отдельно. Потому что это признак некого понятийного разрыва в команде. А тут просто считается среднее.
И это подводит нас к последней мысли. Шакала от 1 до 100? Серьёзно? Кто-то понимает "в граммах" разницу между 60 и 61? Какие у вас в принципе значения приоритетов в тасктрекере?
Во-первых, пюсую опасениям, что размещение "кипятильников" в мировом океане не способствует здоровью планеты. Да, человеки уже заметно повлияли на экосистемы суши. Значит ли это, что теперь пришло время "выжигать" океан? Уверен, что нет.
Во-вторых, при всей технической эффективности подводных ЦОДов, мне не даёт покоя вот какая мысль: неужто подводные ЦОДы не бэкапятся на сушу? Если руководствоваться правилось территориального разнесения резервных копий, то бэкапы должны храниться на удалённой площадке. Либо такой же подводной, либо наземной. Решитесь ли вы иметь и основную и резервную площадку под водой? Если нет, то поздравляю, вам всё равно нужен традиционный ЦОД. Да, в меньших объёмах, но всё же.
Истина
Вы удивитесь, но манагерам* реально не нужно в этом разбираться.
(*) - манагерам высокого порядка.
Условно директор молокозавода не обязан уметь доить. Более того, кроме собственно дойки на молокозаводе происходит очень много всего. Там есть ветеринарная служба, транспортный цех, охрана, какая-то айтишка-аникейщики даже и т.п. По-вашему директор должен уметь вообще во всё это? Ну камон.
Что МТС, что СДЭК - это огромные компании, с кучей компетенций внутри. Не надо применять на них лекало "прораб и пятеро работяг".
Кстати, у меня была похожая история как у штатного сотрудника организации. Для своей конторы я оптимизировал расходы на стационарную и мобильную связь. В масштабах организации это были смешные деньги, но по конкретной статье расходы снизились на треть. И это в принципе была первая оптимизация расходов на связь за предыдущие пять лет, которые я застал - этим просто никто не занимался.
И вот, компания сократила расходы на связь на Х денег каждый месяц, т.е. 12Х в год. Сколько я за это получил? Премию примерно Х/10 один раз, даже меньше своего оклада.
Надо сказать, что тогда это серьёзно подкосило мою и без того просевшую к тому времени мотивацию. Не прошло и года, как я уволился.
Подрядчик сэкономил "много денег", получил оплату по часовой ставке - нехорошо.
Давайте посмотрим на полярно противоположную ситуацию.
Подрядчик сделал какую-то мелочь, стоящую мизер или вообще ничего не стоящую, но требует почасовую оплату, т.к. время затрачено - а это уже нормально?)
В целом ситуация не нова. Нередко организации делают что-то в качестве "жеста доброй воли", но на самом деле ожидают за это конкретное вознаграждение в моменте или в перспективе. Это манипуляция и не стОит обижаться, если её объект не ведётся. Вопросы прежде всего нужно задавать тому, кто решил делать это не озадачившись гарантиями получения выгоды.
Так очевидно же, что MVP - это не конечная точка. Автор умалчивает, пытались ли изобретатели первых ламп улучшать свои изделия, т.е. доводить MVP до полноценного, качественного продукта.
А какую литературу тогда читать? "Ничего не делайте, ждите чуда, упаси Господь попытаться вырасти"?)
Литература бывает разная. Есть профильная обучающая литература, фреймворки и т.п. Есть "истории успеха", когда автор рассказывает про свой путь. Ну и есть откровенная вода, когда автор рассуждает о неких сферических конях в вакууме. Понятное дело, что прокачать навыки проще всего по книгам первого типа. Но кроме навыков, хардскиллов, у человека может быть потребность и в мотивации, уверенности в себе, т.е. софт скиллах. Так почему нет?
А вот третьим типом книг только печки топить)
Я не говорил, что культура куда-то конкретно может привести. Я говорю, что культура помогает компании действительно двигаться куда-то, в одном направлении. В моём понимании в современном мире и тем более в сфере интеллектуального труда корпоративная культура - важная составляющая эффективной работы компании.
Можно представить себе очень простую культуру а ля "копай от забора до обеда и не задавай лишних вопросов, а то тебя уволят". Если вернуться к тому же примеру с Netflix, их CEO уверен, что компания достигла невероятных результатов во многом благодаря культуре открытости, обратной связи, делегирования решений. Но это культура не для "копателей".
Если говорить про "жёсткое управление", то давайте считать это протиповоложностью культуре из предыдущего абзаца. Не делегирование, а замыкание на себя. Не открытость и вовлеченность, а жесткое ограничение на доступ к информации и участию в обсуждениях. И запрет на любые дискуссии с менеджментов. Но это моё видение. За автора статьи я конечно говорить не буду.
На тему культуры можно почитать книжку о внутрянке Netflix "No Rules Rules". Культура - это сочетание как формальных политик, так и неформальных договорённостей, общего видения. Можно очень сильно упороться и расписать на бумаге вообще все аспекты жизни и работы компании, но в большой компании в головах у разных работников это будет отражаться по-разному. И вот поэтому важно заниматься нарративом, культурой и вот этим вот всем.
Фокус в том, что высокая культура - это абстракция высокого порядка. Она доступна только думающим субъектам. А думающие субъекты не очень благосклонно относятся к "жесткому управлению". Если упростить и сгустить краски, то можно даже сказать, что это вещи взаимоисключающие: казарменные порядки и высокоинтеллектуальная публика. Историческое место их пересечения ГУЛАГ точно не походит на организацию, на которую стоит ориентироваться.