WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 | 2 || 4 |

«Эд - ДЕНЬГИ Создание команды разработчиков программного обеспечения Москва 2002 Р У С УДК 004.45 32.973.26-018.2 С16 Э. ...»

-- [ Страница 3 ] --

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

Глава 8. Требования «Фрагментация» требований Отойти от пути при формулировании требо легко. Так бывает, когда упрямый индивид или группа уводит «фокус» требований совсем в другую сторо ну, чем было задумано. Возможно, было легче формулиро вать требования для тех функций, определить которые было проще всего. Может оказаться и так, что требования сопряжены с чрезмерным для таких программ риском.

Как бы ни было, обязательно должны присутствовать объективный взгляд на требования и оценка их влияния на ход проекта.

Категории требований Ниже описаны четыре категории требований.

«Опережающие» и «догоняющие» требования Первые позволяют продукту обогнать конкурентов по рынку.

Они могут описывать просто представление дан ных или возможность поддержки новой платформы. Им обязательно быть революционными — достаточно, что они дают преимущество в конкуренции на выхода программы на рынок. Вторые подтягивают циональность программы до уровня конкурентов. Они призваны сохранить и связаны с решением проблем сбыта и технической Разделение требований на «опережаю щих» и позволяет проанализировать конкурентоспособность вашей программы. Например, если выяснилось, что в программе слиш ком мало требований или их вообще нет, можно реализовать дополнительные опережающие тре бования. Стратегия разработки программ в NuMega гда включает ряд особенностей, которые делают грамму на рынке и позволяют ей стать или остаться, так Часть 2. и планирование проекта Перспективные и ретроспективные требования Пос направлены на решение проблем, связанных с прошлыми выпусками ПО. Например, для решения про блем с производительностью и удобством ния в последнем выпуске в общем случае служат ретро требования. Так как эти требования — не что иное, как реакция на существующий продукт в существу ющем окружении, их реализация позволяет улучшить но не предвосхитить будущие потребности.

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

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

Перспективные требования вовсе не обязательно являются копией опережающих. Перспективные требо Глава 8.

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

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

Догоняющие Опережающие Перспективные Ретроспективные Рис. 8-2. Набор требований, представленный в виде таблицы из четырех ячеек.

Далее приводится описание содержимого каждой ячей ки таблицы. Расписав собственные требования по ячейкам такой таблицы, вы поймете, в каком направлении пойдет работа.

Часть 2. Формулирование и проекта Ячейка 1. Вы предвидите будущие потребности потре бителей и будете первым производителем, предоставившим соответствующее решение. Эти потребности пока еще не до конца поняты и не полностью установлены. Вы первопро ходец в этой области, поэтому уровень риска довольно вы сок. Из-за множества «неизвестных» нельзя заранее предо ставить подробное определение требований. Основное внимание должно быть уделено созданию и последователь ному улучшению прототипа ПО. Потребуется очень быст ро пересматривать ПО в процессе привлечь для тестирования реальных пользователей и об новить требования до начала этапа планирования.

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

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

Глава 8.

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

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

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

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

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

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

Приоритетные функции должны быть ясны каждому участнику проекта.

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

Необходимые функции должны быть реализованы и испытаны как можно раньше;

этому нужно уделить мак симум внимания и все ресурсы.

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

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

Глава 8. Требования Утверждение требований Многие ошибочно считают, что сформулировав ния, они готовы к распределению заданий и проекта. Это не так. Нужно выполнить два важных дей ствия: провести техническую основных факто ров риска, связанных с технологиями, и создать прототип пользовательского интерфейса вашей программы. См. об этом главы 9 и 10, Представим на минуту, что прототип пользовательско го интерфейса уже готов и технологическая экспертиза за кончена. Готовы ли вы поставить свою подпись на списке требований? нет. Нельзя утверждать пока не составлен план работы. Может что на испол плана должно уйти слишком много времени, и при дется отказаться от реализации части Если тре бования уже утверждены, то может оказаться, что при их реализации не удастся уложиться в заданные временные рамки. Не стоит требования поодиночке, пока не будет ясности с другими требованиями.

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

ряд фундаментальных которые учитывать.

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

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

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

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

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

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

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

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

Рассмотрим в качестве примера вышеупомянутое при ложение для обработки заказов. Одно из ключевых требо ваний таково: «Принимая заказ на товар, нужно собрать сле дующую информацию: Y и Z». Заметьте: требование со держит формулировку самой задачи, но не способа ее решения. Можно привести пример требования с описани ем способа его реализации: должен выбрать в меню пункт Order и ввести нужную информа цию в диалоговом Лучше позволить команде, ответ ственной за разработку пользовательского интерфейса, са мостоятельно найти лучший способ реализации этого бования путем работы с прототипом.

Глава 8.

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

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

вы сильно рискуете. Иногда этот оправдан, но чаще — нет. Почему? Да потому, что данном случае против вас:

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

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

рисками и На ранних стадиях реализации проекта опреде основные проблемы и пути их решения. технологические L Глава 9. Исследования, оценка и внести хаос в проекта. Факти чески это одна из самых распространенных причин срыва планов. Не утверждать или над проектом, пока не основные техно логические проблемы.

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

в технологии Чтобы работать на рынке с жесткой конкуренцией необходимы исследования. Сле дует направить часть усилий группы на прогноз нужд потребителей, а также на поиск реше ний и Прекрасные идеи, новые подходы и хито приложения не появляются по волшебству в одно часье — их как — Часть 2. и планирование Исследования Хоть и считают исследовательскую работу чис то академическим занятием, она тем не менее играет важ ную роль в разработке ПО. В этом разделе мы обсудим ос новы исследований в приложении к созданию про граммных продуктов.

О чем пойдет речь Исследования бывают и Первые — это процесс открытий и изобретений в надежде создать что-то полезное. Однако у результата такого иссле дования может и не быть коммерческого применения.

С другой стороны, прикладное исследование на основе ло гических построений и анализа ситуации в некоторой от расли ведет поиск потенциально выгодных решений и пы тается превратить гипотезы в конкретные идеи, которые помогут создать некоторый продукт.

Прикладные исследования — наиболее важная форма исследований в контексте этой книги. Они могут обеспе чить критически важное преимущество в конкурентной борьбе, особенно на нестабильном рынке, когда потребно сти пользователей, ПО и аппаратные платформы и техно логии претерпевают стремительные изменения. Хотя изме нения часто вносят неопределенность, они также дают не вероятные возможности группам, способным предвидеть потребности потребителей и задействовать новые техно логии для их Если, занимаясь новой технологии, вы хотите «остаться на плаву» вопреки всем неожиданностям, то параллельно циклу разработки вести исследовательскую работу, Глава 9. Исследования, оценка технологий и моделирование Из собственного опыта Отладчик ядра созданный NuMega, был хитом на рынке программ для 16-разрядных платформ Microsoft DOS и Microsoft Windows. Нам даже без особых проблем удалось заставить его работать в Windows 95. Однако ры нок двигался к Windows NT, что вынудило нас заняться адаптацией SoftlCE для работы с ОС, иначе росг прибылей нашей компании снизился бы.

