Быть или не быть оффшорной компании

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

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

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

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

Качество персонала обеспечивается последовательно следующими мерами.

• Построение системы отбора. Лучше не взять человека, чем взять неправильного. Этот довольно консервативный подход к отбору не отвечает привычному российскому "авось", но как нельзя лучше подходит для обеспечения качества персонала. Должны быть сформулированы четкие требования к персоналу, нарушение которых не допускается. Требования должны быть максимально детализированы. Необходимо предусмотреть средства проверки кандидата на соответствие этим требованиям: резюме и уверения кандидата в собственной "крутости" не помогут понять, что за этим стоит. Должна быть построена система собеседований с ведущими разработчиками компании, которые в состоянии оценить уровень квалификации кандидата. Целесообразно проводить собеседование с несколькими ведущими специалистами с организацией обратной связи, т.е. с анализом последующей истории работы принятых кандидатов: это позволяет вводить поправки на излишний оптимизм/пессимизм интервьюеров во время процедуры отбора.
• Построение системы естественного отбора персонала внутри компании. Очень важно построить систему выявления проблемных сотрудников, контроля их работы и принятия решения об их адекватности служебным обязанностям. Очень часто для решения этих задач строят мощную менеджерскую структуру из расчета один менеджер на 7-10 сотрудников. Надо отметить, что в разрешении ситуации с проблемным сотрудником больше заинтересованы его коллеги, но они не хотят участвовать в принятии непопулярного решения. В качестве одного из вариантов системы естественного отбора (когда коллеги по работе принимают участие в выявлении проблемных сотрудников) может быть использовано так называемое правило отказов. Сотрудник может быть уволен, если от него последовательно отказываются проектные команды. У менеджеров проекта есть право отказаться, а у руководства есть право принять непопулярное решение на основе отказов.
• Построение системы оценки и карьерного роста.Кроме начальной оценки и наблюдения за сотрудником необходимо построить систему постоянной аттестации сотрудников. Система аттестации неразрывно связана с системой карьерного роста сотрудника. При этом цели должны ставиться как в профессиональной, так и в управленческой плоскости; они должны иметь четко выраженный характер и четкие сроки контроля, а их достижение должно стимулироваться. Такая система не только дает сотрудникам возможность расти материально и профессионально, но и позволяет при расширении компании адаптировать ее структуру за счет собственных сотрудников.
• Построение системы обучения персонала.Знания персонала должны соответствовать требованиям рынка, поэтому необходимо уделять внимание переподготовке сотрудников применительно к новым условиям. Переподготовку можно организовать через курсы или исследовательские проекты. Кроме того, система обучения может быть завязана с системой отбора. Например, если требуется нанять больше сотрудников, чем их можно найти на рынке в соответствии с заданными критериями отбора, то единственный способ все же набрать штат необходимой численности - снизить требования, одновременно организовав подготовку набранных сотрудников.
• Построение системы мотивации. Очень важно построить в компании систему мотивации персонала, направленную на высокое качество исполнения проектов. Одновременно система мотивации должна давать сотруднику ощущение некоторого гарантированного дохода, когда производство связано с успехами других подразделений, например, отдела продаж. Это означает, что у сотрудника должна быть базовая гарантированная зарплата, которая определяется его профессиональным уровнем и пересматривается на аттестации, прирастая еще и премиальными за успех конкретного проекта. Важно, чтобы схема подсчета и распределения премиальных была прозрачной. Еще одним наиглавнейшим условием правильной системы мотивации является ее обязательное исполнение. Задержка выплат зарплаты и проблемы с выплатой премий после успешного завершения проекта могут привести к нарушению морального климата в компании и проблемам с качеством последующих проектов. Можно сэкономить рубль, но затем потерять тысячи.
• Построение системы социальной защиты персонала. Очень часто систему социальной защиты, которая включает в себя медицинскую страховку, обеды, кредиты, ипотеку и другие элементы, воспринимают как некую затратную составляющую, призванную обеспечить конкурентоспособность компании на рынке труда. Однако социальная защита сотрудника может нести компании прямую выгоду. Так, отсутствие сотрудника по болезни в течение недели наносит убыток, потому что его время нельзя выставлять в счетах заказчику. Если же из скоротечного проекта из-за эпидемии гриппа выбыло 30% штатного состава, то проект этот будет трудно спасти.

