Как мне кажется, если CTO начинает смотреть в джиру на загрузку каждого конкретного разработчика, то он тратит свой ресурс не совсем на то дело, за которое ему компания платит зарплату.
Одновременно соглашусь и не соглашусь с этим выводом. Соглашусь с тем, что CTO должен понимать как работают команды, какие у них есть сложности и проблемы, какие есть бест практис в индустрии, что чаще работает, что чаще не работает и почему и т.д. То есть CTO должен понимать что загрузка 40ч/неделю на разработчика на продуктовые задачи не соответствует действительности и те сроки, которые приносят команды - это скорее вера, которая основана на опыте. Она может совпадать с действительностью, может не совпадать. И опираться на эти сроки крайне рискованно.
Но при этом подсвечу, что управлять своим бэклогом, давать приближенные к действительности оценки и еще много много чего - это ответственность самих команд. CTO не может и не должен знать и учитывать больничные, отпуска и вот это вот все каждого разработчика. Ему важно когда конкретно эта команда вынесет весь свой функционал в микросервисы/сервисы. Когда конкретно эта команда переведет свои базы с MS SQL в Postgree и т.д. На этом он строит стратегию технического развития продукта и договаривается с бизнесом на выделение ресурса под технические инициативы.
Тут, наверное, стоит разделить два этапа - продумывание реализации и сама реализация. Продумать реализацию, понять все функ. требования и решить противоречия, собрать не функ. требования и придумать как сделать так что бы все работало, всем требованиям соответствовало, при этом реализация не занимала год с переписыванием всех сопутствующих модулей - действительно очень ресурсоемкая задача и тут про 2-3 часа полностью соглашусь.
А вот сама реализация, когда все уже решено и проработано - не такая дорогая операция. Но, подсвечу, что многие пытаются совмещать эти 2 активности по разным причинам. Часто, в сумме, это получается дороже. Но мы все живем в реальном мире и бывает так, что ответов на вопросы в момент продумывание у бизнеса тупо нет и приходится закладывать наиболее вероятный вариант. Потом когда определенность появляется - все перепридумывать, если не удалось угадать.
Я это к тому, что если есть возможность, лучше разделять эти 2 операции, что бы снизить когнитивную нагрузку. Или, хотя бы, двигаться итерациями. Подумал -> поверил в то, что так наиболее правильно делать -> Сделал. Пришли новые вводные - повторил.
Стоит задуматься над тем как разработчик оценивает задачи, если он регулярно успевает сделать за 40-ка часовую рабочую неделю задач на 60 часов, при этом еще и везде успевает и на встречах участвует не просто как голова в камере. Кажется верить его оценкам нельзя. Как результат вряд ли можно спрогнозировать момент когда он, вдруг, перестанет попадать в эти оценки.
Кажется тут стоит уже с самим сотрудником поработать над тем, а от куда он берет эти оценки. Может быть имеет место быть способ, описанный в предыдущем сообщении, когда он просто умножает свою оценку на 2 и транслирует этот срок.
Опять же, нам важна точность оценок, поскольку давление бизнеса всегда очень высокое и когда в нас впихивают невпихуемое требуется аргументировать почему в нас не впихивается так, что бы бизнес понял. Если для вас это не актуально и бизнесу ОК, что вы даете оценки в которых сами до конца не уверены. То тут я абсолютно с вами соглашусь, что переусложнять не стоит.
Как мне кажется, если CTO начинает смотреть в джиру на загрузку каждого конкретного разработчика, то он тратит свой ресурс не совсем на то дело, за которое ему компания платит зарплату.
Одновременно соглашусь и не соглашусь с этим выводом.
Соглашусь с тем, что CTO должен понимать как работают команды, какие у них есть сложности и проблемы, какие есть бест практис в индустрии, что чаще работает, что чаще не работает и почему и т.д. То есть CTO должен понимать что загрузка 40ч/неделю на разработчика на продуктовые задачи не соответствует действительности и те сроки, которые приносят команды - это скорее вера, которая основана на опыте. Она может совпадать с действительностью, может не совпадать. И опираться на эти сроки крайне рискованно.
Но при этом подсвечу, что управлять своим бэклогом, давать приближенные к действительности оценки и еще много много чего - это ответственность самих команд. CTO не может и не должен знать и учитывать больничные, отпуска и вот это вот все каждого разработчика. Ему важно когда конкретно эта команда вынесет весь свой функционал в микросервисы/сервисы. Когда конкретно эта команда переведет свои базы с MS SQL в Postgree и т.д. На этом он строит стратегию технического развития продукта и договаривается с бизнесом на выделение ресурса под технические инициативы.
Тут, наверное, стоит разделить два этапа - продумывание реализации и сама реализация. Продумать реализацию, понять все функ. требования и решить противоречия, собрать не функ. требования и придумать как сделать так что бы все работало, всем требованиям соответствовало, при этом реализация не занимала год с переписыванием всех сопутствующих модулей - действительно очень ресурсоемкая задача и тут про 2-3 часа полностью соглашусь.
А вот сама реализация, когда все уже решено и проработано - не такая дорогая операция. Но, подсвечу, что многие пытаются совмещать эти 2 активности по разным причинам. Часто, в сумме, это получается дороже. Но мы все живем в реальном мире и бывает так, что ответов на вопросы в момент продумывание у бизнеса тупо нет и приходится закладывать наиболее вероятный вариант. Потом когда определенность появляется - все перепридумывать, если не удалось угадать.
Я это к тому, что если есть возможность, лучше разделять эти 2 операции, что бы снизить когнитивную нагрузку. Или, хотя бы, двигаться итерациями.
Подумал -> поверил в то, что так наиболее правильно делать -> Сделал. Пришли новые вводные - повторил.
Стоит задуматься над тем как разработчик оценивает задачи, если он регулярно успевает сделать за 40-ка часовую рабочую неделю задач на 60 часов, при этом еще и везде успевает и на встречах участвует не просто как голова в камере. Кажется верить его оценкам нельзя. Как результат вряд ли можно спрогнозировать момент когда он, вдруг, перестанет попадать в эти оценки.
Кажется тут стоит уже с самим сотрудником поработать над тем, а от куда он берет эти оценки. Может быть имеет место быть способ, описанный в предыдущем сообщении, когда он просто умножает свою оценку на 2 и транслирует этот срок.
Опять же, нам важна точность оценок, поскольку давление бизнеса всегда очень высокое и когда в нас впихивают невпихуемое требуется аргументировать почему в нас не впихивается так, что бы бизнес понял. Если для вас это не актуально и бизнесу ОК, что вы даете оценки в которых сами до конца не уверены. То тут я абсолютно с вами соглашусь, что переусложнять не стоит.