Но эта задача казалась просто невыполнимой: новая сис тема управлением виртуальной памятью Windows NT де лала реализацию многих функций SoftlCE чрезвычайно затруднительной и требовала от большинства участников группы SoftlCE знания недокументирован ных внутренних механизмов и структур данных Windows.

Большинство работников компании (и не только они) сомневалось, что SoftlCE когда-либо будет перенесен на Windows NT.

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

Он работал над этой проблемой день и ночь в течение двух недель, пока не создал довольно простой прототип, на примере которого смог продемонстрировать основ ные методики, необходимые для поддержки Windows NT.

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

Часть 2. и планирование проекта Как это делается Ниже описаны модели нахождения оптимального баланса между исследованиями и разработкой. Первая тре бует наименьшей затраты ресурсов, последняя — наиболь шей. Если ваша компания невелика или просто не хватает можно начать с модели, по ходу дела она может перерасти в другие.

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

В силу своих особенностей неосновной выпуск — за мечательный способ дать некоторым из ведущих раз работчиков передышку от задач, во время которой у них есть шанс заняться исследовательской работой. Общее требование: к концу работы над нео сновным выпуском надо Помимо самой возможности проведения исследова ний, совмещение исследований и работы над неоснов ными выпусками дает участникам группы целый ряд других преимуществ. Ведущие разработчики могут пе ревести дух и заняться другими проблемами. Это реаль ная возможность дать главным рассла биться, чтобы они не а другим членам коллектива — возможность выйти в лидеры. Взаимное обучение и возможность роста талантливых участников Глава 9. оценка технологий и моделирование критичны для устранения текучести кадров и ного роста мастерства группы.

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

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

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

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

Регулярное общение, как так и неформаль ное, снижает вероятность между группами.

Часть 2. Формулирование и проекта Остается на чем сосредоточить усилия иссле Если работа в среде с небольшими ресур сами, позаботьтесь о том, чтобы шансы на успех исследо вательской работы были максимальны. разумно распределить усилия В общем случае при оритетными являются следующие направления.

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

исследования на поиск, анализ и мониторинг езных изменений рынке. Однако не заходите в сво их исканиях так далеко, чтобы потерять связь с реаль ностью.

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

Анализ и направлений работы конкурентов Одна из самых важных областей исследования — ана лиз инноваций и направлений работы конкурентов.

Чтобы успешно состязаться с ними, надо понимать их технологии, знать их сильные и слабые стороны.

По завершении исследовательского проекта или при смене приоритетов исследования важно задокументиро вать результаты и сделать их доступными коллективу. Необ Глава 9. Исследования, оценка технологий и моделирование довести до сведения группы все без исключения результаты исследований, как положительные, так и отри цательные. Если исследовательский проект действительна обладает недюжинным было бы разумно со здать прототип и продемонстрировать группе его возмож ности, пояснив работы.

Из собственного опыта К концу работы над 3.0 энтузиазм ведущего разработчика изрядно поубавился: проект отнял много времени и сил и необходимость была оче видна каждому его В это время возникла еще одна задача: нужно было разобраться, что может дать но вая технология от Microsoft под названием СОМ для на ших продуктов. СОМ привлекла ее даже считали в Однако мы смутно представляли себе ее суть, поэтому решено было взяться за обе проблемы одновременно.

В то время как остальная часть группы работала над следующим (неосновным) выпуском продукта, ведущий разработчик уделял все свое время изучению внутренней организации СОМ и моделированию новых функций BoundsChecker. Спустя три месяца, когда новая версия была практически главный разработчик был готов присоединиться к работе над BoundsChecker 4-0.

Ему удалось не только восстановить свои силы, но и обу чить остальных участников группы принципам работы с СОМ и показать им рабочие прототипы новых функций.

Так что для начала наше положение было весьма непло хим: вовсю шли поставки BoundsChecker 3.0, только что закончена разработка версии 3.1, а мы уже обладали фун даментальной технологией для следующего выпуска про граммы.

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

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

Глава 9. Исследования, оценка технологий и моделирование Как это делается Оценивая нужно дать ответы на следующие вопросы.

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

Качество: приемлем ли уровень качества технологии?

• Совершенство: ли технология должную производительность, и устойчивость?

Поддержка: обеспечена ли новая технология адекват ной поддержкой?

не слишком ли но вая технология в использовании и при отладке?

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

• критерии: определяйте свои потреб ности заранее и делайте это как точнее с помо щью критериев, данных • критерии при оценке:

объективно оценивайте результаты, опираясь на факты, а не на • учитывать отзывы заказчиков: собирайте отзывы за (как положительные, так и отрицательные) о результатах оценки;

не интересоваться мне нием заказчиков: удовлетворят ли новые технологии их нужды.

! Часть 2. и планирование проекта Моделирование В начале работы над проектом почти всегда возникает ряд важных вопросов, связанных с реализацией той или иной технологии. Моделирование — важная методика, которая поможет получить необходимые ответы.

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

Рассмотрим примеры того, что может если отказаться от работы с прототипом, Определив компо ненты программы, команда решила сначала реализовать ее инфраструктуру, так как без этого компонента, обычно са мого важного и самого сложного, ничего не работает.

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

Рассмотрим еще один пример, на сей раз с противопо ложным сценарием. Участники группы отдают себе отчет в том, что ?!ельзя строить компоненты инфраструктуры проекта, не поняв технических других частей системы, поэтому решено сначала создать полную ! Глава 9. оценка технологий и моделирование фикацию системы. Но эта задача оказалась затруднитель ной, так как не все проблемы, с которыми придется столк нуться, известны заранее. Фактически здесь возникают сплошные вопросы, на которые никто не знает ответа. Ко нечно, можно действовать наугад к что все будет хорошо, но это слитком рискованно.

эти проблемы позволяет решить прототип. В пер вом примере работа с прототипом помогла бы заранее смо делировать систему. Это позволило бы понять, как собрать компоненты. Во втором примере работа с прототипом подсказала бы проектные решения.

Из собственного опыта Оба рассмотренных выше примера из работы над реальными проектами. На заре деятельности мы не уделяли должного внимания созданию прототипов тех использование которых таило в себе наиболь ший риск или неопределенность. Оглядываясь в прошлое, понимаешь, что всех проблем удалось бы избежать, если бы конструкция программы была проверена с помощью прототипа, Как это делается Прототип — не программа, но он дает возмож ность получить фактические данные, которые позволят принимать более удачные Важнее всего — поэтому нужно действовать быстро. Ниже описаны этапы кратчайшего пути, который, однако, позволяет создать вполне приличный прототип, • Определите факторы риска — создание списка основных на которые нуж но ответить. Изучите все вопросы, в которых нужно ра зобраться, чтобы разработать точный план. Если вопро сов много, нужно определить приоритетные и прорабо Часть 2. Формулирование и планирование проекта тать их в первую очередь. Помните: нужно сосредото читься только на ключевых моментах, а не на всех неиз вестных.

