Я в одном комментарии не мог всю теорию вывести, просто привел приблизительное направление решения. Естественно точно, с доказательствами я не смогу на 10 минут все написать. Вот именно из-за этих нюансов, нецелесообразность бросается в глаза. И в большинстве случаев не надо заниматься этой ерундой.
Выплата разрабу - некая монотонно убывающая функция от времени выполнения задания. Премия за оценку - тоже некоторая функция от разности между оценкой и реальным значением. Соответственно, нужно подобрать эти функции так чтобы у разрабов не возникало желания схитрожопить с манипуляцией оценками и времени своей работы.
Я вам должен всю теорию в одном комментарии был написать? Я же написал "приблизительно". Естественно все нюансы нужно учесть, чтобы просто так не получилось схитрожопить с оценками. Если у вас более изящный подход есть, огласите.
Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо?
Я не утверждал что нужно стимулировать разработчиков. Просто если вы хотите получить какую то цифру, желательно имеющую значение, нужно чтобы у людей был стимул делать точную оценку и делать работу максимально быстро (а не по настроению или наличию хорошего кофе). Если эти условия убрать - вы скорее всего не получите нормальных количественных оценок или многократно ухудшите их.
Я не рекомендую так поступать. Я лишь описал возможный способ решения проблемы технически. Я не утверждал что это делать целесообразно. Как судя по тому что получилось нецелесообразность в большинстве случаев бросается в глаза. Если у вас критика технического подхода описанного выше - приводите контрпримеры. Если можете написать лучший технический подход - напишите какой.
Любые подобные метрики "оптимизируются" на раз-два. У вас начнётся банальная "инфляция" оценок - ставишь огромную оценку, и у тебя есть время и для того чтобы "оценка" оказалась "верной", и даже чтобы "выполнить задание быстрее".
Вы не привели контрпример. Если разраб будет оттягивать оценку на поздний срок, он будет гораздо больше терять за медлительность работы. Выплаты разрабам за быстроту работы не связаны с их оценками.
Хотя тут у вас прямо очевидное логическое противоречие. Ведь если выполнил быстрее - значит оценка неверна
Нет противоречия. За быстроту работы получаете больше, чем теряете за неугаданную оценку.
Чтобы доказать что это работает, нужно лишь доказать, что оценка времени выполнения задания программистом дает информацию о реальном времени выполнения им задания.
Вы утверждаете противное? Во всяком случае, строго говоря, нужно исследование на состоятельность этой нулевой гипотезы.
Это работает, просто бизнесу нецелесообразно заниматься этой ерундой (в большинстве случаев). Поэтому никто не занимается и продолжают тыкать. Никто не хочет переводить вопрос из разряда словоблудия менеджеров в техническую плоскость, да и не надо.
Я вообще в первом комментарии не написал, что стоит так поступать. Я написал, что стоило бы сделать, если технически попытаться решать такой вопрос.
В разработке ПО существует неразрешимое противоречие — это оценка сроков.
Просто этой конкретно проблемой часто не занимаются из-за лени менеджеров и прочих ЛПР и "особенностей" бизнеса. С технической точки зрения можно попытаться решить приблизительно следующим образом
Требуем разработчиков оценивать время выполнения работ, собираем статистику
Чтобы устранить влияние прочих факторов, даем стимулы для разработчика:
Выполнишь задание быстрее - получишь больше
Добавляем еще за достоверную оценку времени своей работы (если угадал - получил премию за оценку)
После сбора статистики строим вероятностную модель распределения оценок
Вводим в эту модель функцию риска неправильной оценки сроков (бизнес-требования)
Получаем конечную цифру срока для заказчика
Тут может показаться, что награждать разработчиков за быстрое время выполнения - скользкий путь, но надо понимать, что тут как раз уже наступает реальное противоречие между хотелками бизнеса и приоритетами разработчика. Как эту проблему решать - это уже немного другой вопрос. Во всяком случае стимулы из п.2 нужны для того чтобы
не возникало желания работать "на расслабоне"
у разработчика не возникало желания оттянуть время выполнения до своей оценки, чтобы получить премию за оценку
- длина алфавита - длина пароля - время удвоения вычислительной мощности - начальная скорость перебора, паролей/eд. времени - искомое максимальное время перебора
Составляем уравнение для времени перебора паролей:
После взятия интеграла и решения получаем
Как видно при предельном переходе (скорость вычислений остается постоянной), можно воспользоваться приближением и формула преобразуется в тривиальную
P.S. Оставляю сопоставление параметров , и cо значениями в родительском комментарии в качестве упражнения :)
Да, так и есть. Тут вопрос в том как обобщить отрицательная она или положительная на случай других систем. В физических системах есть понятие энергии - то есть мы можем сказать, если в систему идет накачивание энергии - обратная связь положительная (например, происходит самовозбуждение и автоколебания). Если отрицательная - энергия стремиться к минимуму, другие параметры стабилизируются.
На такие вещи как экономика или социальные процессы обобщить положительную и отрицательную связь наверное можно, но трудно, и похоже надо лезть куда-то в изучение классов решений дифференциальных уравнений.
Ну как пример еще, на озоне несколько лет назад потребовали принести им на заклание телефонный номер, ИЧСХ после этого с паролем вообще войти нельзя в учетку озона (только через код на телефон в крайнем случае на email). Cейчас новым пользователям зарегаться без телефона невозможно. До этого был просто логин/пароль и email.
Кроме того, даже можно было (в старые добрые времена) оплатить товар при получении - кэшем!
Короче это я все к тому, что привязка всего к телефонному номеру - очень опасный тренд последних 5 лет или около того. Он создает больше проблем безопасности, чем все остальное вместе взятое (по моему мнению). Сначала они (доблестные цифровизаторы) решили везде пихать номер ради удобства. Большинство людей не думают и привязывают кучу вещей к одному номеру. Отсюда и проблема утечек - откуда-то что-то утекло с номером из одного места, потом из другого - выполняем join по номеру и узнаем все данные. В банках сейчас походу вообще нельзя без номера телефона даже открыть счет, и при открытии они заставляют согласиться еще, что твои данные передаются некому списку организаций - opt out cделать нельзя. А потом все удивляются почему везде такая(ой) <нужное слово подберите сами> с безопасностью.
И это продолжается. В имеющейся системе я вижу только несколько способов избежания проблем:
пробовать юридически заставлять их выполнять законы (ФЗ "о персональных данных"), отзывать разрешения на обработку, просить всегда уничтожать неиспользуемые данные
везде стараться использовать либо пароли, либо токены безопасности или OTP, но не в коем случае не СМС и номера телефонов
использовать отдельные номера телефонов для каждого сервиса/сайта, либо как минимум один номер телефона для критичных вещей, и один для некритичных
всегда использовать разные email или email aлиасы для разных сайтов
А не помните, номер телефона был тогда в учетке госуслуг сразу после первоначальной регистрации по выданному коду? Вроде бы не было. Вообще вроде только требовался email и ничего более. Вход по СНИЛС(логин) и установленному потом самим паролю.
как и любая система с отрицательной обратной связью он неустойчив
Мне всегда казалось, что отрицательная обратная связь стабилизирует систему. Если проводить аналогию и электротехникой и теорией цепей, то системы с отрицательной связью более устойчивы, в системах же с положительной обратной связью возникают автоколебания или переход в крайние состояния. Опять же, если провести аналогию наоборот - те же экономические циклы и периодические кризисы более похожи на автоколебания - из-за задержек и прочих свойств цепи обратной связи.
Если проводить аналогии дальше, то так называемый "капитализм" скорее похож на систему с неизвестной динамически меняющейся обратной связью, которая может быть как положительной (например ажиотажный спрос на товары, биржевая паника, монопольный захват рынка) так и стабилизирующей отрицательной (конкуренция, выравнивающая цены).
Ну как бы в вашем изначальном комменте вы все правильно написали, за исключением 50%. Просто написал для тех, кто не знает, что игра в красное/черное на рулетке все таки отличается от игры в орлянку.
Лет 10 назад это было вау-вау. И как порядочный гик, был early adopter'ом всего этого, включая Госуслуги.
Вы не помните, случайно как регались? Насколько я помню (тогда ~10 лет назад) нужно было идти в один из УЦ Минкомсвязи с паспортом, потом вам выдавали код на бумажке/конверте для первоначального доступа и регистрации. Причем вроде как никаких привязок к номеру телефона не было, вроде бы даже после такой регистрации телефона в профиле госуслуг не было. Или я что-то неправильно помню?
А теперь везде и всюду форсят телефонный номер, регистрация на госуслугах через передачу данных из банков и прочие "удобные неприятности" - неудивительно, что все пошло по наклонной.
Проблема 1
Как заставить разработчиков не манипулировать временем выполнения (оттягивать срок выполнения)?
Проблема 2
Как заставить разработчиков не манипулировать временем оценки?
Для этого и предложил вещи из пункта 2. Опять же могу ошибаться, но контрпримера обхода пока не увидел.
Я в одном комментарии не мог всю теорию вывести, просто привел приблизительное направление решения. Естественно точно, с доказательствами я не смогу на 10 минут все написать. Вот именно из-за этих нюансов, нецелесообразность бросается в глаза. И в большинстве случаев не надо заниматься этой ерундой.
Выплата разрабу - некая монотонно убывающая функция от времени выполнения задания.
Премия за оценку - тоже некоторая функция от разности между оценкой и реальным значением. Соответственно, нужно подобрать эти функции так чтобы у разрабов не возникало желания схитрожопить с манипуляцией оценками и времени своей работы.
Я вам должен всю теорию в одном комментарии был написать? Я же написал "приблизительно". Естественно все нюансы нужно учесть, чтобы просто так не получилось схитрожопить с оценками. Если у вас более изящный подход есть, огласите.
Я не утверждал что нужно стимулировать разработчиков. Просто если вы хотите получить какую то цифру, желательно имеющую значение, нужно чтобы у людей был стимул делать точную оценку и делать работу максимально быстро (а не по настроению или наличию хорошего кофе). Если эти условия убрать - вы скорее всего не получите нормальных количественных оценок или многократно ухудшите их.
Не забываем https://habr.com/ru/articles/749206/#comment_25770458
Нет. Я же написал, что выплаты разрабам за быстроту работы не связаны с их оценками.
Я повторяю опять. Прочитайте https://habr.com/ru/articles/749206/#comment_25770458
Я не рекомендую так поступать. Я лишь описал возможный способ решения проблемы технически. Я не утверждал что это делать целесообразно. Как судя по тому что получилось нецелесообразность в большинстве случаев бросается в глаза. Если у вас критика технического подхода описанного выше - приводите контрпримеры. Если можете написать лучший технический подход - напишите какой.
Вы не привели контрпример. Если разраб будет оттягивать оценку на поздний срок, он будет гораздо больше терять за медлительность работы. Выплаты разрабам за быстроту работы не связаны с их оценками.
Нет противоречия. За быстроту работы получаете больше, чем теряете за неугаданную оценку.
Чтобы доказать что это работает, нужно лишь доказать, что оценка времени выполнения задания программистом дает информацию о реальном времени выполнения им задания.
Вы утверждаете противное? Во всяком случае, строго говоря, нужно исследование на состоятельность этой нулевой гипотезы.
Это работает, просто бизнесу нецелесообразно заниматься этой ерундой (в большинстве случаев). Поэтому никто не занимается и продолжают тыкать. Никто не хочет переводить вопрос из разряда словоблудия менеджеров в техническую плоскость, да и не надо.
Я вообще в первом комментарии не написал, что стоит так поступать. Я написал, что стоило бы сделать, если технически попытаться решать такой вопрос.
Просто этой конкретно проблемой часто не занимаются из-за лени менеджеров и прочих ЛПР и "особенностей" бизнеса. С технической точки зрения можно попытаться решить приблизительно следующим образом
Требуем разработчиков оценивать время выполнения работ, собираем статистику
Чтобы устранить влияние прочих факторов, даем стимулы для разработчика:
Выполнишь задание быстрее - получишь больше
Добавляем еще за достоверную оценку времени своей работы (если угадал - получил премию за оценку)
После сбора статистики строим вероятностную модель распределения оценок
Вводим в эту модель функцию риска неправильной оценки сроков (бизнес-требования)
Получаем конечную цифру срока для заказчика
Тут может показаться, что награждать разработчиков за быстрое время выполнения - скользкий путь, но надо понимать, что тут как раз уже наступает реальное противоречие между хотелками бизнеса и приоритетами разработчика. Как эту проблему решать - это уже немного другой вопрос. Во всяком случае стимулы из п.2 нужны для того чтобы
не возникало желания работать "на расслабоне"
у разработчика не возникало желания оттянуть время выполнения до своей оценки, чтобы получить премию за оценку
Решил вывести формулу
Составляем уравнение для времени перебора паролей:
После взятия интеграла и решения получаем
Как видно при предельном переходе
(скорость вычислений остается постоянной), можно воспользоваться приближением 
и формула преобразуется в тривиальную
P.S. Оставляю сопоставление параметров
, 
и 
cо значениями в родительском комментарии в качестве упражнения :)
Можно также сказать, что квесты для слабаков. Как говорил великий и ужасный Дональд Кнут - "it's too competitive".
Кому интересно YT видео про "контринтуинивность" многомерных сфер
Да, так и есть. Тут вопрос в том как обобщить отрицательная она или положительная на случай других систем. В физических системах есть понятие энергии - то есть мы можем сказать, если в систему идет накачивание энергии - обратная связь положительная (например, происходит самовозбуждение и автоколебания). Если отрицательная - энергия стремиться к минимуму, другие параметры стабилизируются.
На такие вещи как экономика или социальные процессы обобщить положительную и отрицательную связь наверное можно, но трудно, и похоже надо лезть куда-то в изучение классов решений дифференциальных уравнений.
Ну как пример еще, на озоне несколько лет назад потребовали принести им на заклание телефонный номер, ИЧСХ после этого с паролем вообще войти нельзя в учетку озона (только через код на телефон в крайнем случае на email). Cейчас новым пользователям зарегаться без телефона невозможно. До этого был просто логин/пароль и email.
Кроме того, даже можно было (в старые добрые времена) оплатить товар при получении - кэшем!
Короче это я все к тому, что привязка всего к телефонному номеру - очень опасный тренд последних 5 лет или около того. Он создает больше проблем безопасности, чем все остальное вместе взятое (по моему мнению). Сначала они (доблестные цифровизаторы) решили везде пихать номер ради удобства. Большинство людей не думают и привязывают кучу вещей к одному номеру. Отсюда и проблема утечек - откуда-то что-то утекло с номером из одного места, потом из другого - выполняем join по номеру и узнаем все данные. В банках сейчас походу вообще нельзя без номера телефона даже открыть счет, и при открытии они заставляют согласиться еще, что твои данные передаются некому списку организаций - opt out cделать нельзя. А потом все удивляются почему везде такая(ой) <нужное слово подберите сами> с безопасностью.
И это продолжается. В имеющейся системе я вижу только несколько способов избежания проблем:
пробовать юридически заставлять их выполнять законы (ФЗ "о персональных данных"), отзывать разрешения на обработку, просить всегда уничтожать неиспользуемые данные
везде стараться использовать либо пароли, либо токены безопасности или OTP, но не в коем случае не СМС и номера телефонов
использовать отдельные номера телефонов для каждого сервиса/сайта, либо как минимум один номер телефона для критичных вещей, и один для некритичных
всегда использовать разные email или email aлиасы для разных сайтов
А не помните, номер телефона был тогда в учетке госуслуг сразу после первоначальной регистрации по выданному коду? Вроде бы не было. Вообще вроде только требовался email и ничего более. Вход по СНИЛС(логин) и установленному потом самим паролю.
Мне всегда казалось, что отрицательная обратная связь стабилизирует систему. Если проводить аналогию и электротехникой и теорией цепей, то системы с отрицательной связью более устойчивы, в системах же с положительной обратной связью возникают автоколебания или переход в крайние состояния. Опять же, если провести аналогию наоборот - те же экономические циклы и периодические кризисы более похожи на автоколебания - из-за задержек и прочих свойств цепи обратной связи.
Если проводить аналогии дальше, то так называемый "капитализм" скорее похож на систему с неизвестной динамически меняющейся обратной связью, которая может быть как положительной (например ажиотажный спрос на товары, биржевая паника, монопольный захват рынка) так и стабилизирующей отрицательной (конкуренция, выравнивающая цены).
Ну как бы в вашем изначальном комменте вы все правильно написали, за исключением 50%. Просто написал для тех, кто не знает, что игра в красное/черное на рулетке все таки отличается от игры в орлянку.
Вы не помните, случайно как регались? Насколько я помню (тогда ~10 лет назад) нужно было идти в один из УЦ Минкомсвязи с паспортом, потом вам выдавали код на бумажке/конверте для первоначального доступа и регистрации. Причем вроде как никаких привязок к номеру телефона не было, вроде бы даже после такой регистрации телефона в профиле госуслуг не было. Или я что-то неправильно помню?
А теперь везде и всюду форсят телефонный номер, регистрация на госуслугах через передачу данных из банков и прочие "удобные неприятности" - неудивительно, что все пошло по наклонной.