Мой любимый момент «Звездных войн» — когда Люк говорит Йоде, что он попытается поднять свой истребитель из болота, используя силу. Йода замечательно отчитывает Люка: «Нет! Не пытайся… Делай или не делай… Никаких попыток». Оказывается, этот совет весьма уместен и для разработчиков ПО.
Одно из самых худших ощущений, которые вы будете испытывать как руководитель группы, — осознание, что все идет к тому, что ваша группа сорвет сроки. Это плохая ситуация по многим причинам. По мере приближения к крайним срокам люди начнут работать сверхинтенсивно. Они будут пытаться наверстать упущенное время, иногда работая даже ночами и по выходным. Вдобавок в таких ситуациях часто приходится «срезать углы». Значит, пострадает качество.
Когда наступает крайний срок, а проект все еще не выполнен, вас не ждет раздача медалей за все эти сверхусилия. Останется лишь разочарование от того, что сроки сорваны. И даже если это не было бы довольно плохо, из-за «срезания углов» окажется, что состояние кода, скорее всего, не оптимально. В результате всех этих «попыток» вы каждый месяц будете испытывать горький привкус поражения, а ваш продукт не будет отвечать стандартам.
Одна из областей, в которой вам как менеджеру, сложнее всего соблюсти баланс — необходимость заставить людей укладываться в жесткие сроки и при этом реально оценивать, сколько работы они могут выполнить. Оценить производительность труда сложно. Это одна из причин, по которой люди используют гибкую методологию (Agile): они не очень хорошо справляются с планированием производительности.
Поэтому в любом проекте, рассчитанном на много месяцев, требуется определить, как должен выглядеть конечный результат и сколько усилий потребуется, чтобы его достигнуть. Хотя, чтобы освоить планирование производительности, требуются годы опыта, один из отчетливых признаков, что люди берут на себя слишком много, — слова «я попытаюсь».
Приложить все усилия
Когда кто-то говорит мне «я попытаюсь», у меня в голове это сразу же транслируется в слова: «Я приложу все усилия, и если я не достигну цели, то, по крайней мере, много поработаю, стремясь ее достигнуть. Но я не готов нести ответственность, если потерплю неудачу». При этом сложно выбрать правильную линию поведения и ответные слова. С одной стороны, вы не должны подавлять энтузиазм сотрудников, которые проявляют инициативу или берутся за дела, расширяющие их возможности. С другой стороны, группы и их руководители отвечают за результаты, а не за усилия.
Когда речь идет о критически важных задачах и кто-то говорит мне «я попытаюсь», я всегда отвечаю, что лучше сказать «нет», чем «я попытаюсь». Я могу найти множество способов спланировать работу при ответе «нет». Я могу подключить к проекту дополнительных сотрудников. Могу изменить границы задачи. Могу вникнуть в подробности и устранить неоднозначности, упростив задачу.
Гораздо сложнее планировать при ответе «я попытаюсь». Значит ли это, что над проектом будет должен работать кто-то еще, чтобы была страховка на случай неудачи? Это не эффективно. Должен ли я понадеяться на то, что сотрудник преуспеет, несмотря на то, что у меня уже есть серьезные опасения, что он потерпит неудачу? Это было бы неразумно.
Как же избежать этой ловушки? Создайте обстановку, в которой людям комфортно говорить «нет». Большинство менеджеров не любит, когда кто-то из их группы говорит, что не может что-либо сделать. Ведь это признак слабости, не так ли? Естественный мыслительный процесс подводит к тому, что если бы сотрудник был умнее или трудолюбивее, то он справился бы. С другой стороны, люди не любят говорить «нет» поскольку беспокоятся, что потеряют авторитет.
В конце концов, вы должны усвоить, что каждый человек может выполнить ограниченный объем работы. Люди будут справляться со своими обязанностями или нет, в зависимости от своих навыков и опыта. Если вы ударите кулаком по столу или щелкните кнутом, то в течение какого-то времени люди будут работать на 10 или 20 процентов продуктивнее, но производительность их труда не вырастет в два раза. Сказать «да» и не справиться должно быть хуже, чем сказать «нет». Мотивируйте людей к тому, чтобы они знали свою производительность и свои предельные возможности. В конечном счете, ваша группа будет лучше прогнозировать свою работу и укладываться в сроки.
Нужен научный метод измерения производительности труда вашей группы, основанный на данных. Допустим, вы усвоили урок и сделали так, чтобы сотрудникам вашей группы было комфортно говорить «нет». Однако не исключено, что ваш начальник или руководство компании по-прежнему думают, что заставлять людей обещать, что они уложатся в нереальные сроки, — отличный подход к управлению.
Даже если вы работаете во вспомогательной среде, когда вы дорастете до управления большими группами и планирования работы на месяцы вперед, оценка производительности вашей группы, взятая просто «из головы», не будет соответствовать действительности. Необходимо взять на вооружение модель измерения «полосы пропускания» вашей группы, основанную на данных. Вот несколько факторов, которые надо принять во внимание.
- Отлеживайте соответствие оценок реальности: если ваша группа работает по модели, в которой затраты труда оцениваются заранее (например, методология «водопада» или гибкая модель), начните отслеживать соответствие оценочных затрат и реальных затрат на уровне отдельных сотрудников или групп. С этого момента вы сможете создавать и публиковать таблицы с информацией о том, чьи оценки точны, а чьи — нет. Помогайте руководителями и рядовым сотрудникам групп, которые еще учатся делать оценки, совершенствовать этот навык. Тогда вы как минимум будете знать возможный интервал ошибок. В результате, когда вы будете определять график, у вас будет кое-какая информация о том, сколько резервного времени запланировать.
- Контролируйте скорость поступления запросов/скорость их выполнения/список невыполненных запросов: некоторые группы работают без ведения списка поступивших запросов, «багов» или проблем. Так может быть проще отслеживать общую производительность группы, если решаемые задачи более-менее однородны по сложности (например, имеется пакет из проектов, требующих одни-два дня работы). Если скорость поступления запросов равна скорости их выполнения или если список невыполненных запросов все время имеет примерно одинаковый размер, вы справляетесь с нагрузкой. Если список запросов растет, может возникнуть ситуация, когда ваша группа перестанет справляться с возложенными на нее задачами. Публикуйте эти показатели, чтобы все понимали картину в целом. Используйте эти данные, чтобы поднимать перед руководством вопросы о выделении ресурсов.
- Создайте модель зависимости от масштаба (points of scale): если вы управляете чем-то типа группы поддержки клиентов, нагрузка на вашу группу может зависеть от количества пользователей. Если вам удастся показать корреляцию между количеством запросов поддержки и количеством пользователей, вы сможете воспользоваться данными о прогнозируемых продажах своей компании при оценке своих будущих потребностей в ресурсах. Если ваша группа тратит 10 процентов своего времени на поддержку текущей кодовой базы, то это необходимо учесть при оценке производительности вашей группы в будущих проектах. Имея модель зависимости от масштаба, вы сможете экстраполировать различные сценарии, основываясь на уже имеющихся у вас данных.
Учитесь говорить «нет»
Воздействуйте на людей своим примером и говорите «нет», когда это правильный ответ. Несмотря на все преимущества, которые дает такой ответ, оказывается, что это одно из слов, которые неприятнее всего говорить. Никто не любит узнавать о том, что что-то нельзя сделать. Когда кто-то попросит вас или вашу группу взять на себя больше работы, чем вы можете выполнить, важно направить разговор в русло обсуждения вашей модели данных.
Хотя большинство людей ненавидит математику, оказывается, что большинство руководителей воспринимает соображения, опирающиеся на модель, основанную на данных. Если вы моделируете производительность и скорость работы своей группы, имейте под рукой модель зависимости от масштаба. Если вы можете доказать, что уже «щелкнули кнутом», чтобы увеличить производительность на 10–20 процентов, следует повести разговор в более правильном контексте — о том, что можно сделать. Сместите акцент с вопроса, может ли ваша группа выполнить больше работы, на вопрос об относительном приоритете новой работы в сравнении с существующей.
В следующий раз, когда кто-то скажет вам «я попытаюсь», вспомните слова Йоды: «Никаких попыток». Хотя вам обязательно следует заставлять свою группу работать и создавать ощущение срочности ее работы, будьте осторожны и не перегните палку, сделав так, что сотрудники группы перестанут давать достоверную информацию. Если им будет не комфортно говорить «нет», даже когда это правильный ответ, от этого будет больше вреда, чем пользы.
Не надо просто верить сотрудникам своей группы на слово. Создайте научную модель оценки общей производительности своей группы, основанную на данных. Она поможет лучше планировать производительность и эффективнее обсуждать ресурсы и границы проекта со своим руководством.
Ваш успех, в конечном счете, зависит от полученных результатов. Срыв сроков подтачивает доверие к вам. Если вы будете уверены в себе и будете опираться на модель данных, то вы сможете настоять на своем при обсуждении того, с каким объемом работы справится ваша группа, и добьетесь вместе со своей группой огромного успеха.