Составьте план Следует создать экспериментов, которые помогут ответить на постав ленные вопросы. Можно искать на каждый посредством отдельного эксперимента или решать сколько проблем одновременно, проводя ряд экспери ментов.

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

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

Используйте существующие наработки Еще один важный способ ускорения создания — ис пользование существующих Вовсе не тельно все писать «с Некоторые наиболее успеш ные прототипы появились в результате модификация копии исходного текста рабочей программы.

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

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

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

Из опыта Во время работы над 5.0 разработчикам пришлось почти переписать внут ренние компоненты программы. При этом работа шла основном на двух фронтах: систем сбора и анализа Из-за сложности проекта мы Часть 2. Формулирование и планирование проекта большой соблазн сначала довести до конца кон струирование системы сбора данных, а затем закончить систему анализа. Но опять же в силу сложности проекта мы пришли к выводу, что лучше создать прототипы для обеих систем, чем тратить время на создание подробных спецификаций. Было решено смоделировать сбор части нужных данных и написать лишь кода для только этих данных. Если программа функционировала нормально, выводилось простое диалоговое окно с сооб что все Спустя неделю из программистов зазвал меня в свой и продемонстрировал маленькое простень кое диалоговое окно. Прототип работал! Теперь мы зна ли, что все задуманное от начала до конца и серьезных проблем с производительностью не предви дится. Следующие две недели мы по очереди наращива ли все функции, обретая все большую в ус пехе. Таким образом, окончательная архитектура и кон струкция программы были улучшены. Через три недели у нас был готовый проект, который мы могли точно спланировать. В конечном итоге это нам сэкономить кучу времени при его реализации. Я не гово рю, что после все было прекрасно, но без этих простых действий у нас бы не хватило уверенности, знаний и по чтобы правильно проект.

Типичные проблемы и их решение Далее обсуждается ряд типичных проблем и вопросов, воз никающих при использовании описываемых здесь а также их решения, Не торопитесь Как уже не раз было разработчики часто пытают ся работать с новыми технологиями, лишь на г Глава 9. оценка технологий и моделирование допущениях. Эти допущения проект скорее в азартную игру, чем в серьезную работу. Не то ропите события: хотя некоторые проблемы можно и дол жно решать с ходу, все же следует определить ключевые потребности и убедиться, что новые технологии в состоя нии удовлетворить их. В этом случае вы сможете предви деть проблемы и лучше подготовитесь к их а так же отреагировать на возникшие проблемы на более ранних этапах цикла разработки проекта.

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

Не оставляйте анализ производительности напоследок Большинство считает, что производительность — это что то, что «добавляется* к программе в конце цикла работы над проектом. Хотя настройка разного рода параметров, несом может и выполняться после сборки всех ча стей проекта, также верно и то, что на этом этапе объем изменений ограничен. Неуместно Часть 2. и планирование проекта сить фундаментальные в или внут реннюю структуру продукта последние недели работы над проектом.

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

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

бы что-то изменить на этом этапе, разработчикам, и техническим писателям приходится многое переделывать, так что в этом случае дело пахнет серьезным срывом планов.

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

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

Почему прототип необходим?

Как сказано в главе 8, требования к продукту определяют основные задачи, которые приходится выполнять пользо вателям. Однако в описании требований не сказано, как пользователи будут это делать. Ответ дает прототип пользо вательского интерфейса. Им занимается команда разработ чиков программы и в большей — специалист по инженерной психологии. После создания прототипа появ ляется возможность привлечь пользователей для проверки деталей выбранного вами решения. Результаты тестирова ния позволяют убедиться, что пользовательские потребно сти были поняты правильно. Важнее всего при этом воз можность легко вносить изменения и пробовать новые идеи, руководствуясь результатами Часть 2. и проекта Прототип дает команде множество пре имуществ.

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

Отчасти верно, что остальная функциональность про сто не имеет если трудно решать основные задачи или не ясно, как это делать.

Из опыта Когда в NuMega решили создать новую было что интерфейс для нее придет ся создавать «с нуля*. Но что должен быть похож но вый интерфейс? Какие действия наиболее важны для пользователя? Ознакомившись с положением в мы обнаружили массу хороших продуктов, в целом со весьма развитый набор ПО. Однако все суще ствующие программы перегружали пользователя инфор мацией, что, с нашей точки зрения, является так как это очень затрудняет выполнение самой важной задачи продукта — поиск проблем с производительнос тью программ. Теперь мы знали, к чему стремиться: нуж но сделать так, чтобы поиск проблем с производительно стью с помощью нашей программы требовал не больше трех щелчков. Вся команда сообща работала над создани ем интерфейса, чтобы эту просто сформулиро ванную, такую трудную задачу. Мы решили не услож нять интерфейс и разработали новый подход к навигации по сложной иерархии функций, в которой зачастую та Глава 10. Пользовательский интерфейс проблемы с В пер вый принес премию «Best of присуждаемую журналом Comdex/Byte Основ ным фактором была концентрация усилий коман ды на решении задач.

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

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

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

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

• Тестирование программы также сильно зависит от интерфейса.

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

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

это увеличивает шансы правильно объем предсто ящей работы. Наконец, мы очень быстро доводим прото тип, внося в него ряд изменений, демон стрируя как внутренние, так и его особенности.

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

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

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

попробуйте выделить хотя бы следующие категории.

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

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

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

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

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

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

Кроме того, бумажный прототип не страдает от связанных с программированием, и других помех, неизбежных при разработке ПО. Это Часть 2. и планирование проекта его так как лучше тратить время на тес тирование и доводку пользовательского интерфейса, а не на решение технических или механических про блем, с его созданием.

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

