Почему сильные разработчики ненавидят тайм-трекеры, но любят UpCore?

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

Мы пошли другим путем. UpCore вообще не требует от программистов никаких отчетов. Лучший отчет - это их код.

Мы проводим классический код-ревью, как обычный тимлид. Только у человека часто не хватает времени, и получается глубоко оценить лишь 5-10% работы, а цифровой тимлид делает оценку всего кода, написанного за месяц, за считанные минуты. 

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

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

👇 А как в вашей компании оценивают вклад разработчиков и решают, кому повысить зарплату?

Немного оффтопа)

Пока на улицах бегают люди, а не роботы, и это очень круто!

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

Мы в Dex сами организуем ИТ ЗА!БЕГ и знаем, как это непросто. Поэтому большое спасибо организаторам и всем участникам за атмосферу 👍
Всем здоровья!

А теперь серьезно!)
Про математику и точность.

Начинаю рассказывать, как наша система работает «под капотом».

Поскольку UpCore делает выводы, напрямую влияющие на зарплаты команд, наш главный приоритет - точность.

До сих пор на рынке нет единых стандартов. В одной компании человек Middle, в другой он же считается Senior. А как сравнить эффективность двух людей, если один вайбкодит MVP-лендинг, а второй ищет плавающий баг в легаси-проекте на миллионы строк кода?
Кажется, что привести это к общему знаменателю невозможно, но мы нашли решение!

Короткий ответ - декомпозиция и статистика.

🔹 Любую сложную задачу нужно разделить на простые факторы. В нашей системе их более 50. Какой язык и технологии используются (их особенности и грейды по карте компетенций)? Какой объем, сложность, тип проекта и задач? Давно ли человек работает в проекте? Код в ядре или на периферии? Какова цикломатическая, когнитивная и логическая сложность? Есть ли в коде «шумы» (автогенерация, копипаст, ренеймы, синтаксис)? Сколько «результирующего кода» и багов? Качество кода и код-ревью?
И еще много других, про каждый из которых можно написать отдельный пост (накидайте лайков, если тема интересна!). 

🔹 Второй наш принцип достижения высокой точности - это большой объем данных.
В рамках одной задачи дать точную оценку почти невозможно. Даже опытные лиды разойдутся во мнениях (один скажет 4 часа, другой - 8).
Более того, даже профессиональный мотивированный программист может встать «не с той ноги» и на задачу, которую он обычно решает за 4 часа, сегодня потратить 8. И это нормально!
Но наш цифровой тимлид за пару минут оценивает не одну, а 100 подряд идущих задач! И в каждой - более 50 факторов. А вот тут уже статистика работает безотказно!

Плюс к этому, всё это считает не ИИ, а старая добрая математика. Еще год назад мы отказались от ИИ в пользу надежных детерминированных алгоритмов и матмоделей. ИИ может ошибаться, а математика — нет. В результате UpCore стабильно достигает точности в 85% от уровня глубокой ручной экспертной оценки. 

В следующем посте расскажу, что же именно мы считаем и в какие бизнес-метрики переводим обычный код.

Code Churn: кто съедает ваш ФОТ и как с этим бороться?

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

Высокий процент Code Churn (потери при отладке) - это красный флаг для СТО и HRD. Чаще всего он возникает по трем причинам: человек не тянет грейд и пишет костыли, аналитика меняется на лету, либо разработчик слепо копирует решения из ИИ. 

Проблема в том, что классические трекеры этого не видят. Для них важен сам факт потраченного времени.

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

Сразу видно: один инженер пишет чуть медленнее, но сохраняет 90% кода. А второй печатает как пулемет, но 50% его работы уходит в корзину вместе с деньгами бизнеса.

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

Под капотом UpCore: что такое архитектурная ценность кода?

Почему иногда 50 строк одного кода могут быть дороже 1000 строк другого?

Первый разработчик за неделю наклепал 10 простых формочек для MVP. Второй неделю сидел над изменением 50 строк кода глубоко в ядре системы.

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

В ядре UpCore заложена сложная метрика оценки - архитектурная ценность кода.
Мы учим цифрового тимлида смотреть на проект глазами архитектора. Для этого система строит полное AST-дерево связей. Математически вычисляем, как каждый класс и метод связаны с остальным проектом. 

Построить такое дерево - задача нетривиальная. Особенно когда в проекте активно используется автомаппинг, и многие зависимости скрыты «под капотом» фреймворка. Но мы научили систему распутывать эти связи.

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