Проект удобно представлять себе в виде треугольника, в вершинах которого три параметра.

• Функциональность. Набор требований к проекту.
• Качество. Набор критериев к количественному выражению качества проекта (например, число ошибок определенного приоритета при тестировании по конкретно заданным сценариям).
• Сроки. Даты доставки проекта заданного качества и требуемой функциональности.

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

Проанализируем средства для успешного выполнения проекта.

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

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

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

• Взаимодействие с заказчиком. Организация такого взаимодействия или управление ожиданиями заказчика - один из важнейших элементов качества. Исполнитель должен четко понимать, чего заказчик хочет, а заказчик должен четко осознавать, что и когда тот выполняет и доставляет. Только при таком понимании заказчик будет готов расстаться с деньгами. Кажется, простая формула, но она требует исключительного внимания, ведь между заказчиком и исполнителем лежит порой пропасть в тысячи километров, в языке и культуре. При организации процесса удаленной разработки не существует волшебной формулы, которая может помочь решить все проблемы.
• Управление изменениями. Любой проект, даже при самой детальной проработке требований, подвержен изменениям. Время идет, требования рынка могут измениться, и, соответственно, требования к проекту могут быть пересмотрены. Не нужно этого боятся, надо просто уметь этим управлять. Любое изменение должно быть сформулировано, оценено в разных направлениях (трудоемкость, стоимость, сдвиг дат, риски) и принято или не принято к исполнению. Иначе говоря, процесс оценки каждого изменения направлен на понимание того, что принесет данное изменение, и обоснованное принятие решения по его судьбе.
• Управление рисками проекта. Необходимо постоянно оценивать состояние проекта и возможные риски, которые могут повлиять на выполнение проекта в срок и с заданным качеством. В каждый конкретный момент времени можно оценить десять наиболее значительных рисков и разработать план по их устранению. Каждую неделю такие результаты работ по снижению рисков и сами риски могут пересматриваться и разрабатываться новый план мероприятий. Такой подход позволяет четко выявлять проблемы проекта и постоянно работать над их устранением.
• Управление конфигурацией. Проект не состоит лишь из исполняемых модулей программ, а представляет собой большую коллекцию проектных документов, документов тестирования, текстов программ и исполняемого кода. Это десятки, а то и сотни документов. Все они провязаны по версиям и взаимосвязаны между собой. Так, внесение нового требования к проекту меняет не только исходный код программ, но и всю сопроводительную документацию тестирования. Новое требование должно быть оттестировано, а для этого оно должно попасть в планы тестирования. Управление конфигурацией - это набор процедур, который позволяет поддерживать целостность всей проектной документации и кодов проекта.
• Управление планированием проекта. Без детального предварительного планирования невозможно планировать сроки выполнения проекта; это не пожелание, а жесткое требование. План должен быть максимально детализирован и проработан: нельзя идти туда, не зная куда.
• Управление качеством проекта. Обычно под этим подразумевается тестирование исполняемых модулей проекта на наличие дефектов. Более подробно, управление качеством включает в себя несколько этапов.
• Планирование процесса управления качеством. Уже на этапах оценки проекта надо понимать, как будет тестироваться проект, какие модули, какие элементы, как и на какие воздействия будут тестироваться: функциональность, производительность, нагрузка, соответствие стандартам. Отсутствие требований к качеству в документе с требованиями к проекту может привести к серьезным проблемам на следующих этапах.
• Подготовка проектной документации на тестирование. После процесса планирования необходимо проектировать тестирование.
• Подготовка дополнительных систем для тестирования. Иногда для тестирования на производительность или автоматического тестирования требуется подготовить стандартные средства или даже разработать специальный инструментарий.
• Собственно процесс тестирования и повышения качества проекта. Процесс тестирования должен охватывать не только исполняемый код, но и все, что производится в процессе проекта, например, требования, проектные документы, тест-планы, исходный код и т.д. Только постоянное и сквозное тестирование всех компонентов проекта может обеспечить его качество.
• Управление стандартами проектов. Кроме процессов, в компании можно выделить общие области для всех проектов. Например:
• Стандарты кодирования. Описывают требования к написанию и документированию исходного кода программ. Обычно зависят от языка программирования и являются обязательными для всех проектов, кроме случаев, когда заказчик требует следовать своим стандартам. Применение такого подхода позволяет создавать код в соответствии с предопределенными стандартами, что позволяет сделать его максимально независимым от автора.
• Стандарты пользовательского интерфейса. Не ограничивая творчество, на основе опыта предыдущих проектов показывают, как не надо делать.
• Стандарты проектирования. Позволяют определить требования к уровню деталей проектных документов и избежать волюнтаризма в проектировании. Если в стандарте указано, что должны быть прописаны все сообщения об ошибках, а проектировщик поленился это сделать (что может привести к серьезным проблемам при установке программы), то, в соответствии со стандартами, тестирование проекта должно выявить этот изъян.
• Этика выполнения проектов. Под этикой понимается движение ответственности за качество проекта. Например, если топ-менеджмент совместно с функциональностью задает проектной команде сроки и качество исполнения проекта, то кто отвечает за дату сдачи проекта? Проектная команда? Нет - топ-менеджмент. Если проектная команда выдала сроки, то она и отвечает. Кажется, какая разница, кто за что отвечает, если и те и другие установили одни сроки? Разница очень велика. Разница в морали проектной команды, оказывающей очень большое влияние если не на сроки проекта, то на его качество. Если руководство «прессует» проект по срокам, это может привести к побегу сотрудников из проекта и из компании. Поскольку в отбор и подготовку каждого сотрудника вкладываются значительные деньги, игнорирование этого правила может привести к очень серьезным потерям.

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