Из собственного опыта Бумажные прототипы быть чрезвычайно эффек тивны, но если не верит в результативность этой методики, использовать ее нельзя. Чтобы побороть эту проблему в NuMega, мы отправили всю команду на дневный методический курс, который читали в институ те (Usability Engineering Institute, Особое внимание в этом курсе уделялось работе с бумажными прототипами. Это был замечательный способ продемон стрировать участникам команды, насколько важны и эф фективны могут быть прототипы на бумаге. Этот курс из менил наши представления о разработке ПО.

• прототипов с помощью инструментов для быстрой разработки приложений (RAD, Rapid Application — вероятно, самая популярная методика. Подходящим можно считать лю бой инструмент, позволяющий быстро создать нагляд ную функционирующую модель пользовательского ин терфейса.

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

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

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

Повторная и доводка Получив прототип, можно приступать к его проверке с по мощью реальных пользователей. Для этого нужно попро сить пользователей выполнить определенные вами вые задачи с помощью только что созданного прототипа, При нужно выяснить, что работает хорошо, а что пло Часть 2. Формулирование и проекта хо, и внести в прототип соответствующие изменения, что бы решить обнаруженные Рассмотрим пример с прототипом. Если вы попросите пользователя выполнить задачу, ему придется «щелкнуть» ряд элементов интерфейса. При этом часть работы придется делать вам, управляя механикой терфейса и имитируя для пользователя работу компьюте ра. Вам придется собственноручно выкладывать перед пользователем новые «диалоговые наблюдать за какие он выбирает, и убирать «окна», когда ватель Сколько времени занимает доводка интерфейса? Обыч но немало. Приходится до 20 раз менять структуру фейса в зависимости от приложения. Следует вносить столько изменений, сколько потребуется, и доводить ди зайн, пока не будет достигнут значительный прогресс. По мните: идея в чтобы быстро проработать множество вариантов дизайна, пока форма прототипа не более менее постоянной. Полное представление о прогрессе про тотипа дают результаты тестов. ось ли пользователей? Уменьшилось или увеличилось среднее вре мя, которое пользователь тратит на решение некоторой задачи? Смогла ли последняя партия пользователей легко и быстро выполнить свои задачи или они столкнулись с про блемами? Ответы на эти вопросы позволят выяснить, как обстоят дела в работе над программой и сколько еще пред стоит сделать.

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

Часть 2. и планирование Роль по инженерной психологии Специалисты по инженерной психологии играют крити ческую роль в разработке программ. Мне приходилось ра ботать как с ними, так и них. В результате я бы предпо чел иметь одного или несколько таких специалистов в своей команде. Однако роль специалиста по психологии не всегда ясна и существенно в различных В следующем разделе описана рабо та специалистов по инженерной психологии в компании NuMega.

Сфера ответственности Специалисты по инженерной психологии отвечают за ре шение следующих задач.

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

упрощая процедуру, насколько возможно, и освобождая ее от излишка параметров и ручного труда.

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

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

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

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

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

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

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

контроль хода работы над пользовательским интерфей сом, как так и по завершении каждого суще ственного этапа работы над проектом;

• и санкционирование мелких изменений пользовательского интерфейса;

• создание или поиск элементов графического оформле ния продукта;

• за созданием соглаше ния и формирование впечатления от продукта (см. выше);

и проверка ПО: хотя для крупных изменений может не остаться времени, небольшие изме 9. — Часть 2. Формулирование и планирование проекта нения могут быть вполне возможны — это поможет луч ше подготовиться к работе над следующим выпуском;

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

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

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

! Глава 10. Пользовательский интерфейс Лишние нововведения Представленные в этой главе идеи всего критикуют за то, что они, якобы «душат» инновации. А что, если спустя несколько месяцев работы над продуктом возникла замеча тельная новая Стоит ли уносить изменения, если есть возможность?

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

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

Планирование Часть 2. и планирование оздание плана часто оказывается одним из наиболее затруднительных и насыщенных политикой аспектов проекта. Правильно составленный план становится эффек тивным средством управления проектом. Как бы усердно ни трудилась команда, при плохом планировании вся работа пойдет насмарку, с выпуском ПО. Сложность планирования проектов общеизвестна, однако именно по планирования часто отличает реалистичную оценку сроков реализации проек та от планов «с потолка».

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

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

Модель использования/ проект программы Планирование Анализ осуществимости/ работа с прототипом Рис. критически важные для процесса планирования.

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

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

Объем предстоящей работы, количество доступных ресур сов и время, отведенное на реализацию проекта, должны быть сбалансированы — вот и самое важное пра вило планирования. Если один из этих параметров перевешивать или, хуже того, наложены ограни Часть 2. Формулирование и чения, которые нельзя сбалансировать, создать ПО вовре мя будет невозможно. Даже в начале работы был велика вероятность, что в дальнейшем будет нарушено. В цикле разработки возника ет достаточно чтобы вывести из равновесия даже самый лучший план. По ходу работы менеджер про екта должен регулярно проверять план и всемерно поддер живать его Способы мониторинга проекта и внесения изменений в процессе его реализации мы обсу дим в главе 12.

Задачи и оценка для их выполнения Задачи — это основные строительные блоки плана, они яв ляются представлением конкретной работы, которую нуж но сделать. В общем верно, что легче следить за ходом вы небольших Кратко и точно сформулиро ванные задачи позволяют быстро обнаружить от плана. Если задачу нельзя за 1-2 ее следует разбить на или больше меньших задач. Испол нение плана, составленного из долгосрочных задач, труд нее контролировать, При составлении списка задач обязательно нужно учи тывать их взаимосвязи в рамках проекта. Например, зная, как одни задачи зависят от других, можно расположить их в нужной последовательности, причем ключевые задачи всегда должны завершаться в очередь. Нужно выяс нить, сколько времени займет каждая задача. Это можно сделать, оценив время, необходимое для выполнения торой задачи (т. е. обоснованное предположение о сроках). Поскольку для формулирования требований, конструирования интерфейса и реализации выбранной технологии сделано уже довольно должно быть коплено достаточно информации, чтобы точно и без осо бых затруднений оценить срок для выполнения той или ! Глава иной задачи. Если точно оценить время чевых задач невозможно, вы, провели недостаточ но исследований и работы с прототипом, Оценка должна учитывать всю работу, необходимую для выполнения задачи. Например, специалисты по ПО долж ны оценить суммарное время конструирования невой структуры, а реализации, отладки и блочного тестирования программы. Специалисты по обучению поль зователей должны оценить, какое потребуется на на писание, рецензирование, редактирование и правку их ма Хотя каждый команды самостоятельно срок завершения своей части работы, его всегда должен проверить ведущий специалист в соответ области. На основе этих оценок рассчитывается время реализации поэтому следует быть ным в цифрах, Со временем вы увидите, что ваши оценки становятся все точнее, особенно при работе над аналогичным продук том с те же самых технологий. Обязатель но проанализируйте задачи, на которые ушло значительно больше времени, чем чтобы понять, почему в оценку вкралась Полнота плана Не совершайте ошибку планируя лишь разработку самой программы: план должны отражать проекта.

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

Тестирование Этот раздел должен давать достаточно времени для планов и сценариев испытаний, а также для тестирования самой инфраструктуры. План испытаний должен выделять добавочное время на тес тирование ПО после окончания каждого промежуточ ного работы.

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

К таким факторам относятся поставки и ПО от сторонних разработчиков, доступность.' О Глава Планирование и даже расширение штата или получение поддер жки от других групп.

Одна из основных идей этой книги может быть сформу так;

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

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

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

Баланс ширины и в работе над Следует так упорядочивать задачи при создании плана, что бы группы работали по всему фронту проекта, а не над от дельными его частями. Короче, не ограничивайтесь реали зацией какой-либо одной части системы, игнорируя осталь Например, работая над приложением для размещения заказов через Web, не составляйте план так, чтобы сначала был разработан пользовательский интерфейс, затем реали зована прикладная и лишь потом — весь код для работы с базой данных. Даже при наличии детальных цификаций структуры, поочередное решение всех задач обернется при их интеграции, поэтому надо ра ботать над всеми частями системы одновременно. Сосре доточьтесь на решении задачи, которая позволит простой заказ, сохранить его и вывести подтверждение, Такой подход позволит сразу создать комплексное реше ние, пригодное для и объединяющее все не обходимые программные проекта.

функций Часто в ответ на вопрос о планах от разработчика можно услышать такое: «Сначала нужно обновить менеджер ресур сов поддержкой 32-разрядных идентификаторов, потом изменить алгоритм анализа индекса PRODUCT ID, чтобы !

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

Трудности в работе с людьми Ниже описан ряд трудностей при составлении плана, име ющих отношение к работе с людьми.

Распределение работы Не все разработчики от рождения наделены равными спо собностями. Некоторые лучше всего программируют ин терфейсы, другие — V одних опыта боль ше, у других — меньше. У некоторых производительность труда очень высока, у других средняя или даже низкая.

Нельзя назначать задания случайным образом, полагая, что все люди обладают «типовыми» способностями. Распреде ляя задания между разработчиками, тех нологами и другими членами команды, следует быть очень осторожным. В каждом случае надо учитывать уровень ма стерства, индивидуальную опыт прак тической работы над проектами и Часть 2. и проекта Балансировка Задача состоит в равномерном распределении рабочей на грузки по реализации проекта на основе индивидуальных способностей участников команды. Однако будьте осто рожны и не перегрузите лучших участников команды. Хотя они могут сделать больше других, у них тоже есть свой пре дел. Эти люди еще пригодятся, чтобы помочь другим, ког да возникнут неприятности.

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

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

- : Глава Планирование подстерегающие любую команду Ниже ряд наиболее распространенных проблем с с которыми приходится сталкиваться ко мандам разработчиков.

Сроки: конечный и Конечный срок — это предположительная дата сдачи про екта. Обычно он на внешней рыночной конъ юнктуре и состоянии дел в отрасли. Эта дата очень поэтому нельзя с конечным сроком, не соста прежде план. Подставьте этот срок в пла нирования как одну из переменных и попробуйте уравно весить требуемую функциональность ПО и ресурсы для се разработки. Если уравнение не придется исклю чить часть добавить ресурсы или сделать то и дру гое в некоторой пропорции. Конечная цель в том, чтобы составить реалистичный и правдоподоб ный план, против которого не бы возражать ни один член команды.

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

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

Часть 2. и планирование проекта Ответственность за плана Чаще всего команду ставят перед жестко необходимый объем функциональности ПО, выделенные для этого ресурсы и к которому все должно быть го тово. И что за выполнение пла лежит не на разработчиках, а на организации или пер соне, которая эти требования «спустила Такова об щая формулировка этой проблемы. Боевой дух участников команды будет невысок: ведь они будут чувство вать, что их поставили в заведомо положе ние. Без чувства не принимая на себя обя зательств, команда не сможет вложить в реализацию про екта сердце и душу, и никакого Вместо этого группа разработки должна создать свой собственный план, точнее, сама поддерживать баланс в рам ках плана. С принятием обязательств в команде появляет ся чувство Выдвинув свой план разработ ки ПО, за который она отвечает, команда должна прило жить все чтобы выдержать установленные в нем сроки. Доверие — это следствие выполненных обязательств.

Из собственного опыта Разработка ПО в обычно проходила под огром ным давлением необходимости уложиться в срок. Конеч ные сроки сдачи наших продуктов приурочены к выходу Microsoft Visual Studio или появлению новых платформ и технологий, например Microsoft Windows 95, Microsoft Windows NT или Microsoft COM. Чтобы восполь зоваться преимуществом этих событий, наши группы маркетинга планы продвиже ния включающие рекламу, пресс-конференции, аналитические исследования, презентации и обучение продавцов. Ассигнования на эти мероприятия, зависящие от даты выхода ПО. достигают тысяч долларов.

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

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

Вопрос доверия к техническим специалистам Одна из наибольших проблем, с которыми сталкиваются технические специалисты, — доверия.

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

Ч Часть 2. Формулирование и планирование проекта Как составить хороший план Теперь можно сосредоточиться на особенностях составле ния хорошего плана разработки ПО. В этом процессе три основных этапа: определение задач, объединение задач в группы, называемые базовыми уровнями, и группировка последних в этапы проекта.

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

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

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

Базовые уровни Базовые уровни определяют срок реализации группы свя занных функций. Каждые 2-3 должен готов очередной базовый уровень. Помните: соответствующий фрагмент ПО должен устанавливаться с помощью програм мы установки, а его функциональность должна быть на для разработчиков. Реализация уровней — важ ные краткосрочные цели, на достижении которых необхо димо сосредоточить внимание и усилия команды. Вообще ничто может быть важнее своевременного завершения очередного базового Если он запаздывает, можно официально говорить об отставании проекта от плана, что требует немедленных корректирующих действий. Ниже приводятся ряд базовых уровней (из продукта Bounds Checker, для ошибок в программах).

• библиотека исходных текстов, выполнена пер вая ежедневная сборка программы, закончена устано вочная процедура для «скелета» программы.

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

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

• Программа успешно обнаруживает памяти типа 1 2.

Программа успешно обнаруживает утечки памяти типа • Программа успешно обнаруживает утечки памяти типа 6.

Часть 2. Формулирование и планирование проекта Появляется реальный пользовательский интерфейс программы, но без поддержки печати, сортировки и фильтрации.

• Закончена поддержка печати, сортировки и фильтрации, • Программа интегрируется с другими программами пакета.

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

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

Внешние промежуточные этапы В завершении промежуточных этапов участвуют люди или группы, не работающие над проектом Глава 11.

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

альфа-версии не предназначены для широкого однако могут быть полезны для демонстрации прогресса про или сбора внешних отзывов о функций;

бета-версия — выпуск, в котором реализованы если не все, то большинство функций;

бета-версии передаются клиентам для испытаний и оценки;

• на выпуск — в случае успешного окончания тестирования этот будет передан в ство для тиражирования;

появление кандидата на пуск — знак того, что проект почти закончен и выпуск ПО состоится;

• передача в производство — к этому времени рабочий выпуск будет передан в производство для тиражирова (или опубликован в Web, в зависимости от назна чения ПО).

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

выполнить частей и устранить остав шиеся неполадки перед выпуском продукта. (Подробнее о бета-версии и кандидате на выпуск см. главы 13 и Пример Чтобы закрепить основы, давайте шаг за рассмотрим подробный пример (табл. В таблице показано упро щенное описание проекта, откуда удалена часть 2 i] Часть 2. Формулирование и проекта ции, обычно в нем. Тем не менее этот пример достаточно чтобы продемонстрировать стыковку всех частей Ниже ряд допу сделанных при этого примера.

Принципы планирования.

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

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

Специалисты по обучению пользователей составля ют функций по мере их завершения. Ра бота по составлению документации должна как можно меньше отставать от реализации функции.

Подробно эти действия описаны в плане обучения пользователей.

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

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

Участники работы над проектом;

— ведущий занятый полное ра бочее время;

Джон — программист;

Джим — ведущий также отвечает за ав томатизацию;

Ф Фрэнк — тестировщик, исполняет ванное и ручное тестирование функций;

Сара — ведущий специалист по обучению пользо вателей;

— ведущий специалист по инженерной хологии;

Боб — ведущий технолог.

Промежуточные и внутренние.

План проекта состоит из 4 уровней, на ре ализацию которых отводится по 2 месяца, и 2 глав ных промежуточных этапов. Будут выпущены 1 на выпуск и 1 вер сия для тиражирования.

Каждый промежуточный этап 2 базовы ми уровнями. промежуточному этапу будет соответствовать наполовину закопченный проект, а — полностью законченный проект.

Часть 2. Формулирование и планирование проекта Примерный Дата Задача Разработчики Джон Джим января (место пустым, работа началась с следующей I Ф1 Ф2 P 22 января Базовый 2 Ф A № ] 19 Базовый уровень 3 А 26 февраля 05 уровень 4 А8 Р марта 26 марта 02 Базовый уровень 5 НИ 09 апреля набором функций fel с 23 апреля и мая и и небольших улучшений согласно Глава 11. Планирование Группа по обучению Группа по Группа по работе пользователей над использованию Сора сборки прог раммы и установочной процедуры в простом Д И И5 Улучшение программы и дуры плану Период и Д И Д Отдых сборки и ной согласно плану и И10.И И13 Версия с полным Д12,Д терка бета-версии Работа над Завершающая про цией согласно плану верка, оценка впечатления от продукта Часть 2. Формулирование и планирование проекта (продолжение) Дата Разработчики Джим с 28 мая №2 Устранение оши по 25 июня и и тес улучшений согласно 02 га Цифрами обозначены функции, следующими Ф — функция запрограммирована, выполнено блочное и псе с ней технические задачи;

Работа над бета-версией 1 займет 1 месяц. Функции 14 и будут добавлены время работы над бета версией а оставшееся время будет на тестирование, настройку и исправление ошибок. У каждого участника группы есть некоторый список действий на время работы над бета-версией Ф В бета-версии 2 не будет новых функций по сравне нию с бета-версией Внесение значительных изме нений в главные функции не допускается, разреше но лишь тестирование, настройка и исправление ошибок. У каждого члена группы есть список задач на это время.

• Кандидат на выпуск.

ф Версия-кандидат на выпуск будет готова к концу ра боты над №2, если ее пройдет успешно и не будет обнаружено серьезных ошибок.

Глава по обучению Группа по по работе над выпуском Сара Боб бета-версии документа- Визуальная Окончательная согласно плану оценка ПО Л — тестирование функции Т — функция протестирована вручную;

Д — функция документирована:

И — проверена простота использования функции.

Контрольные собрания.

Проведение собраний для контроля за состоянием проекта запланировано на каждый понедельник.

Если достигнуть базового уровня вовремя не лось (или все говорит об этом), придется вносить изменения, чтобы наверстать упущенное.

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

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

Однако разработка ПО — это не точная наука, и до проблем всегда рукой подать. Чтобы заметить малейшее отклонение проекта от намеченного пути, нужно проверять ход выполнения плана и после завершения каждого жуточного этапа сравнивать фактическое состояние екта с планом. Если работа отстает от плана, надо лить проблему, изменить план и постараться завершить очередной промежуточный этап в срок. Все так просто?

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

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

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

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

Это чем кажется на первый Кажется, что втиснуть задачи в рамки недель так про сто, но это может быть настоящим испытанием. Наверное, в плане всегда найдется задача, на выполнение которой отводится 3-5 недель. Такую долгосрочную задачу лучше разбить на несколько меньших. Чем чаще контролируется прогресс проекта, тем проще обнаружить отклонения от плана. Как правило, трудности при разбиении задачи воз никают из-за неполного ее понимания, а это тревожный признак. Чтобы лучше разобраться в том, что предстоит сделать, решение нужно смоделировать.

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

ИСПОЛНЕНИЕ Держим курс 3. Исполнение так, основное планирование закончено — остается лишь «нажать на рычаг и выдать готовый Хотя процесс выглядит довольно механистичным, все рав но приходится постоянно следить за ходом реализации проекта и бороться с повседневными проблемами. В этой главе мы обсудим, как эффективно следить за состоянием проекта и какие меры принимать, чтобы дать проекту от клониться от намеченного пути.

Анология с самолетом Представим самолег, из Бостона в Сан-Фран циско. Во время полета бессчетное множество факторов могут нарушить график рейса или сбить самолет с курса.

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

полета План полета разрабатывается задолго до взлета. Среди прочего в плане описаны этапы полета, следуя которым экипаж может привести самолет из пун кта отправления в пункт назначения (например: «лететь миль на запад, в пункте X повернуть на северо-за пад, затем 500 миль этот и т. д.).

Аналогично работа с прототипом и моделью ис пользования ПО позволила сформировать базовое представление о том, что создается в рамках проекта и на что это будет похоже в готовом виде. Грамотно веденное планирование позволило наметить основные этапы создания и определить сроки их нения. Таким образом, основное внимание во второй части этой книги (главы мы сосредоточили на создании «плана для проекта, Глава 12. Держим курс Элемент Хотя план полета рег ламентирует экипажа во время рейса, он не может и не должен предсказывать решать все про блемы, которые могут в полете.

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

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

По мере приближения к пункту назначения начинается работа по подготовке самолета к посадке, которая включает ряд специальных действий — от вы деления полосы диспетчером Часть 3. проекта до поднятия столиков пассажирами. Члены экипажа знают, какие процедуры нужно чтобы безопасно посадить самолет в нужном месте и точно по расписанию. Им приходиться лихорадоч но соображать, что делать, когда самолет уже на снижение.

Проект также нужно безопасно не до пуская никаких промахов при приближении конца пути. Надо организовать плавного направляющий завершающие этапы проекта. Этот про цесс нужно заранее, а не создавать в спешке во время на посадку*. Из-за важности последнего этапа я полностью посвятить ему главу 14.

Финиш Старт Время * Анализ и корректировка курса Рис. 12-1. Навигация в непредсказуемых условиях, Процесс измерений и мониторинга состояния проекта Как сказано в главе 9, план проекта — это совокупность описаний отдельных его этапов, каждый из которых харак теризуется определенным уровнем законченности Глава 12. Держим курс функций программы, который должен быть достигнут к заданному сроку. Эти этапы можно формально рассмат ривать как контрольные точки для оценки прогресса про екта. Если программы реализуется в срок, в заданном объеме и работает должным образом, зна чит, вы не сбились с курса. Обратная ситуация является про блемой, которую нужно сразу решать. Если программа бирается каждый день, в любой момент ее можно устано вить и ее тестирование ведется параллельно разработке, у вас есть необходимые инструменты и процедуры для регулярного контроля проекта. Кроме того, обладая планом, в котором отмечены даты и параметры конт рольных точек, всегда можно определить, на каком этапе находится проект в данный момент. Сравнив текущее поло жение проекта с планом, можно узнать, в верном ли направ лении идет работа.

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

Не конца работы над проектом, чтобы упущенное: тогда будет уже слишком поздно. Следу ет успевать выполнить намеченное к определенному сро ку прямо перед наступлением этого срока. Удалось уложить ся в срок — это хорошая работа, и успех обязательно нужно отметить всем вместе. Но если работа просрочена, соберите группу, в чем дело, и устраните проблему. Также необходимо составить план наверстывания упущенного.

Чтобы закончить проект к группа дол жна работать очень серьезно и напористо, про межуточные контрольные сроки.

: Часть 3. Исполнение проекта А есть ли способ заранее удастся ли достичь сле дующую контрольную точку вовремя? Завершение отдель ных этапов проекта формальные события, с которыми обычно объективные параметры. Но их, как прави ло, разделяет несколько а для проек та в периоды между соседними контрольными точками нужны дополнительные Решению этой проблемы и будет посвящена остальная часть главы. Я о правилах сбора текущих сведений о проекте и о том, как при необходимости менять направ ление и темп проекта. Помните: срыв плана в рабо ты проектом случается не а назревает ку, день за днем.

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

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

Собрания В той или иной форме контрольные собрания проводятся почти в каждой группе. Контрольные собрания — тельный способ сбора и распространения ключевой ин формации о состоянии проекта, поддержания и совместной работы в коллективе. Но если контрольные со брания проводятся они могут до смерти наскучить людям, породить ощущение беспомощности и нарушить сплоченность группы. Ниже перечислен ряд при держиваясь которых, можно извлечь из контрольных со браний максимум пользы, • У должна определенная цель На конт собрании участники группы сообща обсужда ют крупные достижения, неудачи и трудности. Сосредо точьтесь на том, что удалось и что не удалось. На также поднимают важные проблемы, требующие внимания одного или нескольких участников группы:

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

• Не посвящайте решению часто становятся местом встречи нескольких группы, которые хотят обсудить свои про блемы. Несомненно, эти проблемы важны и требуют но контрольное собрание — не место для решения технических и других Часть 3. проекта вопросов. Если попытаться охватить проблемы всех участников группы, то лучшую часть дня придется потратить на собрания, при этом часть времени остальных участников группы будет потеряна зря: люди должны знать суть решения, а не его подроб ности, ли каждый разработчик отсиживать на со брании, новому формату электронной справки? Должен ли каждый тестировщик как разработчики обсуждают набор изменений в API?

Нет. Если проблему нельзя решить за две минуты, для ее решения надо отдельное собрание, пригласив только тех, кого эта проблема касается. Решения, выра ботанные на собраниях, посвященных частным пробле мам, следует доложить на общем контрольном собра нии. используйте общегрупповые контрольные со брания для решения частных проблем.

Столь же неправильно докладывать на контрольном собрании о всех задачах, над которыми пришлось ра ботать за неделю. Нужно лишь сказать, идет ли разра ботка проекта по намеченному пути. Если нет, надо пе речислить причины, все остальное несущественно.

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

Глава 12. Держим курс • Ведите список нерешенных Во время реали зации обычно возникают проблемы, которые надо решать. Чтобы не забыть о них. в главе 5 я реко мендовал регистрировать такие проблемы, ответственных за их решение и обязательно найденное другим, Аналогичную концепцию можно применить при проведении контрольных собра ний. На собраниях проводится анализ нерешенных проблем, ответственные за их решение и устанавливаются сроки. Таким образом, каждый будет знать, что все проблемы будут рассмотрены и решены.

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

мимоходом» Очень полезна технология «управления мимоходом» (Mana by Walking Around, Контрольные собрания формальность, но менеджер проекта и I Часть 3. Исполнение проекта просто находясь группе, могут встречаться с участниками для неформального тех или иных проблем.

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

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

• Такая практика допускает спонтанное обсуждение важ ных предметов и проблем, в ходе которого часто рож даются совершенно новые подходы к их решению. За мечательные идеи не рождаются в два часа пополудни каждый понедельник. Чтобы они возникали, нужно по ощрять внеплановое, неформальное и нерегламентиро ванное общение, Поскольку почти все ведущие специалисты когда-то были просто инженерами, они очень не любят отры ваться от компьютера и покидать свой офис. Но проис ходят просто удивительные вещи, когда кто-то мимохо дом спрашивает их: «как идут базисные «что но вого с проблемой X?» или «ну как, уже заканчиваем второй • Хороший менеджер проекта и ведущий специалист обя зательно проводит некоторое время наедине с участни ками группы. Такие встречи не обязательно должны быть формальными или проводиться по расписанию.

Одного короткого визита участника по какому-нибудь ! Глава 12. Держим курс личному или рабочему вопросу достаточно для поддер жания сосредоточенной и слаженной работы. Кроме того, это замечательный способ избавиться от проблем с кадрами или иных трудностей при про екта, прежде чем они возникнут. Если вы не хотите по лучить неприятный сюрприз во собрания или, что еще хуже, накануне сдачи проекта, как можно чаще общайтесь со всеми участниками груп пы и с каждым по отдельности.

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

Неудачи Неудачи необходимо как можно скорее сообщать о них всем участникам команды и устранять. Не стоит ожидать от команды абсолютно бе зупречной работы. Знайте: проблемы возникнут непре менно. Работа команды заключается том, чтобы как можно скорее найти их и решить. Худший способ борьбы с замалчивать их или вовсе не признавать их существования, так как это не поможет Часть 3. Исполнение проекта ни проблему, ни вернуть проект на намечен ный путь.

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

Внесение изменений Беспроблемных проектов не бывает. Конечно, есть надеж что заранее предупредит о трудностях. Это поможет ликвидировать их, прежде чем они перерастут в проблемы. Однако чтобы уст ранить отклонение проекта от намеченного пути, потребу ется изменить направление работы и, возможно, увеличи вать ее темп. Посмотрим, как можно это сделать.

Смена курса Анализируя возможность изменения существенных элемен тов проекта (функций, технологии, платформ или плана реализации), нужно обязательно придерживаться следую щих правил. Они избежать неприятностей и при нять правильное решение, • факты, но не с их анали Часто решение на основе ний, эмоций или случая, а не анализа на бора неопровержимых фактов. Прежде чем в проект изменения, убедитесь в их необхо димости. В частности, не позволяйте эмоциональным утверждениями типа "Программа виснет на каждом шагу» стать причиной от реализации половины функций программы и переброски дополнительных ресурсов на Прежде чем действовать, со Глава 12. Держим курс берите факты. каких условиях происходит зависа Кто о зависаниях? Как часто они проис Вполне выяснится, что все эти зави сания связаны с заурядными ошибками, устраненными на прошлой неделе.

С другой стороны, постарайтесь не в ловуш ку «паралича анализа». Не убивайте на анализ проблем лишь чтобы оказалось, что момент для исправления Например, если после долгих раз думий так и не удалось собрать достаточно данных, что бы на изменение какой-то функции, прими те решение немедленно, исходя из текущих знаний.

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

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

по выпуску или продаже или другие члены команды по созданию попросите их помочь.

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

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

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

• и Следует подумать о найме консультантов и исполнителей для выполнения четко и относительно крат косрочной работы. Ваша задача — закрыть критические участки на которые не хватает кадров, Но остерегайтесь в ведущих специалистов, так как они скорее всего покинут группу по завершении проекта.

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

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

Задавайте верные вопросы Есть хороший способ решить, вносить или не вносить менение. этого нужно спросить у себя: «А что, если я не стану этого Такие вопросы особенно полезны в борьбе с так называемым «дрейфом который может прибавить работы группе. Однако за частую изменения вносят без солидного технического или обоснования. Изменение может вопло щать хорошую идею, но она может не стоить того риска, ко торому подвергает весь проект. должен быть оп ределенный уровень совершенствования функций, но не до такой степени, чтобы проект был захлестнут потоком мел ких изменений. Всегда спрашивайте себя: «А что, если я не стану этого Это заставит сравнить цену отказа от изменения с ценой его реализации.

Вот примеры хороших вопросов, па которые нужно ответить при предложения о реализации но вой функции.

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

• Скольким клиентами будет полезна новая функция?

• Не сорвет ли (или риску) новая функция срок выхода продукта?

Часть 3. Исполнение проекта Снизится ли конкурентоспособность продукта без этой функции?

Какому риску подвергнется качество продукта при от сутствии новой функции?

Какое влияние окажет функция на использование программы, документацию, а также на процессы ее сборки и установки?

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

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

Смена темпа работы Несмотря на самые благие намерения и усилия по плани рованию, порой приходится увеличивать темп работы, что бы уложиться в сроки или отреагировать на изменившие ся условия. На первых порах сверхурочная работа требуется • Глава 12. Держим курс для большинства такая ситуация так же типична для которые в сжатые сроки, но бывают действительно требующие особой и речь здесь идет не про сто о парс лишних часов в неделю. Прежде чем принять об увеличении нагрузки на группу, нужно знать, когда это уместно и как делать это Когда увеличить нагрузку проекта и специалистам очень знать, когда нужно просичъ команду или ее участника о до усилиях. Чтобы эта ее причины должны быть обоснованы, а — ясны каж дому. Дополнительная работа потребуется, необходи мо этап в срок Если очередной этап работы близится к концу и при этом ние, что можно не уложиться в нужно начинать сверхурочную сейчас, а не позже. Как сказа следует дожидаться следующего эта па, чтобы обнаружить проблемы с текуще го. Если что план может сорван, приложить усилия чем позже.

Если не удалось уложиться срок при этапа работы, упущенное придется Помимо этого, нуж но завершить следующий этап в срок. Если вы хотите закончить работу проектом, прило жите усилия уже • с Если на произошли серьезные изменения, чтобы достигнуть успеха или просто не быть вытесненным реализацию проекта придется ускорить. При этом, воз можно, придется добавлять новые функции к продукту Время — деньги Часть 3. Исполнение или ужать план на месяц. Это потребует от всей группы полной самоотдачи.

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

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

Определите сверхурочных бот Необходимо четко определить продолжитель ность периода работы — он не может быть открытым или неопределенным. Следует поста вить конечную задачу: уложиться в заданный срок или достичь определенного конечного результата;

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

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

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

Когда работы было особенно много, как правило, все работали сверхурочно, оставаясь после работы. Это было веселое время, и часто сверхурочные часы превращались в вечеринку. Хотя людям приходилось жертвовать соб ственным и допоздна на работе, все знали, для чего это делается, и верили, что наша ра бота для общего дела. Когда работа была за кончена, мы решили пригласить на празднование выпуска своих Мы понимали, какие не удобства работа доставила нашим семьям, и хотели как-то отблагодарить их за проявленное терпение, Часть 3. Исполнение проекта • о прогрессе Если людям приходится много работать сверхурочно, они обязательно знать, что они являются двигателем проекта, Как менеджер проекта или ведущий специалист, вы дол жны показать команде, что их усилия оправдываются;

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

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

Бы что завершили эту работу?

Вас никогда не спрашивали на контрольном собрании: «Вы уже закончили работу над На самом деле это очень рас плывчатый вопрос, однозначный ответ на который дать очень трудно. Означает ли что код написан и его мож но скомпилировать? Или функция но работала пару раз, когда вы пытались использовать А, может быть, выполнено блочное тестирование мы на всех поддерживаемых платформах и конфигураци ях? А что это означает для из соседнего от дела? Обязательно заведите для себя ченной и ознакомьте с ним всех, иначе вы запросто обнаружите людей, в поте лица работающих над тем, что вы «закончили» несколько недель назад, Глава 12. Держим курс Борьба с нехваткой Один из главных грехов фазы исполнения проекта — задер жка работы из-за «нехватки оборудования*. Если разработ чику понадобится более емкий жесткий диск, техническо му писателю — новая мышь, а — программа для мониторинга, следует доставить их немедленно. Ника кие мелочи и пустяки не должны задерживать работу над проектами или снижать эффективность команды. Менед жер проекта должен заботиться о личных нуждах, проблемах и потребностях каждого члена группы, Из собственного опыта В преддверии выпуска последней одного из продуктов нам приходилось работать все ночи и выходные напролет. К сожалению, нельзя сказать, что наш сервер был с нами солидарен: в течение дня он постоян но зависал без видимых причин, останавливая при этом всю сеть, В результате мы не могли проводить сдачу раз работанных фрагментов ПО и делать контрольные сбор что просто убивало нашу производительность.

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

мы поумнели настолько, что просто купили новый сервер. Если бы мы догадались поменять его пер вые два дня, то смогли бы три недели рабо ты, времени л усилий.

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

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

Pages:     | 1 | 2 || 4 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.