«Работа заполняет время, отпущенное на неё».
Закон Паркинсона
Если ты не британский чиновник образца 1958 года, не надо следовать этому закону. Никакая работа не обязана занимать всё отведённое на неё время.
Пара слов о законе
Сирил Норткот Паркинсон – британский историк и блестящий сатирик. С цитаты, которую так часто всерьез называют законом, начинается эссе, опубликованное 19 ноября 1955 года в журнале «The Economist».
Эссе не имеет отношения ни к управлению проектами, ни к менеджменту в целом. Это хлёсткая сатира, высмеивающая госаппарат, который десятилетиями раздувается и не становится ни капли эффективнее.
Паркинсон объясняет существование закона действием двух факторов:
- Чиновник хочет иметь дело с подчиненными, а не с соперниками
- Чиновники создают работу друг для друга
Очень рекомендую прочитать само эссе, а в двух словах это выглядит так:
Чиновник, считающий себя перегруженным, нанимает двух подчиненных, чтобы они делали его работу. Разделить её с уже работающими коллегами или нанять одного подчиненного и разделить с ним он не может – никому не нужны соперники. Дальше история повторяется, его сотрудники нанимают сотрудников себе. И вот уже 7 человек делают работу одного. Все очень загружены, но ни скорость работы, ни её качество не повышаются.
Возможно, тебе знакома именно эта ситуация, но есть множество других причин, по которым работа заполняет всё время до дедлайна и немного больше.
Как этого можно избежать:
1. Не думай за всех
Не жди, что кто-то проявит уважение, если ты не проявляешь его сам. Хочешь, чтобы команда ответственно относилась к срокам и к работе в целом – постарайся получить реальный коммитмент, а не вынужденное согласие.
2. Не ставь срок «вчера»
Во-первых, это всех нервирует, а ты не хочешь работать среди психопатов. Во-вторых, успеть «вчера» невозможно, а значит, сроки сорвутся. Они сорвутся один раз, второй. И что ты сделаешь? Всех уволишь? Вряд ли. А если после ничего не произойдет, то что тогда? Зачем пытаться успеть в срок и тем более раньше? Maniana.
3. Не пытайся добиться 100% загрузки
Для 100% загрузки (на самом деле нет) мы придумали машины, а человеку нужно отдыхать. А ещё развиваться и вытирать пыль с клавиатуры. Зачем спешить завершать задачу досрочно, если сразу прилетит новая? Тогда точно ни на что времени не будет.
4. Не делай вид, что после дедлайна конец света
Во-первых, это не так, и смотри пункт 2. Во-вторых, никто не хочет получить по шапке, и все закладывают подстраховку. Проблема в том, что задержки всё равно будут суммироваться, а вот опережения – нет. Про это хорошо написал Элияху Голдратт в книге «Цель 2».
5. Не нужно фиксировать всё
Не надо рисовать мифический треугольник ограничений и пытаться втиснуть в него свой проект. Если хочешь получить Sagrada Familia, будь готов прождать сто лет. Если тебе нужно к четвергу, прояви гибкость.
6. Не поощряй мультизадачность
Во-первых, это не продуктивно. Во-вторых, каждый решает свою оптимизационную задачу. И получить 2 новых поручения вместо того, чтобы сидеть на одном готовом, не выглядит как хорошая затея.
7. Не тяни с аппрувом.
Серьезно. На работу уходит 2 дня, а потом еще 2 недели ждать, пока менеджер/заказчик посмотрит и даст правки. А потом удивляемся, почему все тянут до дедлайна.
8. Избегай большого взрыва.
Не тяни с одной большой поставкой, работайте инкрементально. Не факт, что работа сделается быстрее, но по крайней мере, ты сможешь что-то использовать, не дожидаясь месяцами.
9. Не раздувай команду
Если не хочешь быть как британские чиновники :)
Комментарии (9)
usdglander
31.07.2019 08:04-1«Работа заполняет время, отпущенное на неё».
Возможно пропущено слово «всё». «Работа заполняет всё время, отпущенное на неё».
vvbob
31.07.2019 08:33Вот прямо сейчас закончил задачу, которая при постановке выглядела как лютый капец, казалось что работы там на пару недель как минимум. В реальности, когда изучил ее более пристально, все оказалось намного оптимистичнее и за неделю ее удалось сделать (а было запрошено две недели). Но зато я потратил оставшееся время на то что довел код до идеального состояния и тщательно все проверил (отловив при этом несколько непринципиальных, но неприятных багов).
Я это к тому, что не всегда это плохо, когда задача решается дольше чем могла-бы.
SemenPV
daIlenkov Автор
На самом деле не совсем. Про это как раз Паркинсон хорошо писал. Если на задачу поставить больше людей, совсем не факт, что она сделается быстрее. Как минимум увеличится время на коммуникации, согласования, исправления и все прочие радости. Вместо простых решений команда будет выбирать более сложные, требующие больше времени и несущие больше рисков. В итоге команда станет больше, работать все будут не меньше, а скорость поставки не сократится.
Разумеется, это тоже не закон :)
А 100% загрузки можно избежать другими способами. Например, не придумывать задачи просто чтоб создать загрузку. И не играть в мультизадачность, где это можно избежать.
SemenPV
«Не раздувай команду» — обычно собственник горячий сторонник подобных пунктов и противник «Не пытайся добиться 100% загрузки». Понятно что адекватный собственник не будет заставлять траву ножницами подстригать как армии, но всегда найдутся нужные задачи, которые хорошо бы сделать.
Ну и скрам как раз один из способов манипуляции сотрудниками, чтобы они сами на себя побольше взвалили (а по исследованиям, оценки у разработчиков черезмерно оптимистичны) и под чувством вины что не успевают в собственноручно назначинные сроки, не 100%, а 110% отбивали.
«Не раздувай команду» — это зачастую значит что разработчикам придумывают новые роли. Зачем новые люди в команду, если разработчик может DevOps, TestOps, SecOps, AnalOps, CleanOps и т.п.
salkat
Если вспомнить Голдратовскую «Цель», то под «Не пытайся добиться 100% загрузки» понималось что не надо загружать людей какой-нибудь работой, лишь бы не бездельничали. Он сделал, что ему поручили и гуляет. Если его за это ловят и припахивают, он начинает растягивать поручение подольше
SemenPV
Всё правильно, но мне интересно как на практике это выглядит. Есть двухнедельный спринт, гребец закрыл его за неделю и пошёл в отпуск на оставшуюся неделю?
В моей вселенной так не бывает. Если он закроет все тикеты, ему начальник подкинет добавки. И это правильно и ожидаемо, в том числе со стороны самого работника, конечно если он получает деньги за время, а не за результат.
Поэтому через пару спринтов, работник просекает что ему выгоднее и действует соответсвенно собственному желанию.
Можно конечно мечтать чтобы по другому было — но что-то сильно сомневаюсь, что кроме как в книжках такое случается.
ardraeiss
Там же прекрасный пример как одна из проблем была создана желанием нагрузить узел полностью 100% времени, дабы оправдать его покупку.
rboots
Чтобы балансировать между 100%-ной загрузкой и резервным временем, можно заразить команду крутой технической идеей, выбрать хобби-проекты (связанные с работой), и дать работать над ними после того, как основные задачи сделаны. Сильно зависит от целей и взглядов разработчика на жизнь, но опыт показывает, что ребята в стадии активного развития стремятся скорее разделаться с основными задачами и перейти к десерту, в результате чаще всего все выигрывают.