Искусство управления IT-проектами

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

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

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

• Что именно в соответствии с ним (проектом) требуется сделать?

• Как это будет работать? Как будет работать каждый компонент?

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

• Насколько надежны, эффективны, расширяемы и производительны существующие и нами создаваемые системы? Существуют ли пробелы между всем этим и требованиями проекта?

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

• Какие технологические процессы и подходы соответствуют данной команде и данному проекту?

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

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

• Сколько времени займет создание продукта и каков при этом будет его уровень качества?

Взгляд потребителя

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

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