Искусство управления IT-проектами - читать онлайн книгу. Автор: Скотт Беркун cтр.№ 53

Все неопределенности, к которым рано или поздно придется вернуться, должны быть отражены в списке. Ни у кого, кроме руководителя проекта, не возникнет потребности заглянуть в этот список, и разумеется, не сразу. Но по прошествии времени список может послужить поводом для сбора команды или проведения обсуждений «на ходу». Цель не в том, чтобы испортить людям настроение, просто им нужно иногда напомнить о том, что осталось нерешенным, и помочь понять, какие проблемы нужно решить специалистам команды. Поскольку работа руководителя проекта касается всех, вывешивание списка на видном месте позволит людям сотрудничать в решении проблем: «А этот пункт и меня касается. Кто им займется, ты или я?» По этой причине я держу список проблем на доске в своем офисе или коридоре. (Может сработать и wiki-технология, но никто, кроме составителя, туда не заглядывает. Обычные невиртуальные и неформальные места срабатывают куда лучше.)

Когда люди заходили в мой офис и спрашивали, как продвигаются наши дела, я указывал на список и говорил: «Вот так и продвигаются. Пока список не будет исчерпан, я не смогу закончить составление технических условий». Хотя этот список – не показатель производительности и не объект, подлежащий строгим измерениям в течение длительного времени, состояние списка проблем, находящегося у руководителя проекта, и круг вопросов, в него включенный, являются существенным показателем того, насколько хорошо идут дела. Если список достаточно длинный, но состоит из сугубо специфических и узкоспециальных проблем, все идет хорошо. А если он короткий, но его вопросы пугают своей основательностью, например: «Какую проблему мы пытаемся решить?» или «Какой язык программирования мы используем?», то проект, что называется, еще толком и не сдвинулся с места.

• Идеи обладают собственной инерционностью. Доминирование идей в творческом процессе продлится дольше ваших ожиданий. Изменения влекут за собой цепную реакцию во всем проекте.

• Для отслеживания хода творческого процесса и управления им следует установить контрольные точки. В число обычных контрольных точек включаются: доказательство состоятельности концепции, группировка идей, три альтернативных варианта, два альтернативных варианта, единый замысел.

• Для объединения идей используйте диаграмму сходства.

• Прототипы позволяют проекту противостоять разногласиям на ранней стадии и учиться на ошибках без существенного риска.

• Для ответов на вопросы, оценки степени прогресса и принятия решения о том, что делать дальше, делайте новые версии прототипов или обновляйте существующие.

• Для отслеживания вопросов, требующих разрешения до составления технических условий, составьте список открытых проблем.

1. Как вы составляете свой список текущих дел, по личным задачам или по задачам работы? Можете ли вы применить такую же систему для приведения в порядок, отслеживания или управления своими идеями? Почему «да» или почему «нет»?

2. В каком режиме должно вестись управление идеями, в закрытом или открытом? Кто в вашей проектной команде должен иметь доступ к: а) просмотру; б) изменению; в) добавлению или удалению идей?

3. Представьте, что вы близки к завершению проекта и поняли, что есть великолепная идея, способная радикально улучшить то, что вы делаете. Каковы способы сохранить эту идею, чтобы при запуске планирования следующего выпуска работы ею можно было воспользоваться? Можете ли вы придумать способ сбора подобных идей для всей команды?

4. Проведите сутки, занимаясь записью любых, услышанных от кого-то или самостоятельно придуманных идей. Сколько идей вам удастся собрать? Больше или меньше ожидаемого количества?

5. Возьмите список из предыдущего упражнения. Сколько различных способов группировки идей по категориям можно придумать? (Если вы поленились выполнить предыдущее упражнение, воспользуйтесь любым списком – покупок, людей, которых вам хотелось бы увидеть в голом виде, всего, что угодно.)

6. Что является тревожным признаком работы над проектом, для которого сгенерировано слишком много идей? Есть ли какое-нибудь разумное соотношение количества идей к отведенному времени, количеству сотрудников или к сложности проекта?

7. Управление творческим процессом требует определенных навыков, которые могут быть невостребованы при других этапах управления проектом. Каковы преимущества или опасности привлечения разработчиков или проектировщиков к руководству творческой стадии проекта?

8. Представьте, что вы работаете над проектом в середине этапа планирования. Никто не представил никакого прототипа, и в вашем распоряжении только письменные документы. Вы понимаете, что на некоторые вопросы невозможно получить ответы, используя лишь эти документы. Что вам делать? Изготавливать прототип самостоятельно? Привлечь к этой работе какого-нибудь другого специалиста команды? Кому вы покажете прототип? Какую реакцию вы от него ожидаете?

9. Представим, что в предыдущем упражнении вы решили изготовить прототип. Вы показали его команде, и он ей понравился. То есть он ей настолько понравился, что команда согласилась прекратить всю другую проектировочную работу и оснащение ради того единственного созданного вами прототипа. Вы знаете, что прототип создает массу предположений, требующих проверки, но их это мало волнует. Как убедить их в необходимости другого прототипа? Что можно сделать до показа прототипа, чтобы свести к минимуму шансы подобного развития событий?

10. Как расценить действия руководителя проекта, если он требует, чтобы список открытых проблем был пуст? Кому вы больше станете доверять, тому руководителю, у которого пять, или тому, у которого пятьдесят записей в списке открытых проблем? Испытываете ли вы какие-нибудь опасения насчет слишком больших затрат времени на отслеживание хода сокращения открытых проблем?

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

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