Текст книги "Время — деньги. Создание команды разработчиков программного обеспечения"

Автор книги: Эд Салливан

сообщить о нарушении

Текущая страница: 4 (всего у книги 19 страниц)

Удерживание сотрудников

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

• Профессиональные

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

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

• Финансовые

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

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

• Социальные

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

Методики удерживания сотрудников

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

• Профессиональная сфера.

– Убедитесь, что люди получают новые навыки и пробуют что-то новое.

– Люди должны знать, что они отвечают за свою работу.

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

– Хвалите людей как лично, так и публично.

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

– Узнавайте о целях карьеры своих сотрудников и обеспечивайте их карьерный рост.

• Финансовые условия.

– Зарплата и другие выплаты талантливым сотрудникам должны быть выше средних по отрасли.

– Выдавайте премии за выдающиеся достижения.

– Премируйте ведущих сотрудников акциями компании.

• Социальная сфера.

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

– Организуйте внеурочные мероприятия (спортивные игры, походы в кино).

– Заботьтесь о социальных контактах между членами коллектива.

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

Типичные проблемы и их решение

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

Собеседование: проблемы и решения

• Слабые методики и подходы

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

• Плохо описанная вакансия

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

• Слишком много времени уделяется неквалифицированным кандидатам

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

• Чрезмерная или недостаточная реклама собственных возможностей

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

• Нереализованные возможности

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

• Медлительность

Хороших кандидатов трудно найти. Если вы уверены, что нашли достойного, – действуйте быстро. Не стесняйтесь пригласить кандидата на интервью вечером или предложить прилететь на выходные. Будьте готовы провести собеседование в тот же день. Я не предлагаю спешить с собеседованием, но бывают обстоятельства, требующие быстрого принятия решения, в том числе во внеурочное время.

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

Сохранение сотрудников: проблемы и решения

• Неправильный баланс

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

• Текучесть кадров

Текучка существует всегда. Меняются личные обстоятельства и приоритеты. Люди уходят по причинам, которые вы не можете контролировать: родился ребёнок, нужно быть поближе к родным, далеко до работы… С другой стороны, текучка может указывать на серьёзные проблемы в коллективе или организации. Чтобы оставаться в курсе причин текучести кадров, беседуйте с людьми перед их увольнением и прислушивайтесь к их замечаниям. Если обнаруживается внутренняя проблема, спросите других сотрудников, разделяют ли они такую точку зрения. В больших организациях неплохо вести список причин увольнения сотрудников. Эти сведения помогут отслеживать тенденции и принимать соответствующие меры.

Глава 3
Организация проекта

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

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

Модель организационной структуры компании NuMega

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

• основной состав группы – специалисты, полностью занятые в создании нового программного продукта:

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

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

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

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

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

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

• вспомогательная группа – специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:

– группа менеджмента и маркетинга продукта;

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

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

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

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

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

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

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

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

• Гибкое использование ресурсов

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

• Ответственность за распределение специализированных ресурсов

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

• Централизованное принятие решений

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

• Более чёткое взаимодействие

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

• Инициативная ответственность

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

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

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

Ведущие специалисты

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

Рис.3-1. Связи между менеджером проекта и ведущими специалистами функциональных подразделений.

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

Роли и обязанности

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

Менеджер проекта

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

• Подбор кадров и управление ими

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

• Формулирование и исполнение плана проекта

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

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

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

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

• Руководство командой

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

• Обеспечение связи между подразделениями

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

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

• Обеспечение готовности продукта

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

Программисты

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

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

Ведущий разработчик

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

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

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

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

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

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

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

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

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

Ведущие программисты, отвечающие за реализацию отдельных функций

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

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

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

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

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

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

Рядовые программисты

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

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

• её тестирование;

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

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

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

Тестировщики

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

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

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

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

Ведущий тестировщик

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

• Составление плана тестирования продукта

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

• Исполнение плана тестирования

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

• Автоматизация испытаний

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

• Проведение регрессивного тестирования

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

• Выбор инструментов, метрик и стандартов для тестирования

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

Инженер по автоматизации

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

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

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

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

Рядовой тестировщик

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

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

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

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

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

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

Группа разработчиков пользовательской документации

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