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

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

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

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

Первый уровень — качество персонала

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

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

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

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

Второй уровень качества — уровень проекта

Предположим, что у компании имеется подготовленный, обученный и правильно мотивированный персонал. Что дальше? Есть ли теперь уверенность, что все проекты станут выполняться с требуемым качеством в требуемые сроки? Думаем, нет. Надо еще дать сотрудникам средства для успешного выполнения проекта.

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

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

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

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

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

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

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

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

Третий уровень качества — уровень компании

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

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

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

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

Снова о фабрике и организованном производстве

Теперь попробуем ответить тем, кто воспринимает слово «фабрика» в негативном смысле.

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

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

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

Проблемы выполнения проектов