The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Микрозадачи, о которых я объяснял в предыдущем посте, работают только тогда, когда у каждой задачи есть конкретное вознаграждение за успех и наказание за неудачу. Я считаю, что лучшим инструментом вознаграждения и наказания является деньги. Бюджет фиксирован, программист получает его только после выполнения задачи (вознаграждение), независимо от того, сколько времени это занимает; если задача не выполнена, денег вообще нет (наказание). Просто и понятно. Однако возникает логичный вопрос: как мы можем заранее знать, какой должен быть правильный бюджет? Кто его устанавливает?
Когда мы начали пробовать микрозадачи в наших проектах в 2009 году, мы просили программистов оценивать каждую задачу. Это работало, но только с очень простыми и очевидными задачами. Более сложные практически всегда страдали от недооценки или завышения стоимости - числа были либо слишком маленькими, и исполнители задач жаловались в конце, либо слишком большими, и заказчики просили возврат средств. Это была неподъемная ситуация.
Затем мы поняли, что будет лучше, если все задачи будут достаточно маленькими, с одинаковым бюджетом. Мы попытались использовать два часа в качестве универсальной и фиксированной оценки. Все, что не вписывалось в это время, программисты имели право отклонить. Но и эту модель не удалось реализовать, потому что наши менеджеры столкнулись с огромным количеством отклоненных задач и не знали, как сделать их меньше, так как они не были программистами.
Наконец, в марте 2010 года мы нашли решение, которое получило название “Puzzle Driven Development” (PDD). Согласно этой концепции: 1) Каждая задача имеет очень маленький фиксированный бюджет (мы используем 30 минут); 2) Исполнителю задачи разрешается выполнить только часть задачи; 3) Код, который возвращается в ветку “master”, должен содержать пометки @todo, называемые “головоломками”; 4) Головоломки автоматически преобразуются в новые задачи.
Преимущество этого подхода заключается в том, что самая сложная часть управления программным проектом - разбиение области - перекладывается на плечи тех, кто в этом лучше всего разбирается: программистов.
Мы сейчас используем PDD во всех наших проектах и даже создали общедоступный инструмент для репозиториев GitHub, который позволяет каждому играть с PDD бесплатно: 0pdd.com. Это точно такой же инструмент, которым мы пользуемся в наших коммерческих проектах.
Однако, если вы решите применить микробюджетирование в своем проекте вместе с PDD, возникнут проблемы. В основном, психологические. Из моего опыта, люди проходят пять стадий, когда они впервые сталкиваются с микробюджетированием:
Гнев. Некоторые из них решают попробовать. Благодаря своему предыдущему многолетнему опыту, они ожидают получить оплату к концу дня/недели/месяца, независимо от того, чем они занимались. Очень скоро они понимают, что общий доход за первый рабочий день составляет $0.00, несмотря на то, что они что-то делали. Они очень злы. Они называют нас мошенниками, обманщиками и множеством других имен. Просьба перечитать политику им не помогает. Они просто не могут поверить, что мы не собираемся им платить ничего, несмотря на то, что они что-то делали. Большинство из них уходит.
Торговаться. Почти каждый на этом этапе рекомендует нам изменить модель. Они объясняют, почему она не слишком эффективна, и насколько было бы здорово, если бы мы платили им традиционным способом. Они приводят нам примеры своих предыдущих проектов, отправляют рекомендации от бывших сотрудников и критикуют мои блог-посты. С некоторыми из них я пытаюсь спорить, когда их критика конструктивна. Большинство из них уходят.
Депрессия. Большинство программистов привыкли работать, потому что им стыдно, если задача не выполнена или ошибка не исправлена. Микробюджетирование требует совершенно противоположного отношения: мы все должны работать, потому что мы жадные. Деньги должны мотивировать нас, а не стыд. Если нет денег, мы не работаем. Большинство людей, увидев эту новую мотивационную парадигму и не увидев привычного стыда, теряют координацию и не знают, что делать. Они не могут действительно достичь чего-либо, потому что за ними не стоит традиционный менеджер, подталкивающий их вперед. Им предстоит идти за деньгами. Они этого не делают, и поэтому не зарабатывают. Большинство из них уходит.
Принятие. Наконец, лучшие из них понимают, что модель может работать, если они следуют правилам, которые очень просты: быть жадными, эгоистичными, центрированными на деньгах, ориентированными на результат, ленивыми, мизантропами, бездушными и высокомерными. Они принимают тот факт, что они проигрывают, конкурируют, работают и зарабатывают деньги только при достижении результатов. Они начинают наслаждаться лучшими чертами меритократии.
Вы уже понимаете, что подавляющее большинство тех, кто пытается работать с нами, на самом деле не могут достичь конечной цели - они отказываются где-то посередине. Скорее всего, на ваших проектах произойдет что-то очень похожее.
Какое здесь решение? Я на самом деле не знаю.
Статистически говоря, только три-пять человек из ста смогут выжить и стать эффективными и продуктивными. Таким образом, чтобы собрать команду из двадцати человек, вам придется просмотреть и попробовать хотя бы 400 человек.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 10:00
