Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Очередное рацпредложение как правильно контролировать процесс? Вместо того чтобы просто смотреть время от времени на реальные результаты? Ну ок.
Да, единственный вариант как сделать так, чтобы сотрудник работал хорошо - это сделать так, чтобы он был сам заинтересован в результатах своей работы. И тут все рецепты давно известны. Либо работа должна быть такая, чтобы человека от ней штырило. Либо у человека должен быть прямой финансовый интерес в компании (доля/RSU/опционы). Оптимально и то и другое.
А на каждый новый кнут найдутся нехитрые способы его обойти.
Не знаю, где вы увидели здесь кнут. Идея была обратная, призванная показать, что 2 строки кода могут даваться очень непросто, в то время, как кнут требует отчитаться, куда ты потратил 2 недели.
А зачем вообще нужно отчитываться и показывать чего-то кому-то, если это про процесс, а не про результат?
У вас же не абстрактные "две строки кода", у вас тикет на них. И на тикет есть какой-то эстимейт. И пусть это будет даже не две строки а минус две строки. А может и вообще ноль строк. Но если тикет закрыт - то результат есть.
Вопросы тут могут быть только если он закрыт за две недели, а заэстимейтен он был на четыре часа. Вот тут да, можно просто поинтересоваться кто был настолько оптимистичен и как избежать этого в будущем (либо эстимейтить лучше, либо в следующий раз поручать такого типа задачи тому, кто сделает их за два часа, а не за две недели).
Зачем отчитываться? Но вы сами говорите про эстимейты. Зачем тогда они? Тикет закрыт, результат есть и ладно. Зачем эстимейты? Для отчетности. Для планирования. Для оценки. Для приоритетов. Бизнес хочет знать, сколько ему это будет стоить до начала, сколько это реально стоило и насколько действительно задача сложная. Но это все суррогат, потому что измеряет теплое в килограммах.
Кто ставит эти эстимейты? Люди. На основании чего? Субъективной оценки: я угадаю эту мелодию с трех нот. Если речь идет о разработке с нуля или линейных изменениях, типа покрасить кнопочку, тогда да, можно оценить трудозатраты. Дизайн есть? АПИ есть? Тогда 10 минут.
Но если ставится задача починить баг или оптимизировать какой-то кусок в легаси. Какая здесь может быть оценка? Это пальцем в небо. Я оптимизирую этот запрос из 500 строк за 2 часа. Что? Как можно дать такую оценку не зная причины тормозов? Там может быть все что угодно, от конфигов до блокировок и умирающих дисков.
А если кто-то скажет месяц, но починит за час, нужно ли здесь поинтересоваться, кто был настолько пессимистичен и как избежать этого в будущем? А может кто-то справился бы за полчаса. Нужно ли передать такого типа задачи тому, кто справился бы за полчаса?
Здесь уже оценка скорее сводится тому, насколько эта починка необходима. Некий верхний порог, типа если за 2 дня не удастся разобраться - откладываем на неопределенный срок.
Все, что описано в статье, это про то, почему на задачу было потрачено Х часов. Действительно человек ей занимался или просто сказал что она сложная, а сам развлекался неделю, даже не прикасаясь к ней. После сорванных сроков попросил еще времени. Суррогатные метрики обесценивают труд одних, но необоснованно поднимая стоимость других.
Я вам расскажу историю из студенческих лет.
Подрабатывал я в автосервисе электриком. Однажды состоятельный клиент привез старый УАЗик, чтобы подготовить его для охоты. Он не скупился на запчасти. Там поменяли КПП, половину мотора и прочего. Одной из задач было установить туда новое электрооборудование: стеклоочиститель, новые фары, вывести управление светом на подрулевой переключатель и прочее. Как вы знаете, в старом УАЗике подрулевой только один, управляющий поворотниками. Был куплен новый руль от волги, торпеда, подрулевые, двигатель дворников с несколькими скоростями и программируемым интервалом. Осталось дело за малым - подключить это все.
Я 2 недели приходил по вечерам, прозванивал, обжимал клеммы, плел новые жгуты из проводов, каждый провод был с биркой и подписан. Никакой изоленты. Схему нарисовал.
Знаете, как руководство сервиса оценило мою работу? Они взяли нормачасы из официальной книжки автоваза.
Замена подрулевого (с/у) 10 минут.
Замена кнопки габаритов (с/у) 3 минуты.
Замена реле стеклоочистителя (с/у) 1 минута.
И т.д.
Получите 300р.
Якобы это я такой медленный, раз делал так долго. Вон, в книжке все давно рассчитано и клиента они возьмут по книжке. (конечно они все понимали, просто не хотели мне платить 30%, как изначально договорились)
(с УАЗика они взяли за эту работу 5000р, а 95 бензин тогда стоил 17р)
Так какой тут должен был быть эстимейт? По книжке ~30 минут.
Ну тут у вас ключевой вопрос "а кто эстимейтит".
Зачем эстимейтить понятно - не для отчётности, а именно для планирования. Когда не влезает в отведённые сроки, надо урезать функционал.
А вот эстимейтят либо сами инженеры, либо PM со слов тех же инженеров. Если это происходит как-то по-другому, то надо просто в спокойном режиме искать нормальную работу.
Умиляет такой стиль кода:
вместо:
if (a == b) c = d; else c = e;писать:
if (a == b) {
c = d;
}
else {
c = e;
}Мастер-класс по KPI.
c = a == b ? d : e;
Вообще форматтеры у всех давным-давно живут. И запускаются либо в pre-commit hook, либо вообще по любому изменению в файле.
Так что как не пиши отформатирует одинаково.
А потом добавится еще действий, и все равно разворачивать.
Мне ваш вариант не нравится: это он в однобуквенных переменных читается, а в длинных - либо уйдет за экран, либо сам перенесется. Не лучше тогда и скобочки добавить для будущих поколений.
И Diff наглядней будет.
Я как-то по запарке после такого if ещё строчку вставил и потом долго тупил со странных результатов. После этого предпочитаю всегда фигурные скобки ставить, а для компактности тернарный оператор есть.
В Гугл, похоже, об этом тоже что-то знают
https://google.github.io/styleguide/javaguide.html#s4.1-braces
Braces are used with
if,else,for,doandwhilestatements, even when the body is empty or contains only a single statement.
func some(a,b,d,e int) int {
if a == b {
return d
}
return e
}
func main() {
...
c := some(1,2,3,4)
}
Есть мнение, что платить нужно именно за количество строк кода.
Что толку от того что вы поправили 2 строчки кода? Через месяц причину уже не вспомнить, придет другой человек и уберет их, чтобы поправить очередной баг, и тоже потратит на удаление целую неделю. Кроме этих 2-х строчек должны были родиться тесты на 100 строчек кода. И вот за эти 102 строчки и нужно начислять зарплату.
Руководители и старшие разработчики не в счет. Их сложно померить. Можно предложить считать строчки кода подчиненных с некоторым коэффициентом.
Давайте не будем придумывать, какими способами можно еще греть планету через инференс. Всегда же можно рендерить котиков!
А по сути, эта статья как будто из года 2005. Ностальгия есть, к этим замечательным временам "неделя мучения, и вот они заветные три строки". Но сейчас нет. Если это багфикс, то хоть и сам фикс может занимать даже одну строку, или один символ, как артефакты работы нужны еще тесты, которые не проходятся старым кодом, и скорее всего, очевидно, небольшое изменение архитектуры, чтобы эти тесты подключить к проблемному коду (и если "не повезет" очень как дофига придется замокать). Если это архитектурное изменение, то хорошо, редко, но возможно, что все изменение в API это три строки. Но это еще пачка вики-док с описанием как мигрировать, чем лучше новое решение, как минимум. И опять же тесты. Ну а фичи на три строчки маловероятны. Тут наоборот, в каком-нибудь легаси, кажется что фича на три строки, а в реальности пришлось перелопатить полтысячи.
А в 2005 да, бывало такое, что эти три строки достались сутками ковыряния бинарей в дизассемблере и отладчике. Но обычно это когда что-то сделать "нельзя, не надо, но очень хочется". Но сейчас такие практики, мб, только у вирусописателей и остались.
Не верю я в три строчки, не верю.
Конечно 3 строчки это багфикс/оптимизация или доработка. Разве где-то речь шла о том, что это новая фича?
О каком 2005 и дизассемблере вы говорите? Я вам приведу десятки примеров, как в современных архитектурах не могли починить месяцами плавающий баг авторизации из-за куков. Выделяли каждый спринт несколько часов. Каждый новый решатель говорил, что предыдущий балбес, а я вот точно знаю где искать. Но обломали зубы. Баг так и живет.
О том 2005, где в небольшой компании живет жесткий водопад, репозиторий cvs (это хорошо, если так) и файлики. Там же в этих файликах выкидывались какие-то progress_module1.txt, какие-то сборочные артефакты, какие-то тестовые бинари и у кого как. Тогда да, работа это то, что попадает в репозиторий, а остальное раз в месяц сносил админ (на самом деле эникей, которого пнули, что место на шаре мол кончается). В тех же файликах еще нередко валялись фотки с новогоднего корпоратива, ppt презентации для заказчиков, какие-то небольшие игрухи. Замечательные были врема, спору нет...
И если Вы продолжаете в них жить, да при текущем уровне зарплат, то ничуть не сострадаю вашей проблеме, скорее просто завидую.
Но какие багфиксы на три строчки в этом мире? Говорите, плавающая проблема? Так первое с чего начинают, строят образ проблемной конфигурации (даже в самом унылом случае, это виртуалка с специально сконфигурированной средой, которая попадает потом в бинарные артефакты), а чаще это отдельный бранч, где плавающий баг специально доталкивается до повторяющегося отдельным кодом. И это еще до непосредственно исследования бага и его исправления. Потом отладка, и исправление. Да даже если непосредственно обход проблемы занимает три строчки, нужно всегда смотреть на окружение этого кода, постараться рефакторить то, что этот баг скрывало. Ну и в конце концов тесты. Чтобы вот четенько было видно, что до фикса тест был красненьким (да-да, этого не обязательно можно добиться юнит-тестами, и тогда проблемные конфиги надо включать уже в интеграционные тесты, в общем тут еще больше вариантов), но вот эти тесты точно никак нигде и никогда не будут тремя строчками.
С моим опытом скажу, что любые PR в три строчки без других артефактов (обозначено выше) можно сначала отклонить, а потом уже изучить. Потому что это не будут фиксы, в 98% это просто костыли. В 1%, ой-бой, это исправление безобидного недосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.
А дальше все просто, если у сотрудника эти 1% превращаются в хотя бы 20% его работы, то вывод даже без теоремы Байеса понятен, он халтурит.
Про оптимизации еще смешнее. Вот тут хочу любой пример. Да, в три строчки где-то можно поменять под задачу коллекцию вроде дерева, на хэш-мапу. Или убрать лишний запрос к БД, потому что в соседнем поле эти данные и так болтаются. Но остаются два вопроса, как в эти три строчки уместить еще и доказательство того, что оптимизация полезна в принципе (то есть как "у себя локально потестил", вроде в 2 раза быстрее, а вам зачем знать, что и как я тестил), и что там можно две недели оптимизировать, когда профайлеры всего и везде есть.
Все когда-то халтурили, все иногда выгорали, изредка можно встретить реально противную проблемку, но что бы три строчки кода за две недели без других артефактов было хоть чем-то похожим на норму говорить смешно. А если это превращается в 6 строчек за месяц, то грустно, и пора с человеком прощаться.
Я не очень понимаю вектор этого разговора. Зачем вы навешиваете на меня ярлыки, которых нет. "2005 год, водопад..." Это не моя проблема. Я не пишу код уже давно (о чем говорил в самом начале), хотя по-прежнему очень близок к разработке. И как бы если посмотреть с этой позиции, можно сказать, что мне все равно, как там ПМ оценивают свои сторипоинты. Я лишь поделился размышлениями и не более.
Если суть статьи вам не понравилась и вы не увидели в нем рационального зерна, ок.
Может вам не понравился заголовок статьи и вы хотите сказать, что он неправдоподобен? Это просто заголовок. В статье несколько другой посыл.
построить образ проблемной конфигурации
А разве чтобы его построить, не нужно вникнуть в проблему и изучить хотя бы условия, при которых это воспроизводится. Разве это не интеллектуальная деятельность?
Все это окружение, виртуалки, эксперименты, о которых вы говорите, разве будут как-то отражены в финальном комите? Но вы их делали. Вы тратили время на гипотезы и их проверки.
Там будет только фикс по делу. Артефакты могут остаться, если кто-то требует их в качестве доказательств, но это не всегда и не везде так. Если у вас этот процесс налажен - прекрасно. Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.
Потом отладка, и исправление
Вот в этом и кроется вся соль задумки. Отладка это не нажатие одной кнопки. Весь процесс этой отладки никто не видит. Не видно количества усилий, которые были на это затрачены. Видно только результат фикса, новые тесты, что-то еще. Это все готовый результаты. Они не появились по щелчку пальцев. Вы работали, думали, искали нестыковки. Это интеллектуальная деятельность, объем которой не виден в комите и в скринах. Этого артефакта просто нет, потому что нет системы, которая могла бы его зафиксировать. Не видно путь, который вы прошли, чтобы получить результат.
Вы говорите про высокий уровень разработки в современном мире? Скорее он перегружен процессами вокруг, а багов стало только больше. Фреймворки генерят что-то под капотом, создавая мусорный код, а разраб не знает, как работает ORM и дергает в цикле атрибут БД.
Пример про баг в три строчки: когда убрали WITH NOLOCK, который кто-то когда-то добавил. Халтура это была или оправданный хинт на тот момент - неизвестно. Но он был. А человек уже давно не работает. В какой-то момент это выстрелило. Оказалось, что он где-то внутри вложенного запроса в хранимке, которая вызывается только в одном месте раз в квартал. И это то, о чем вы говорите:
В 1%, ой-бой, это исправление
безобидногонедосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.
Это не значит, что так не бывает.
Пример оправданной оптимизации:
Чтобы в наше время кто-то действительно этим занимался... В современном мире мне назвать такой пример сложно. Это скорее исключение. Потому что сторипоинты показывают, что проще докупить еще мощностей в ЦОД. Проще послать пользователя подальше, и сказать, что у него старый телефон, чем заниматься оптимизацией. Это реальность. Куча багованого софта, который никто никогда не будет исправлять, потому что якобы всего одна жалоба за все время, а не мажор. Зато там все покрыто автотестами.
Вы пользуетесь оперой? У нас же явно сказано, что мы гарантируем только хром.
Разве не так выглядит реальность? Но это уже очень большое отступление от темы статьи.
Повторюсь, мне непонятен контекст разговора. Что мы обсуждаем?
PS. Статья не предлагает менять подход к разработке. Статья лишь предлагает попробовать оценить когнитивные затраты.
Я не пишу код уже давно
Вот а я пишу код. Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
Обе проблемы важны, требуют решения, но обычно в грамотно организованных командах они решаются через фиксацию промежуточных результатов. Это важно еще и с другой стороны, что "недоделанное" решение, имеющее полезные артефакты (ту же конфигурацию, где проблема повторяется) можно перенести на другого программиста, если у изначально ее решавшего, появляется более срочный кейс.
Даже менее консистентные промежуточные результаты в большинстве компаний фиксировались, если это тикет на плавающий баг, то ежедневно обновляется план дальнейшего исследования, и фиксируются попытки, которые не привели к результатам. Поначалу, там, где не было так принято, некоторые носы ворочали, а потом сами убедились, что очень удобно придти в понедельник "с пустой головой" и понять с чего надо продолжить. А тикет всегда добавляется в PR.
Может изначально я как-то слишком прямолинейно начал, но, хоть и не отрицаю проблем, описанных в статье, утверждаю, что решение уже есть, и оно в организации работы команды. Для хаба "управление разработкой" это как бы довольно очевидно.
Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.
Вот именно. Я бы это бы и сказал, может помягче, но суть та же. Не надо позволять работникам даже играть в Генри Форда. Если не ставить документирование о выполненной работе в процессы команды, то очень быстро команда фрагментируется до тех кто использует отсутствие лишней вербозности себе в плюс, и на тех, кто от этого "молча" страдает.
Это сломанный процесс, который раньше решали либо глупыми и формальными KPI, либо ежедневными собраниями по полчаса, где все отчитываются друг перед другом что делают (но слово не воробей), либо вообще в стримы с экрана (а их все равно никто не смотрит, или смотрят когда и так уже ясно, что человек не работает).
А проблему "старается"/"не старается" не нужно решать. Вот допутим некий Коля берет некую "сложную задачу" (потому что либо плавающая, либо описание неполное, либо ранее ее уже кто-то брал, но не справился, или она снова всплыла). Оценивает ее в две недели. Открывает отладчик, и начинает там рандомные какие-то пути гонять, в код поглядывая, надеясь что проблема на глаз найдется. А что, времени еще уйма, если он ждет решения в три строчки, то он хоть в последний момент его может разродить.
Прошла неделя, проблему Коля не смог воспроизвести, но уже в принципе придумал решение в 5 строчек, как ее вообще закостылить. Сидит дальше в отладчике ковряет. Вот уже два дня осталось, Коля уже коммитит свой workaround в 5 строчек, в тикете пишет, "проблема не воспроизвелась, но теперь она точно не вылезет". Надеется на чудо в пятиницу, но если что готов, сделать PR того что есть. Старался? Ну да, наверное. Или просто фрустрировал. Но дело не в этом, дело в том, что проблема решена хреново. И это выстрелит при первом же существенном рефакторинге. И Коля это знает. И теперь, чтобы не встрять еще долго он не будет брать задачи связанные с рефакторингом.
Допустим я беру такую задачу. Первым делом пытаюсь уточнить подробности о проблеме, чаще всего они исходят от клиентов продукта/сервиса, параллельно добавляю логирование всех хоть как-то связанных с проблемой мест. Логи естественно отключаемые. Сразу добавляю несколько тестов, которые хоть на моей машине и будут зелененькими, но есть шанс, что где-то, хоть на CI мигнут. Мигнут тесты, будут логи, будет понимание проблемного стейта. Если проблема еще более редкая, то уже буду просить клиентов, понятно через службу поддержки, развернуть апдейт, который якобы чинит баг, ну и здесь понятно что можно и дальше рабочий процесс рассказывать, но да, это не игра в одни ворота. "Коля, отладчик, код, и тишина". Здесь нужна организация. Часто люди за этим и идут работать в команду.
И так у них и складывается понимание, что есть хорошая команда, а что слабая, что есть удобная организация, а что бардак. Хорошие практики закрепляются, эволюционируют...
И тут Вы правы, дело не в 2005 году. В принципе это просто часть моего опыта. Но где-то с тех пор, ни в каких других командах (а не все из них были прям супер) такой практики как "две недели - три строчки кода" ни в прямом ни в менее строгом значении уже не существовало.
А когда нет юниттестов, логов, билдсервера, CI, автотестов, специалиста поддержки пользователей, таск трекера, гита, - хотя бы чего-то из этого, то путь может быть сложнее.
Полностью согласен с вашим посылом и вижу, что у вас очень большой опыт.
либо вообще в стримы с экрана (а их все равно никто не смотрит, или смотрят когда и так уже ясно, что человек не работает)
Вот смысл статьи как раз оцифровать (картировать) это. Построить паттерны.
Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
И ту и другую. Если из этих тепловых карт удастся выделить паттерны. Каждый найдет в них свое. Программист поймет, что он не просто так потратил время. Будет видно его интеллектуальную активность на все 100, что нет повода для неловкого чувства. И руководство увидит способы мышления для разных людей, а так же то, что одни задачи эффективнее решает Вася, а другие - Петя. Но это будет не субъективная оценка начальника, а реальная карта. Как-то так.
Мне очень нравилось и до сих пор нравится когда у тебя в пуле разные задачи: в одних тебе надо потратить неделю и в результуте написать две сьрочки, в других за 1 день написать 500. В этом случае ты можешь начать с непонятной баги, котрая случается только на проде, и если нет прогресса, перейти к какой-то скучной технической таске.
Мне скидывали вот такие видео от одного известного в своих кругах товарища:
https://youtube.com/shorts/FZqBp1i73tI?si=p6MKkKS2DyrdPgpb
https://www.youtube.com/live/\_H0isUrZ8l0?si=WvLa7Hf4eSxJm4aP&t=35m52s
Вот. Самая актуальная тема разработчик и оценка его деятельности. Я бы предложил кто захочет пусть кидают предложения как проверить что программист вообще работал. Тут просто вариантов много, но нужен самый эффективный.
Вот опять же - зачем нужно проверять «что программист работал»? Сизиф вон тоже работал.
Если мы говорим об абсолютно любом бизнесе, а даже и не бизнесе, некоммерческой или государственной организации, то единственный критерий - это результат работы. Новый функционал. Оптимизация старого функционала (измеряемая - уменьшение задержек или количества запросов, уменьшение затрат, поддержка большого количества устройств). Облегчение дальнейшей поддержки проекта или имплементации нового функционала.
Процесс работы ради процесса (например стремление сделать код максимально изящным и красивым) - это абсолютно бессмысленное, не сказать вредное. Кстати очень многие опен-сорсщики приходящие в коммерческие компании этого не понимают. И обижаются когда их стремление отполировать код до совершенства никто не ценит
Бизнес хочет понимать, что он заплатил Х не за красивые глаза.
Что есть результат? Выпуск фичи?
У бизнеса есть масса задач, а ресурс, в виде программиста, ограничен.
Если строить деловые отношения на доверии, из предположения, что человек не просто так делал работу долго, а что это действительно нельзя было сделать быстрее, то ваш вариант нормальный. Но это утопия.
Бизнес же хочет сделать что-то еще за этот период, сроки горят. А программер вроде как занят другой задачей. Именно из-за наличия других задач, которые бизнесу тоже нужны сейчас, возникает резонный вопрос: Программист действительно ей занят или просто тянет время? А если поднажать на газ?
Обычно бизнес платит оклад и хочет за этот оклад (по сути абонентская плата) получать максимально возможное количество фичей. Но фича получилась только одна.
У бизнеса всегда будут вопросы:
Почему только одна?
А могли ли мы получить 2 фичи?
Что нужно, чтобы было 2 фичи?
Может, нам купить печеньки или более мощное оборудование? Изменить график работы? Чего не хватает, чтобы было 2 фичи в месяц?
Все вот эти сторипоинты это лишь попытка бизнеса суррогатными метриками доказать самому себе, что он использовал ресурс на максимум.
Мне кажется у вас есть небольшое непонимание того, как работает бизнес. То есть на уровне, условно говоря, ночного ларька, всё примерно так. Но для чуть более сложных систем всё чуть сложнее. Для больших корпораций - вообще совершенно по-другому.
Да, у бизнеса есть масса задач, это верно. И тактических, и стратегических. Для реализации этих задач бизнесу нужны ресурсы. Человеческие ресурсы в том числе. Но рассуждать о них в терминах "сроки сгорят" и "фичей сделать" - это крайнее упрощение. Иногда (я бы даже сказал изредка) встречающееся среди младшего менеджмента в не самых крупных и удачливых компаниях, но не более того.
Бизнес заинтересован в деньгах. Деньги - это не обязательно прибыли (в информационных технологиях и вообще хайтеке даже чаще всего совсем не прибыли). Деньги - это не фичи. Деньги - это то, как оценивается компания. На основании того, что она делает. Или планирует сделать. Или на основании интеллектуальной собственности которая у неё есть. Или аудитории (в широком или узком смысле - два десятка топовых хирургов мирового уровня пользующихся специализированным софтом сделают компанию гораздо более дорогостоящей чем два миллиона бездельников, условно тапающих на условного хомяка, хотя это тоже каких-то денег вероятно стоит).
Фичи? Фичи это хорошо, когда надо именно фичи. Когда они создают customer value, если она важна. Иногда компании держат какой-то проект и соотвественно команду на проекте исключительно для того чтобы держать часть рынка, или ту же интеллектуальную собственность. Будет добавлено сто фич или ноль фич - вообще без разницы. Иногда компании (особенно крупные) держат сотрудников просто для того чтобы иметь возможность бросить их на какой-нибудь другой проект. И они могут вообще ничего не делать, это выгодно бизнесу, потому что у них есть ресурс и пространство для маневра. Ну хорошо, конечно, когда этих людей можно чем-то занять (например тот же код в порядок приводить, если делать больше нечего), но и это совершенно не обязательно.
Не говоря уж о случае, когда человека держат просто за имя или за звания. И исключительно это добавляет к стоимости компании (и к деньгам соотвественно), а уж что он делает - вообще не важно. Кстати бывает что таким людям лучше б вообще ничего не делать (особенно на уровне менеджмента), меньше убытков будет.
Ну и возвращаяся к тому самом простому случаю, с фичами. Бизнесу по-хорошему совершенно параллельно, кто там и сколько будет работать. Ему нужны фичи в определённые сроки за определённые деньги. Плюс какая-то гибкость в возможности изменять количество добавляемых фич, сроки и деньги (понятно что эти три параметра взаимосвязанные). А уж как это делается (и кем конкретно - штатным сотрудником, контрактором, внешним подрядчиком) - это вообще дело двадцатое. А уж то, сколько километров наматывает мышкой и сколько строк коммитит конкретный Вася - это вообще никому по-хорошему не интересно.
Сейчас вы смещаете фокус в другое русло и противоречите себе
Коротко хронология нашей беседы
Зачем проверять, работал ли программист? Результат - это фичи, оптимизация, польза. Процесс ради процесса - вреден. Полировка кода без бизнес-цели - бессмысленна.
Окей. Давайте про результат. Бизнес купил программиста и хочет максимум результата (2 фичи вместо одной). Почему только одна? Может, ему печенек не хватает? Бизнес ищет метрики, чтобы понять, выжал ли он из ресурса всё.
Вы мыслите на уровне ларька. В большой корпорации часто держат людей просто так - для пространства, для маневра, для имени, для захвата рынка. Фичи - это не главное. Главное деньги - это капитализация. Считать комиты и строки - удел мелких. Важны лишь сроки, бюджет и результат, а процесс - дело десятое. Если результат предоставлен в срок, ты - молодец.
Противоречие
Если бизнесу плевать на фичи, и он держит людей ради имени или чтобы забить рынок, то вопрос «Почему программист сделал мало фич?» просто не возникает. Понятие эффективности не возникает. Бизнес не дергает такого программиста вопросами про сторипоинты. (Но бизнес почему-то дергает. Видимо, ларечники, в душе).
Если же бизнес задается вопросом «Почему только одна фича?», значит, он находится именно в той парадигме, где важна эффективность и где каждый день простоя - это потеря денег. И эти самые фичи оформляются как CAPEX (инвестиция), чтобы показать инвесторам активы. Задавая вопрос "почему только одна фича?" бизнес как раз и стремится увеличить актив, минимизируя CAPEX (вложения).
Смещение фокуса
Сначала вы говорите, что не нужно отчитываться за процесс, потому что важен результат. Отчитываться нужно за результат и платить за него же.
Затем внезапно вы говорите, что корпорации нанимают Звезду, которая ничего не делает, но это увеличивает привлекательность компании.
Однако компания сознательно пошла на первый и на второй шаг. И ждет от каждого из них разный результат. Измеряет эти результаты и путь к ним по-разному .
Нанимая программистов ждет фичи и задает вопросы об эффективности: почему одна фича, а не две
Нанимая Звезду ждет имидж и взлет акций и задает вопросы о PR: почему только 0.5% конверсии
Компания задает эти вопросы, потому что они неизбежны где есть деньги. Бизнес покупает станок, который по паспорту производит Х деталей в час. Как только запаса мощности перестанет хватать, рано или поздно бизнес задаст вопрос: Почему Х? А как сделать Х+1? Бизнес вынужден лезть в процесс. Он пока не готов покупать второй станок и пытается понять, все ли соки он выжал из существующего.
Как раз все эти суррогатные метрики и являются изобретением крупного и гигантского бизнеса. Мелкому и среднему это не надо, хоть они и пытаются посматривать на старших братьев. Но там все на виду. Директор видит, что Вася сидит до ночи и в курилке не появляется уже неделю, потому что НДС и аврал.
А в крупном, с размытой географией и часовыми поясами, где не понятно, как за всеми уследить, начинают изобретать/покупать сотни разных метрик.
Метрики - это дитя недоверия, рожденное масштабом.
Естественно я сместил фокус. На то о чём начали говорить вы.
Вы начали говорить об интересах бизнеса.
На что я вам сказал что даже фичи - это вообще ни разу не основной интерес бизнеса.
А даже если вернуться исключительно к фичам, то замеры трудолюбивости конкретного Васи - это вообще ни о чём.
Ну и да, вы видите "противоречия" в том, что я говорю что бизнес - это вообще-то не что-то простое, и бывают разные ситуации и разные требования.
При этом обратите внимание на свой лонгрид - вы везде описываете "бизнес" как какое-то одно существо с одним желанием. Когда в реальности это множество интересов совершенно разных людей, часто взаимоисключающих (но правда деньги нравятся всем, и тут можно найти общее, да и то я вам элементарно приведу десяток примеров того, как под деньгами каждый понимает совершенно своё, и опять же интересы людей могут быть полностью противоположны).
И да, метрики от недоверия - есть такое. Не то чтобы прям необходимое, но работает чтобы отфильтровывать хотя бы небольшой процент тех кто уж совсем ничего не делает и никакого толку не приносит никаким образом. Просто один из механизмов саморегуляции, который, кстати, применяется не всеми и не везде.
Идея хорошая, а норм реализации или идею конкретную или предложение не понял. Где-то видел новость, что пытаются создать новый формат для гит в котором комментарии будут идти не от пользователя, а от аи которая этот код изменяла, и будут метаданными рядом со строками самими. Чтобы видеть ее скитания. Похоже на твою идею?
Вероятно, вы про Git AI
Не совсем то. GitAI фиксирует рассуждения модели, промежуточные этапы, уточнения контекста.
С живым человеком рассуждения зафиксировать не получится. Человек просто делает и не проговаривает это все. Но можно зафиксировать инкрементальные изменения того, как вы писали слово "привет".
п->пр->при->прив->приве->привет
Затем ставили перед ним табуляции, меняли регистр
привет->_привет->__привет->__Привет
Это все действия, которые были сделаны до того, как появился какой-то работающий блок кода
Далее вы с кем-то обсуждали в чате эту задачу.
Трекер видит, что обсуждение в контексте этой задачи и добавляет этой задаче баллы.
Еще вы читали stackoverflow на тему этой задачи и трекер снова отмечает это.
Сырой лог можно затем сжать в некие формы.
Все эти маркеры выстроить в некую последовательность и вес (но это уже этап анализа и построения карты)
Мне сложно сейчас сказать, на что будет похожа эта карта и какие выводы из нее можно будет сделать, но задумка в этом.
ИИ здесь нужен для выделения паттернов, потому что вручную этот "шум" анализировать невозможно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Три строки кода за две недели — это не всегда лень