Robur

Поэтому выходит что ответственность по ревью (или полностью, или всё кроме архитектуры) нужно делегировать лидам команд.

делегируйте, лиды затем и нужны.

Если делегировать ответственность на лидов команд, выходит что общий уровень качества обеспечивается только уровнем команд,

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

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

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

Текст звучит так что у вас есть кто-то слишком за все ответственный, кто контролирует код который пишут 80-100 человек. Это заведомо гиблое дело. Либо у кого-то очень большое эго, если он сам на себя это взял, либо очень слабый характер, если на него навешали. На таких масштабах вам нужны иерархия и делегирование.

Это что касается уровня написанного кода.
А качество самого продукта(и это совершенно другая штука) должен проверять отдел QA. Либо те кто выполняет эти функции, но на таких масштабах у вас должен быть такой отдел из нескольких человек, явно или не явно.

Но с результатами данной формулы не согласно мое начальство и клиенты. Мол, это много.

А как с результатами данной формулы согласуется реальность? Если подходит, то "это много" - чисто дипломатическая задача.
Если ситуация такая что вы говорите "4 часа" и всем "это много", а когда говорите "1 час", и потом все равно делаете 4 часа - это ок, то реально оценка 4 часа.
А если от вас в принципе ждут более быстрой работы чем вы выдаете, и из-за этого напряги, то тут два варианта:
- либо вы действительно медленно все делаете
- либо у менеджмента завышенные и неадекватные ожидания.

нужно определить какой вариант - ваш и действовать в соответствии.

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

еще вот такой метод очень популярен:

Собрал с разработчиков оценку, посчитал. Надо заложить риски.
- умножить на два?
- Нет, на два это не научно. Надо умножать на число e или на число пи, в зависимости от сложности проекта.
- А это как определяется? "E..., какой сложный" и "Пи... какой сложный"?

основные вопросы на которые надо найти ответ:

1. Что думают сами разработчики по этому поводу? Вы с ними общались? какие выводы - что поменяли в основе этого общения?
2. Зачем самим разработчикам трекать это время? вы на них какие-то ваши менеджерские заморочки перекладываете, им все это не нужно и не должно быть нужно. Зачем им ваша "оценка маржинальности проекта"? У них своей работы хватает.

Хотите чтобы все трекали время - дайте им внятный повод зачем им это делать и ощущаемую пользу. Например - оплата почасовая.
"мне нужно чтобы вы это делали" - так себе мотивация. Даже если вы кнута добавите.

Как в конкретной компании организовано так для нее и норм. Подходит ли это вам или нет - это другой вопрос.

В целом конечно размытие обязанностей или работа за пределами вашего набора навыков или контрактных договоренностей это гораздо чаще минус чем плюс. Но бывает что люди наоборот - расширяют свою зону ответственности по разными причинам.

Судя по вопросу это не ваш случай и такая ситауция вам не подходит - так что тут уже другой вопрос - что делать.

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

Важный момент: "тратить на ФОТ меньше чем он реально того требует" - такая себе оптимизация бизнес-процессов. Это как заложить на аренду офиса 2000р когда она стоит 5000. от того что вы на бумаге выделили 2000 потому что "бюджета больше нет" - его вам автоматически за эту цену не сдадут.

Какие-то внятные советы на тему что можно поменять в бизнесе чтобы выйти в плюс - с такой информацией невозможно дать. Да и сайт наверное не той тематики.

Если вы хотите двойное слепое рандомизированное плацебоконтролируемое исследование на тему эффективности применения Agile, то таких нет.
А вообще, неплохо бы привести пример "серьезных научных исследований" других методов разработки продукта, например водопада или канбана или еще чего, чтобы было понятно что вы хотите.

Вокруг этого подхода действительно много шума и бесполезной/неверной информации, много примеров неудачного применения, но это не значит что это фуфло какое-то.

Сам я несколько раз пробовал работать по этой методологии и так и не понял какие задачи она решает.

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

Более того в компании в которой работал от Agail отказались и неожиданно получили прирост в производительности.

И это нормально - может там не было тех проблем на которые нацелен Agile. Можно попробовать молотком забивать шурупы, потом отказаться в пользу ответрки и получить прирост производительности, но это не значит что фраза "молоток - хороший инструмент" это маркетинговый буллшит и надо искать научные исследования на тему молотка. Надо сначала понять как применять молоток правильно и есть ли у вас вообще гвозди которые надо забить. А то может у вас все на болтах там.

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

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

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

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

те прикидки которые выходят, выдают - на мой взгляд - пугающую цену.

вам же надо определить реальность цены а не то пугает она вас или нет. Не стоит занижать просто потому что вам страшно выставить такой счет - если посчитали и получилась какая-то сумма, на нее и ориентируйтесь.

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

Как по мне, адекватная выработка

Адекватная выработка - это то на сколько вы договорились. Если это 10 часов, то 10 будет адекватно. Если 100 - адекватно будет сто. Если "как по вам" не совпадает с тем как договорились или не договорились никак - обсудите с ним.

Если разработчик обещал работать 55 часов а работает 35-40, в первую очередь спросите почему у него самого. Может быть у него ребенок болеет, выгорел, считает что этого достаточно, стыдно тратить ваш бюджет сверх меры и куча еще причин про которые вы не узнаете пока не спросите.

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

Как вы считаете, как лучше в таких случаях мотивировать разработчиков?

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

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

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

Все что с приставкой Lead это уже не про технологию а про людей. Читайте все что найдете про Soft Skills и базовую психологию.
Если хотите прямо по серьезному зайти - то курсы Стратоплана, у них как раз набор на осень.

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

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

Если вы не можете ответить зачем он нужен - значит не нужен.
Прожект нужен когда у вас настолько большой проект что команды (множественное число) уже не могут сами эффективно координировать работу.
А вам возможно и продакт не нужен.

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