Управленческий миф: Только «Эксперт» может выполнять эту работу
| November 6, 2012 | Posted by admin under Практики, Статьи |
Статья из серии «Management Myth»
Автор: Johanna Rothman
Для многих менеджеров, когда проект ждет “эксперта”, варианты действий ограничиваются следующими: можно отложить проект, можно попросить эксперта заниматься несколькими проектами одновременно или взять на работу еще одного эксперта. В конце концов, эксперт не нужен на полное время в каждом из проектов, поэтому это подойдет, так ведь? Так уж ли это важно, если администратор баз данных, ведущий тестировщик или релиз инженер не знает ваш проект вдоль и поперек?
Нет, это не подходит. Нельзя начинать проект без людей, в которых он нуждается. Решение с многозадачностью эксперта – неудачное. Человек, который не знает ваш проект, – это не эксперт для вашего проекта.
Есть еще один вариант – уменьшить необходимость в эксперте. Можно распространить экспертизу в проекте, можно вообще прогнать экспертов из ваших проектов, можно так управлять проектным портфолио, чтобы выделить проекты, которые действительно требуют экспертизы, или можно набрать больше экспертов.
Эксперт не должен работать один
Иногда проектную экспертизу можно распространить среди других членов команды. Например, у вас в команде есть только один человек, который умеет строить систему, но всем в проекте нужно знать, как это делается. В этом случае я обычно прошу человека, который знает, как строить систему, поработать в паре с каждым членом команды, так что в итоге все члены команды будут знать, как строить систему, на уровне эксперта.
Не позволяя эксперту работать в одиночку, вы распространите экспертизу в команде. В зависимости от экспертизы, вам, возможно, потребуется провести внутренний семинар, чтобы у всех было единое базовое понимание инструмента или технологии. Иногда, релиз инженеру имеет смысл провести внутренний семинар, чтобы объяснить внутреннюю организацию системы сборки, а потом поработать с каждым в отдельности, чтобы убедиться, что человек понимает, как использовать систему. Ту же самую модель можно применить для многих активностей администратора баз данных.
Этот подход хорошо работает для технической экспертизы, которая базируется на инструментах или на навыке, сходном с навыком какого-то члена команды. Это работает не везде. В случаях, когда у вас есть значительная экспертиза области решения, где людям нужно знать систему изнутри, вам лучше рассмотреть другие опции, такие как изгнание эксперта.
Изгнание незаменимого эксперта
Некоторые люди становятся незаменимыми. Если они работают на другой проект, а вы хотите затронуть «их код», ваш проект должен ждать, когда они освободятся и смогут это сделать сами.
Не попадайтесь на это. Прогоните их. Или, если они работают на ваш проект, пригласите их работать на другой проект. Что бы вы не придумали, уберите их из своего проекта сегодня. Если эксперт – внутри вашей организации, но на другом проекте, он все еще остается доступным. В какой-то момент эксперт пойдет на пенсию, и отправится плавать на Карибы и попивать сладкий ром, и тогда уже у вас не будет возможности к нему обратиться. Когда вы предпочитаете, чтобы члены вашей команды практиковались в построении своей экспертизы? Я считаю, что лучше это делать, пока эксперт все еще доступен.
У команды есть нездоровая зависимость от эксперта, а у эксперта есть зависимость от команды. Я не психолог, и даже не разыгрываю эту роль по телевизору, но, с точки зрения проекта, это ужасная ситуация. Для поддержки самооценки эксперта, вся команда поддерживает его в этом. В результате, это удерживает других членов команды от изучения продукта.
Если вы работаете в крупной организации в качестве менеджера , вы можете организовать переход эксперта в другой проект. В маленькой организации, вы можете организовать работу эксперта над специальным проектом. В этом специальном проекте должно быть много поставляемых компонентов, чтобы эксперт был достаточно занят, и у него не было времени на старый проект.
Команда должна научиться учиться вместе. Как только вы убрали эксперта, у команды есть возможность стать настоящей командой, потому что теперь у членов команды общая цель.
Как только вы убрали эксперта, члены команды станут работать вместе, чтобы как можно быстрее выяснить то, что они до этого не знали. И будут обмениваться своими знаниями. Но, эксперт должен быть доступен в течение ограниченного периода времени каждую неделю. Возможно, один час, и только если команда застряла. Поощряйте команду разрабатывать и использовать тесты, вместо вопросов о том, как работает продукт.
Упорядочивание проектов, чтобы лучше использовать экспертов
Возможно, эксперт с проблемами самооценки – это не случай вашего проекта. Возможно, у вас действительно мало экспертов по экспертизе безопасности, и они нужны в проекте на полное время. И, возможно, вы надеетесь как можно быстрее завершить проект A , чтобы можно было начать проект B. Но проект A еще не готов. Эту проблему легко решить. Если A более значимый, чем проект B, не начинайте пока B. Если проект B более значимый, чем A, остановите проект A и начните B. Да, именно так.
Но, скажете вы, мы же еще не выпустили проект A. Ок, если вы использовали для проекта A agile подход, то возможно у вас уже есть что-то достаточно значимое для релиза. Но возможно и нет. Это плохо. Если смотреть на управление проектным портфолио изнутри, то это как игра с нулевой суммой, а оптимизация делается для всей организации в целом. Вы хотите, чтобы ваша организация была успешной?
Управление проектным портфолио неразрывно связано с проведением сложных дискуссий на уровне организации, а замедляя оба проекта, вы не делаете их оба.
Какой проект ценнее, A или B? Какой проект продвинет организацию вперед? Насколько мало нужно сделать, чтобы получить имеющий ценность релиз? Вот вопросы, которые вы должны задать.
Если вы не использовали для проекта A agile, никогда не поздно начать. Завершите фичи, которые близки к завершению, а затем ранжируйте остальные фичи. Надеюсь, вы начали работать над фичами в порядке значимости.
Наймите больше экспертов
Если вы действительно хотите, чтобы оба проекта, A и B, разрабатывались одновременно, вам нужно нанять больше людей. Наем и введение в курс дела займет значительное время, поэтому результат вы получите не скоро. Однако, наем людей должен помочь.
Осознаем основные причины
Одна из причин, почему в наших организациях так много многозадачности, – это то, что у нас есть много экспертов с очень узкой экспертизой. Чем уже экспертиза, тем меньше времени требуется этот человек в проекте, но когда вам нужен этот человек, он вам действительно нужен.
Есть много мифов о том, что для проведения некой работы нужны эксперты и только эксперты. Есть работа, которую могут сделать только они. Вопрос в том, сколько? Я не ожидаю, что разработчики станут тестировщиками или наоборот. Также я не ожидаю, что дизайнеры пользовательского интерфейса станут экспертами по безопасности. Но, как менеджер, я ожидаю, что все в проекте узнают достаточно, чтобы быть хорошо осведомленными обо всем проекте в целом. И, что важнее всего, я надеюсь, что эксперты будут работать с остальными, чтобы делиться своими знаниями.
Чем больше у вас людей, которые придерживаются таких взглядов на разработку, тем больше гибкости будет в ваших проектах. Когда я говорю: “Работа проходит через команду”, вы соглашаетесь со мной и говорите: “Конечно. Как еще это будет работать?”
Вам не нужно обходиться без экспертов, ваша задача – уменьшить необходимость в них и расширить технические знания и возможности каждого сотрудника в вашей организации.
