Книги, научные публикации
Pages: | 1 | ... | 2 | 3 | 4 | Эд - ДЕНЬГИ Создание команды разработчиков программного обеспечения Москва 2002 Р У С УДК 004.45 32.973.26-018.2 С16 Э. ...
-- [ Страница 4 ] --28 ] Бета тестирование Часть Исполнение проекта ета-тестирование Ч это процесс проверки ПО внеш ними силами. Б начале программы бета-тестирования новое ПО рассылается реальным или потенциальным заказ чикам (бета-тестерам) для и предостав ления отзыва о его работе. Задача Ч получить от бета-тес теров объективную оценку возможностей и качества ПО.
получить ценные сведе ния о готовности ПО, прежде чем оно попадает к заказчи кам. Программы бета-тестирования являются решающим фактором успеха в начале развития компаний, когда объем ресурсов, выделенных под проекты, ограничен. Бета-тести рование, как никакой другой способ, позволяет эффектив но организовать тестирование программы. Оно не только расширяет группы разработчиков в сфере контроля качества, но и обеспечивает поступление из внешнего мира объективных и достоверных отзывов о воз можностях вашего ПО.
С другой плохо проведенное бета-тестирова ние означает, что не только разработчики, но и бета-тесте ры лишь зря потратили на него свое время. В этой главе мы обсудим ключевые аспекты проведения хорошей програм мы бета-тестирования и способы улучшения программных продуктов с помощью бета-тестирования.
Ценность бета-тестирования Прежде чем говорить о способах проведения хорошего бета-тестирования, обсудим, в чем вообще его польза.
понимая ценности бета-тестирования или не веря в ее су ществование, вы никогда не выделите достаточно времени и средств, чтобы провести его на должном уровне. Вот са мые значительные аспекты пользы от бета-тестирования, Х Проверка ПО в условиях реального мира Независимо от того, хорошо проведено внутреннее тес воспроизвести в полном объеме все Глава Бета-тестирование проводимые многочисленными бета-тестерами, было бы сложно (если такая задача вооб ще выполнима). Если вы не ошиблись с подбором бета тестеров, они помогут проверить работу новой про граммы на широком спектре вычислительных плат форм и в самых разных ситуациях, все которых вы скорее всего никогда не смогли бы охва тить. Поскольку бета-тестирование выполняется реаль ными пользователями в реальных условиях, они часто обнаруживают такие которые никогда бы не были найдены без их помощи.
Хорошие бета-тестеры позволяют проверить готов ность ПО к использованию чем оно будет от правлено заказчику. Эта информация сама по себе уже стоит затраченных на проведение бета-тести рования;
Оценка работы ПО Второй аспект пользы бета-тести рования Ч это получение отзывов о качестве о производительности и о качестве пользовательского интерфейса ПО. Поскольку бета-тестеры работают с программой в самых разных условиях, они лучше го смогут обеспечить вас о пользователь ских потребностях, симпатиях и антипатиях. Кроме того, они подскажут вам массу новых идей. Хотя на дан ном этапе вносить существенные изменения в програм му не желательно, эти идеи послужат превосходной от правной точкой для работы над следующим выпуском;
маркетинге Бета-тестирование позволяет сделать программу более на рынке и повысить доверие к ней, что будет вовсе не лишним для маркетин говой политики нового продукта. полу чившие положительное впечатление от работы с новой программой, Ч отличный источник материалов для пресс-релизов и рекламных каталогов. Они также про ' 3. Исполнение проекта вашу программу в по скольку склонны обсуждать, рекомендовать и высказы ваться за использование программы как в своих фир мах, так и публично. Бета-тестеры распространя ют слухи о новой программе, что особенно ценно для ее презентации и при на рынок.
Однако от плохо бета тестирования вряд ли стоит ожидать помощи в марке тинге и раскрутке новой программы. Нужно тесно вза с бета-тестерами, идти навстречу их и оказывать им всестороннюю поддержку. Кро ме того, необходимо дать бета-тестерам почувствовать, что вместе с разработчиками они являются единой командой. Чем больше усилий вложено в бета-тестиро вание, тем больше шансов получить от него пользу.
рабочая сила Один из главных ас пектов бета-тестирования Ч возможность увеличить число работающих над проектом. При реализации как начальных, так и крупномасштабных проектов, про граммы обеспечивают изрядное ко личество дополнительной рабочей силы, которая обо шлась бы в сотни тысяч или даже миллионы долларов при найме по или иным способом. В следу ющий когда вы задумаетесь над вопросом, нужна ли вам программа бета-тестирования, проведите нехитрый расчет. Умножьте число бета-тестеров на время, кото рое тратит каждый из них на испытания ПО, умножьте результат на размер почасовой оплаты труда наемных и получите денежное выражение цен ности бета-тестирования.
Глава Бета-тестирование распространенная при проведении бета-тестирования В том, что результаты бета-тестирования становятся опре деляющими при формулировании требований к программе. Не следует использовать программу бета-тести рования для поиска функций, которые должны быть реа лизованы в чтобы обеспечить ее успех. Так подбирать функции уже слишком поздно, их нужно было определить на этапе формулирования требований и ком мерческого анализа программы (см. главу Если стало ясно, что программа обречена на провал на рынке, не ста райтесь впихнуть новые функции в продукт, который вот вот будет закончен. тайм-аут и обсудите возмож ные альтернативы: может, лучше начать все с самого нача ла, составив новый набор требований и план?
Помните: цель программы бета-тестирования Ч испы тание и усовершенствование продукта, поиск идей на буду щее и помощь в продвижении продукта на рынке. Во вре мя работы с бета-версией идет сбор отзывов о реализации функций, возможных улучшениях, и качестве программы. Кое-что из этого еще можно изменить, но для добавления новых сложных функций этот период совер шенно не годится.
Типы программ бета-тестирования Программа бета-тестирования обычно состоит из несколь ких фаз. Каждая последующая фаза включает в себя все большую группу пользователей, и результатом ее является все более сложный и стабильный продукт. Несмотря на от сутствие формального определения фаз программы бета тестирования, принятого в отрасли, приведенное ниже описание поможет составить общее представление о каж дой фазе.
3. Исполнение проекта Фаза 1 К этой фазы должно быть написано 60-80% кода. Задача этой фазы Ч как можно скорее пе редать функции программы для испытаний лучшим бета-тестерам.
Допустим, фазу решено начать уже после завершения основных функции. В программе пока поддержки реализована лишь малая спра вочной нет сложных алгоритмов сортировки, фильтрации и функций пользовательского интерфейса.
Однако продукт уже пригоден для работы, и отзывы окажут существенную помощь при тестировании и до водке его функций.
этом этапе еще есть время для внесения неболь ших, но важных изменений. Это вполне обычная прак в ней нет ничего неожиданного. Необходим под ходящий момент для улучшения ПО на отзывов клиентов и углубленного понимания продукта. Однако нужно быть уверенным, что изменения не нарушат пла на и не снизят качества Если такой уверенно сти нет, подумайте, перевесит ли выгода от реализации новых функций затраты на расширение плана.
Фаза 2 К началу второй фазы код продукта готов на 100%, Все функции, которые намечено реализовать в окончательном выпуске продукта, запрограммированы и работают. Хотя существенно менять какие-либо функ ции не планируется, некоторые изменения все же мож но внести, если они действительно важны и не влекут за собой серьезного риска. В этом случае тоже необхо дима уверенность в отсутствии негативного влияния изменений на исполнение плана проекта или качество продукта.
Фаза 3 В начале этой фазы функции продукта приоб ретают окончательный вид. Изменений возможностей программы или набора ее функций не планируется.
Глава 13.
Согласно плану программы получит здесь форму, никаких изменений пользовательского интерфейса ожидается. Набор функций блокируется, и группа концентрируется на качества, производительности и ке, необходимой для успеха хорошей программы. На этом этапе задачей всей группы является подготовка продукта к коммерческому использованию путем тести рования, исправления ошибок и приведения докумен тации к окончательному Маркетинговое Это особый тип программы бета-тестирования, в рамках которой по тенциальные клиенты получают ПО, чтобы оценить, насколько оно соответствует их потребностям. Марке тинговое бета-тестирование особенно когда программа даст клиентам существенные, циально революционные возможности, а также в случае продукта, имеющего большое значение для роста про даж компании. В таких ситуациях имеет смысл проде монстрировать клиентам успехи при создании продук та и спектр возможностей, которые они получат после его завершения, важно произвести положительное чатление на клиентов, не спровоцировав у них необос нованных ожиданий, лучше использовать для гового бета-тестирования одну из поздних бета-версий (вторую или третью). Таким образом, можно быть уверенным, что клиенты увидят высококачествен ное и технически совершенное ПО.
Из собственного опыта Когда работа в NuMega вступала к фазы бета-тестирования, мы всегда рассылали копии тем, кто в отрасли. В этот список входили Часть 3. проекте партнеры, специализирован ные издания и занятые в отрасли, Прежде всего мы хотели, чтобы ПО было свободно до ступно кто может нашему Это было маркетинговое бета-тестирование в полном смысле этого слова, так как мы не ждали (и даже хоте ли!) извещений о ошибках или затруднениях, Этот способ позволил донести имя и нашу продукцию до способных к ствию в нашем деле.
Элементы программы бета-тестирования Мы проанализируем ключевые элементы бета-тестирова ния и рассмотрим, что необходимо сделать для максималь ного эффективности этого процесса в группе.
Начало программы Прежде чем приступать к набору первых бета-тестеров, надо решить ряд простых, но важных вопросов.
Х Каковы основные черты бета-тестера? Опре делите профиль потенциального пользователя вашей программы. Какими навыками он должен обладать, ка кой опыт работы с подобными продуктами в данный расли ему нужен? Какие технологии, конфигурации и платформы должны быть ему доступны? Сколько време ни и усилий потребуется от бета-тестеров на испытание программы?
Х В чем цель программы Независимо от того, начинаются ли испытания ного или неосновного выпуска нужно, чтобы люди сосредоточились на испытании ключевых программы, находящихся в разработке. Принципы ра Глава 13.
боты этих быть всем бета-тесте рам, чтобы они смогли лучше и оце нить ПО.
бета-тестеров потребуется? Количество критично для эффективности программы Если их слишком мало, то и инфор мации будет собрано а если их число черес чур велико, то можно не справиться с администрирова нием, управлением и поддержкой всех что у ощущение беспомощнос ти и к потере важной информации. Как пра вило, лучше привлекать на 3096 больше чем по расчетам понадобится для испытания програм мы. Это позволяет от неизбежных на кладок, возникающих, когда бета-тестеры неэффектив но или вообще тестирование.
Обычно в первой фазе бета-тестирования задей ствовано меньше всего тестеров, так как продукт еще готов для всесторонней оценки. К участию в первой фазе следует привлекать таких бета-тестеров, которые смогут с и трудностя а также помогут при отладке и диагностике ошибок.
во время третьей фазы к испытаниям програм мы должны присоединится все привлеченные для уча стия бета-тестеры.
Каковы сроки Про должительность программы бета-тестирования также имеет значение для ее Хотя как правило, стремятся максималь но (чтобы быстрее отправить продукт заказ чику), урезать ее настолько, чтобы преимуществ, которые она дает.
Часть 3. проекта существенно расширить штат бета-тестеров, одна ко надо убедиться в наличии у них достаточной для это го квалификации.
и союзники Партнеры и поставщики ком пании также могут стать отличными бета-тестерами.
При наличии деловых или технических связей с други ми компаниями попробуйте привлечь их к бета-тести рованию продукта. Взаимный интерес может быть до статочно велик, чтобы протестировать совместную ра боту продуктов.
Необходимо составить профили бета-тестеров, кото рых хотелось бы привлечь к участию в программе бета-те стирования. Например, желательно, чтобы часть бета-тес теров пользовалась локализованными версиями Microsoft для тестирования продукта, предназначенного для японского, корейского и китайского рынков, а другая часть бета-тестеров работала на многопроцессорных системах.
Не важно, какова формулировка задач, чтобы при распределении их между бета-тестерами последние обес печивали доскональную проверку ПО в соответствии с тре бованиями бета-тестирования.
Кроме того, перед получением ПО каждый бета-тестер должен подписать соглашение о коммер ческой тайны. Это соглашение поможет обеспечить конфи денциальность ПО и свести к минимуму потенциальную утечку информации к конкурентам.
с бета-тестерами Регулярный обмен с бета-тестерами достоверной и правди вой информацией имеет решающее значение для успеха программы бета-тестирования. Нужно заранее определить все ожидания и обеспечить своевременное решение любых проблем, а также удовлетворение любых потенциальных потребностей и запросов. Вот основные правила.
Глава 13.
Четко обозначьте начало и ко нец бета-тестирования, проинформируйте бета-тесте ров о новшествах в текущем выпуске ПО, заострив вни мание на всех моментах, требующих проверки. Поставьте тестеров в известность о том, что как можно скорее сообщать о найденных ошибках, а после бета-тестирования Ч за полнить Дайте что их отзывы представ ляют большую ценность и вы постараетесь как можно скорее устранить найденные неполадки, О и решениях все Если какая-то важная часть программы не работает, дайте о возникшей про блеме и что над ее решением уже работают. Для этой цели лучше всего подходит электронная почта. Однако если требуется более интерактивное обсуждение труд ностей, проблем и потребностей, надо подумать об от крытии на вашем Web-узле специализированной теле конференции.
Решайте проблемы их возникновения стеры должны сообщать о своих трудностях и обнару женных проблемах (и достаточ но опытному) персоналу из группы поддержки. Если у вас пока нет группы поддержки, нужно выделить для работы с бета-тестерами одного из В любом случае нужно регистрировать возникшие зат руднения и обнаруженные ошибки.
Также следует рассмотреть создания или, если надо, покупки для обработки посту пающих сообщений об обнаруженных бета Системы по обработке сообщений специально для обработки обращений клиентов, желающих сообщить о возникших трудностях. Возмож ность следить за поступающими от Часть 3. Исполнение проекта их адреса и контактную ин обстоятельства возникновения ошибки, ча стоту обращений и другие данные, а также взаимодей ствовать с группой технической поддержки представляет настоящую ценность. Эта задача превосходно решает ся с систем обработки поступающих сообще в то время как большинство систем отслеживания ошибок с ней не справляется. пользовате лем сообщение об следует регистрировать в системе, только если оно и ошибка изводится.
Х Доводите решение до Как правило, выделить специального разработчика, который в прямом контакте с бета-тестером доведет решение найденных проблем до конца. Прямое взаимодействие ускоряет процесс разрешения проблем и способствует упрочению связей бета-тестерами и раз работчиков. Кроме это прекрасная возможность для технических специалистов поближе познакомить ся с их проблемами и их манерой работы с программой.
Не закрывайте глаза на проблемы бета-тестеров Вам наверняка придется столкнуться с проблемами, возни кающими у Ваше ПО может повредить реестр их ОС, а программа удаления ПО может заодно стереть ключевые системные файлы. Обязательно про следите, чтобы под рукой всегда были люди, способные разобраться с этими проблемами.
Оценка прогресса бета-тестирования Чтобы начало программы бета-тестирования, бета-тестеры должны быстро получить и ПО.
Это можно сделать, опубликовав ПО в Web или разослав его на CD-ROM. Если выбрать публикацию ПО в Web, можно ;
, Глава 13. Бета-тестирование отслеживать число скачивании и сравнивать с числом бета-тестеров. С другой стороны, рассылка бета-версии на CD-ROM позволяет быть уверенным, что тестеры получат продукт целиком.
Когда ПО будет у каждого, проследите, чтобы все бета тестеры с ним. В любом случае разумно обязать администратора бета-тестирования обзвонить или спи саться по почте с каждым бета-тестером, что бы убедиться, что все они работают с ПО. Важно стимули ровать усилия бета-тестеров и не дать им остановиться на полпути, В начале поступления выделите самые распро страненные трудности, с которыми пришлось столкнуться бета-тестерам. В частности, немедленного решения требу ют проблемы, возникшие из-за ошибок при установке или из-за недостаточного ставших причиной затруд нений у значительной части бета-тестеров. Самыми подхо дящими кандидатами на эту роль являются администратор бета-тестирования и ведущий специалист технической под реагирующие на любые возникающие проблемы.
Такие неполадки нужно устранить как скорее, ина че под угрозой окажется вся программа бета-тестирования и ее польза для группы.
Завершение программы бета-тестирования При свертывании обязательно попроси те прислать сведения обо всех ошибках и до сих пор оставшихся без внимания. Это также самое подхо дящее время, чтобы разослать бета-тестерам анкету, пред ставляющую формальный план отзыва о работе продукта.
С ее помощью очень легко выяснить, насколько интенсив но и для каких целей продукт, какие при этом возникли трудности и проблемы. Такая информация слишком часто остается в голове бета-тестера, а анкета Ч Часть 3. проекта прекрасный способ выудить оттуда ценные мысли и идеи, чтобы позже извлечь из них выгоду. Ниже приводят ся примеры вопросов Как долго использовался продукт?
Удалось ли легко и быстро установить его?
Х Помог ли продукт быстро решить ваши проблемы и до стичь поставленных целей?
Х Какая из функций программы оказалась самой полез ной для вас?
Какая из функций оказалась наименее полезной и по чему?
Х Какую из функций вам больше всего хотелось бы уви деть в следующем выпуске программы?
Х Как можно было бы улучшить документацию или спра вочную систему ПО?
Оправдала ли производительность продукта ваши ожи дания?
Х Собираетесь ли вы регулярно использовать продукт?
Собираетесь ли вы стимулировать использование про дукта в вашей группе? Почему?
Х Порекомендовали бы вы его другим? Почему?
Готов ли продукт? Если нет, то почему?
Обязательно поинтересуйтесь, нет ли у бета-тестеров комментариев для пресс-релизов. Оказалось, что авторами лучших отзывов о продуктах компании NuMega были имен но участники бета-тестирования. Мы донесли эти отзывы до всех работников компании и клиентов и, конечно же, опубликовали.
Из собственного опыта По окончании бета-тестирования мы в NuMega оценива ем эффективность каждого бета-тестера как высокую, Глава 13.
или бета-тестерам мы посыла бесплатные программы, футболки и даже куртки. Средним достается только один подарок, а тех, кто принимал заметного участия в мы вов се исключаем из программы. Со мы почувство вали, что можем положиться на наших бета-тестеров в получении отзывов, так и в испытании новых продуктов работе над бета-версиями и канди датами на выпуск.
Как-то раз мы выпускали бета-версию в пятницу око ло четырех часов дня. Разослав бета-тестерам сообщения, мы уже готовились отправиться по домам, когда один из тестеров прислал где говорил, что отложил свида ние лишь для чтобы увидеть наш выпуск!
В тот же вечер он сообщил, что на первый взгляд новый выпуск неплох, но он еще не успел полностью его изу чить. Вот так порой сталкиваются преданность и личные дела!
Поощрение лучших бета-тестеров По завершении проанализиро вать, что прошло хорошо, а что Ч нет. Б рамках этого ана лиза нужно оценить работу самих бета-тестеров. Необхо димо выделить и поощрить тех, кто вовремя предоставлял ценную информацию. Если какие-либо тестеры вообще никакой от их услуг лучше от казаться, чтобы освободить место для новых участников.
Менеджер бета-тестирования Курирует бета-тестирование и управляет ее исполнением.
Поскольку программы бета-тестирования зачастую и сложны, эту работу должен выполнять штат ный специалист. Это может показаться чересчур для такой работы, но с учетом ценности хорошо проведенного Часть 3. Исполнение проекта тестирования, все затраты с лихвой.
В компетенцию менеджера бета-тестирования входит сле дующее.
Х целей и задач Менеджер ния должен следить за тем, что для программы бета-те стирования определены профиль клиента, мас штаб и Х бета-тестеров Менеджер должен чтобы к выпуска бета-версии было набрано достаточно при нять участие в испытаниях программы. Очевидно, что любая задержка с набором достаточного числа бета-те стеров уменьшит объем и снизит качество получаемой информации.
Х ПО Менеджер бета-тестирования составляет и реализует план распространения ПО сре ди бета-тестеров как через Интернет, так и на физичес ких носителях. Он должен обеспечить быструю и эф фективную передачу ПО каждому бета-тестеру. Если ре шено распространять программы через сеть, надо убедиться в наличии линий связи и серверов, необхо димых для поддержки большого числа одновременных обращений Если для ПО выбран физический носитель, необходимо обеспе чить достаточные производственные мощности для своевременного распространения ПО.
Х Распространение сведений о состоянии бета-тести рования Менеджер является информационным цент ром, снабжающим всех бета-тестеров сведениями о со стоянии программы бета-тестирования. В частности, он объявляет начало и конец бета-тестирования, а также сообщает о новом доступном ПО. Он также является связующим звеном между бета-тестерами и группой создателей продукта, обеспечивая обмен важными S Глава 13. Бета-тестирование изменения в плане программы бета тестирования, появление ПО, исправлений критических ошибок и передачу специальных запросов на отзывы.
Х Управление бета-тестирования От менеджера во многом зависит успех программы бета тестирования. Почти сразу после ее начала он должен обзвонить бета-тестеров, чтобы проверить, получили ли они ПО и, если да, начали ли работать с ним. Менед жер бета-тестирования должен за успехами каждого бета-тестера и обязательно стимулировать от чтобы они ПО и приступили к работе;
Х Завершение программы бета-тестирования Менед жер должен так провести свертывание бета-тестиро вания, чтобы не разочаровать еще не закон чивших работу с продуктом. Менеджер запрашивает у тестеров их окончательные идеи, комментарии и со общения об ошибках, а также обеспечивает их своевре менное получение.
бета-тестеров Бета-тестеры Ч чрезвы ценные участники проекта. Хороших тестеров необходимо поощрять, плохих Ч исключать из про граммы.
Общие проблемы и решения Далее обсуждается ряд типичных проблем и воз никающих при использовании описываемых здесь методик, а также их решения.
Начинайте пораньше Набор бета-тестеров требует как и подписание соглашения о коммерческой тайны. Набор задолго до готовности Часть 3. Исполнение версии программы. Для программы, в которой участвует 200 бета-тестеров, я рекомендую оставлять 60-90 дней.
Не забывайте, что бета-тестеры заняты своими делами меньше вас и приступить к оценке ПО с опозда нием. В общем случае эту проблему можно решить тремя способами. Во-первых, если продукт сложен и для его ус тановки нужны значительные ресурсы, можно послать к бета-тестерам своих людей, чтобы помогли установить и запустить ПО для тестирования. Во-вторых, можно пред положить, что до трети не смогут начать те стирование вовремя или откажутся от него. Поэто му следует включить в программу дополнительных бета тестеров, чтобы компенсировать их возможный недостаток и не допустить задержки. В-третьих, следует непременно с каждым бета-тестером лично (если можно, по телефону), чтобы следить за их успехами в начале проекта и составить представление об их возможности участвовать в программе бета-тестирования, Бета-версии должны быть проверены Как я говорил в главе выпуск каждой бета-версии зна менует завершение крупного промежуточного этапа в ра боте над проектом. Таким образом, прежде чем рассылать бета-версию бета-тестерам, нужно завершить период ста билизации и интеграции. Этот период (обычно 1 -2 две на дели) используется для тестирования, исправления ошибок и решения серьезных проблем. Качество ПО должно быть достаточным для работы на местах бета-тестирования. До выпуска продукта во внешний мир надо подумать о прове дении внутренних испытаний, о которых пойдет речь в гла ве 14. Бета-версия Ч это не окончательная версия ПО, однако изложенные в этой главе концепции помогут из влечь пользу даже из нее.
Глава 13.
Необходима мощная инфраструктура Для нормального проведения бета-тестирования нужна подходящая программная и аппаратная инфраструктура, Скажем, для управления поступающей от бета-тестеров формацией, статусом о неразглашении ком мерческой тайны, оценки работы бета-тестеров скорее все го потребуется специальная программа. недооцени вать объем информации, с которым работать.
Как справиться с потоком информации Самой большую пользу от бета-тестирования представля ет информация, которую оно позволяет получить. Проце дуры передачи, обработки и продвижения информации должны быть четкими и понятными. Для поддержки бета тестирования обязательно нужны компетентные и хорошо обученные специалисты. Также необходимо оставаться в контакте с бета-тестерами в течение всего процесса бета тестирования.
Не жалейте времени Для бета-тестирования должно быть выделено достаточно времени. Начав его в понедельник, не надейтесь его в пятницу, если рассчитываете на хорошие результаты.
Собирайте отзывы Как я уже говорил, ценность бета-тестирования числом отзывов, которые она помогает со брать. Если отзывов слишком мало, нужно собрать их. Зво ните и спрашивайте, установили ли тестеры программу и успешно ли они с ней работают. Пишите по электронной почте, чтобы что у всех все идет нормально. Анкеты также помогают собрать сведения, по зволяющие решать проблемы и следить, чтобы реализация проекта шла по пути.
Кандидат на Часть 3. Исполнение от и исправлена ошибка Ч все готово к окончательной сборке ПО, которая станет кандида том на (relca.se candidate, Хочется думать, что на этом этапе уж точно не случится, ко вероятность серьезных проблем все еще велика. В выпуска с вашим ПО будут ра ботать сотни, тысячи и миллионы пользователей.
Можно ли быть в готовности Как знать что последний набор не привел к существенному падению производительности или что протестированную на прошлой не нарушили вчера или позавчера? Нельзя просто сидеть и надеяться, что все идет хорошо. Отзыв ПО из производства или из сети после того, как было публично объявлено о его не только большими но и поте рей репутации компании.
При работе над кандидатом на выпуск проводится сис тематическая и объективная окончательной сбор ки программного продукта, чтобы выяснить, готова ли она к выходу. В этой главе будут раскрыты базовые организации работы над кандидатами на выпуск, преследу ющей цель подготовки ПО к выходу wo внешний мир.
Начальные требования К началу тестирования кандидата на выпуск все работы продуктом (кроме собственно испытаний кандидата) дол жны быть на это простое всегда есть сильное искушение найти еще несколько оши бок или изменения в программу и ее документацию, Начав работу над кандидатом на выпуск, вести очень строгий контроль любых изменений. Не обманывай те себя, думая, что все готово, когда на самом деле все на оборот. Чтобы внести ясность в этот вопрос, пройдемся по основным требованиям, предъявляемым к кандидатам.
Глава 14. на выпуск Готовы все Все без исключения должны быть на 100%. Участники команды должны быть уверены, что цель разработки ПО достигнута и в случае тести в ПО планируется вносить никаких изменений.
Справочные приведены в вид Команда полностью завершила работу над спра вочной системой программы, цией, информационными файлами и электронными учебниками. проанализированы, выверены и Можно дать еще на за подготовки но элек которая будет поставляться с ПО, должна быть готова.
Завершена ин терфейса Группа уже закончила оценку и доводку интерфейса, так что ос вплоть до продукта за казчик):
Закончено Группа выпол нила план тестирования в полном объеме:
системное, тестирование, тести рование производительности и пользова тельского интерфейса, а автоматизированное те Все тесты пройдены, по крайней мере из все неполадки и поставлять продукт, не устраняя их.
Все ошибки исправлены Все ошибки, которые ровалось исправлены. Что касается ос то, проанализировав о неисправленных ошибках, группа пришла к выводу;
что они не могут или не должны быть исправлены в этом ПО.
Часть 3.
бой программой на плечи ведущих участников программы ложится огромная нагрузка, и сведения из внешнего мира могут дать им непредвзятую оценку ПО, необходимую для принятия правильных решений. В конце концов, если до отправки ПО заказчику ни один из десятка пользователей не смог добиться успеха в работе с программой, как мож но ожидать, что у сотен и тысяч других пользователей, ко торые получат программу, все получится?
Отбор части лучших клиентов для участия в испытани ях кандидата на выпуск в компетенции админи стратора бета-тестирования. Хорошие тестировщики дол жны согласиться поработать с ПО в реальных ситуациях, быть способными уложиться в сроки плана работы с кан дидатом и предоставить информацию о неполадках в слу чае их возникновения. Во время работы над кандидатом на выпуск нужно практически ежедневно контактировать с чтобы контролировать их работу и соби рать как положительные, так и отрицательные отзывы. По скольку с тестировщиками кандидатов на выпуск часто складываются даже более интенсивные чем с другими бета-тестерами, их обычно меньше, чем дру гих бета-тестеров.
Из опыта Для работы над кандидатами на выпуск в обыч но приглашают только лучших бета-тестеров. По завер внутренних мы посылаем программу тес терам кандидатов на выпуск с вынести в тече ние 3-5 вердикт: ПО или нет. Администратор бета-тестирования остается на с тестерами: если возникают проблемы, тестеры получают приоритетную поддержку, часто прямо от Когда сильно поджимают сроки, клиентов могут быть как весь ма так и очень тревожными. После начала поставок продукта мы часто дарим нашим Глава 14. Кандидат на выпуск рам его копию с разработчиков в бла за их труд.
Обеспечьте мягкую посадку проекта Возвращаясь к с самолетом (см. главу мож но сказать, что в том, чтобы в сжатые сроки посте пенно вывести проект и посадить его. Как и экипажу самолета, вам набор предопреде ленных процедур, действия при Вот и пришла пора убрать столики и привести спинки кре сел в вертикальное положение.
Поскольку работа над на выпуск Ч крити ческий период проекта, он требует открытого точ ной информацией о состоянии проекта, отражающей как успехи, так и неудачи. В этот период необходимо оператив принимать решения, чтобы устранять ключевые затруд ошибки, контролировать риск и выби рать между альтернативами. Чтобы справиться с этими за дачами, нужно создать штурмовую состоящую из лидеров всех функциональных Х разработчиков;
Х группы по обучению пользователей;
группы инженерной психологии;
Х технологов Х технической поддержки;
продукта;
Х администратора бета-тестирования.
Из собственного опыта Пока в NuMega не работать группа, на работы над проектами никала куча проблем. Они были везде: с мони ' Часть 3. Исполнение текущего состояния работы над программой, сообщений о найденных ошибках, назначени ем ответственных за их устранение, координацией тести контролем слухов, принятием решений и обме ном информацией в группе. Когда численность групп воз росла и от создания отдельных продуктов мы перешли к разработке пакетов программ, проблемы особенно обострились. Порой это напоминало шоу трех просто К счастью, мы же догадались создать вую группу, что позволило решать большинство проблем, преследовавших нас на завершающих стадиях проекта.
Идея состоит создании штабного помещения Ч един места, где можно ставить, и об суждать проблемы. собрания должны про водится ежедневно в одной и той же комнате. Такой подход, использующий предварительное планирование, позволяет формализовать и упорядочить область ответственности каждого докладывающего о состоянии дел в ней, а также о накопившихся проблемах. По мере проведе ния заключительных тестов и поступления клиентских отзывов извне значительная информация, которую можно и нужно довести до сведения каждого чле на группы. Даже когда проблемы и трудности отсутствуют, все равно неплохо собраться всем вместе, чтобы разделить эту хорошую новость. Наконец, если требуется немедлен но принять критически важное решение, можно просто со звать экстренное собрание Если что-то идет не стоит задуматься При проведении последних тестов служба поддержки, тес администратор бета-тестирования, инженеры да и любой участник группы могут обнаружить Популярное в США телешоу Three Stooges с участием трех Ч редактора.
И !
Глава 14. на выпуск Ее следует рассмотреть на собрании группы, которая может предпринять следующие проблему Прежде всего надо убедиться в реальности проблемы, затем исследовать ее природу и ее значение для выяснить, воспро изводится ли она, а также какие и сколько платформ затрагивает.
Х на исправление ошибок или ние изменений Сначала нужно определить, можно ли устранить в а затем оценить мас штаб и величину которые для этого придет ся внести в программу.
Х ли сборку программы Следует взвесить затраты на решение проблемы и сравнить их с ущербом, которая она нанесет, если оставить ее без решения. Достаточно ли серьезна проблема, чтобы оправдать затраченное на ее решение особенно если при этом задержится выпуск продукта?
Если решено создать новую сборку, следует назвать ее с учетом схемы именования где Ч номер версии кандидата на выпуск. Проследите, чтобы номер сборки нового кандидата стал известен каждому.
повторный тестирования кандида та на выпуск Если неполадка локальна, достаточно повторного тестирования лишь той части программы, что была изменена при ее устранении. Однако повтор ное тестирование программы установки следует сти в любом случае.
Эти решения очень важны, и следует проследить, что бы их принимали компетентные представители каждого из подразделений. Поскольку эти проблемы решаются на собраниях с участием Часть 3. Исполнение проекта всех ключевых специалистов, можно быть уверенным в на личии достоверных данных, солидном опыте принимаю щих решение и в распространении сведений о принятых решениях от первого лица.
Если все в заканчивать Если тестирование кандидата на выпуск успешно прошло в полном объеме, его можно утвердить. Последнее утверж дение продукта Ч во многом формальность, так как имен но успешное окончание испытаний кандидата определяет момент, когда проект можно завершенным. Одна ко эта процедура гарантирует, что каждый внесший свой вклад в создание проекта, будет готов поддержать проект и, если понадобится, отстаивать его. Проект должны утвер дить следующие специалисты.
Х Технические специалисты Все подразделения: разра ботчики, специалисты по обучению инженерные психологи и технологи Ч должны единогласно утвердить проект. Это означает, что каждое подразделение внесло свой вклад в создание реального продукта и готово дать ему зеленый В рамках модели, принятой в NuMega, за готовность про екта в конечном счете отвечает менеджер проекта, а сама готовность определяется по согласованию с ко мандой. Технические специалисты первыми ставят свою подпись под проектом, без их визы проект даль ше не пойдет.
Х Менеджеры продукта Если группа менеджеров утвер дила проект, это означает, что качество реализации функций ПО позволяет выйти с ним на рынок. Планы лицензирования, формирования обучения про давцов, производства дистрибутивов и сбыта также уже составлены, и можно приступать к их реализации.
Х Группа технической поддержки Виза группы техни ческой означает, что ни одна критическая Глава 14. Кандидат на выпуск проблема не нерешенной и группа готовя осуществлять поддержку продукта после выхода его на рынок.
Заказчики Виза заказчиков означает, что продукт го тов к использованию в их производственном или ком мерческом окружении.
Когда продукт его заказчику После того, как все дали зеленый можно передавать проект заказчику и принимать поздравления с окончани ем работы! Но прежде, чем считать проект завершенным, обязательно прочитайте следующую главу. Закрытие про (вот тогда проект действительно будет Общие проблемы и решения Далее обсуждается ряд типичных проблем и вопросов, воз никающих при использовании описываемых здесь а также их решения.
Отсутствие руководства Одна из наиболее распространенных проблем, завершить проект, Ч нехватка руководства и дис циплины на завершающих стадиях. В этот период менед жер проекта отрабатывает свой оклад, поскольку должен быть кто-то один, ответственный за ПО. Обеспечить эффективную работу на завершающих этапах проекта не легко. Возможно, придется задержать группу в чтобы провести повторные тесты или отвергнуть после дний набор классных изменений из-за высокого риска. Не ограничивайте себя в сред чтобы выполнить эту работу в лучшем виде, Обмен информацией Когда на группу обрушиваются все заботы, связанные с ходом ПО, информацией между участниками Часть 3. Исполнение проекта часто нарушается, что провоцирует возникновение слу хов и сомнительных Обязательно нужно орга управление работой над проектом до его закрытия, обмен информацией о его состоянии и решение любых проблем по мере их возникновения.
Ответственность Поскольку в производстве ПО участвует много людей и по стоянно приходится решения, важно назначить в каждом подразделении, работающем над кандидатом на выпуск. Очень плохо, когда ответственность постоянно переходит от одних людей к другим. Нужны люди, которые могут отвечать за вверенные им команды и за принятые План тестирования Необходим конкретный план тестирования кандидата на выпуск. Нельзя все на это просто не хватит времени. Нужно сосредоточиться на важнейших фрагментах. Однако у многих групп отсутствует четкое представление о том, что и как нужно делать. Заключитель ное тестирование должно быть продумано, прежде чем проект вступит в фазу работы с кандидатом на выпуск, Автоматизация Если тестирование автоматизировано недостаточно, дело плохо. Возможность автоматизированного тестирования ключевых функций на окончательной сборке программы (и на новых сборках программы, если они будут созданы) имеет решающее значение для своевременной и полной проверки продукта. Нельзя тратить время на тестирование каждого кандидата на выпуск вручную.
Закрытие проекта Часть Исполнение проекта аконец, проект завершен, программа отправлена казчикам! Это все, не так ли? Еще нет. Завершить ра над проектом Ч это больше, чем просто вынести за дверь и уйти домой. В проект вложено много времени и сил, команде пришлось принести большие жертвы, теперь критически важно должным образом провести закрытие не забыв никого из участников. Если отказаться от этого этапа, можно упустить прекрасную возможность от благодарить людей, выразить команде признательность за внесенный вклад и подготовить ее к работе над следующим проектом.
Почему это так важно?
Закрытие проекта венчает работу команды. Оно также по зволяет участникам осознать всю важность проекта, я также почувствовать, что их вклад и самопожертвование получили признание и оценены по достоинству, Слишком часто упадок сил после завершения проекта ведет к неразберихе и даже к депрессии. Люди должны быть уве рены, что их усилия, сверхурочные часы и бессонные ночи не пропали зря. Они спросить себя: Была ли моя ра бота замечена? Стоило ли так Ч или, что еще важнее: ли я выкладываться в следующий раз? Пра вильно проведенное закрытие проекта дает ответ на эти во просы. При проведенном закрытии необходимо:
Х известить всех об окончании проекта и о про граммы заказчику;
Х выделить индивидуальные достижения, вклад и предан ность делу;
Х отметить общие усилия и работы команды в целом;
помочь участникам команды увидеть их ошибки и из влечь из них урок;
Глава Закрытие проекта Х решить текущие проблемы с кадрами или проектом;
начать подготовку к следующему проекту.
Как это делается?
Провести закрытие проекта несложно, но для этого нужно решить множество задач.
Передача программы Выпуск во внешний мир продукта его созда телями должен быть общественным событием. Нельзя при думать более удачной церемонии закрытия проекта, чем передача прав собственности командой заказчику. Это со бытие должно происходить на глазах у всей команды. Оно представляет собой яркий и запоминающийся момент для каждого участника работы над проектом.
Например, если ПО передается производственной орга низации, можно устроить небольшую церемонию, во вре мя которой менеджер проекта передает компакт-диски с ПО представителю этой организации. Если программа пе редается через сеть, то поводом для сбора всех участников команды может быть последнее нажатие клавиши ввода. Как бы это ни происходило, главное Ч собрать всю команду, что бы каждый участник узнал о передаче проекта заказчику.
Конечно, событию должна предшествовать краткая речь. Всегда весело, когда люди вспоминают самые трудные задачи проекта и как команда решала их сообща. Забавно припомнить самые комичные эпизоды работы над проек том, поинтересовавшись, как же все-таки удалось пережить их живым и невредимым!
А теперь рассмотрим противоположную ситуацию, ког да не проводилось. Если участникам команды приходится спрашивать, отправили ли проект заказчику или они обнаруживают, что их не пригласили на передачу !
Часть 3. Исполнение проекта, они ощущают себя вовсе не игроками одной команды, а скорее которые сослужили свою службу в составе большой но так и не стали ее неотъемлемыми частями. Так быть не должно.
письмо Если команда многочисленна или ее участники ны по обширной собрать всех вместе может быть сложно. В таких случаях обычно прибегают к рассыл ке по электронной почте писем, приуроченных к заверше нию проекта. Получив такое письмо, все смогут одновре менно и в равной степени почувствовать, что проект закон чен и команда поставленную ней задачу.
Это письмо также может послужить катализатором празд нования выхода нового Празднование нового выпуска Один из самых замечательных моментов, наступающих после выхода программного продукта, Ч праздник по слу чаю нового выпуска. Чувство выполненного долга, после которого приходит праздник, Ч это что-то потрясающее.
Чем дальше отстоят эти моменты во времени, тем меньшее впечатление от праздника. После выпуска ПО можно:
+ открыть бутылку шампанского;
Х подать всем мороженое прямо на рабочие места;
пригласить команду на ужин в ресторан;
устроить совместный поход в кино;
Х собраться на в доме одного из участников команды;
Х отправиться в боулинг и т. п.
Какое бы мероприятие вы ни выбрали, главное, чтобы все смогли принять о нем участие: некоторые могут и не изъявить желания участвовать в турнире по или в катании на горных велосипедах.
Глава 15. Закрытие проекта Общественное признание признание может стать мощным средством выражения благодарности группам и отдельным кам за исключительные достижения. Общественное при знание может быть как на подразделения, так и на более Ч группы или целой компании. Однако не зависимо от размера команды следует придерживаться не которых правил.
Х достиже ния Награды только усилия, выходящие за рамки должностных обязанностей.
Х отличную работу па любам поприще Следует поощрять работни ков всех а не только какого-либо одного.
Излагайте Не следует что все в курсе всех событий. Расскажи те немного людям о возникших проблемах и о том, как действия группы или отдельного специалиста помогли справиться с ними.
Х должна быть Памят ный знак или премия сделают по-настояще му запоминающимся.
Из собственного опыта Практически каждый месяц в проводятся общие собрания компании. Сотрудники в полном составе заслу шивают новости, поступающие из разных групп. В завер шение собрания мы присуждаем награду Спасителю ком пании. Ею беспримерный работника, который помог решить критическую проблему, выйти из затруднительной ситуации или существенно увеличить прибыль. Эта церемония всегда сопровождается расска зом о действиях работника или группы, чтобы убедить всех в том, что награждаемый сыграл важную роль и на Часть 3. Исполнение проекта града получена Отличившиеся получают на бейсболки с надписью Я спас компанию, кото рые они с гордостью носят или держат в своем кабинете.
Личная благодарность Личная благодарность Ч эффективный способ про демонстрировать ценность вклада отдельного участника команды в реализацию проекта. Фактически искренняя личная благодарность часто значит для людей даже боль ше, чем любая форма общественного признания.
обычно выражают на собрани ях, где менеджер проекта или ведущий специалист откры то и искренне благодарит человека за сделанный вклад.
Простая фраза вроде ля рад, в конце работы над проектом вы смогли протестировать программу на других платформах;
если бы мы не обнаружили эту ошибку, про дукт пришлось бы отозвать может быть очень важной для кто, вложив дополнительные усилия, смог решить проблему. Это дает работнику понять, что адми в курсе его достижений и признательна ему.
К способам выражения личной признательности также можно отнести благодарственное письмо, присылаемое по электронной почте. Надеюсь, вы получали раньше благодарственные послания, и ощущения, сопро вождающие получение такого письма, вам Премии, подарки и акции компании Еще один способ выразить благодарность Ч наградить от личившегося. Ничто не так и пить благодарность как получение премии или по дарка. подарка или премии говорит о том, что хорошая работа замече] и. что еще важнее, не осталась без награды. Часто, когда люди что администрация ви Глава 15. Закрытие проекта ценит и поощряет работу, стремятся ра еще лучше.
Хотя денежные и материальные формы поощрения са мые желательные, они не всегда доступны или возможны.
Постарайтесь тогда придумать иные способы наградить Почетная грамота или прибавка к отпуску тоже могут быть выражением благодарности.
Памятные фотографии и пасхальные яйца Как было сказано в начале книги, реализованный проект является усилий всей команды. Что может под черкнуть это лучше, чем групповая фотография после вы хода нового выпуска? Подарите такую фотографию каждому участнику команды, а еще одну повесьте в рамке на видном месте, лучше всего на стене, достижениям компании. Эти фотографии свидетельствуют, что в нии всегда видели и ценили командную работу. Пройдет и будет здорово вспомнить, с кем вы работали над разными выпусками, взглянув на эти фотографии.
Кроме того, во многих любят помещать в программы так яйца Ч это скры тые окна, которые определенной цией нажатий клавиш, команд меню и содержащие список создателей программы, а иногда и их фотогра фию. Они похожи на заключительные титры кинофильма, Из опыта Группа над програм мой программу пасхальное у кого есть эта его. Для этого окно О мандой меню навести указатель па клетчатый значок продукта, затем при прижатой клавише Shift триж ды кнопкой.
Часть 3, Исполнение проекта Что дальше?
все благодарности пора переключаться на подготовку к следующему проекту. Хотя этот период очень важен, часто о нем Это самое подходящее время для извлечения из прошлых ошибок и подготовки к решению грядущих задач.
Учимся на ошибках прошлого Чтобы встретить во всеоружии, следует разобрать ся в ошибках прошлого. Что Что нет? Чем больше всего будет отличаться работа над следующим проектом?
Определите, в каких продуктах, процессах, технологиях или оборудовании ощущалась острая нехватка на протяже нии последних месяцев и проследите, чтобы все это теперь было в наличии, Классический способ анализа законченного проекта Ч это обсуждение его на итоговых собраниях. Как правило, такое собрание проводится с участием всей команды вско ре после выхода нового выпуска. Оно служит для обмена мнениями о том, что а что нет, а также для мозго вого штурма проблем. Цель такого не в том, что бы кого-то обвинить или отыскать личные просчеты, а в том, чтобы сообща извлечь уроки из прошлых ошибок и что нужно сделать во время следующего проек та. Эти собрания подходят для подготовки почвы для грядущих Усиление инфраструктуры Первые дни и недели после выпуска ПО также очень удоб ны для инфраструктуры Ч организации новых рабочих повышения пополнения оборудования и инструментария. Как известно, вносить су щественные изменения в эти во работы над трудно. Рассмотрим их поочередно.
ХХ-' Глава Закрытие проекта Х Рабочие Как следует изучите все рабочие процедуры: создание ежедневных ПО, базисные тесты, требований, оценку практичности и набор антикризисных мер. Как с командой? Адекватны ли планы и методики задачам ли эти сферы в улучшении?
Х Часто команды находят авто разработки и программы недо статочной для решения поставленных перед ними за дач. Время до следующего проекта идеально под ходит для автоматизации и наверстывания упущенного в этой области.
Оборудование Следует использовать полученную воз можность для оборудования, потребуется для работы над следующими проектами.
Х Инструментарий Замена инструментов для управле ния исходным кодом и отслеживания во время работы над как является ошибкой и всегда требует больше времени (см. главу 5). Но когда проект уделить часть времени оцен ке новых версий программ и обновлению имеющегося инструментария.
Работа с кадрами Вложения в кадры важны, в инфраструктуру.
Как это сделать конкретно?
Х Анализ эффективности работы По окончании про екта следует проанализировать работы участников, Хотя в компаний такое мероприятие проводится лишь в день приема сотрудни ка на анализ работы каждого члена команды по окончании каждого проекта позво ляет держать в памяти свежие о его Часть 3.
ности и устранить ряд проблем чем начнется работа над следующим проектом.
Х Взаимное обучение Следует подумать об обмене обя между участниками команды. Очень важно, чтобы при над разными фрагментами ПО они обучали друг друга. Плохо, когда какого либо фрагмента программы полностью зависит от единственного специалиста. Взаимное обучение прида ет большую гибкость и позволяет каждому чле ну команды получить более четкое представление о аспектах проекта.
Х Повышение Это прекрасное время для повышения квалификации сотрудников. Когда работа над проектом позади, участники команды смогут сосре доточиться на изучении новых технологий или нов шеств в уже известных им методиках, появившихся время работы над проектом.
+ Отпуска В любом случае у каждого участника коман ды должен быть отпуск. Промежуток между проектами лучше всего посвятить семье и личным интересам.
Люди стремятся трудиться интенсивнее и много рабо тают сверхурочно, если знают, что смогут хорошенько отдохнуть после завершения проекта.
Тс, кто особенно интенсивно работал в течение дол гого времени, выходных.
Следует беречь силы тех. кто вносит ключевой вклад во цикл реализации проекта и давать им до полнительное для отдыха. Ваша задача Ч не до пуская чрезмерного расслабления, помочь вос становить свои чтобы спустя некоторое время они вновь смогли работать с максимальной самоотдачей, В первоначальный период работы любой когда особенно часто приходится работать сверхурочно.
, Глава 15. Закрытие проекта потребность в увеличении времени отдыха после интенсив ной работы ощущается особенно остро. В мы ли взять месяц оплачиваемого отпуска лишь после пяти лет работы. Все были наконец получить компенсацию за все наши сверхурочные. К счастью, все больше компаний признают увеличенного периода отдыха и осознают то благо, которое он может со сти как так и компании, Общие проблемы и решения Далее обсуждается ряд типичных проблем и воз никающих при использовании описываемых здесь а также их решения.
Чувство опустошенности Когда проект завершен, у некоторых ощущение опустошенности и разочарования. чувство, что их вклад и усилия Ч Поэтому они вновь и берутся за но без особых шансов решить альные проблемы в масштабах всего проекта или свой личный Чтобы избежать этой сле дует правильно проводить закрытие проекта, отмечать лю внесших основной вклад, проводить итоговые собра ния и анализировать эффективность работы участников, которые должны меняться обязанностями и получать до статочно времени для отдыха, Истощение сил Истощение сил Ч самая серьезная причина возникновения ощущения У перегоревших на работе нет ни сил, ни интереса для участия в проекте или даже для выполнения своих Исто развивается со временем и становится настоящей бедой после того, как нанесет свой удар. Основная цель Часть 3.
этой главы Ч действия, для предот вращения истощения сил, а не для с ним после того, как оно проявилось.
Нужно довести проект до конца многие изложенные в этой главе идеи не новы, но уж слишком часто люди относятся к ним очень легко мысленно. Следует составить конкретный план, чтобы все действия по закрытию были обязательно проведены в пол ном объеме. Не следует приступать к работе над следующим проектом, не завершив текущий.
Предметный указатель 3.0 бета-версия бета-тестирование 66, С C++ Ч бета-тестер 295, Code Ч Ч маркетинговое D M Ч Ч MFC Ч ПО Ч результат N Ч Ч P Ч тип Per!
Ч цель 289. Ч R RAD Develop ment) В ведущий s Ч исследователь Ч программист 55- Т Ч Ч разработчик Ч специалист V Ч Visual Slick Edit финансирование Visual взаимное обучение Source Safe) взаимоуважение выставка график ассемблер Ч указатель Ч работ группа политика Ч кадровое агентство Ч менеджмента и кадровое 47-48, Ч состав 46 Ч разработок Ч поощрение Ч опыт Ч 322 Ч идеальный Ч 80 Ч изоляция Ч связь 54 Ч квалификация 5, Ч поддержки Ч коллектив 316 ~ Ч Ч моральный дух д Ч неквалифицированный компенсация Ч Ч опыт работы интерфейса Ч особое внимание Ч отбор документация Ч отношение к делу Ч поведение 7, Ч поиск заказчик Ч потенциал запрос Ч преданность зарплата Ч предложение затраты Ч И Ч привлечение внимания имитация конечного результата Ч профессиональный кругозор Ч рабочая среда инженер по автоматизации Ч резюме инженерный психолог Ч решение Ч интерфейс Ч бизнеса исследования Ч собеседование Ч прикладные Ч знаний Ч фундаментальные Ч сопроводительное письмо работа Ч к обучению код Ч сфера Ч файлов Ч телефонное интервью Ч Ч Ч система управления Ч требования Ч функции Ч удерживание Ч квалификация 5, исходный файл клиент Ч ключевых файлов колледж Ч содержание Предметный указатель разработчиков поиск система поиск продукта 135 Ч вакансии культура Ч выставка Ч Интернет круг обязанностей Ч кадровое Ч колледж Л Ч опыт работы благодарность Ч по сборка м Ч технологии Ч рекламное Ч маркетинг 28?
Ч реорганизация менеджер Ч Ч Ч Ч продукта Ч ! Ч проекта интерфейс менеджмент 47-48. мониторинг продукта 56 потребности пользователя J 76 О премия обмен пресс-релиз программист 46, 48, 55, программный продукт объявление проект обязанность Ч Ч мониторинг Ч ности организация управления Ч отдых Ч Ч тестирован отпуск Ч ПО технологий этап п Ч 25 i план Ч планирование Ч кандидат выпуск Ч Ч передача в производство Ч неполадок подарок подбор Предметный указатель прототип Ч машина 222 Ч среда Ч создание Ч описание Ч ер- Ч фейса 228 Ч Ч программы установки 228 Ч Ч штраф 163 сборка программы Ч комплект сверхурочная работа Ч создание рынка пакет Р протокол работа с кадрами система контроля качества собеседование 4. 27. Ч документации Ч ключевые вопросы Ч пользовательской докумен Ч обратная связь 32- тации Ч оценка собрание Ч внешний крут Ч антикризисное Ч внутренний круг Ч контрольное Ч проблемы специалист по технической Ч круг поддержке ПО список задач Ч привилегий 76- средство сценария Ч работы Ч структура организации расширение сценарий резюме 24, Т реклама текучесть кадров рекомендация реорганизация 22 интервью роль 5 2 тестирование Ч С Ч ручное самообразование -файл сборка Ч Ч измерение продукта Ч номер Ч Ч окончательная Ч цикл Ч хорошая Ч входное Ч проверка Ч ежедневное Ч программы Ч инструмент Ч самая последняя Ч Ч сборочная Ч кандидат на выпуск Ч Ч ключевой функции Предметный указатель Ч коррекция Ч Ф Ч метрика фаворит Ч оборудование йл Ч Ч библиотеки Ч блокировка/разблокировка Ч Ч Ч план Ч группирование Ч и нагрузки Ч для Ч для программ Ч психологический фактор Ч доступ Ч реализованной функции Ч заголовка Ч Ч Ч ручное Ч Ч Ч ключевой Ч Ч 94, 46, 48, 57, Ч компоновка лаборатория Ч маркировка 93. технический специалист Ч выдача техническое Ч технолог Ч по ПО 46.
среды Ч хранение Ч централизация требование к фактор Ч финансы Ч детализация Ч Ч Ч категория Ч контекст Ч Ч Ч общее функциональность Ч опережающее Ч ц - приоритет Ч идея проекта Ч фрагментация цикл разработки Ч частное Ч к продукту установка У ш Ч профессиональная сфера группа Ч социальная Ч действия Ч условия 39, офиса Я вакансии Об авторе Ветеран программных средств Эд Салливан от ей лет. Он получил степень бакалавра информатики с отличием в колледже Позже в Бостонском университете он стал магистром этой дисциплины, Эд лет трудился и отделении корпорации DEC по раз работке ПО, расположенном в (штат Нью-Гемпшир).
На самых разных и руководящих должностях он занимался разработкой средств для проверки ОС В конце концов он перешел в кон отдел DEC, где возглавил разработку и развер ряда специализированных программных про дуктов для системы работы с клиентами на основе пор тативных компьютеров общей стоимостью более 6 млн.
долларов.
С 1994 г. Эд в небольшой молодой компании Technologies, Inc., где сначала совмещал должности жера по и менеджера по Bounds Checker продукта для поиска ошибок в программах.
Как менеджер по разработке, Эд полностью курировал со здание четырех выпусков продукта в критический период истории NuMega. Будучи первым менеджером по маркетин гу, он сыграл значительную роль в определении стратегии, позиционировании продукта, популяризации, рекламы и продвижении на рынке, Позднее, как начальник отдела разработки NuMega, он направил компанию па развивающийся рынок средств раз работки на Visual Basic и Java, а также создания ПО для Web.
Он управлял стратегией и реализацией вось ми различных занимающих четыре уникальных сегмента рынка. В период его пребывания на должности ди ректора и менеджера по разработке программные продук ты компании NuMega завоевали множество отраслевых премий, включая призы за техническое совершенство и журнала PC шесть призов Jolt и несколько раз были отмечены различными ями Выбором читателя.
В 1999 г. NuMega Technologies вошла в состав корпора ции В настоящее время Эд Ч директор центра разработки NuMega, ставшей одной из лабораторий Com puware. Он возглавляет коллектив из сотрудников и ку рирует разработку продуктов, дающих ежегодный оборот на сумму более чем 40 млн. долларов.
Эд ВРЕМЯ - ДЕНЬГИ Создание разработчиков программного с под общей редакцией В. Г.
Предметный указатель С. В.
Технический редактор Н. Г. Тимченко Компьютерный и подготовка иллюстраций В. Б.
Дизайнер обложки Е. В. Козлова Оригинал-макет с издательской Adobe PageMaker 6. Главный А. И. Козлов Подготовлено к печати домом Русская Лицензия № 066422 от 19.03.99 г.
Подписано в печать 22.01.02 г. Тираж 3000 экз.
Формат 84x108 п. л.
в тип. ОАО Молодая 103030, ул., Заказ 0759.
книги ДЛЯ ЛЮДЕЙ ДЕЛА Э.
словарь по ной Интернету и РУССКИЙ Словарь более 9600 используемых в компьютерной технике, вычисли тельных сетях а также основных областях.
В терминов и введены новые Для терминов приводятся их полимание и правильное применение.
Эд Создание разработчиков обеспечения В этой книге ветеран индустрии программных средств Эд делится своим 17-ти летним опытам созда ния Он описывает модель создания управления успешной команды секреты и методики, о которых пор писали очень мало. Здесь Вы как найти и как их на результатов.
Чарльз Эта книга Ч азбука компьютерных технологий. Шаг.
за шагом автор знакомит читателя с сущностью представ информации в компьютере, рассказывает об истории его на примерах помогает освоить концепции информационных технологий, подробно принципы работы процессора компьютера.
ПРОДАЖА издательство компьютерной 142 0571, e-mail:
в и 38, ( В НАШЕМ ЖУРНАЛЕ И ТОЛЬКО ДЛЯ ВАС:
* НОВОСТИ КОМПЬЮТЕРНОЙ ИНДУСТРИИ ПОДРОБНОСТИ О СОВРЕМЕННЫХ И ПЕРСПЕКТИВНЫХ ТЕХНОЛОГИЯХ * ТЕСТЫ И ОБЗОРЫ АППАРАТНЫХ И ПРОГРАММНЫХ ПРОДУКТОВ * КОНСУЛЬТАЦИИ ЭКСПЕРТОВ, ВСТРЕЧИ С ИНТЕРЕСНЫМИ ЛЮДЬМИ ВИКТОРИНЫ С ЦЕННЫМИ ПРИЗАМИ CD-ПРИЛОЖЕНИЕ С ПОЛЕЗНЫМИ УТИЛИТАМИ НАШИ SOFT CD - р с с с и о ь ПРОГРАММИСТ посвященный Наши делятся с читателями секретами мастерства.
Мы публикуем о современных технологиях и средствах разработки, статьи о и методах, теории и Мы статьи на самые разные программерские любого уровня сложности.
каталоге "Пресса - 45775.
Droammme.ru Новые продукты Microsoft С помощью каталога программного обеспечения вы всегда первыми узнаете о новинках ПО;
ориентируетесь а схемах лицензирования, специальных л скидках;
знаете самые выгодные цены, удобно заказываете с бесплатной доставкой;
Ш регулярно знакомитесь с программами Ч продаж:
имеете уникальную консультировать своих коллег знакомых по выбору ПО И все это БЕСПЛАТНО!!!
форма на единственный в Восточной каталог программного обеспечения (шесть номеров в год): заполните форму на Посетите наш web сайт и заполните подписки ФАКС и ее по факсу (ОЭ5] 232- [095) 232- Свяжитесь с и о Заполните анкету ПОЧТА ул и вышлите ее по почте Тел :
Россия, 117036, ул. Шверника, д. 4, (095] e-mail СофтЛайн, Подлиски.
Посвящается и Ч самым людям, из тех, которых знаю.
Майкл Посвящается Дженифер за все уикенды, мы могли провести, но не провели вместе, на лошадях.
Pages: | 1 | ... | 2 | 3 | 4 |
Книги, научные публикации