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

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

• бета-тёсmирование — как с помощью бета-тестирования получать из внешнего мира отзывы о программе и расширить возможности тестирования;

• работа с кандидатами на выпуск — как управлять заключительными этапами проекта и обеспечить готовность продукта;

• закрытие проекта — что это такое, зачем оно нужно и как его провести.

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

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

Я бы хотел услышать ваши соображения и комментарии по поводу этой книги. Кроме того, было бы интересно, если б читатели поделились своими уроками, которые они извлекли из собственного опыта, а также оригинальными способами создания программ в срок. Пишите мне по адресу: eds_books@botmail.com

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

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

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

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

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

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

• C++ объектно-ориентированное проектирование;

• создание СОМ-компонентов;

• MFC и разработка пользовательского интерфейса;

• ассемблер и внутренняя организация Windows;

• разработка драйверов устройств;

• разработка сетевых протоколов;

• оптимизация производительности.