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