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

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

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

При работе в крупной организации следует учитывать распределение сил по всем точкам зрения. Например, если инженеры превосходят по численности бизнес-аналитиков в соотношении три к одному, в принимаемых решениях будет уклон на доминирование технологического взгляда. Соотношение сил – это простое соотношение количества приверженцев того или иного взгляда. Для баланса взглядов соотношение должно быть 1:1:1 (с позиций разработчика, бизнесмена и потребителя). Чем больше несбалансированность, тем больше усилий требуется от руководителей, чтобы ее скомпенсировать.

Разумеется, примерное количество людей не определяет объем имеющихся у них полномочий. В армии Наполеона были тысячи солдат, но Наполеон был только один. В команде может быть 10 программистов и 1 специалист по маркетингу (10:1:0), но последний может иметь больше полномочий в рамках проекта, определяющих его роль или старшинство. Это означает, что руководитель в состоянии компенсировать натуральное соотношение, наделяя полномочиями тех, кто должен иметь больше влияние на проект. А поскольку сущность проекта со временем меняется, представители различных взглядов должны в разное время получать различный уровень полномочий. О том, как можно поручать принятие решений для достижения нужного баланса в нужное время, рассказывается в главе 12.

Уточнение набора вопросов, на которые необходимо ответить при планировании – простейший вариант организации работы. Вопросы должны быть извлечены из перечней, составленных на основе трех взглядов на проект, с намерением собрать их в единый план.

Эти вопросы (часто называемые вопросами планирования проекта) должны быть извлечены из трех ранее рассмотренных перечней. Если проект новый (а не разработка очередной версии продукта), то для определения его основных положений понадобятся исходные вопросы. Если суть проекта заключается в незначительном обновлении существующей системы, то вопросов о бизнесе и потребительских интересах может быть совсем немного. Но независимо от характера проекта нужно просмотреть все вопросы. Тогда на поверхность всплывут не выявленные ранее предположения и дадут всем равноценные исходные точки для обсуждения.

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

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

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

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

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

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

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

• Можем ли мы создать технологию или набраться опыта для создания продукта, удовлетворяющего этим запросам или решающего эти проблемы? (Да, может быть, нет.)

• Присутствуют ли эти значимые возможности в новом продукте или линейке продуктов? Или связаны ли непосредственно с продуктом (линейкой продуктов) выявленные запросы?

• Существуют ли действенные бизнес-модели для использования нашего делового опыта и технологии в решении выявленных проблем или в удовлетворении запросов? (Смогут ли доходы превысить затраты в обозримом будущем?)

• Какими должны быть сроки выпуска на рынок следующей версии или следующего продукта? В какие благоприятные моменты лучше всего выпустить продукт?

• Чем в этой рыночной нише заняты конкуренты? В чем по нашему мнению заключается их рыночная стратегия и как мы можем с ними конкурировать?

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