"Время — деньги. Создание команды разработчиков программного обеспечения" - читать интересную книгу автора (Салливан Эд)Определение «замечательных»Прежде всего нужно понять, кого же вы ищете. Если вы не можете определить, кто вам нужен, как вы узнаете, что нашли того, кого искали? Как отличить классного разработчика, потрясающего технического писателя и cупep-тестировщика от не столь выдающихся? Критериев оценки масса, но я выделил шесть основных. Каждый потенциальный кандидат должен иметь признание в своей области. Разработчик должен иметь квалификацию в своей специфической технической области, технический писатель — опыт в создании учебных материалов, инженер по обеспечению качества — владеть методами автоматизированного тестирования. Я говорю не просто о компетентности, а о мастерстве. Кандидат должен в совершенстве (ну, почти) владеть предметом, относящимся к потребностям проекта. Он должен быть способен «с лёту» рассказать о своей теме и в любой момент продемонстрировать глубокое понимание того, что и как было сделано. Разработчик, например, должен доказать, что его технические познания соответствуют предлагаемой ему должности. Вот некоторые возможные темы: • C++ объектно-ориентированное проектирование; • создание СОМ-компонентов; • MFC и разработка пользовательского интерфейса; • ассемблер и внутренняя организация Windows; • разработка драйверов устройств; • разработка сетевых протоколов; • оптимизация производительности. Почему это важно? Во-первых, если человек в совершенстве овладел хотя бы одним предметом, он, вероятно, при необходимости освоит и другие. Технология меняется быстро, и способность к обучению и постижению сложных предметов — очень важное качество. Во-вторых, в мощных командах важно взаимоуважение друг к другу её членов, а оно зачастую основывается на знаниях и способностях. Каждый должен иметь квалификацию в одной или нескольких областях, в которые он может внести такой же или больший вклад, чем другие. Значит ли это, что каждый разработчик должен иметь учёную степень и 20-летний опыт разработки ПО? Нет, конечно. Но если вы решили нанять начинающего разработчика для поддержки и сопровождения, вы должны быть уверены, что он выделится на своём месте, а не просто будет ему соответствовать. На собеседования с кандидатом вам нужно основательно потрудиться, чтобы удостовериться в его квалификации и в том, что она соответствует вашим текущим или будущим потребностям. (О собеседовании мы поговорим ниже.) Разработка практически любого проекта переживает плохие времена. Кто знает, какие проблемы вас ждут впереди: ваш конкурент объявит о выпуске своего продукта первым, ведущий разработчик заболеет, производительность продукта окажется плачевно низкой — мало ли что! Но именно преданность ваших людей и их вера в то, что они делают, доведёт проект до конца. Они будут демонстрировать свою приверженность делу, не прекратят работу и будут помогать, пока не добьются своего. Самые преданные люди стремятся к завершению проекта и готовы пожертвовать чем угодно во имя победы. Хорошие специалисты зачастую проявляют завидное усердие и недюжинную энергию. Они самоуверенны, но не циничны и сосредоточены на хорошем. Их трудно выбить из колеи: они оптимисты и легко адаптируются. Ищите их. Тяните в свою команду. Они будут поддерживать её моральный дух во всё время работы над проектом, особенно в тяжелые времена. Их энтузиазм воодушевит коллектив. Вам нужны специалисты, склонные к активным действиям, из тех, кто идёт своим путём для достижения цели. Имённо стремление к действию отличает истинно классных разработчиков. Люди этой породы не сворачивают с намеченного пути, они стремятся иметь больше обязанностей, исправить пару лишних ошибок или общаться по электронной почте, чтобы оставаться в курсе событий. Для разработки ПО нужны люди, способные делиться идеями, мнениями и опытом. Только тогда можно решать сложные проблемы. Только так человек способен помочь другому. Только так создаётся ощущение, что работа кончается тогда, когда закончен весь проект. ПО создаётся командой. Если у вас нет хорошей команды, вы не создадите хорошего ПО. Вот почему необходимо поддерживать сплочённость команды. Исключений здесь быть не должно. Если суперспециалист не способен сработаться с другими, его ценность для коллектива становится заметно ниже. В худшем случае люди такого типа могут даже разрушить команду. На первом месте — забота о коллективе. Ищите жаждущих знаний, тех, кто постоянно занимается самообразованием, поиском новых интересных способов применения технологий. Они интересуются новинками и знают, что происходит в их индустрии; они не дают своим знаниям устареть. Они понимают, что происходило с ПО раньше, что творится сейчас и что его ждёт в будущем. Наличие таких людей при выработке перспективных решений трудно переоценить. Это поможет вашей команде быстро и легко переходить к новым технологиям, инструментам и методам. Совершенных людей не бывает. Так что не надейтесь, что найдёте кандидата идеального во всех отношениях. Скажем, подходит ли вам прекрасный специалист, демонстрирующий заинтересованность в проекте, хорошо работающий в команде и читающий всё, что ему попадёт, но вялый и не уверенный в себе? Как знать. Во всяком случае, если с ним нет других проблем. Ещё один важный фактор — способность кандидата к росту. Посмотрите на его потенциал: его способности, отношение к делу. То, что он знает в первый день, не так важно в сравнении с тем, что он будет знать через три, шесть месяцев и через год. Убедитесь, что вы правильно оценили способность кандидата к росту, даже если он не столь ярок, как другие члены вашей команды. Не бойтесь взять подающего надежды талантливого человека и вырастить его. Иногда просчёт при выборе кандидата может обернуться серьёзными проблемами. • Допустим, это было сделано не по злому умыслу — просто кто-то не приложил достаточно усилий, чтобы оценить квалификацию нового сотрудника, но он принят на должность, для которой не годится. • В сплочённых командах очень важно, чтобы каждый тянул свою лямку. Работник, не способный справиться со своей работой, часто становится изгоем: люди редко советуются, просят помощи или оценки у отстающего. Им кажется, что он «сидит у них на шее». Если у вас более одного неуспевающего, коллектив раздробится на группировки, начнутся интриги… Чтобы команда функционировала нормально, каждый должен вносить свой ощутимый вклад и общее дело. • Если с одним из членов команды невозможно работать, боевой дух всей команды начнёт стремительно падать. Нужно проверять, что любой кандидат — особенно претендующий на роль лидера, — хорошо вписывается в команду. • Для общего успеха коллектива очень важно реагировать на изменения в своей индустрии. Например, если вы решили, что ваша традиционная стратегия двухуровневых клиент-серверных приложений устарела и вам нужно переходить на трехуровневую стратегию Web-приложений, а кто-то из членов команды не способен достаточно быстро усовершенствовать свои знания, вы потеряете время, а возможно, и интересные заказы. Теперь посмотрим, как неправильный выбор сотрудника сказывается на финансах. Вот пример одно— и двухгодичных выплат одному разработчику: $90 000 Зарплата $5 000 «Подъёмные» $20 000 Комиссионные агентам по найму $30 000 Социальное страхование, льготы, обучение Итого: $145 000 Затраты за первый год $175 000 Затраты за первый и второй год (включая небольшой рост, без премий) Куча денег! И только на одного человека. Так как зачастую оплата труда является крупнейшей статьёй расходов при разработке ПО, возникает вопрос: стоит ли тратить столько же времени и сил на оценку новых кандидатов, как на новые технологии и средства разработки? В обоих случаях вы хотите быть уверены. В том, что удовлетворены ваши сегодняшние и будущие потребности. И в том, что сделали надёжный выбор, который облегчит вашу деятельность. Очевидно, что вы должны выбирать новых сотрудников не менее тщательно, чем оборудование. Одно неверное решение при подборе сотрудников, конечно, не очень приятно, но не имеет фатального влияния на проект. Гораздо сложней преодолеть последствия серии неудачных решений при подборе персонала, в результате которых команда формируется из посредственностей. • Низкая производительность для слабой команды — норма. Трудно рассчитывать на череду успехов, победы кратковременны, и проект начинает пробуксовывать. Сбиваясь с пути, слабая команда начинает бессмысленную борьбу, поскольку не может понять суть проблем и сменить курс быстро и решительно. • Слабая команда часто выпускает «сырой» продукт. У людей нет стремления сделать своё дело наилучшим образом и страстного желания создать солидный продукт, удовлетворяющий пользователя. В плохой команде люди не остаются после работы и не прихватывают обеденное время, чтобы чуть повысить производительность программы, прогнать лишний тест или переписать параграф документации. Без таких мелочей время работы увеличивается, а его качество значительно ухудшается. • Плохой команде трудно спланировать график выпуска продукта. Исполнители зачастую не осознают сложность технологий, с которыми имеют дело, не способны предвидеть возможных проблем и не желают жертвовать во имя своевременного завершения работы. Сама по себе задержка проекта не значит, что у вас плохая команда. Но я убеждён, что для плохой команды это в порядке вещей и что эти проблемы часто являются следствием плохо организованного кадрового обеспечения. |
||
|