Если покупатель продукта, как правило, может увидеть, или даже опробовать то, что он покупает еще до момента покупки, то покупатель услуги, по сути, приобретает нечто невидимое и неосязаемое. Поэтому основа основ в отношениях «клиент–поставщик услуг» – это доверие. Заказчик должен быть непременно уверен, что поставщик выполнит все обещания. В полной мере это применимо к оказанию услуг по разработке программного обеспечения на заказ.
Но что делать поставщикам услуг, которые одновременно ведут огромное количество разнообразных IТ-проектов, интересы которых могут не только пересекаться, но и конфликтовать?
Первый совет, который можно дать в таком случае, – постарайтесь, чтобы каждый проект соответствовал некоему гарантированному стандарту качества. Не нужно стремиться сделать один идеальный проект, забыв про все остальные. Добиваться гарантированного уровня качества на каждом проекте – вот что действительно можно назвать профессионализмом.
Будем откровенны: часто потребитель услуг испытывает опасение: можно ли довериться этому поставщику? Получу ли я вообще то, на что рассчитываю? Не потеряю ли я свои время или деньги? Сложно представить себе заказчика, который настолько уверен в результате, что единственное, чего он опасается, так это то, что результат будет «не выдающимся».
Что есть качество?
Качество тесно связанно с ожиданиями клиента. Когда результаты проекта совпадают с ожиданиями, услуги воспринимаются как высококачественные. Если результаты не совпадают с ожиданиями, то услуга воспринимается как низкокачественная. Как правило, заказчик имеет достаточно полное представление о последствиях низкого качества и, как было сказано выше, в первую очередь беспокоится о том, чтобы не вложиться в нечто провальное, что негативным образом скажется на его имидже. Никто не хочет попасть в ситуацию, в которой придется признать, что был сделан ошибочный выбор.
Хотя это не относится к основной теме данной статьи, но одним из приемов работы с подобным опасениями заказчика является определение испытательного срока, выполнение тестового задания. Гарантия в ее классическом виде, по меньшей мере в сфере заказной разработки ПО, решает эту проблему лишь отчасти. Если материальные и финансовые затраты клиента подрядчик может компенсировать (в том числе, доработкой ПО до ожидаемого уровня за свой счет), то упущенное время и связанные с этим упущенные возможности зачастую вернуть невозможно.
Функциональные и нефункциональные требования
Хотя уровень качества, как было показано выше, вещь субъективная, все же им можно управлять. Более того, его можно измерять в числовых показателях.
Применительно к результатам проектов по разработке программного обеспечения можно вести речь о двух больших и различных, хотя отчасти и пересекающихся категориях атрибутов качества – функциональных и нефункциональных.
Хотя может показаться, что функциональное качество – вещь объективная и не зависит от субъекта, и если программа работает с ошибкой, то это факт, который может зафиксировать любой беспристрастный наблюдатель. Для некоторых типов ошибок это действительно так. Но существует огромная «серая зона» особенностей поведения ПО, которое может восприниматься и как желаемое, полезное поведение, и как нежелаемое проявление ненадлежащего качества.
С нефункциональными особенностями ситуация еще более сложная. Как правило, ни заказчик, ни пользователь программного обеспечения не может ни самостоятельно сформулировать свои ожидания по поводу нефункциональных атрибутов качества, ни проверить соответствует ли разработанное ПО заявляемым нефункциональным характеристикам. В начале проекта заказчик может и вовсе не задумываться над нефункциональными характеристиками будущего ПО, а конечный пользователь и вовсе никогда не столкнется с их проявлениями. Примерами «нефункциональных характеристик» могут быть общая стоимость владения системой или вопросы качества программного кода (масштабируемость, тестируемость, возможность усовершенствования, разработки новых функций, наличие и качество комментариев в коде и т.д.).
Вот, к примеру, хороший мысленный эксперимент, позволяющий понять относительную независимость функциональных и нефункциональных атрибутов качества ПО: нужно представить два продукта, которые обладают идентичной функциональностью с точки зрения пользователя. Но в то же время модификация одного из этих продуктов может стоить дороже, чем написание нового продукта с нуля, а вот другой сделан так, что позволяет изменять и добавлять функции быстро и легко.
Для того чтобы управлять уровнем качества, желательно уметь его измерять. На практике уровень качества (как функционального, так и нефункционального) удобнее всего измерять в долларах. Чтобы оценить уровень качества, нам нужно ответить на вопрос: сколько будет стоить внесение изменений в продукт, который позволит добиться выполнения ожиданий клиента. В случае нефункциональных атрибутов качества для определения целевых характеристик может понадобиться помощь эксперта, который поможет клиенту понять, как тестируемость, расширяемость и т.п. повлияют на стоимость владения, и другие выраженные в понятных клиенту терминах характеристики. Выраженную в долларах величину несоответствия целевых и фактических значений нефункциональных атрибутов качества принято называть техническим долгом проекта.
Управление уровнем качества (особенно это относится к техническому долгу), как правило, сводится к его измерению и удержанию в пределах определенной оговоренной величины.
Разные проекты – разные уровни качества
На каждом проекте состав команды и условия работы разные. Тот факт, что специалист успешно завершил один проект, не гарантирует такого же успеха данного специалиста на следующем проекте.
Аналогичная ситуация с методологиями и инструментами. При прочих равных успех сильно зависит и от взаимоотношений внутри команды, и от отношений с клиентом. Из-за этого уровень качества программного обеспечения, создаваемого в рамках разных проектов в одной компании, может сильно отличаться. Цель успешного поставщика услуг – не ограничивая сильнейшие проекты в их стремлении к совершенству, помочь «отстающим» проектам обеспечить максимально возможный гарантированный уровень качества. Поднимать уровень качества проектов в компании следует инвестируя, в первую очередь, в мероприятия, которые позволят поднять на следующую ступень гарантированный уровень качества каждого проекта, а не в возможность поднять максимально возможный уровень качества на единичных проектах.
Как добиться качества?
Общие вопросы управления качеством выходят за пределы данной статьи. Тут же хотелось бы упомянуть о существовании SQALE, проработанной методологии контроля за нефункциональными атрибутами качества программного обеспечения (контроля технического долга). Также стоит упомянуть SonarQube как средство статического анализа исходного кода, реализующего заложенные в SQALE принципы.
Особо стоит выделить один аспект: обеспечение независимости аудита. Практика показывает, что повторяемую объективность контроля может обеспечить только его независимость. Если уровень качества оценивает специалист, находящийся в непосредственном подчинении руководителя, оценка работы которого зависит от того, какую оценку получит качество проекта – рано или поздно возникнет конфликт интересов. Автоматические методы контроля в этом смысле имеют несомненное преимущество, но наличие независимого департамента оценки качества также решает эту проблему.
Менеджмент и качество: проектные карточки
Практика для контроля общего качества проектов, которую мы используем в Itransition, основана на так называемых проектных карточках. По сути – это набор кратких ответов на простые вопросы о каждом проекте. Проектные карточки позволяют оценить состояние конкретного проекта и ситуацию по всем проектам компании в каждый конкретный момент.
Вопросы в проектных карточках иногда могут показаться достаточно тривиальными, подразумевающими очевидный ответ. Но молчаливое предположение «очевидного» ответа всеми заинтересованными лицами может иметь резко негативные последствия в случае, если это предположение окажется ошибочным. И наоборот, если были собраны ответы на все вопросы (и у каждого ответа есть персонифицированный автор, у которого можно при необходимости уточнить детали), это дает определенные гарантии того, что важные аспекты не остались без внимания. И даже если стали видны некоторые проблемы, у вас есть возможность исправить все вовремя. Вопросы могут звучать примерно так:
- Есть ли план проекта?
- Актуален ли он?
- Регулярно ли он обновляется?
- Можно ли однозначно видеть, что очередной пункт плана выполнен?
- Все ли в команде знакомы с планом?
Любопытно, что практика ответов на такие вопросы работает как «самореализующееся пророчество». Зачастую специалист, заполняющий подобную анкету, предпочитает реализовать изменение, которое позволит ему дать позитивный ответ, а не объяснять причины отрицательного ответа (тем более что зачастую, никаких объективных причин нет). На следующем проекте, зная, что придется заполнить такой же опросник, этот специалист заранее позаботится о том, чтобы обеспечить себе возможность ответить на все вопросы положительно.
Стороннему наблюдателю практика заполнения таких проектных карточек может показаться избыточной бюрократией: на некоторые вопросы почти все отвечают положительно. Но это реально означает позитивное изменение (по меньшей мере, наш опыт демонстрирует именно это), а не избыточность измерения. Можно провести некоторую аналогию с видеокамерой, которая будучи установлена в месте, в котором ранее совершались инциденты, не фиксирует ни одного – так как потенциальные участники инцидентов знают о существовании камеры.
Одна из задач любого менеджера – не оставлять проект без внимания. Хотя бы какая-то часть проекта должна быть под контролем ежедневно. Менеджмент посредством ежедневного обхода (это устоявшееся название) – отличный способ ненавязчивого управления несколькими командами и проектами. Такой подход позволяет выявить «узкие места» проекта еще до того, как они станут настоящей проблемой, даже в том случае, если до момента обхода менеджер и не предполагал, что за узкие места это могут быть.
Заполнение проектных карточек и их регулярное просматривание – вариация такого типа менеджмента, только без реального обхода всех сотрудников на проекте. Это «лицо» проекта, которое может сказать менеджеру очень многое: каково реальное положение дел на проекте, на какие вопросы из карточек нет ответа, где могут быть проблемы и т.д.
Практика показывает, что регулярный просмотр проектных карточек позволит избежать ситуации, когда какая-то проблема просто остается незамеченной. Своевременное обнаружение потенциальных проблем, и организация адекватных мероприятий существенно снижает риск возникновения реальных проблем на проекте.
При этом команда может просто не замечать проблем изнутри, так что контроль с разных точек зрения может помочь менеджеру понять, что же реально происходит на проекте.
Геймификация повышают мотивацию
В рутинный процесс заполнения карточек можно и нужно вносить элементы игры. Например, процент заполнения карточек поощряется по неким оговоренным правилам, что дополнительно мотивирует сотрудников, внося и соревновательный элемент.
Состояние самих карточек уже может сказать менеджеру многое о проекте и необходимости внести какие-то изменения. Незаполнение карточек – тоже информация. Естественно, очень важно оперативно узнать, почему так происходит. Возможно, стандартные вопросы просто не соответствуют специфике конкретного проекта? Или все-таки сработало какое-то из «слабых звеньев» проекта?
Заключение
Существует масса техник, методик и инструментов, которые позволяют контролировать проект менеджеру, непосредственно вовлеченному в проектную работу. Когда речь идет о десятках или даже сотнях проектов, оценка зрелости проекта, и соответственно, проектных процессов (а именно о зрелости можно судить по заполнению проектной карточки)является фактически единственным способом составить представление о статусе каждого проекта и проанализировать, спрогнозировать перспективы его развития.
Эффективность работы над большим проектным портфолио требует от компании опыта, нарабатываемого годами, также как и глубокого понимания предметной области. Ведь именно опыт и знания помогают сделать оптимальный выбор в условиях неопределенности. Кстати, мощнейшей практикой тут является осознанное (а лучше задокументированное) отклонение реально рассмотренных альтернатив.
Контроль над уровнем зрелости, инвестиции в поддержание и рост гарантированного уровня значений как функциональных, так и нефункциональных атрибутов качества, позволяет обеспечить удовлетворение результатами сотрудничества «клиент–поставщик услуг» на каждом проекте. А удовлетворение потребностей каждого заказчика при соблюдении собственных коммерческих интересов – это и есть цель всякой компании, оказывающей профессиональные услуги.
Юрий Зеленский, технический директор в Itransition
