В чём заключается мотивация человека, который хочет не сегодня, но завтра себе больше позволить, чем сегодня?
Это человек типа X. Ему нужны кнут и пряник. Так ему понятнее и комфортнее. И не нужно его перевоспитывать. Он будет прекрасно работать в компании типа X (с псевдо-agile или без него). А из компании Y его лучше мягко попросить уйти. В его же интересах.
То же самое касается людей типа Y в компаниях типа X.
Когда цель просматривается плохо, да еще и имеет тенденцию к перемещению (что характерно для многих проектов разработки ПО), высокая производительность работает как инерция, снижает результативность.
Получается, что работаем производительно, двигаемся быстро, но приходим не туда, куда нужно.
Поделюсь опытом работы в одной крупной компании. Стандартизация там была на высоте. Целые департаменты занимались созданием и контролем соблюдения стандартов. Заказчик что-то хотел, но его быстро ставили на место, подгоняли под стандарт. Называлось "инженерной культурой" (хотя, скорее, это был "синдром инженера"). Результативность была очень низкой. Некоторые проекты после нескольких лет разработки сворачивали, так и не запустив в эксплуатацию.
Стек был единый, шаблоны и стандартные решения отрабативались годами (если не дясятилетиями), и вот какие были в этом недостатки (помимо вышеупомянутой низкой результативности):
мы использовали технологии >10 летней давности; забудьте про модернизацию, даже версии не обновлялись (так как было слишком много зависимостей)
ошибок было много, так как стандартные решения были старыми и обросшими "костылями", заглядывать внутрь было страшно
планирование, и вообще, разгон проекта до плановой скорости занимал немало времени – не меньше полугода уходило на составление ТЗ, согласование архитектуры и прочие подготовительные работы, чтобы потом взять, и быстро всё сделать
общение было далеко не эффективным, так как сводилось к написанию и прочтению заданий, требований, регламентов и процедур, обвинениям в нарушении таковых и парировании этих обвинений
В статье говорится, что стандартизация помогает со всем этим бороться, но на мой взгляд, как раз наоборот, именно она это порождает.
Между стандартизацией и свободой необходим баланс. Перекос в любую сторону ведет к негативным последствиям.
К сожалению, перекос в сторону стандартизации царит в большинстве крупных российских ИТ компаний.
Допускаю, что в стартапах есть перекос в другую сторону, но для них производительность – вообще не цель, важна только результативность.
В Agile оценку задач рекомендуют делать на общем собрании команды. Так есть возможность обсудить, подсветить риски, задать уточняющие вопросы, ответы на которые сразу услышат все. Если делать оценку off-line, то теряеются преимущества живого общения (быстрая обратная связь, подтверждение правильности понимания и т.п.). Кроме того, совместная деятельность сплочает команду.
примерно понятно, кто сколько в SP может закрыть от общего количества и планирование идет с учетом этого
Для планирования используется velocity всей команды. Она учитывает всё разнообразие темпов участников команды. Индивидуальные velocity будут менее стабильными, чем velocity всей команды (сеньор ведь тоже может промахиваться с оценками отдельных задач).
Или у вас состав команды нестабилен? Если так, очень рекомендую стабилизировать его, как можно скорее. Команда, состав которой не меняется, со временем начинает работать намного эффективнее.
Как объективно оценить, кого стоит повысить, поднять зарплату и наградить премией, а кому подыскать замену?
По-моему, это единственный вопрос, на который дает ответ performance review. Вопрос действительно актуальный во всех компаниях, и, как сказал автор в заключении, здесь лучше иметь какую-то систему, чем разрешать менеджерам действовать наобум.
Как повысить производительность команды, чтобы за то же время делать в полтора раза больше?
Как замотивировать, чтобы люди горели своей работой?
На эти два вопроса ответа в статье я не увидел. Я вообще не упоминал бы их в связи с performance review.
Плохо проведенный performance review может сильно и надолго демотивировать сотрудника. А вот подхлестнуть в другую сторону, повысить энтузиазм, он вряд ли способен. Премия или даже повышение зарплаты даст лишь кратковременный эффект. Так как повышать зарплату после каждого ревью невозможно, все последующие ревью без повышения з/п будут лишь демотивировать.
Как в ценном сотруднике распознать слабые стороны и дать ему развивающий фидбэк?
В разных источниках я встречал утверждение о том, что полезным и развивающим может быть только фидбэк, не привязанный к материальному вознаграждению. Попытка объединить развитие сотрудника с performance review — самая большая ощибка существующих систем.
Реальные шороховатости лучше видны изнутри. Я могу судить только по косвенным факторам.
Все последующие спринты сделаем двухнедельными, так мы сможем экономить время на планированиях.
Выигрыш сомнительный: если спринт больше, то и планирование его займет дольше.
Спринт – это цикл получения обратной связи (разумеется, вы должны уметь этой обратной связью пользоваться). Чем он короче, тем лучше, особенно в условиях неопределенности. Но на практике не всегда удается уменьшить его до желаемого размера.
Обычно размер спринта – это срок, в течение которого команда способна выполнить минимальный законченный объем работ, который, как минимум, можно показать заказчику, а в идеале еще и вывести в продакшн. Этот срок может зависеть от проекта, размера задач в нем, технологического процесса CI/CD, слаженности работы команды, накладных издержек.
Если команда не может закончить взятые задачи внутри спринта, можно попробовать удлинить спринт. Но лучше разобраться и устранить причины этого.
Оценки не совпадают, дискуссия, обсуждение, вновь оценка… Было одно планирование, на которое мы потратили целый рабочий день, с 10 до 19 и так и не пришли к консенсусу.
Консенсус не обязателен. Важно, чтобы все участники высказались и поняли опасения друг друга. Потом обычно берут максимальную оценку.
Вообще, если группа людей ходит по кругу и не может придти к консенсусу, это означает, что они обсуждают не то, что на самом деле их тревожит. Если человек снова и снова повторяет одно и то же, значит он не чувствует, что другие поняли его точку зрения. Вместо того, чтобы спорить с ним, надо подтвердить, что вы его услышали (пересказать своими словами то, что он говорит, чего опасается, и попросить подтвердить, правильно ли вы его поняли).
Планирование вслепую
Как вариант, попробуйте покер планирования.
Вообще, мне кажется, у вас многовато параметров, таблиц и прочего учета. Попробуйте упросить процесс. Вы правильно написали, что оценка должна учитывать и сложность, и неопределенность, и объем, но после небольшой практики участники обычно могут оценить всё это интегрально одним числом в стори-поинтах.
следим за велосити каждого из команды
В Agile команда – это единое целое. Поощряется совместная работа нескольких (или даже всех) участников команды над одной задачей. Раздельный учет чего-либо разобщает команду, что наносит больший ущерб, чем может быть получена выгода (есть ли вообще она?) от индивидуального учета.
Организация статусов задач
Я не вижу у вас в процессе тестирования. У вас этим занимается отдельная команда? Такое разделение практикуют во многих организациях. И это первое, что надо устранять при переходе на Agile – включать тестировщиков в команды разработки. Здесь вы получите существенный выигрыш в производительности, а главное, в оперативности обратной связи.
Зачем вообще оценивать производительность разработчиков? Обычно это нужно менеджеру.
У него два главных вопроса:
Как понять, насколько эффективно работают мои подчиненные? Не дурачат ли они меня?
Как продемонстрировать начальству, что я – эффективный менеджер?
Вот бы найти чудо-метрику "эффективности", она бы на оба вопроса ответ дала.
Стремлению найти метрику также способствует менеджерская истина: управлять можно только тем, что можно измерить.
Я бы переформулировал её так: тем, что можно измерить, намного легче управлять.
Вот и получается, что увлечённые погоней за "эффективностью" менеджеры управляют лишь тем, что удается измерить.
Всё как в анекдоте: "Почему вы ищете часы возле фонарного столба? Вы их здесь потеряли? — Нет, потерял я их в канаве, но там темно, и ничего не видно".
Для начала, я бы посоветовал разобраться, что значит быть эффективным (см. статью) в каждом конкретном случае. А уж потом искать метрики.
SAFe и LeSS внедряют в крупных организациях, которые изначально "красные". Да, фреймворк – это "клетка", но в данном случае она скорее призвана защитить "зеленые ростки" от "красной среды". Иначе им здесь просто не выжить.
По моему опыту именно так это и работает. На начальном этапе фреймворки сильно помогают. Объясняют "красным" людям, что такое Agile на доступном им языке.
Позволят ли фреймворки переродить всю организацию – в этом я не уверен.
Кадровый голод – существенный фактор. Работаем с теми, кого удалось найти. Но даже этих людей можно правильно распределить. И даже когда распределение сделано, можно каждого понять и правильно использовать. Не душить естественные устремления человека, и напрвлять в правильное русло. На всех уровнях нужно это учитывать.
Рабочие процедуры четко документированы, процессы налажены. Сдача-приемка между отделами проходит по графику. Разработанный продукт в точности соответсвует ТЗ. Но внешнего результата нет. Работа ради работы.
не свойство Agile. Не надо присваивать чужие достижения
У Agile нет и не может быть достижений. Он практически ничего не изобрел, да и цели такой не было. Группа (небезызвестных) разработчиков ПО собралась и сформулировала Манифест – свод ценностей, которых они сами придерживаются и считают важными.
Рефакторинг был популяризован в рамках eXtreme Programming (XP) за несколько лет до публикации Манифеста, а изобретен еще раньше. Да и вообще, изобретать тут особо нечего, просто здравый смысл. Тем не менее, это – Agile-практика. Не потому что только Agile сделал её возможной, а потому что она соответствует его ценностям. Весь eXtreme Programming был признан Agile методологией, хотя и существовал намного раньше.
все что вы перечисляете — это свойства просто хорошо организованного процесса разработки
Так и есть. И если Вы согласны с тем, что эти свойства хороши, значит Вы тоже разделяете ценности, описанные в Agile Манифесте. Хоть, возможно, узнали об этих свойствах и без помощи Agile.
Вообще я задумывал эту статью не как рекламу Agile. Не для того, чтобы сказать, что он хорош, а для того чтобы разобраться, что же такое Agile. Пока мы не сошлись в определении, бессмысленно говорить, хорошо это или плохо.
В комментариях вижу недовольство Agile, но о каком Agile вы пишете? О том, который определен в Манифесте, или о том, который описан в моей статье, или о том, каким вы его себе представляете?
Давайте поговорим именно об определении, и как вы его трактуете. Я описал свою трактовку. Опишите вашу.
Обучение можно и нужно закладывать при планировании. Если этого не происходит, вы работаете не совсем по Agile.
В SAFe, например, каждый пятый спринт рекомендуют полностью посвящать "инновациям и планированию". Обучение явно указано как один из видов деятельности в этот спринт.
Кроме того, для изучения новых областей и технологий, необходимых для проекта, можно заводить задачи типа Spike.
Ваша цель не уникальна и никому не чужда. На этой почве Вы найдете общий язык со многими. Возможно, поделившись своей целью с коллегами, вы станете больше доверять друг другу, сработаетесь в отличную команду.
Возможно после этого Вы сможете поделиться с ними и другими своими целями, о которых пока стесняетесь говорить, прячась за маской циника.
«договориться», «подмазать», «достать по блату», «дать на лапу», ..., «найти профессионалов» – всё это виды отношений с людьми, которых Вы, кажется, хотели избежать.
Это человек типа X. Ему нужны кнут и пряник. Так ему понятнее и комфортнее. И не нужно его перевоспитывать. Он будет прекрасно работать в компании типа X (с псевдо-agile или без него). А из компании Y его лучше мягко попросить уйти. В его же интересах.
То же самое касается людей типа Y в компаниях типа X.
Когда цель просматривается плохо, да еще и имеет тенденцию к перемещению (что характерно для многих проектов разработки ПО), высокая производительность работает как инерция, снижает результативность.
Получается, что работаем производительно, двигаемся быстро, но приходим не туда, куда нужно.
Поделюсь опытом работы в одной крупной компании. Стандартизация там была на высоте. Целые департаменты занимались созданием и контролем соблюдения стандартов. Заказчик что-то хотел, но его быстро ставили на место, подгоняли под стандарт. Называлось "инженерной культурой" (хотя, скорее, это был "синдром инженера"). Результативность была очень низкой. Некоторые проекты после нескольких лет разработки сворачивали, так и не запустив в эксплуатацию.
Стек был единый, шаблоны и стандартные решения отрабативались годами (если не дясятилетиями), и вот какие были в этом недостатки (помимо вышеупомянутой низкой результативности):
В статье говорится, что стандартизация помогает со всем этим бороться, но на мой взгляд, как раз наоборот, именно она это порождает.
Между стандартизацией и свободой необходим баланс. Перекос в любую сторону ведет к негативным последствиям.
К сожалению, перекос в сторону стандартизации царит в большинстве крупных российских ИТ компаний.
Допускаю, что в стартапах есть перекос в другую сторону, но для них производительность – вообще не цель, важна только результативность.
Похоже, это относится только к новым ритуалам. А от старых отказаться, всё-таки, не получается:
А разве Agile не прадлагает альтернатив без костылей?
На мой взгляд, цифровая бюрократия ненамного лучше бумажной.
В Agile оценку задач рекомендуют делать на общем собрании команды. Так есть возможность обсудить, подсветить риски, задать уточняющие вопросы, ответы на которые сразу услышат все. Если делать оценку off-line, то теряеются преимущества живого общения (быстрая обратная связь, подтверждение правильности понимания и т.п.). Кроме того, совместная деятельность сплочает команду.
Для планирования используется velocity всей команды. Она учитывает всё разнообразие темпов участников команды. Индивидуальные velocity будут менее стабильными, чем velocity всей команды (сеньор ведь тоже может промахиваться с оценками отдельных задач).
Или у вас состав команды нестабилен? Если так, очень рекомендую стабилизировать его, как можно скорее. Команда, состав которой не меняется, со временем начинает работать намного эффективнее.
По-моему, это единственный вопрос, на который дает ответ performance review. Вопрос действительно актуальный во всех компаниях, и, как сказал автор в заключении, здесь лучше иметь какую-то систему, чем разрешать менеджерам действовать наобум.
На эти два вопроса ответа в статье я не увидел. Я вообще не упоминал бы их в связи с performance review.
Плохо проведенный performance review может сильно и надолго демотивировать сотрудника. А вот подхлестнуть в другую сторону, повысить энтузиазм, он вряд ли способен. Премия или даже повышение зарплаты даст лишь кратковременный эффект. Так как повышать зарплату после каждого ревью невозможно, все последующие ревью без повышения з/п будут лишь демотивировать.
В разных источниках я встречал утверждение о том, что полезным и развивающим может быть только фидбэк, не привязанный к материальному вознаграждению. Попытка объединить развитие сотрудника с performance review — самая большая ощибка существующих систем.
Реальные шороховатости лучше видны изнутри. Я могу судить только по косвенным факторам.
Выигрыш сомнительный: если спринт больше, то и планирование его займет дольше.
Спринт – это цикл получения обратной связи (разумеется, вы должны уметь этой обратной связью пользоваться). Чем он короче, тем лучше, особенно в условиях неопределенности. Но на практике не всегда удается уменьшить его до желаемого размера.
Обычно размер спринта – это срок, в течение которого команда способна выполнить минимальный законченный объем работ, который, как минимум, можно показать заказчику, а в идеале еще и вывести в продакшн. Этот срок может зависеть от проекта, размера задач в нем, технологического процесса CI/CD, слаженности работы команды, накладных издержек.
Если команда не может закончить взятые задачи внутри спринта, можно попробовать удлинить спринт. Но лучше разобраться и устранить причины этого.
Консенсус не обязателен. Важно, чтобы все участники высказались и поняли опасения друг друга. Потом обычно берут максимальную оценку.
Вообще, если группа людей ходит по кругу и не может придти к консенсусу, это означает, что они обсуждают не то, что на самом деле их тревожит. Если человек снова и снова повторяет одно и то же, значит он не чувствует, что другие поняли его точку зрения. Вместо того, чтобы спорить с ним, надо подтвердить, что вы его услышали (пересказать своими словами то, что он говорит, чего опасается, и попросить подтвердить, правильно ли вы его поняли).
Как вариант, попробуйте покер планирования.
Вообще, мне кажется, у вас многовато параметров, таблиц и прочего учета. Попробуйте упросить процесс. Вы правильно написали, что оценка должна учитывать и сложность, и неопределенность, и объем, но после небольшой практики участники обычно могут оценить всё это интегрально одним числом в стори-поинтах.
В Agile команда – это единое целое. Поощряется совместная работа нескольких (или даже всех) участников команды над одной задачей. Раздельный учет чего-либо разобщает команду, что наносит больший ущерб, чем может быть получена выгода (есть ли вообще она?) от индивидуального учета.
Я не вижу у вас в процессе тестирования. У вас этим занимается отдельная команда? Такое разделение практикуют во многих организациях. И это первое, что надо устранять при переходе на Agile – включать тестировщиков в команды разработки. Здесь вы получите существенный выигрыш в производительности, а главное, в оперативности обратной связи.
Спасибо за статью. Очень напомнило мои собственные первые шаги в сторону Agile. Не всё гладко пока, но вектор правильный.
Особенно понравилось жизненное описание проблем, фиксация достигнутых результатов (ценностей).
Зачем вообще оценивать производительность разработчиков? Обычно это нужно менеджеру.
У него два главных вопроса:
Вот бы найти чудо-метрику "эффективности", она бы на оба вопроса ответ дала.
Стремлению найти метрику также способствует менеджерская истина: управлять можно только тем, что можно измерить.
Я бы переформулировал её так: тем, что можно измерить, намного легче управлять.
Вот и получается, что увлечённые погоней за "эффективностью" менеджеры управляют лишь тем, что удается измерить.
Всё как в анекдоте: "Почему вы ищете часы возле фонарного столба? Вы их здесь потеряли? — Нет, потерял я их в канаве, но там темно, и ничего не видно".
Для начала, я бы посоветовал разобраться, что значит быть эффективным (см. статью) в каждом конкретном случае. А уж потом искать метрики.
SAFe и LeSS внедряют в крупных организациях, которые изначально "красные". Да, фреймворк – это "клетка", но в данном случае она скорее призвана защитить "зеленые ростки" от "красной среды". Иначе им здесь просто не выжить.
По моему опыту именно так это и работает. На начальном этапе фреймворки сильно помогают. Объясняют "красным" людям, что такое Agile на доступном им языке.
Позволят ли фреймворки переродить всю организацию – в этом я не уверен.
В статье я увидел только одну полезную и худо-бедно измеримую метрику: были ли достигнуты бизнес цели / решены поставленные задачи?
Ну, ещё посещаемость – но это, на мой взгляд, для особо запущенных случаев.
Число коммитов – это сродни числу строк кода. Ни о чем не говорит (в лучшем случае, о посещаемости).
Оказание помощи – такая цель может легко увести в сторону.
На скриншотах упоминаются Teamwork, Efficiency, Technical Debt, но совершенно непонятно, как их измерить.
Для меня вопрос остался неотвеченным.
Кадровый голод – существенный фактор. Работаем с теми, кого удалось найти. Но даже этих людей можно правильно распределить. И даже когда распределение сделано, можно каждого понять и правильно использовать. Не душить естественные устремления человека, и напрвлять в правильное русло. На всех уровнях нужно это учитывать.
Однако, на практике встречается. Часто.
Рабочие процедуры четко документированы, процессы налажены. Сдача-приемка между отделами проходит по графику. Разработанный продукт в точности соответсвует ТЗ. Но внешнего результата нет. Работа ради работы.
У Agile нет и не может быть достижений. Он практически ничего не изобрел, да и цели такой не было. Группа (небезызвестных) разработчиков ПО собралась и сформулировала Манифест – свод ценностей, которых они сами придерживаются и считают важными.
Рефакторинг был популяризован в рамках eXtreme Programming (XP) за несколько лет до публикации Манифеста, а изобретен еще раньше. Да и вообще, изобретать тут особо нечего, просто здравый смысл. Тем не менее, это – Agile-практика. Не потому что только Agile сделал её возможной, а потому что она соответствует его ценностям. Весь eXtreme Programming был признан Agile методологией, хотя и существовал намного раньше.
Так и есть. И если Вы согласны с тем, что эти свойства хороши, значит Вы тоже разделяете ценности, описанные в Agile Манифесте. Хоть, возможно, узнали об этих свойствах и без помощи Agile.
Она и не задумывалась дать его. Речь здесь только об определении.
Это точно не про Agile. Об этом сказано в 8-м принципе Манифеста. И мой критерий номер 1 это подчеркивает.
Это про Agile. По сути, мой четвертый критерий.
Хотели сделать одно, а получилось другое. Не думаю, что это имеет отношение к Agile. Скорее говорит о том, что не получилось с первого раза.
Очевидно нарушено требование Agile фокусироваться на ценности для клиента (критерий 3).
Но зато обратная связь работает (критерий 4). Может раньше проблем не было, потому что о них никто не знал (не выполнялся критерий 2)?
Вообще я задумывал эту статью не как рекламу Agile. Не для того, чтобы сказать, что он хорош, а для того чтобы разобраться, что же такое Agile. Пока мы не сошлись в определении, бессмысленно говорить, хорошо это или плохо.
В комментариях вижу недовольство Agile, но о каком Agile вы пишете? О том, который определен в Манифесте, или о том, который описан в моей статье, или о том, каким вы его себе представляете?
Давайте поговорим именно об определении, и как вы его трактуете. Я описал свою трактовку. Опишите вашу.
Обучение можно и нужно закладывать при планировании. Если этого не происходит, вы работаете не совсем по Agile.
В SAFe, например, каждый пятый спринт рекомендуют полностью посвящать "инновациям и планированию". Обучение явно указано как один из видов деятельности в этот спринт.
Кроме того, для изучения новых областей и технологий, необходимых для проекта, можно заводить задачи типа Spike.
Совершенно верно. В статье я неточно выразился, но имел в виду именно это.
Ваша цель не уникальна и никому не чужда. На этой почве Вы найдете общий язык со многими. Возможно, поделившись своей целью с коллегами, вы станете больше доверять друг другу, сработаетесь в отличную команду.
Возможно после этого Вы сможете поделиться с ними и другими своими целями, о которых пока стесняетесь говорить, прячась за маской циника.
И всё это, походу, никак не противоречит Agile.
«договориться», «подмазать», «достать по блату», «дать на лапу», ..., «найти профессионалов» – всё это виды отношений с людьми, которых Вы, кажется, хотели избежать.