Делаем проекты или предоставляем сервис?

В свете предстоящего мероприятия “Что вы знаете о модели CMMI for Services?” от сертифицированного SEI инструктора и ведущего оценщика по моделям CMMI Александра Кондакова, вот что подумалось. Наверное в большей половине случаев в индустрии аутсорсинга разработки ПО мы, не всегда того осознавая, на самом деле предоставляем сервис, а не делаем проекты. Или, говоря другими словами, скорее делаем операционную деятельность, чем проекты.

Поясню. Рассуждения не касаются относительно краткосрочных проектов по модели Fixed Price. Речь о долгосрочных отношениях с заказчиком с относительно стабильными бизнес областью, продуктом/сервисом, командой, рабочими процессами. Называется это по-разному – outstaffing, bodyshop, dedicated development center и т.д., но суть от этого не меняется.

Здесь отходят на второй план практики управления проектами, например, то же детальное планирование (оценки, расписание). Разработка архитектуры продукта или подходов к его тестированию то ли не делается исполнителем вообще, т.к. это уже было сделано до начала взаимоотношений, то ли делается исполнителем один раз. Даже выяснение ожиданий, их подробное документирование, а потом утверждение с заказчиком может оказаться на втором плане.

Что же на первом плане? Тут хочу предложить наблюдения из своего опыта. Большая часть серьезных заказчиков, ищущих долгосрочного сотрудничества мало интересуются нашими способностями в области управления проектами, бизнес анализ тоже может не особо интересовать, и даже технические познания инженеров!

Их на самом деле интересует:

  • Если проводится интервью с нашими техническими специалистами, то они на самом деле оценивают коммуникативные навыки – владение языком, умение выражать свои мысли. А после, уже в процессе работы – нашу способность таки УСЛЫШАТЬ то, что хочет заказчик, а не то что нам хочется предложить. А спрашиваемые технические вопросы обычно довольно тривиальны J.
  • Интересует способность интегрироваться в инфраструктуру заказчика, т.к. зачастую репозитории кода, документации и прочие системы находятся у заказчика. То есть разработать и поддерживать некоторое техническое решение, обеспечивающее повседневную работу
  • Способность перенять знания и рабочие процессы.
  • Способность обеспечить деятельность необходимыми ресурсами (люди, оборудование, интернет, визы, командировки и т.д.)
  • Способность долгосрочно выдавать результаты (качество, количество) на ожидаемом уровне, т.е. SLA (Service Level Agreement), что типично для предоставления сервисов
  • Способность обеспечить непрерывность бизнеса, т.е. наличие выработанных реакций на всякого рода инциденты (стучим по дереву): «падение» сервера с потерей всех данных, текучка кадров и сезонные эпидемии гриппа, затопление, противоправные действия и т.п.
  • Вопросы информационной безопасности, т.е. каким образом интеллектуальная собственность заказчика не «уплывет» куда не надо.

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

Завершая свои мысли, хочу предложить обратить ваше внимание как на модель CMMI for Services в целом, так и на специфические для сервисов Process Areas (процессные области) из этой модели, сравните со списком интересов заказчика выше, много общего, не правда ли?

  • Capacity and Availability Management (CAM):
    • making sure you have enough of the resources you need to deliver services and that they are available when needed—at an appropriate cost
  • Incident Resolution and Prevention (IRP):
    • handling what goes wrong—and preventing it from going wrong if you can
  • Service Continuity (SCON):
    • being ready to recover from a disaster and get back to delivering your service
  • Service Delivery (SD):
    • setting up agreements, taking care of service requests, and operating the service system
  • Service System Development (SSD):
    • making sure you have everything you need to deliver services, including people, processes, consumables, and equipment
  • Service System Transition (SST):
    • getting new systems in place, changing existing systems, or retiring obsolete systems—all while making sure nothing goes terribly wrong with the service
  • Strategic Service Management (STSM):
    • deciding what services you should be providing, making them standard, and letting people know about them

Для более углубленного ознакомления можно обратиться к первоисточникам.

О моделях CMMI: http://www.sei.cmu.edu/cmmi/solutions/?location=secondary-nav&source=652355

Презентация о модели CMMI for Services: http://www.sei.cmu.edu/library/abstracts/presentations/CMMI-for-Services-Overview.cfm

Модель «CMMI for Services, Version 1.3»: http://www.sei.cmu.edu/library/abstracts/reports/10tr034.cfm

Tags: , , ,

Comments are closed.