Почему делегирование обязанностей лучше, чем распределение задач
Доверие — высочайшая форма мотивации. Оно выявляет в людях самое лучшее.
Стивен Р. Кови, «Семь навыков высокоэффективных людей»
По сути, сегодня это стало священной мантрой управления проектами: разделяй работу на как можно меньшие по размеру задачи. Оцените их со своей командой. А затем закиньте их во всезнающий бэклог продукта. Однако никто, похоже, критически не изучал влияние этого подхода на профессию проектировщика ПО. В 90-х годах, когда я начинал заниматься программированием, мы работали иначе. Осмелюсь сказать, что тогда всё было чуть более профессиональным.
В те времена твой начальник нёс ответственность ещё за десяток или того больше задач, поэтому когда тебя нанимали, он мог облегчённо вздохнуть.
«Наконец-то, у нас появился Винсент, я могу поручить ему заняться A и B; Тед будет делать C, D
и E, Джен займётся F, G и H, а я смогу добраться до I, J, K, L и M».
Самое важное здесь то, что A и B были крупными задачами, например, целыми продуктами или большими системными библиотеками. На их создание и поддержку уходило всё твоё время. Они были делегированной ответственностью, а не просто задачами. Было просто при этом и управлять людьми. Если ты не справляешься, то начальник тебе об этом скажет.
«Винсент, работа над задачей A идёт не совсем так, как я представлял. Ты можешь чуть лучше.»
Затем ты возвращался в свой личный офис (я скучаю по частным офисам, но это уже тема для другого поста) и исправлял свои ошибки. Позже, на еженедельной планёрке ты рассказывал, как всё прошло — да, без всяких ежедневных пятиминуток, на которых ты печально смотришь в пол и признаёшься, что пока не достиг никакого значимого прогресса.
Не было и никакой возни с бэклогами и диаграмм сгорания задач. Твой руководитель просто смотрел на то, как дела у твоих продуктов. Немного доверия, чуточку отчётности и разумная доля «свободы делать свою работу».
Сегодня мы работаем иначе. Увы, но процесс стал менее мотивирующим, менее эффективным и он гораздо хуже учитывает индивидуальные навыки.
Так чьё это видение?
На мой взгляд, разделение на мелкие задачи родилось из фундаментально иного подхода к руководству. Мелкие задачи — довольно прямой способ показать, что ответственность за всё видение продукта возлагается на руководство. Отойди и не трогай.
Крупные же задачи посылают совершенно иной сигнал. В этом случае руководство даёт тебе работу посерьёзнее, приглашая вложить в конечный продукт собственную креативность. Тебе удаётся поучаствовать в проектировании, задуматься о потребностях заказчика, испытать гордость за результат труда. Разумеется, организация руководствуется собственной стратегией, но она всё равно стремится, чтобы люди брали на себя ответственность, а не выполняли поручения. Она верит, что ты будешь ориентироваться на общее видение, и ты так и делаешь, поскольку хочешь быть частью «клуба».
Слишком много любви к метрикам
Мелкие задачи прижились ещё и потому, что хорошо соответствуют сложившемуся за век менталитету «сборочной линии». К сожалению, есть целые армии менеджеров, до сих пор живущих этой догмой. Для них весь смысл сводится к подбору метрик и их оптимизации — к управлению посредством графиков и диаграмм.
К сожалению, мелкие задачи в Jira (или в любом из десятков других систем отслеживания ошибок) приносят с собой перспективу целого множества новых вкусных графиков и диаграмм: burn down, burn up, velocity, lead time, cycle time, task age, throughput, failed deployment, flow and control. Всё это манит, как ребёнка манит конфета.
Распределение обязанностей вместо задач забирает у менеджера сборочной линии его любимые инструменты. Из-за большего размера обязанности не так легко измерять и отслеживать. Поэтому менеджеры метрик будут до последней капли крови бороться за то, чтобы работа оставалась разделённой на крошечные отслеживаемые инструкции.
Когда у меня появится возможность получить опыт проектирования?
К сожалению, мы, как разработчики, тоже склонны к этому. Как только нас переводят на должность получше, мы сразу приступаем к делу с готовой программой. Когда обычный разработчик может иметь возможность провести исследований или заняться проектированием, мы мгновенно забираем эту задачу себе.
На должности технического руководителя мы стандартизируем фреймворки, языки, операционные системы и поставщиков облачных сервисов. Мы пишем обёртки для сетевых библиотек, библиотек для логгинга и мониторинга, и требуем, чтобы ими пользовались всегда. Затем, взяв на себя риск проектирования и исследования инструментов и конвейера CI/CD, мы пишем стандарты кодирования для своих стандартов кодирования.
Хуже того, мы проектируем архитектуру каждого проекта и ожидаем, что любое отклонение от неё должно сначала получить наше одобрение. Другим мы оставляем крохотные кусочки. Рутинную работу для пехоты, из которой убрали всё интересное.
Бедным программистам, трудящимся на самом фронте работ, ничего не остаётся, они просят: «Сэр, пожалуйста, можно мне ещё немного? Я просто хотел спроектировать один небольшой сервис. Я знаю, что недостоин этого, но пожалуйста, можно ли мне просто писать собственные sql-запросы без этого ужасного ORM?»
Увы, но когда эти бедные программисты наконец-то ожидают повышения, надеясь на свою первую реальную возможность на более высокой должности, им отказывают: «Боюсь, у вас нет опыта проектирования. Мы ищем того, кто уже проектировал крупные системы».
Своим менеджерам они могут справедливо сказать: «Это была твоя работа, не моя!»
Оценка всегда требует ресурсов
Существует серьёзное заблуждение о том, что если просто сесть в удобное кресло конференц-зала, разделить проект на крошечные задачи, каждую из которых можно оценить по отдельности, а затем сложить их, то вуаля — у вас появится точная оценка всего проекта. Легче лёгкого.
Однако у этой иллюзии есть две проблемы. Во-первых, ни одну задачу, даже самую мелкую, не легко оценить. Я часто видел «крошечные» задачи на один день, которые разрастались в недельные кампании. Это происходило из-за сокрытой сложности, вываливающейся как из ящика Пандоры после того, как начинаешь писать код. Во-вторых, когда ты разделяешь работу на мелкие задачи ещё до начала работы над ними, ты делаешь непроверенные предположения. И их получается много. Чем больше заданий ты определяешь, тем больше граней гипотетической архитектуры нужно предполагать (разумеется, косвенно, потому что никто не указывает предположений в описаниях задач). Вскоре у вас получится длинная цепочка проектных решений в виде листочков на стене, каждое из которых зависит от предыдущего.
Проблема в том, что как только вы начнёте работать над одним из них, то осознаете, что подразумеваемые проектные решения неверны. Теперь вам нужно потратить ГОРАЗДО больше времени, чем прежняя оценка задач, а все остальные задачи, зависящие от этого ошибочного решения, окажутся недействительными. Весь карточный домик развалится. Пришла пора ещё одного ещё дня возни с бэклогом? Какая трата времени!
Вывод
В те времена, когда мы ещё не осознали, что компании-разработчики ПО должны зарабатывать кучу денег, у нас было пространство для манёвра. У нас была большая доля ответственности и возможность принимать множество решений. Но сегодня на нашу землю пришло гораздо больше людей. К сожалению, некоторые из них постепенно разрушили сферу возможностей разработчика ПО. Один за другим они спускались со своих судов и водружали свои флаги:
«Я Америго, менеджер по продукту. А посему ни один разработчик не будет принимать проектные решения, ведь это моя вотчина.»
«А я Фернан, менеджер процессов. А посему ни один разработчик не будет принимать решений об организации процесса, ведь это моя вотчина».
«Я, Бартоломеу, буду обеспечивать соответствие требованиям».
«Я, Васко, неплохо разбирался в Microsoft Access, поэтому, наверно, буду заниматься базами данных».
Одну за другой у разработчиков отняли все обязанности, кроме обязанности «открыть emacs и начать писать код». А потом оставшиеся чисто технические задачи были отобраны проектировщиками архитектур и инженерами по стандартам, жадными до существенных задач. На земле остались только высушенные, раздробленные оболочки.
Разумеется, из этой затруднительной ситуации есть выход — делегировать обязанности всем, до самого низа иерархии. Или даже лучше — сделать иерархию плоской, а то и полностью от неё избавиться. Но пока этого не случилось, нам приходится довольствоваться жалкими циклами for и операторами if. Конечно же, соответствующими всем стандартам кодирования.
На правах рекламы
VDSina предлагает мощные и недорогие VPS с посуточной оплатой. Интернет-канал для каждого сервера — 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!
