Да, про подход к выполнению требований регуляторов по персональным данным было бы очень интересно узнать. Это в некоторых проектах сдерживает от использования облачных решений от Azure и AWS.
Кажется, прояснилась одна из причин, почему мы не можем найти со многими общий язык в этом обсуждении. Судя по фразе «как вы бы оценивали хирургов», вы ставите в один ряд метрики (это просто некие характеристики происходящего процесса) и показатели эффективности. Это все-таки разные вещи. На примере футбольной команды — показателем эффективности является количество выигранных матчей, титулов. При этом метрик существует огромное множество — точность передач, количество нарушений, количество забитых и пропущенных мячей и т.п. Стоит ли говорить о том, что метрики — это всего лишь инструмент, позволяющий, лучше понять, что происходит (в основном тренеру и игрокам). Но счёт на табло остается счетом на табло. В вашем примере с хирургами я и правда не знаю, будет ли полезной информация, которую вы предлагаете мерять. Но уж точно оценивать хирурга нужно по успешным операциям.
Я отвечу на ваш вопрос, хоть он и похож на риторический. Нет, я не оценил бы вас таким образом, если все написанное вами правда. Метрика — это всего лишь цифра, которую нужно на равне с другой информацией в последующем использовать для анализа ситуации.
Но и задам вам встречный вопрос: что из написанного мной заставило вас задать такой вопрос? Правда, очень хочу для себя прояснить, как можно было бы понятнее донести мысль, что «чем больше у вас объективных цифр, тем больше шансов разобраться в любой сложной проблеме», не вызвав такое количество странных вопросов.
Почему вам показалось, что увидев такой прекрасный результат вашей работы, я посчитал бы, что важнее количество строк кода? А ещё поделитесь, у вас по такой же схеме и предыдущий проект прошёл? И доводилось ли вам работать с людьми и командами, которые плохо делают свою работу, которые плохо разрабатывают или просто безответственно относятся к работе? Если приходилось, то очень интересно, почему вы игнорировали при этом, что некоторые разработчики вовсе не пишут код? Почему не считали нужным углубляться и разбираться, как так получается?
Я и не утверждаю, что не существует таких задач. Просто кого не спроси вокруг — все пишут в среднем больше. То есть ситуация, когда вы пишете так мало кода за год и это нормально — это скорее исключение, чем правило. Но повторюсь ещё раз — это же всего лишь одна из метрик, на которую можно поглядывать. Если сильно выбивается на фоне других разработчиков, команд — углубляться, что происходит.
Вряд ли для хирургов это релевантная метрика. Тем более, не понятно как ее можно измерить. Но если бы ее можно было легко получить — не думаю что практикующие хирурги отказались бы от такой информации. И какое-то применение ей бы нашли. Хотя тут у хирургов, конечно, нужно спрашивать. А ещё лучше — у преподавателей, которые их готовят.
Я боюсь вы приписываете мне то, чего я не говорил. У меня нет любимых метрик. Но прекрасно, что в среднем вы пишете больше чем две строки в день — я в этом не сомневался почему-то.
Например, да. Или решает в три раза больше задач, если глянуть на другие метрики. Или пишет больше тестов и потом меньше тратит времени на регрессионное тестирование. Разные интересные отличия можно найти в подходах команд и основываясь на этом вырабатывать лучшие практики для конкретного продукта, компании или проекта. И если вы работаете не в формате «собрались на два месяца на проект, чтобы потом год не видеться», то такую работу по постоянному улучшению следует делать систематически. И чем больше цифр у вас будет при этом под рукой — тем больше шансов найти возможности для улучшения. Вы как-нибудь поинтересуйтесь, как в современном мире устроено управление, например, топовыми футбольными или баскетбольными командами. Удивитесь, какое количество информации автоматически собирается и оцифровывается по каждому игроку, как с этим работают разные тренеры.
Глупо спорить, что лучше решить задачу при помощи двух строк, а не двухста. Но на практике задач, которые решаются двумя строками кода — меньшинство. И на длинной дистанции это актуально для 99% разработчиков. И к человеку, который стабильно пишет по две строки кода в день — точно стоит присмотреться и понять, что происходит. Но так поступил бы я, потому что мне не все равно, что происходит на моих проектах. Я так понимаю, если бы кто-то из моих оппонентов в этой ветке у себя в команде столкнулся с разработчиком с таким значением метрики — просто порадовались бы за человека, даже не поинтересовавшись, почему так. Не может же быть, чтобы человек плохо работал. Там точно проработка архитектуры постоянная и жесткий дебаг.
Даже не знаю, что парировать. Вы до этого отвечали, что разработчик может успешно решать задачи, создавая по две строки в день. Сами при этом создаёте существенно больше. Почему думаете, что решая какую-то задачу реальную, можно обойтись двумя строками в день — я так и не понял.
Я уже несколько раз написал, что это одна из метрик, которых на самом деле на много больше — и количество комитов, и количество закрытых задач, и количество найденных ошибок, и любые другие объективно рассчитываемые показатели — все это полезная информация, анализируя которую можно улучшать процессы разработки, диагностировать проблемы в этих процессах. Но вы почему-то приписываете мне желание оценить разработчика по количеству строк кода как по единственному показателю.
Ну и, к слову, пока что-то в этом треде не нашлось много авторов, которые писали бы по две строки в день в среднем. А очень бы хотелось узнать, чем такие люди занимаются.
Нет, конечно. Я нигде подобного не писал. В целом — как только вы пытаетесь подогнать эффективность под какую-то метрику, люди очень быстро адаптируются, чтобы соответствовать вашим ожиданиям. Однако это не означает, что метрики не нужно анализировать — можно много полезного понять сравнивая между собой команды, людей, даже сравнивая в динамике одну и ту же метрику по команде.
Сказать разработчику, что он плохо работает, потому что написал мало кода — это так не работает думаю ни в одной здравой организации. А вот глядя на две команды, работающие на схожей технологии и над схожими задачами, увидеть, что одни пишут в три раза больше кода чем другие — это точно вопрос в котором нужно разобраться и понять, почему так происходит. Подобные метрики — это индикаторы возможных проблем, которые позволяют своевременно углубиться и понять, есть ли проблема на самом деле.
Я правильно понимаю, что руководствуясь этим прекрасным правилом у вас получается решать поставленные задачи, создавая в среднем по две строки кода в день? Если да, то поделитесь, пожалуйста, деталями — какие задачи, какие технологии используете. Очень интересно
В реальной разработке большим количеством команд вам понадобятся метрики, чтобы понимать что происходит. Количество строк кода — одна из таких метрик, на равне с количеством ошибок, частотой поставок и многими другими. К счастью, современные инструменты позволяют получать эти данные практически без накладных расходов. А уже ваша задача, как менеджера, разбираться, какие из метрик о чем сигнализируют. Если у вас такой специфический проект, что количество строк кода не показательно (что-то с оборудованием, сопровождением legacy-систем и т.п.) — вы, предположу, будете опираться на другие метрики. Но на практике, в большинстве проектов используются такие языки программирования и решаются такие задачи, которые подразумевают написание более чем двух строк кода в день одним разработчиком, и такая метрика будет давать полезную информацию.
Да, про подход к выполнению требований регуляторов по персональным данным было бы очень интересно узнать. Это в некоторых проектах сдерживает от использования облачных решений от Azure и AWS.
Спасибо. А как соотносятся области ответственности бизнес-экспертов и product owner?
Расскажите, пожалуйста, подробнее об этом «Бизнес-эксперты работают вместе с разработчиками в одних командах». В каких ролях, по каким процессам?
Кажется, прояснилась одна из причин, почему мы не можем найти со многими общий язык в этом обсуждении. Судя по фразе «как вы бы оценивали хирургов», вы ставите в один ряд метрики (это просто некие характеристики происходящего процесса) и показатели эффективности. Это все-таки разные вещи. На примере футбольной команды — показателем эффективности является количество выигранных матчей, титулов. При этом метрик существует огромное множество — точность передач, количество нарушений, количество забитых и пропущенных мячей и т.п. Стоит ли говорить о том, что метрики — это всего лишь инструмент, позволяющий, лучше понять, что происходит (в основном тренеру и игрокам). Но счёт на табло остается счетом на табло. В вашем примере с хирургами я и правда не знаю, будет ли полезной информация, которую вы предлагаете мерять. Но уж точно оценивать хирурга нужно по успешным операциям.
Я отвечу на ваш вопрос, хоть он и похож на риторический. Нет, я не оценил бы вас таким образом, если все написанное вами правда. Метрика — это всего лишь цифра, которую нужно на равне с другой информацией в последующем использовать для анализа ситуации.
Но и задам вам встречный вопрос: что из написанного мной заставило вас задать такой вопрос? Правда, очень хочу для себя прояснить, как можно было бы понятнее донести мысль, что «чем больше у вас объективных цифр, тем больше шансов разобраться в любой сложной проблеме», не вызвав такое количество странных вопросов.
Почему вам показалось, что увидев такой прекрасный результат вашей работы, я посчитал бы, что важнее количество строк кода? А ещё поделитесь, у вас по такой же схеме и предыдущий проект прошёл? И доводилось ли вам работать с людьми и командами, которые плохо делают свою работу, которые плохо разрабатывают или просто безответственно относятся к работе? Если приходилось, то очень интересно, почему вы игнорировали при этом, что некоторые разработчики вовсе не пишут код? Почему не считали нужным углубляться и разбираться, как так получается?
Я и не утверждаю, что не существует таких задач. Просто кого не спроси вокруг — все пишут в среднем больше. То есть ситуация, когда вы пишете так мало кода за год и это нормально — это скорее исключение, чем правило. Но повторюсь ещё раз — это же всего лишь одна из метрик, на которую можно поглядывать. Если сильно выбивается на фоне других разработчиков, команд — углубляться, что происходит.
Вряд ли для хирургов это релевантная метрика. Тем более, не понятно как ее можно измерить. Но если бы ее можно было легко получить — не думаю что практикующие хирурги отказались бы от такой информации. И какое-то применение ей бы нашли. Хотя тут у хирургов, конечно, нужно спрашивать. А ещё лучше — у преподавателей, которые их готовят.
Я боюсь вы приписываете мне то, чего я не говорил. У меня нет любимых метрик. Но прекрасно, что в среднем вы пишете больше чем две строки в день — я в этом не сомневался почему-то.
Просто пока ваша и моя практика говорят об обратном. А в теории может быть все что угодно, конечно.
Например, да. Или решает в три раза больше задач, если глянуть на другие метрики. Или пишет больше тестов и потом меньше тратит времени на регрессионное тестирование. Разные интересные отличия можно найти в подходах команд и основываясь на этом вырабатывать лучшие практики для конкретного продукта, компании или проекта. И если вы работаете не в формате «собрались на два месяца на проект, чтобы потом год не видеться», то такую работу по постоянному улучшению следует делать систематически. И чем больше цифр у вас будет при этом под рукой — тем больше шансов найти возможности для улучшения. Вы как-нибудь поинтересуйтесь, как в современном мире устроено управление, например, топовыми футбольными или баскетбольными командами. Удивитесь, какое количество информации автоматически собирается и оцифровывается по каждому игроку, как с этим работают разные тренеры.
Бывают, конечно, разные периоды, но в среднем больше. Все пока с этим соглашаются.
Глупо спорить, что лучше решить задачу при помощи двух строк, а не двухста. Но на практике задач, которые решаются двумя строками кода — меньшинство. И на длинной дистанции это актуально для 99% разработчиков. И к человеку, который стабильно пишет по две строки кода в день — точно стоит присмотреться и понять, что происходит. Но так поступил бы я, потому что мне не все равно, что происходит на моих проектах. Я так понимаю, если бы кто-то из моих оппонентов в этой ветке у себя в команде столкнулся с разработчиком с таким значением метрики — просто порадовались бы за человека, даже не поинтересовавшись, почему так. Не может же быть, чтобы человек плохо работал. Там точно проработка архитектуры постоянная и жесткий дебаг.
Даже не знаю, что парировать. Вы до этого отвечали, что разработчик может успешно решать задачи, создавая по две строки в день. Сами при этом создаёте существенно больше. Почему думаете, что решая какую-то задачу реальную, можно обойтись двумя строками в день — я так и не понял.
Я уже несколько раз написал, что это одна из метрик, которых на самом деле на много больше — и количество комитов, и количество закрытых задач, и количество найденных ошибок, и любые другие объективно рассчитываемые показатели — все это полезная информация, анализируя которую можно улучшать процессы разработки, диагностировать проблемы в этих процессах. Но вы почему-то приписываете мне желание оценить разработчика по количеству строк кода как по единственному показателю.
Ну и, к слову, пока что-то в этом треде не нашлось много авторов, которые писали бы по две строки в день в среднем. А очень бы хотелось узнать, чем такие люди занимаются.
Так лично вы сколько кода за последний год написали? Меньше 500 строк? Что разрабатывали при этом?
Нет, конечно. Я нигде подобного не писал. В целом — как только вы пытаетесь подогнать эффективность под какую-то метрику, люди очень быстро адаптируются, чтобы соответствовать вашим ожиданиям. Однако это не означает, что метрики не нужно анализировать — можно много полезного понять сравнивая между собой команды, людей, даже сравнивая в динамике одну и ту же метрику по команде.
Сказать разработчику, что он плохо работает, потому что написал мало кода — это так не работает думаю ни в одной здравой организации. А вот глядя на две команды, работающие на схожей технологии и над схожими задачами, увидеть, что одни пишут в три раза больше кода чем другие — это точно вопрос в котором нужно разобраться и понять, почему так происходит. Подобные метрики — это индикаторы возможных проблем, которые позволяют своевременно углубиться и понять, есть ли проблема на самом деле.
Я правильно понимаю, что руководствуясь этим прекрасным правилом у вас получается решать поставленные задачи, создавая в среднем по две строки кода в день? Если да, то поделитесь, пожалуйста, деталями — какие задачи, какие технологии используете. Очень интересно
В реальной разработке большим количеством команд вам понадобятся метрики, чтобы понимать что происходит. Количество строк кода — одна из таких метрик, на равне с количеством ошибок, частотой поставок и многими другими. К счастью, современные инструменты позволяют получать эти данные практически без накладных расходов. А уже ваша задача, как менеджера, разбираться, какие из метрик о чем сигнализируют. Если у вас такой специфический проект, что количество строк кода не показательно (что-то с оборудованием, сопровождением legacy-систем и т.п.) — вы, предположу, будете опираться на другие метрики. Но на практике, в большинстве проектов используются такие языки программирования и решаются такие задачи, которые подразумевают написание более чем двух строк кода в день одним разработчиком, и такая метрика будет давать полезную информацию.