Разумный метод управления

Срок сдачи проекта – мистическая сущность. С одной стороны, техника управления сроками примитивна, с другой стороны – большинство проектов по срокам проваливается. Позволю себе снова обвинить в этом человеческий фактор, потому что рациональных объяснений у меня нет. На мой взгляд, базовое предположение классической экономической теории о том, что каждый человек в каждую секунду обладает доступом ко всей информации в прошлом и настоящем, а все решения принимает на основе рационального взвешивания альтернативных вариантов, является откровенным бредом.

Я не одинок в своем мнении: см. интернет по запросу «парадоксы теории ожидаемой полезности», книги по институциональной экономике, а также многочисленные психологические эффекты (самосаботаж[26], эффект дезинформации[27], ошибка выживших[28], влияние штрафов[29] и т. д.). Человеческий фактор был, есть и, скорее всего, будет главным риском любого проекта до тех пор, пока роботы не захватят нашу планету. Да и то, скорее всего, в ядре операционной системы через сотни лет найдется баг, который сделает поведение роботов бестолковым и позволит людям восстановить мир на Земле:)

Чтобы минимизировать влияние человеческого фактора, нужно делать себя немного роботом, т. е. вырабатывать привычки.

Вот набор привычек, которые помогут снизить риск провала сроков:

– начинать проверять выполнение задачи за половину времени до дедлайна. Попутно стоит приучить всех специалистов показывать промежуточные результаты, которые можно потрогать и понять готовность продукта. Это очевидная практика, но пользуются ею крайне редко. Если вы договорились, что вам сделают задачу за пять дней, нет смысла начинать проверять ее на пятый и даже на четвертый день – объем доработок и комментариев, с высокой вероятностью, будет такой, что вы выйдете работать в выходные. Крайне желательно потестировать бета-версию на второй, максимум третий день, чтобы оставить запас времени. Вопросы, правки и комментарии будут всегда. 100 %;

– для рядовых специалистов делить задачи на подзадачи размером не более двух дней. Это эмпирический срок, который может зависеть от отрасли, типа и размера проекта. Я выработал его на проектах по разработке программных продуктов длиной от одного месяца до одного года, хотя, даже в этой отрасли есть мнение, что минимальная задача должна иметь объем в половину рабочего дня. На вкус и цвет товарища нет, но мнения все равно сходятся: делить задачи надо на минимально возможные куски (коллеги из Accenture провели небольшое исследование[30] на эту тему);

– никогда не надеяться на единственный вариант. Как сказал один умный человек: «нельзя стать успешным к следующему вторнику». Успех – это плод многократных попыток достичь результата (см. исследование Ричарда Вайзмана[31]). Вариантов всегда должно быть больше одного: запасной субподрядчик, запасной инженер, запасной источник финансирования, а лучше даже не один, а несколько. Многие менеджеры мне отвечают на это с возмущением: «Зачем два человека там, где и один справится? И вообще, с удвоением количества людей сроки сокращаются всего в полтора раза». На это я могу ответить цитатой из Сунь-Цзы: «война любит победу и не любит продолжительность». Чем быстрее вы достигнете результата, тем меньше вероятность происхождения неприятных ситуаций во время работы. Еще один побочный эффект затяжных проектов: от них все устают и теряют фокусировку. В общем, не скупитесь на запасные ресурсы: даже если вдруг все пройдет хорошо, вы просто получите бонус в виде сохраненных нервов и свободного времени для научно-исследовательской работы, отпуска или новых проектов;

– никогда не транслировать следующему человеку в цепочке принятия решений тот срок, который вам сказала команда. Всегда добавляйте запас времени, потому что в каждом проекте что-то да происходит не так, как планировали. Это правило нарушается повсеместно, и я даже не могу толком понять причину: наверное, менеджеры боятся показаться недостаточно быстрыми… Чтобы понять, как и сколько сроков надо добавлять, рекомендую прочесть книгу Голдратта Элияху «Критическая цепь»;