Для начала сравните текущую продуктивность труда сотрудников вашей компании со средней продуктивностью труда работников компаний из списка Global 500. Для этого просто заполните пустые ячейки в правой колонке Таблицы 1.
Замечательно, если показатели продуктивности вашей компании превышают средние показатели по списку Global 500 и плохо, если — ниже, однако самый главный индикатор в Таблице 1 отсутствует. Это показатель ежегодной скорости роста продуктивности труда. В компаниях из списка Global 500 эта скорость за последние два года составила 29% в год, а рост оборота на одного сотрудника составил 21%.
Что обеспечивает рост?
Говоря о продуктивности, необходимо помнить не только об обороте и прибыли. Труд — это результат, польза, которую создает сотрудник.
Несколько лет назад мне пришлось работать в транснациональной корпорации, в которой было принято решение о повсеместном внедрении ERP-системы, созданной другой, не менее известной корпорацией. После внедрения стало понятно, что теперь менеджеры большую часть своего времени тратят на ввод в систему необходимой информации, поэтому для экономии времени руководство назначило ответственными за работу с системой секретарей, которые должны были выступать в качестве своеобразных «посредников» между менеджерами и программой. Это, в свою очередь, удвоило нагрузку на секретарей, у которых теперь не оставалось времени для выполнения других обязанностей. Тогда было решено увеличить количество секретарей, и была нанята тысяча новых сотрудников, основная задача которых состояла в том, чтобы переносить информацию из сообщений электронной почты менеджеров в ERP-систему. На первый взгляд, ситуация замечательная — компания создала новые рабочие места; но действительно ли цель состояла в открытии новых вакансий, требующих от кандидатов умения эффективно делать операции cut-and-paste?
Главная цель автоматизации — избавить человечество от рутины, передать ее на «аутсорсинг» компьютерам, освободить человеку время для выполнения тех задач, которые передать машинам невозможно. Именно это является ключевым направлением эволюции компьютерных технологий, которое определяет бизнес-стратегии успешных высокотехнологических компаний, а также позволяет более глубоко понять суть термина «продуктивность труда» — не только как «прибыль, приносимая сотрудником» (количественный уровень), но и как «новые человеческие ценности, создаваемые сотрудником» (качественный уровень).
Экосистема
Оценивая бизнес компании, разрабатывающей программное обеспечение, проанализируем ее экосистему. Рост продуктивности труда в компании невозможен в отрыве от роста продуктивности ее бизнес-среды. Необходимо задать себе несколько вопросов.
-
Какова продуктивность труда в нашей компании? Какова прибыль, создаваемая одним сотрудником? Как продуктивность труда растет от года к году? Достаточен ли этот рост? Что можно сделать, чтобы продуктивность труда росла быстрее, чем у конкурентов?
-
Какова продуктивность труда наших клиентов? Какова прибыль, создаваемая одним сотрудником компании-клиента? Как наше программное обеспечение помогает нашим клиентам повышать их продуктивность труда? Достаточен ли этот рост? Что мы должны сделать, чтобы продуктивность труда наших клиентов росла быстрее, чем у их конкурентов?
-
Какова продуктивность труда наших партнеров? Какова прибыль, создаваемая одним сотрудником компании-партнера? Как наши партнерские программы помогают им повышать их продуктивность труда? Достаточен ли этот рост? Что мы должны сделать, чтобы продуктивность труда наших партнеров росла быстрее, чем у их конкурентов?
Успешная стратегия должна учитывать все компоненты экосистемы и предоставлять четкие ответы на перечисленные вопросы. Для каждого элемента бизнес-среды есть только два простых способа повысить продуктивность: увеличить выработку или понизить расходы (рис. 1). Средняя прибыль, создаваемая сотрудником компании из списка Global 500, растет быстрее, чем создаваемый им оборот, — это означает, что успешные корпорации используют оба этих способа.
Как достичь роста продуктивности?
В компаниях, производящих программное обеспечение, особое внимание должно быть уделено продуктивности труда инженеров — к этому подталкивают не только основанные на макропоказателях экономические выкладки, но и банальная нехватка программистов на рынке труда. Эффективность труда инженеров — ключевое конкурентное преимущество, поэтому новые методологии разработки программного обеспечения появляются сегодня почти так же часто, как появлялись новые языки программирования два десятилетия назад: Agile Unified Process (AUP), Design-Driven Development (D3), Dynamic Systems Development Method (DSDM), Test-Driven Development (TDD) и т.п. Такое разнообразие подтверждает, что ИТ-отрасль еще далека от зрелости.
Какова же основная тенденция развития методологий в ИТ-индустрии? Какие из них будут использоваться через пять лет? И каким методологиям должна отдать предпочтение компания, разрабатывающая программное обеспечение, чтобы повысить эффективность работы своих инженеров и тем самым получить реальное конкурентное преимущество?
В ближайшие годы рост продуктивности будет происходить в основном за счет эволюции производственных процессов, оптимизации работы первого «элемента» в паре «человек + компьютер» и более полного раскрытия творческого потенциала инженеров. Поясним на деле.
К примеру, eXtreme Programming — скорая (agile) методология, содержащая набор практик и рекомендаций, помогающих инженерам лучше организовать их работу. Пожалуй, самой известной методикой XP является «парное программирование» — два инженера совместно работают над задачей, с выполнением которой каждый из них мог бы справиться в одиночку. С «традиционной» точки зрения, «парное программирование» создает ненужную избыточность и неэффективно использует человеческие ресурсы. Но на практике оно ведет к повышению качества кода и снижению количества последующих переработок, тем самым сокращая общий производственный цикл. При парном программировании продуктивность труда повышается не за счет автоматизации или применения сложных алгоритмов, а за счет оптимизации взаимодействия людей друг с другом.
Методология INTSPEI P-Modeling Framework (надстройка над существующими методологиями, расширяющая их новыми методиками и механизмами) менее известна и касается главным образом рекомендаций по оптимизации деятельности инженеров. Например, «бессловесное моделирование», согласно которому аналитики и проектировщики проводят сессию моделирования и создают архитектуру будущей системы, не использует «человеческие» языки — для взаимодействия с коллегами может применяться только UML или иной язык моделирования. С «традиционной» точки зрения, «бессловесное моделирование» должно вести к потере информации, но в действительности оно повышает качество создаваемой модели и понижает количество проявляющих себя в последующем архитектурных проблем, тем самым сокращая общий производственный цикл. И снова продуктивность труда повышается не за счет автоматизации, а за счет применения новых методов организации труда людей.
Оба примера иллюстрируют простоту и мощь общей тенденции — существующие методологии разработки будут развиваться по пути оптимизации прежде всего тех процессов, которые сложно или невозможно «поручить» компьютеру, по пути поиска новых механизмов взаимодействия между людьми и активизации их творческих способностей.
Ранняя диагностика архитектурных ошибок
Начальные стадии (анализ и проектирование) больших проектов являются чрезвычайно ответственными — именно здесь принимаются наиболее важные решения и допускаются ошибки, которые наиболее дорого обходятся впоследствии. Затем, по мере развития проекта, стоимость ошибки снижается. В то же время уровень контроля качества на начальной стадии является минимальным и повышается в процессе продвижения процесса разработки. К полноценному тестированию приступают только на поздних этапах проекта — тогда, когда уже имеется исполнимый код. Результатом такого «эффекта ножниц» часто становится несвоевременная (поздняя) диагностика архитектурных ошибок и последующая дорогостоящая переработка всей системы либо ее отдельных частей.
Для решения проблемы задержек диагностики есть два пути. Первый — сокращение длительности итераций. Время между моментом внесения ошибки и моментом ее выявления не может быть больше, чем длительность итерации. Сокращая итерации, мы сокращаем максимальную возможную задержку диагностики ошибок. Именно по этому пути — частых итераций — идут скорые методологии. Однако этот путь неприемлем для больших проектов, а также для проектов с повышенными требованиями к качеству (медицинские, аэрокосмические, военные приложения).
Второй путь — включение дополнительных методов контроля качества на каждой фазе процесса создания программного обеспечения. Теоретически с их помощью мы могли бы выявлять и устранять архитектурные ошибки сразу в момент их возникновения, не позволяя ошибкам распространяться на последующие фазы производственного процесса. В этом случае можно было бы говорить не столько о выявлении ошибок, сколько об их предотвращении. Практически же существовавшие до сих пор методы не позволяли делать это эффективно. В результате более чем шести лет экспериментально-исследовательских работ сегодня INTSPEI располагает технологией раннего выявления критических ошибок, в основе которой лежит метод обратной семантической трассировки.
Метод обратной семантической трассировки
Представим себе гипотетическую ситуацию. Предприятие планирует выйти на рынок Японии, и у него нет переводчиков с японского, но имеется местная компания-партнер, сотрудники которой не говорят по-русски. Предприятие нанимает внешнюю команду лингвистов, которые переводят маркетинговые материалы. После того как они заканчивают работу, результаты перевода отсылаются на проверку партнеру в Страну восходящего солнца. В ответ предприятие получает сообщение, в котором на ломаном русском сообщается, что полученные тексты действительно написаны на японском языке. Как оценить качество перевода? Как проверить, что переводчики всю информацию передали правильно и ничего не исказили? Как избежать эффекта «испорченного телефона»? От ответов на эти вопросы зависит успех запускаемой в Японии массовой рекламной кампании.
Обычный ответ — перевести назад с японского на русский, для чего привлечь новую команду лингвистов, которая не знакома с первоначальными русскими версиями текстов. Таким образом, для процесса перевода существует простой метод проверки его качества путем «обратной инженерии» результатов перевода с последующим сравнением оригинального и восстановленного текстов. Подобный же метод можно применить и при разработке программного обеспечения. Действительно, процесс создания программ можно рассматривать как последовательность «переводов» с одного языка на другой. Аналитик «переводит» с человеческого языка на язык формального описания бизнес-процессов, проектировщик «переводит» полученный текст на язык описания архитектуры, затем программист «переводит» его на язык программирования, и наконец компилятор «переводит» результат работы программиста на язык машинных кодов (рис. 2).
Каждый из этих шагов имеет две составляющие: трансляция информации с предыдущего шага на последующий; понижение уровня абстракции, детализация транслируемой информации и принятие технических решений. Очевидно, что проверка путем обратного «перевода» поможет выявить не все ошибки, а только те, которые относятся к первой составляющей. Однако и это немало, тем более что большинство проблем при разработке и внедрении программного обеспечения связано не с неверными техническими решениями, а с ошибками коммуникации. Упомянутый метод получил название обратной семантической трассировки (ОСТ) и в общем виде применим к произвольным шагам информационных процессов, имеющим своей целью преобразование информации из входных артефактов в выходные. Метод позволяет:
-
оценить качество трансляции информации, преобразованной в результате осуществления шага процесса;
-
принять решение о необходимости коррекции входных и/или результирующих артефактов;
-
принять решение о необходимости повторного осуществления шага процесса или о возможности перехода к следующему шагу.
Применение этого метода совместно с «традиционными» методологиями позволяет осуществлять сквозной контроль информационных потоков в процесе создания программного обеспечения (рис. 3). Использование термина «семантическая» в названии подчеркивает тот факт, что при сравнении оригинальной и восстановленной версий «текстов» необходимо анализировать их сходство и различие на содержательном, семантическом уровне, что пока автоматизировать невозможно.
На практике этот метод может принимать неожиданные формы. Например, компания — один из лидеров российского рынка разработки программного обеспечения для операторов мобильной связи — решила использовать метод обратной семантической трассировки для сокращения расходов на сопровождение и рефакторинг уже созданных программ. В процессе модификации кода программисты часто совершали ошибки, а во время устранения выявленных ошибок они вносили в код новые ошибки, и при большом потоке изменений сопровождение становилось весьма дорогостоящим. Для решения этой проблемы компания изменила свой производственный процесс, который теперь выглядит следующим образом. Когда тестер находит ошибку, он создает ее описание и направляет его программисту. Программист, проанализировав описание ошибки, устраняет ее, для чего вносит изменения в код. После этого два варианта кода (до изменения и после) направляются другому программисту, который не видит изначальное описание ошибки. Его задача — по изменениям в коде восстановить описание ошибки, которую эти изменения устраняют. После того как он выполняет эту задачу, собирается небольшое совещание в составе нашедшего ошибку тестера и двух вовлеченных в процесс программистов. Участники совещания анализируют два варианта описания ошибки и принимают решение о том, достаточно ли качество измененного кода, или требуются дальнейшие переделки. В результате внедрения этого процесса количество ошибок, вносимых на этапе сопровождения, сократилось в несколько раз. Кроме того, значительно повысился уровень документирования кода, что также является существенным плюсом (хотя это и не было изначально сформулированной целью).
Метод обратной семантической трассировки требует привлечения дополнительных ресурсов — как минимум, обратный «перевод» должен делаться кем-то, кто не знаком с оригинальным вариантом восстанавливаемого «текста». Этот подход эффективен, но дорог, поэтому важно уметь идентифицировать те места в производственном процессе, где его использование оправдано. На интуитивном уровне понятно: максимальная отдача будет от его применения на этапах анализа и проектирования — там, где цена ошибки наиболее высока, а существующие подходы к контролю качества наименее эффективны. Однако кроме интуиции нужна практически применимая технология, формализованный и проверенный производственный процесс.
INTSPEI P-Modeling Framework
В основе бесплатного продукта INTSPEI P-Modeling Framework лежат существующие методологии, дополненные методиками, направленными на повышение эффективности труда инженеров и предотвращение критических ошибок. Первая версия INTSPEI P-Modeling Framework была создана в сотрудничестве со специалистами из IBM и Microsoft и интегрируется в IBM Rational Unified Process (RUP), Open Unified Process (OpenUP) и Microsoft Solutions Framework (MSF).
Каждый из этих продуктов представляет собой интерактивный справочник, содержащий детальное описание соответствующего производственного процесса, предусмотренных им фаз, этапов, задач, шагов, процедур; производственных ролей и их зон ответственности; создаваемых и используемых артефактов, их шаблонов и т.п.
Дополнительные механизмы и методики, предлагаемые в INTSPEI P-Modeling Framework, можно условно разделить на три группы.
Первая группа предназначена для решения задач планирования и оптимизации процесса. Очевидно, что предлагаемые INTSPEI новые методики не имеет смысла внедрять на каждой фазе, каждом этапе и шаге проекта. В этом случае они приведут к неоправданному увеличению трудозатрат, поэтому в начале проекта необходимо идентифицировать «узкие места» существующего процесса и определить самые значимые артефакты, требующие особого внимания. Надо запланировать применение новых методик только там, где это принесет наибольшую пользу, и изменить в соответствии с выработанным планом текущие производственные процессы, научив сотрудников их эффективно применять. Вся эта деятельность обеспечивается предлагаемыми INTSPEI P-Modeling Framework механизмами, в основе которых лежит подход к приоритизации артефактов, основанный на ранжировании ассоциированных с ними рисков.
Вторая группа методик регламентирует непосредственную интеграцию метода обратной семантической трассировки с конкретными шагами производственного процесса. Эта интеграция осуществляется не везде, а только в выявленных ранее узких местах, однако таковых обычно находится немало, кроме того, в разных проектах узкие места будут на разных этапах процесса. Соответственно, INTSPEI P-Modeling Framework предлагает полный набор готовых «рецептов» по внедрению ОСТ на разных этапах и шагах, хотя в каждом конкретном проекте используются далеко не все эти «рецепты». Конкретные способы внедрения ОСТ существенно отличаются друг от друга в зависимости от того, к чему ОСТ применяется, а практика использования этого метода уже ушла довольно далеко от изначальной простой идеи.
Чаще всего потребность во внедрении ОСТ возникает на начальных этапах производственного цикла — анализе и проектировании. Эти этапы наиболее ответственны и в некоторых случаях ОСТ недостаточно — требуются дополнительные механизмы контроля качества и повышения эффективности труда инженеров на этапах выработки архитектуры решения. Они образуют третью группу, которая основывается на упомянутом методе бессловесного моделирования. Эксперименты показали, что запрет на использование естественного языка во время работы группы проектировщиков позволяет в два-три раза сократить длительность процесса формирования архитектуры, и при этом существенно повысить качество результата. Бессловесный режим не позволяет архитекторам отвлекаться на посторонние вопросы и дает возможность сфокусироваться на решаемой проблеме, активизировать свои творческие способности, увеличить глубину проработки модели, в процессе ее создания полностью специфицировать все предположения и умолчания, повысить читаемость и понимаемость созданной архитектурной модели. Однако у него есть и минусы — он энергетически «выматывает» участников бессловесной сессии, что делает невозможным частое проведение таких мероприятий. Поэтому INTSPEI P-Modeling Framework рекомендует проводить бессловесные сессии только при создании первых версий архитектуры, а также во время учебных семинаров.
***
В условиях глобализации ключевым фактором успеха в конкурентной борьбе является способность компании стабильно увеличивать продуктивность труда своих сотрудников. Передовые методологии позволяют оптимизировать шаги процесса создания программного обеспечения, которые невозможно либо трудно автоматизировать и которые требуют от человека максимального раскрытия его творческих способностей.
Владимир Павлов (vlpavlov@intspei.com) — директор Международного НИИ проблем программирования INTSPEI (Москва).
