The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
“Что ты делаешь сейчас?” - когда вы слышите этот вопрос от своего начальника, будьте готовы: вы имеете дело с микроменеджером. Задачей этих существ является занятие нас, и вот что делает их такими раздражающими. В отличие от этого, эффективные менеджеры следят за тем, чтобы мы были продуктивными, то есть наши результаты удовлетворяют их ожиданиям. Им не интересно знать, что мы делаем, чтобы доставить их - они управляют проектом, а не нами. И первый шаг к тому, чтобы сделать проект управляемым, - разложить его область на более мелкие части.
Представьте, что вы хотите перекрасить свою квартиру, имея несколько тысяч долларов на эту работу. Вы нанимаете группу людей и отдаете им все ваши деньги сразу. Они просят вас вернуться через два месяца, когда все будет готово. Вы говорите “Хорошо” и ждете два месяца. Я уверен, что вы уже понимаете, о чем я говорю - этот проект, скорее всего, окажется неудачным, по крайней мере, отчасти. В худшем случае вы никогда не увидите этих ребят, они просто украдут ваши деньги. В лучшем случае они сделают что-то, что будет выглядеть “неплохо”, но не так хорошо, как вы ожидали.
Что делаете, чтобы увеличить свои шансы на лучший сценарий? Верно, вы микроуправляете ими: вы посещаете их каждый день, задаете известный вопрос “Что вы делаете сейчас?”, подталкиваете их, когда они становятся ленивыми, контролируете, доминируете, раздражаете, “остаетесь на вершине”, играете на чувстве вины, когда они пропускают или забывают, наказываете их всеми возможными способами.
Вы делаете это не потому, что злой. Вы просто знаете, что в противном случае они запорят вашу квартиру, забудут вещи, пропустят что-то, сделают ошибки, потратят больше времени и денег, чем должны, выберут неправильные ткани, приобретут мебель, которая вам не нравится, и сделают много других вещей, о которых вы хорошо знаете, если когда-либо имели дело с дизайнерами интерьера и строителями домов.
Чем агрессивнее вы, тем выше шансы на победу.
И это не потому, что вы злой. Вы не злой, вы глупый (не вы лично, уважаемый и уважаемая читательница, но вы понимаете суть).
Проблема в том, что проект неуправляемый. Вот почему вам приходится прибегать к последней возможной мере - микроуправлению. Почему проект неуправляемый? Потому что его объем не разбит на части. В нем содержится одна большая задача под названием “Перепланировка квартиры”.
Одним из ключевых факторов успешности управляемости является известное правило 0/100, согласно которому любая задача должна быть либо “в процессе выполнения”, либо “завершена”. Не может быть ничего посередине. Когда такое правило действует, задачу можно делегировать ее исполнителю, и он может стать ответственным за ее завершение, ему можно доверять.
Мы не можем “доверять” нашу одну большую задачу исполнителю, просто потому, что она слишком большая, чтобы ей можно было доверять. Если они провалятся, стоимость ошибки будет слишком высокой. Нам приходится взять микро-скоп и вникнуть в задачу, чтобы управлять ею изнутри, раздражая ее исполнителей, которым мы должны доверять. Микроуправление, которое мы делаем, неизбежно, потому что объем не разбит.
Разложение объема было изобретено в основном для решения этой очень проблемы: сделать проект более управляемым. Нам нужны маленькие задачи в объеме, чтобы мы могли делегировать их и больше не вмешиваться, чтобы проверить, что там происходит, кто что делает, почему и где.
Чем меньше задач мы можем разбить объем, тем лучше.
В наших проектах мы разбиваем объем проекта на задачи продолжительностью 30 минут каждая. Это может показаться вам слишком экстремальным, но для нас это работает. Мы называем их микрозадачами. Мы начали практиковать микрозадачи примерно семь лет назад. Мы экспериментировали с разными размерами задач, от 10 часов до 15 минут, но в конечном итоге остановились на 30 минутах.
Когда задачи становятся большими, мы теряем управляемость и возвращаемся к макрозадачам. Когда задачи слишком маленькие, накладные расходы на переключение контекста становятся слишком раздражающими.
По нашему опыту, старший программист, если полностью посвящен проекту, выполняет 6-10 задач в день. Это означает, что он проводит 3-5 часов работы, в то время как остальное время тратит на что-то другое. Это гораздо более эффективное использование рабочего времени, чем мы можем достичь с помощью традиционного управления макрозадачами, где программисты едва работают два часа в день, проводя остальное время на что-то другое (мое личное наблюдение).
Если вы решите заняться микрозаданиями, скорее всего у вас возникнут те же или похожие проблемы, с которыми мы столкнулись. Вот краткий список из них и мои советы, которые могут помочь, если вы решите разбить задачу “Разработка мобильного приложения” на, скажем, 2 500+ микрозаданий.
Отвлечение. Программисты привыкли делать много разных вещей одновременно: писать код, помогать другим, смотреть YouTube, пролистывать Facebook, браниться на Reddit и читать мой блог. Изначально большинству из них не понравится идея иметь явные задачи перед собой, просто потому что это структурирует их рабочее время и делает его более заметным для руководства. Они скажут вам, что у них есть много других дел помимо ваших чертовых задач. Мы решаем эту проблему, платя за результат и запрещая болтовню.
Лень. Точно так же, как дизайнеры квартир, программисты тоже любят получать деньги и ничего не делать. Кто не любит, верно? Они скажут вам, что их работа сложнее, чем вы думаете, что им нужно гораздо больше времени, что им нужно сначала исследовать проблему, что чтение документации также занимает много времени и т.д. Они просто испорчены традиционным макрозадачным подходом, где им платят по месяцам, и никто действительно не контролирует их результаты. Они привыкли быть ленивыми. Мы решаем эту проблему, оплачивая результат, и ленивые просто уходят.
Ответственность. Микрозадачи сделают индивидуальные результаты видимыми. Когда задания большие, люди обычно работают над ними в группах, и неясно, кто именно несет ответственность за неудачи и успехи. Маленькие задачи подчеркивают ошибки и заставляют людей “платить” за них. Не обязательно деньгами, но определенным образом, в любом случае. Большинство программистов найдут эту концепцию очень новой и тревожной - им почти никогда раньше не приходилось платить за свои ошибки и не иметь своих задач. Ответственность всегда распределялась по группе. Мы решаем это с помощью денежных вознаграждений и наказаний, что делает их очень мотивированными и готовыми к неудачам.
Обида. Это одна из самых популярных и раздражающих проблем: они скажут вам, что они “не обезьяны”. Они фактически объединят все вышеперечисленные проблемы и скажут, что правильным способом их решения является предоставление программистам свободы и позволение им выполнять свою работу, так как они достаточно умны и не нуждаются в руководстве сверху. И они будут говорить об этом вполне искренне, без намерения манипулировать. Дело в том, что они привыкли к макрозадачам и верят, что это единственный и правильный путь. Я пытаюсь решить эту проблему, написав данный блог-пост.
Может быть, есть и другие проблемы, но это больше или менее исчерпывающий список проблем, с которыми мы столкнулись.
Очевидно, что у каждого подхода есть свои плюсы и минусы. Микрозадачи кажутся наиболее эффективной парадигмой управления для нас. Однако, согласно нашему опыту, она не всегда применима везде. Есть территории, где нам не удалось ее применить.
UI/UX. За последние несколько лет мы в основном занимались проектами на стороне сервера с использованием Java/Ruby/C++, и у нас было немного возможностей применить микрозадачи к работе с пользовательским интерфейсом и пользовательским опытом. Однако все, что мы пытались сделать, так и не сработало: графические дизайнеры не могли разделить свои задачи на более мелкие части.
Клиенты. Мы несколько раз пытались разложить задачу выявления требований у наших клиентов и не справились. Возможно, наши клиенты были глупыми (сомневаюсь в этом), возможно, требования были слишком сложными, или, может быть, наши системные аналитики не были достаточно профессиональными. Главное, что мы поняли, что такая задача должна быть выполнена как сплошная работа, без какого-либо разложения.
Пожаротушение. Когда скорость доставки является наиболее важной задачей, микрозадачи не подходят нам. Затраты на отправку и уточнение задач занимали слишком много времени. Когда что-то действительно срочное, мы должны перейти к традиционной макрозадаче и просто “заставить это работать”. Затем мы возвращаемся к микрозадачам.
Все остальное, включая программирование, модульное тестирование, ручное тестирование, тестирование производительности/нагрузки, интеграционное тестирование, развертывание, проверку кода, документацию и даже обучение, можно и должно управлять с помощью микрозадач.
Самое важное преимущество микрозадач заключается в том, что проект становится более управляемым, как уже упоминалось выше. Вот более подробный разбор:
Мы платим меньше. Мы серьезно снижаем наши расходы, несмотря на то, что почасовые ставки наших программистов выше, чем многие другие проекты могут позволить себе. Я провел более или менее подробный анализ несколько лет назад, который показал, что наши проекты были в 30 (!) раз эффективнее по себестоимости, чем традиционные.
Мотивация очень высока. Несмотря на очень распространенный стереотип о том, что маленькие и изолированные задачи снижают мотивацию исполнителей, мы видим совершенно противоположную реакцию: программисты воодушевлены, когда наконец становится возможным работать в рамках четко определенных и явных границ, независимо и изолированно. Хотя не все из них. Мое личное наблюдение гласит: только 25% из них могут понять и наслаждаться микрозадачами. Другие либо недостаточно профессиональны, либо испорчены офисной рабством, где можно почти ничего не делать и оставаться очень уважаемыми и хорошо вознагражденными.
Оборот не причиняет боли. Чтобы сделать возможным выполнение микрозадач, руководство должно научиться их ясно, однозначно и быстро описывать. Когда достигается такой высокий уровень прозрачности, формальности и гибкости одновременно, проект становится менее зависимым от экспертов. Мы лишаемся страха потери людей, потому что почти все, что нам нужно знать о проекте, находится в нашей системе отслеживания задач и документации проекта.
Более удобное параллельное выполнение. Меньшие задачи легче распределить между большим количеством программистов. В некоторых проектах у нас иногда работает более 40 программистов одновременно, в то время как количество задач относительно небольшое (до 200).
Метрики работают. Когда один программист закрывает 40-50 задач в неделю, а другой закрывает 5-10, это что-то значит, имея в виду, что все задачи почти одинакового размера. Мы используем эту метрику (и несколько других) для принятия организационных и дисциплинарных решений. В условиях макро-распределения задач, почти все метрики HR не слишком эффективны.
Качество обязательно. Большое количество мелких задач подразумевает, что мы постоянно и часто закрываем их. Каждое закрытие является важным моментом контроля качества. Именно здесь у нас есть возможность сказать “Нет” и отклонить результаты, нарушающие наши стандарты качества. Для программистов такое “Нет” гораздо более болезненное при выполнении больших задач.
Риски приемлемы. Невозможно принять риск полного провала перепланировки всей квартиры, так как его стоимость слишком высока - несколько тысяч долларов. Однако, совершенно разумно принять риск установки кухонной лампы. Даже если она упадет и разобьется, мы потратим всего несколько долларов и купим новую. Нам необходимости контролировать “человека, занимающегося лампой” - у нас есть возможность делегировать и доверять.
Преимущества, которые получают программисты, пересекаются с нашими преимуществами. Если они профессиональны и достаточно мотивированы, им кажется эффективным и продуктивным работать с микрозадачами, которые всегда четко определены и оплачиваются должным образом.
Теперь самая типичная жалоба, которую мы слышим о микрозадачах, звучит так: “Это для младших программистов, которые согласны быть кодовыми обезьянками”. Честно говоря, я тоже так думал несколько лет назад, когда мы начали экспериментировать с XDSD. Однако я быстро понял, что самые профессиональные и самомотивированные разработчики с удовольствием занимаются микрозадачами, в то время как их менее опытные и менее квалифицированные коллеги испытывают трудности в удержании темпа.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 21:39