Для постоянного повышения качества на уровне компании существует много подходов. Приведем некоторые из них.

• Лучший опыт (best practices). Основан на стимулировании генерации изменений внутри проектной команды, направленных на улучшение качества, их выявлении, анализе и последующем закреплении внутри всех проектных команд.
• Метрики. Направлен на постоянный сбор и анализ объективной информации о работе каждого сотрудника, проекта и компании в целом. Под объективной информацией подразумеваются количественные параметры, описывающие качество работы. Например, средняя величина задержки в доставке проекта или количество ошибок. Наличие таких метрик и сбор информации в течение длительно времени позволяет менеджменту компании принимать решения на основе более объективных данных и, следовательно, более эффективно повышать качество.
• Аудит проекта. Преследует две основные цели: выявление проблем с ведением проекта, которые еще не выявил заказчик, и принятие корректирующих мер; выявление соответствия работы проектной команды требованиям компании и принятие корректирующих мер по поводу команды.
• Пост-анализ проекта. Аналог аудита, осуществляется в конце проекта и позволяет выявить достижения и проблемы, встретившиеся в ходе работы над проектом.
• Сертификация компании. Закрепляет то, что уже наработано в процессе построения системы управления компанией. Часто сертификацию рассматривают как панацею для создания системы качества. Однако последовательность должна быть иная - сначала построение системы качества (возможно, с учетом последующей сертификации), а потом ее сертификация.

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

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

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

• Местный менеджер заказчика, который территориально находится рядом с заказчиком, является «аборигеном» - говорит на одном языке с заказчиком, понимает его культурные особенности и взаимодействует с заказчиком и с командой проекта. Естественно, его роль и значение зависит от его персональных особенностей. Нужно также понимать, что нетрудно найти человека, который может решать бизнес-проблемы, либо технические проблемы, но трудно найти того, кто будет силен как в том, так и в другом.
• Следующим этапом является формирование группы технических специалистов, которые работают в офисе заказчика (on-site) и взаимодействуют с удаленной командой. По опыту больших индийских компаний, часто используется соотношение: один сотрудник on-site и девять удаленных.

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

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

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