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

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

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

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

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

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

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

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

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

• Поскольку разработчик пользовательской документации создаёт руководство, описывающее использование продукта, часто именно он первым обнаруживает несогласованности, проблемы с функционированием продукта и недостатки в реализации функций. Нет ничего необычного, когда технический писатель заявляет: «Да, на собрании, посвящённому анализу спецификаций, у меня никаких вопросов не возникло. Но теперь, когда я начал писать руководство пользователя, мне ясно, что пользователю придётся выполнить целых десять действий, чтобы решить эту задачу, – чепуха какая-то!» Таким образом, он на ранних стадиях цикла разработки выполняет весьма ценную параллельную проверку удобства использования программы и даёт отзывы, позволяющие скорректировать недочёты.

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

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

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

Мы в NuMega всегда были убеждены, что именно первые 20 минут общения с нашим продуктом определяют, примет ли его пользователь и будет ли продолжать с ним работать. Это явление получило название «первоначальное впечатление от работы с продуктом». Если продукт не оставил у пользователя положительного впечатления и не помог ему легко и быстро решить свои проблемы, маловероятно, что этот продукт будет регулярно использоваться или будет по-настоящему ценным для потребителя.

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

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

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

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

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

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

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

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

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

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

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

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

• Создание и сопровождение подходящей среды для сборки продукта

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

• Создание и сопровождение процедуры установки

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

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

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

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

С точки зрения технических подразделений, эта группа играет две роли; первая – сбор информации, а вторая – её выдача.

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

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

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

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

Группа технической поддержки

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

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

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

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

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

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

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

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

Администратор программы бета-тестирования

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

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

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

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

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

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

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

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

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

Даже самым талантливым людям нужно объяснять их роли и обязанности. Они должны представлять, что от них требуется, чтобы знать, чему посвятить своё время. Формулировки обязанностей должны быть подробными и ориентированными на решение тех или иных задач. Но не переусердствуйте с этим, иначе эти формулировки станут слишком формальными и жёсткими. Вряд ли нужно, чтобы участники группы лишь цитировали описание их задания, когда пора уже выпускать продукт. Главное – избежать основных просчётов при исполнении проекта, а не пытаться управлять всем и всеми, даже в мелочах (см. описание обязанностей специалистов, приведённое в этой главе);

• Дисбаланс подразделений

Одно лишь наличие модели, которая поощряет равновесие навыков и опыта специалистов различных подразделений не означает, что обеспечение проекта кадрами осуществлялось как надо. Постоянно следите за балансом ресурсов функциональных подразделений проекта. Например, хватает ли в группе тестировщиков для реализации проекта? Бессмысленно держать 4-5 тестировщиков на 100 разработчиков, даже если первые обладают необходимыми навыками. Отношение числа разработчиков к числу тестировщиков критично для проекта и должно быть сбалансировано. Значение этого отношения зависит от потребностей проекта, но большинство организаций стремится поддерживать его между 2:1 и 4:1. Даже если не соблюдать такое отношение, тестирование всё равно придётся проводить, только в этом случае оно займёт больше времени.

• Недостаток масштабируемости

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

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

Второй подход – создать несколько групп с вышеописанной структурой организации, небольшие или средние по размеру. Это особенно хорошо работает, когда в рамках проекта ведётся разработка независимых программ, например, двух продуктов, редакций или независимых компонентов одного продукта. Для работы над каждой из независимых задач можно выделить небольшое число людей и обойтись даже меньшей, чем показанная здесь, моделью. Сформировав несколько небольших групп, можно решить проблему с масштабируемостью, но при этом возникают другие проблемы, присущие этой модели. Так, организацию из 100 человек можно разбить на независимые группы по 6-7 человек, но они не смогут в полной мере задействовать в совместной работе инструменты, стандарты, выделенные средства, наработанные процедуры и информацию.

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

Глава 4
Ранжирование сотрудников и корпоративная культура

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

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

Ранжирование

Само по себе понятие рейтинга не ново. Одни из примеров – спортивные команды, возводящие самых результативных спортсменов в ранг «привилегированных». Их значение для команды настолько велико, что с ними заключаются контракты на особых условиях. В некоторых организациях, занятых в создании ПО, рейтинг воплощён в системе должностных титулов. Например, используют такие приставки к названию должности, как «специалист первого (или второго) ранга», «старший» или «главный» специалист. Во всех примерах ранг служит для решения важных кадровых вопросов.

Правила ранжирования

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

Внутренний круг

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

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

Средний круг

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

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

Внешний круг

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

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

Для чего нужно ранжирование?

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

• Поощрение заслуженных сотрудников

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

• Распределение привилегий и ограниченных ресурсов

Когда в компании появляются новые привилегии и ресурсы, которые нельзя разделить поровну, возникает вопрос: кому отдать предпочтение? Хорошая мысль – определить достойных по их рангу. Неважно, что это будет: захватывающие исследования новой технологии, посещение выставки, собственный кабинет или встреча с клиентом на Гавайях, – ранжирование даёт упорядоченный список авторов наибольшего вклада в успехи компании, которые будут первыми кандидатами на получение привилегий.

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

• Планирование денежных компенсаций

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

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

• Планирование кадровой политики

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

Некорректное использование ранжирования

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

Привилегии и ответственность

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

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

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

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

Когда люди меняются

Что происходит, когда член внутреннего круга начинает вести себя, как член внешнего? Или наоборот, когда новичок поражает всех качеством своей работы?

В первом случае лучше всего обсудить возникшие проблемы с этим человеком, представив ему конкретные факты в подтверждение снижения эффективности его труда. Часто такое обсуждение позволяет выявить источник проблемы: может, это упадок сил или какие-то личные проблемы? Вооружившись этим знанием, можно попробовать сразу же решить эту проблему с большими шансами на успех.

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

К чему стремиться

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