БЛИЖАЙШИЕ МЕРОПРИЯТИЯ:
22-23 июня: КИЕВ,
Certified ScrumMaster by ScrumAlliance | Курс c Натальей Трениной (на русском языке)
27 июня: ХАРЬКОВ,
AgilePizza #68
27 июня: КИЕВ,
AgilePizza #69

2011/12/05

Три мифа и три совета

Три мифа и три совета

Мне посчастливилось в этом году работать и общаться в интернациональной среде. Могу вам сказать, что почти везде, где я бываю, некий менеджер, или менеджер проекта отводит меня в сторонку со словами: «Джоанна, можно ли задать вам дурацкий вопрос?». Я всегда отвечаю, что уверена в том, что этот вопрос вовсе не дурацкий. . Этот менеджер, он или она, кивает в ответ, убежденный в том, что такая проблема есть только у него. «Все так быстро меняется. Я просто не знаю, как мне за этим угнаться, как это все контролировать. Как правильно распределить людей по проектам? Мне кажется, что не нужно постоянно переводить их с места на место, но ведь задействовать экспертов в проектах все-таки стоит, не правда ли? Оказывается, некоторые проекты не требуют постоянного участия такого количества сотрудников. Поэтому я не хочу перенасыщать такие проекты персоналом. С другой стороны, недостаток сотрудников тоже нежелателен. Иногда выиграть невозможно». Дорогие менеджеры, интуиция вас не подвела. Вы столкнулись с серьезными проблемами. Кроме того, они взаимосвязаны, поэтому давайте разберем их по очереди и снабдим вас необходимыми советами.

МИФ ПЕРВЫЙ: «Если в соответствующие моменты задействовать в проектах соответствующие ресурсы, эти проекты будут работать». 
Люди – это не ресурсы. Деньги – ресурс, письменные столы – тоже. Оснащение офиса – это ресурс. Программное обеспечение тоже может выступать в таком качестве. Ресурсы можно задействовать в другом месте, и они не станут жаловаться. Ну а люди? Люди – участники команд. Если вывести человека из одной команды и попытаться «воткнуть» его в другую, вам может очень повезти, если эта вторая команда примет его, и работа пойдет без сбоев. Однако не рассчитывайте на это. Люди – не ресурсы. Это чудесные человеческие существа, которые живут и дышат. 

СОВЕТ ПЕРВЫЙ: Обеспечьте плавность рабочего процесса внутри команд. Если ваши команды работают хорошо, это великолепно. Старайтесь сохранить их. Проекты должны задействовать всю команду и поступать в разработку по одному. Не волнуйтесь, если в командах нет экспертизы (см. Миф Второй). Люди либо выполнят работу, либо попросят помощи – но как команда. 

МИФ ВТОРОЙ: «Такая работа под силу только эксперту».
У нас в ходу множество мифов о том, что для выполнения определенной работы нужны «эксперты и только эксперты». Конечно, есть работа, которую могут выполнить только они. Реальный вопрос таков: сколько ее? Я вовсе не хочу, что разработчики стали тестерами, и наоборот. Кроме того, не жду, что дизайнеры пользовательского интерфейса превратятся в экспертов по безопасности. Однако, как менеджер проекта, я хочу, чтобы каждый участник проекта изучил его целиком и хорошо в нем разбирался. И что самое главное, эксперты должны работать вместе с другими, чтобы поделиться своими знаниями.

СОВЕТ ВТОРОЙ: Никогда не позволяйте экспертам работать в одиночку. 
Когда эксперты работают в своих областях экспертизы, я всегда прошу их объединиться в пары не-экспертами. Если они отказались, я переводила их в другой проект, где экспертизы у них нет. Держу пари, кто-то наверняка считает меня сумасшедшей. Но вот почему я так поступаю. Если эксперт продолжает работать в вашей организации над другим проектом, он все равно вам доступен. Если же он выиграл лотерею и находится на Фиджи, наслаждаясь там коктейлями с зонтиками, он вам недоступен. Когда вы захотите проводить экспертизу? Я хочу проводить ее в условиях доступности эксперта. Готова биться об заклад, что некоторые из вас, менеджеры, обеспокоены ритмом проекта. Ну что ж, удалив из команды эксперта, вы увидите забавную вещь. Команда объединяется и работает как единое целое, а не как разобщенная группа людей. Хотите, чтобы команда работала быстрее? Удалите из нее экспертов. Команда будет работать вместе, и люди быстро поймут, чего они не знают. А тем, что они знают хорошо, они поделятся с вами. 

МИФ ТРЕТИЙ: «Это проект для одного человека». 
Вам кажется, что этот проект действительно небольшой. Похоже, что один человек справится с ним за несколько месяцев. Не попадайтесь на это! Такой вещи, как «проект для одного человека» просто нет. Разработчику нужно общаться с заказчиком или человеком, отвечающим за соблюдение требований заказчика. Разработчику может понадобиться помощь в развертывании проекта, или же ему нужна помощь DBA, или небольшое тестирование. Дело здесь в том, что разработка программного обеспечения - это социальная проблема. Даже интровертам нужно проговаривать некоторые вещи, а еще вероятнее – прорабатывать проблемы с другим человеком.

СОВЕТ ТРЕТИЙ: Всегда ставьте на проект двоих сотрудников. 
Если вы всегда ставите на проект двоих сотрудников, они работают в паре. Они могут протестировать друг у друга коды, обменяться идеями, помочь друг другу в развертывании. Если им непонятно, почему что-то не работает, они могут оказать друг другу моральную поддержку. Поэтому никогда не попадайтесь на удочку мифа о «проекте для одного человека».

Перевод с английского, автор оригинальной статьи - Джоанна Ротман

No comments: