Проблема выбора источников ИТ

В течение последнего десятилетия фирмы все в большей степени полагались на внешние источники получения программного обеспечения. Растущие издержки крупномасштаб­ных проектов, ограниченный штат, доступность стандартизованных баз данных и сетей, прикладных пакетов программного обеспечения и громадное увеличение числа потенциальных приложений являются теми факторами, которые подталкивают к использованию внешних источников. Столкнувшись с растущей сложностью управления ИТ, необходимостью сосредоточиться на ключевых моментах деятельности, многие руководители задаются вопросами: «Стоит ли заниматься самим или можно передоверить внешним специалистам инфраструктурные операции, чтобы сконцентрироваться на создании приложений ИТ?» Факторы, которые следует учитывать при ответе на эти вопросы, обобщены в таблице 7.6.

Предпочтение покупки изготовлению «своими силами» существенно повлияло на практику управления ИТ. В середине 90-х годов менее 1% используемого программного обеспечения было разработано специалистами подразделений ИТ предприятий. Фирмы, специализирующиеся на создании ИТ, явно стали исполнять интеграционные функции, поэтому возникла потребность в новых процессах управления предприятием. Например, подразделения ИТ должны подвергаться проверке — нет ли у них стимула планировать ненужные разработки, когда необходимый продукт можно купить. Если основным источником технологий являются внешние разработчики, то необходимы межорганизационые системы управления и процедуры аудита, гарантирующие, что обе стороны способны выполнять свои обязательства.

Таблица 7.6

Анализ источников ИТ

Критерий решения	Факторы в пользу собственной разработки	Факторы в пользу покупки
деловая стратегия	приложения ИТ или инфраструктура дают конкурентные преимущества	приложения ИТ или инфраструктура обеспечивают поддержку стратегии или операциям, но не рассматриваются как стратегические
ключевая компетенция	требуемые знания или опыт в области разработки/эксплуатации приложений рассматриваются в качестве одной из специализаций фирмы	требуемые знания или опыт для разработки/эксплуатации приложений (инфраструктуры) не являются решающими для успеха фирмы
конфиденциальность и безопасность информации	информация или ее обработка рассматриваются как высокосекретные	неудачи в области безопасности создают проблемы, но не вызывают организационной дисфункциональности
доступность соответствующих образцов	не существует надежных партнеров-разработчиков приложений и необходимой инфраструктуры	надежные и компетентные поставщики существуют
доступность пакетов программного обеспечения	необходимые приложения уникальны	пакеты, отвечающие необходимым требованиям, доступны
анализ издержки/выгоды	покупка продукта/услуги и координация (контроль) межорганизационных отношений обходится дороже, чем собственное создание продукта/услуги	издержки покупки продукта/услуги ниже издержек получения услуги внутри организации
временные ограничения	есть время для создания внутренних ресурсов и обучения персонала для внедрения ИТ	время, необходимое для создания ресурсов и получения опыта, слишком велико
эволюция и сложность технологии	фирма способна привлечь экспертов ИТ, которые обеспечат внедрение при разумных издержках	фирма неспособна приспособиться к быстрым изменениям технологии
легкость внедрения	программные инструменты, обеспечивающие быструю разработку приложений, доступны	инструменты для быстрой разработки приложений недоступны или неэффективны

 

Создание временных коллективов для внедрения ИТ и ИС и их менеджмент

 

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

основной состав группы:

§ менеджеры проекта;

§ программисты;

§ тестировщики;

§ разработчики документации;

§ инженерные психологи;

§ технологи по разработке ПО;

вспомогательная группа:

§ группа менеджмента и маркетинга продукта;
специалисты по технической поддержке ПО;

§ администраторы бета-тестирования.

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

Управление проектом

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

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

Принципы способствова­ло дальнейшему повышению ее эффективности:

§ Гибкое использование ресурсов. Менеджер проекта мог выделять нужные ресурсы и направлять группу специ­алистов для решения любой отдельной проблемы, уст­ранения той или иной неполадки или поддержания ка­кой-либо инициативы. Такая система позволила менед­жеру проекта распределять ресурсы в соответствии с текущими внутренними приоритетами проекта и обес­печила полноту использования и оперативную баланси­ровку ресурсов согласно быстро меняющимся потреб­ностям проекта.

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

1. Централизованное принятие решений Поскольку проект целиком находится в ведении одного менедже­ра, он может оперативно принимать критически важ­ные решения, разрубая «Гордиевы узлы», когда не уда­лось достичь согласия.

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

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

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

Основной состав группы

1)Менеджер проекта. Совершенно ясно, что менеджер играет ключевую роль в реализации проекта. Его функционал включает следующие многочисленные роли и обязанности.

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

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

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

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

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

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

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

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

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

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

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

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

§ наблюдение за соблюдением архитектурных и техни­ческих спецификаций продукта;

§ подбор ключевых технологических инструментов и стандартов;

§ диагностика и разрешение всех технических проблем;

§ выполнение роли технического инструктора и консуль­танта для участников проекта;

§ наблюдение и контроль за работой групп разработчи­ков документации, тестировщиков и технологов;

§ мониторинг состояния продукта (ведение списка обна­руженных ошибок);

§ подбор инструментов разработки, метрик и стандартов и наблюдение за их использованием;

§ ну и, конечно, программирование, программирование и еще раз программирование.

Ведущие программисты, отвечающие за реализацию отдельных функций. Отвечают за реализацию отдельных функций продукта, ча­сто на основе конкретной технологии. Обычно определе­ние функций формулируют довольно широко, например, «интеграция с IDE» или «разработка API доступа к БД». Обя­занностями ведущих программистов, отвечающих за созда­ние отдельных функций ПО, являются:

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

§ формулирование требований к функциям и их крити­ческий анализ;

§ проектирование функций;

§ снабжение тестировщиков и разработчиков документа­ции техническими материалами;

§ ну и, конечно, программирование, программирование и еще раз программирование.

3) Рядовые программисты. Работают над реализацией определенной функции ПО обычно под руководством ведущего программиста, ответ­ственного за эту функцию. Они отвечают за реализацию конкретных аспектов этой функции, например, за «интег­рацию в IDE окон X, Y и Z» или «написание для API баз дан­ных методов create, update и delete». В круг их обязаннос­тей входит:

1) реализация функции;

2) ее тестирование;

3) исправление ошибок в реализованной функции;

4) помощь техническим писателям в документировании реализованной функции;

5) помощь тестировщикам в испытаниях этой функции

4) Тестировщики. Отвечают за составление и исполнение плана тестирования программы, создаваемой в рамках проекта. Чтобы обеспе­чить истинное партнерство между теми, кто пишет код и теми, кто его тестирует, роли и обязанности группы тести­ровщиков должны быть «параллельны» обязанностям раз­работчиков.

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

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

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

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

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

Рисунок 7.2 - Связи между группами разработчиков и тестировщиков

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

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

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

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

§ проведение автоматизированных испытаний;

§ регистрация результатов автоматизированных испыта­ний и анализ обнаруженных неполадок;

§ окончательное подтверждение устранения ошибки;

§ подготовка среды для испытаний.

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

§ планирование испытаний;

§ автоматизация испытаний;

§ оценка и выбор инструментальных средств.

 

6) Группа разработчиков пользовательской документации. Обеспечивает пользователя справочными материалами: печатной документацией, электронной справочной систе­мой, обучающими программами и карточками быстрой справки.

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

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

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

 

7) Инженерные психологи. Впечатление, которое оставит продукт у пользователя, кри­тически важно для его успеха на рынке. Интерфейс, доку­ментация, упаковка — все должно работать на то, чтобы создать у клиента положительное впечатление о продукте.

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

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

Специалист по инженерной психологии должен:

§ транслировать формулировки требований в ключевые задачи;

§ разрабатывать дизайн пользовательского интерфейса (макеты диалоговых окон и т. д.) для решения этих задач;

§ тестировать разработанный дизайн и согласовывать его с командой;

§ определять, как сформировать положительное первона­чальное впечатление от продукта;

§ проводить подгонку и доводку пользовательского ин­терфейса;

§ работать с заказчиком после выпуска ПО.

 

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

В общем случае у технолога по созданию ПО три основ­ные обязанности.

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

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

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

Вспомогательная группа

1 ) Группа менеджмента и маркетинга продукта. С точки зрения технических подразделений, эта группа иг­рает две роли: первая — сбор информации, а вторая — ее выдача.

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

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

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

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

 

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

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

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

§ предоставление статистики поступающих обращений за технической поддержкой (упорядоченной по типу и степени серьезности проблемы, а также по числу обра­щений) и демонстрация необходимости исправлений или изменений программы;

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

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

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

3)Администратор программы бета-тестирования. Отвечает за планирование, управление и исполнение про­граммы бета-тестирования. Хорошо проведенная программа бета-тестирования способствует успеху продукта, обес­печивая поступление отзывов о нем из реального мира. Рассмотрим основные обязанности администратора программы бета-тестирования:

§ поиск, проверка квалификации и привлечение кандида­тов в бета-тестеры;

§ распространение инструкций и ПО среди бета-тесте­ров;

§ рассылка кандидатам в бета-тестеры анкет и других не­обходимых материалов;

§ опубликование результатов бета-тестирования внутри группы;

§ постепенное усовершенствование процесса бета-тести­рования.