"Время — деньги. Создание команды разработчиков программного обеспечения" - читать интересную книгу автора (Салливан Эд)

Центральная идея проекта

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

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

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

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

• закрыть путь на рынок новым конкурентам, предоставив программистам на языке C/C++ продукт с самым полным набором функций по обнаружению ошибок;

• создать продукт для анализа производительности, самый простой в эксплуатации во всей отрасли, и добиться признания этого факта;

• создать самый мощный и функционально насыщенный отладчик ядра Windows NT.

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

Поиск и решение пользовательских проблем

Сформулировав центральную идею проекта, надо сосредоточиться на потребностях пользователя. На этом этапе процесса формулирования требований следует рассматривать те проблемы, что необходимо решить пользователю, а не конкретные действия, которые он хотел бы выполнять. Возьмём в качестве примера одну из формулировок идеи проекта из предыдущего раздела. Если нужно предоставить программистам на C/C++ наиболее полный продукт для обнаружения ошибок, то надо выяснить, какие ошибки являются наиболее распространёнными и труднее всего поддаются обнаружению. Вот ещё один пример: если нужен самый простой в использовании продукт для анализа производительности, нужно понять, какие сведения о производительности критичны для пользователей и в каком виде они хотели бы их получить.

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

Из собственного опыта

При работе над BoundsChecker 3.0 было много прений вокруг набора функций продукта. Несколько недель обсуждения этого предмета, порой доходившего до жарких споров, прошли без видимого прогресса. Было принято совместное соглашение оставить этот вопрос, чтобы избежать возобновления споров. Чтобы выйти из тупика и поднять боевой дух группы, мы решили пригласить группу заказчиков и потенциальных пользователей на вечеринку с угощением и раздачей призов. Там мы продемонстрировали разные идеи о возможных функциях программы и попросили приглашённых высказать своё мнение. На основе информации извне стало намного легче прийти к компромиссу и выработать решение, у которого были неплохие шансы на успех.