Онлайн-Книжки » Книги » 🤯 Психология » Искусство управления IT-проектами - Скотт Беркун

Читать книгу "Искусство управления IT-проектами - Скотт Беркун"

196
0

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 30 31 32 ... 145
Перейти на страницу:

Вдохновляющая способность

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

Запоминаемость

Запоминаемость предполагает наличие двух условий: во-первых, идеи должны иметь смысл, и во-вторых, они должны отложиться в сознании читателей и оставаться в нем на весь срок работы над проектом. Они могут запомниться не более чем несколькими характерными особенностями, но этого будет достаточно для уверенности исполнителей в правильной направленности их повседневной работы. (Если концептуальный документ слишком сложен для понимания, добиться желаемого эффекта невозможно. Люди редко запоминают то, в чем не могут разобраться.)

Запоминанию больше всего способствует прямое и простое изложение мыслей. Если вы сможете впечатлить сутью принятых решений и понятно их изложить, то даже не до конца согласные с ними люди будут помнить их намного дольше, чем решения концептуального документа, изложенные неубедительно и запутанно, но полные идей, в которые они безоглядно верят. Поэтому стремитесь к понятному и убедительному изложению концептуальных взглядов. Вооружите команду четкой концепцией и образом мышления в отношении предстоящей работы. Старайтесь избегать ярких идей, способных увлечь людей на короткое время, или увлечений вычурными и сиюминутными тенденциями, которые могут через пару недель «сойти на нет», полностью обесценивая ранее соответствовавшие им идеи.

Ключевые моменты

В основу концепции должны быть положены ответы на многие из приводимых далее вопросов. Обычно эти ответы становятся основными заголовками концептуального документа или перечисляются в конце, в разделе вопросов и ответов. (Даже если данные вопросы не нашли свое место в основном документе и отражены в приложении, предполагается, что инженерам свойственно переходить к последним страницам в надежде отыскать что-либо негативное в противовес всему изложенному ранее.)

Для ответа на многие из приводимых далее вопросов требуется привлечение специалистов по рыночным исследованиям, по изучению потребительских запросов, по проектированию изделий или других доступных вам экспертов, причем делать это нужно своевременно. Часть вопросов намеренно совпадает с вопросами из предыдущей главы, которая посвящалась планированию. Отличие состоит в том, что эти вопросы рассматриваются строго в ракурсе приоритетов и решений, а не содержимого и предположений. Хотя в ходе планирования отводится место и исследованиям, концепция должна быть преподнесена в утвердительной и убедительной форме.

Каким одним предложением можно определить конкретный выпуск изделия в рамках этого конкретного проекта? (Это часто называется концептуальным положением, или, как говорят штатные шутники команды разработчиков, «формулировкой заблуждения». Примеры подобных предложений будут вскоре предоставлены.)

• Как этот проект содействует целям организации? Почему он важнее других проектов, которые также могут содействовать достижению этих целей?

• Какие сценарии или потребительские свойства являются основными для данного проекта? (Приоритет – 1.)

• Какие сценарии или потребительские свойства, не являющиеся основными, желательно реализовать? (Приоритет – 2.)

• Что представляют собой потребители продукта? Какие проблемы решаются в их интересах реализацией данного проекта? Какими очевидными признаками или исследованиями (в противовес мнениям и предположениям) подкреплены эти утверждения? Как потребители справляются со своей работой без продукта, реализуемого данным проектом?

• Кто представляет в организации стороны, заинтересованные в данном проекте (люди, облеченные полномочиями по реализации данного проекта, которые не обязательно должны быть пользователями создаваемого в его рамках продукта)? Какая роль им отводится в проекте? (Заинтересованные стороны будут рассмотрены в главе 16.)

• Почему потенциальные потребители станут покупать изделие или подписываться на услугу? (Туманные фразы вроде «потому что это круто» или «потому что им не из чего выбирать» в качестве ответа не годятся. Тем не менее допустим краткий обзор того, на что эти потребители тратят средства в данный момент и как новый продукт впишется в их образ жизни, бюджет или устоявшиеся привычки. Разумеется, если имеется в виду продукт из сферы информационных технологий, может прозвучать и ответ «потому что им не из чего выбирать».)

• Кто является конкурентом в данной области и как продукт, создаваемый в рамках проекта, выдерживает сравнение с изделиями этого конкурента? (В число конкурирующих факторов должны включаться предыдущие реализации подобных проектов или всевозможные нетехнологичные альтернативы, такие как карандаш и бумага. Для наладонного органайзера Palm Pilot простейшей конструкции в качестве первичного конкурента должна рассматриваться обыкновенная бумага, а не другие электронные устройства.)

• Какие решения, направленные на удовлетворение потребительских нужд, были востребованы или предложены, но определенно не станут частью проекта?

• Какие существуют не связанные с технологией подходы к исследованию проблемы?

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

• Каковы более-менее вероятные возможности провала данного проекта и как их можно исключить или свести к минимуму? (В ранних прикидках могут быть только оценки рисков без планов, как их избежать или справиться с ними.)

• Что в успехе данного проекта зависит от других компаний или групп? Зависит ли успех других компаний или групп от реализации данного проекта?

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

• Какие были выдвинуты предположения, от которых зависит успех проекта? В какой степени данный проект зависит от других проектов, компаний или организаций?

1 ... 30 31 32 ... 145
Перейти на страницу:

Внимание!

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

Комментарии и отзывы (0) к книге "Искусство управления IT-проектами - Скотт Беркун"