Работа с Заказчиком в ИТ. Что нас ждет дальше?

Процесс ориентированный на ЗаказчикаСовсем недавно задал себе вопрос о том, как процесс работы с заказчиком интегрирован в разработку ПО и что же нас ждет в ближайшем будущем.

Следуя своей философии поиска аналогий (я неоднократно отмечал, что ИТ отрасль является довольно молодой, а значит нужно просто посмотреть, как это уже реализовано у других) я попытался посмотреть на процесс выстраивания взаимоотношений с клиентом в других областях. И этой областью оказались гостиницы, как пример того, как весь процесс сосредоточен вокруг одного стремления – сделать пребывание гостя хорошим и комфортным. Но аналогии с гостиницей были слишком «далекими» поэтому я сделал небольшую ретроспективу развития процессов разработки ПО и нашел классный пример, на котором буду строить свои аналогии. Таким примером оказался процесс тестирования и его эволюция в ИТ отрасли. Именно благодаря этому примеру я смог показать, какое направление развития нас ждет в процессе взаимоотношений с Заказчиком.

Так как материал аналитический и претендует на долгосрочные прогнозы, то решил его опубликовать его на ресурсе украинских разработчиков: Developers.org.ua. После чего осознал, что только 35% читателей моего блога из Украины, а значит статью нужно повторить у себя. Исправляюсь:

Активный рост аутсорсинга в странах восточной Европы является сейчас одним из основных источников инвестиций в развитие IT отрасли в постсоветских странах. Приятно думать, что эта тенденция сохранится в дальнейшем и мы будем получать вложения еще долгие годы. Но мировая конкуренция будет вынуждать нас все больше улучшать качество «сервиса». Это когда код и продукт станут только одним из списка обязательных поставок для клиента.

Попробую привести аналогию из нашего IT-шного мира и в качестве наглядного примера выберу эволюцию процесса тестирования программного обеспечения.

Сейчас идет активный эволюционный процесс в понимании того, что такое тестирование программных продуктов и как оно должно происходить. Понятие «тестирование» расширилось и приобрело невероятное количество подвидов: функциональное, нефункциональное, регрессионное, тестирование надежности, нагрузочное тестирование и т.д. Но основным вектором развития тестирования, является интеграция тестирования во все этапы жизненного цикла разработки. Следствием этого является появление понятия «кросс-функциональных команд» (привет Agile методологиям), «white-box» тестирования (unit и integration тесты) и автоматизированные тесты.

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

Что же сейчас происходит в сфере взаимоотношений с Заказчиком? Как наша команда собирается выиграть конкурентную борьбу?

Давайте посмотрим на процессы, которые влияют на уровень предоставляемого сервиса в IT-компаниях. Для примера возьмем стандартную аутсорсинговую модель построения бизнеса:

Продажа услуг (занимается отдел продаж/маркетинг)

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

Контроль прибыльности проекта (занимается руководитель отдела/департамента или владелец)

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

Контроль реализации и реализация проекта (руководитель проекта и команда)

Данный процесс хорошо описан во всех книгах по управлению проектами, а также дополнен миллионами статей в блогах и новостях. Основной посыл: делайте все, чтобы команда сдала проект вовремя, в рамках бюджета и с нужным уровнем качества. При этом многие процессы (PMBoK, SCRUM, Lean) не описывают форму взаимодействия с Заказчиком. Они говорят (и то не все) «что» нужно делать, но никто не говорит «как» это делать.

Вот именно в последнем процессе происходит конфликт с предыдущими двумя. Руководитель проекта «отдувается» за завышенные ожидания клиента, которые поставили ребята из отдела продаж. Также он постоянно борется с руководителем отдела (собственником), который тянет краткосрочные показатели прибыли.

А так как руководитель проекта зачастую далеко не супермен, то единственной степенью свободы остается качество сервиса, который предоставляется Заказчику. Так и получается, что вроде как и продукт готов, вроде даже «перебороли» завышенные обещания, а Заказчик не доволен командой и уходит к другому подрядчику.

Возвращаемся к параллелям с развитием тестирования: процесс предоставления сервиса пока еще живет в мире Software development где-то на задворках. Есть разрозненные активности (работа маркетинга, «приступы любви» у Топ-менеджеров, ежедневное общение руководителя проекта и т.д.), которые, являются именно тем прообразом, который потом вырастет в большой процесс.

Даже учитывая, что я давно занимаюсь вопросом взаимоотношений с Заказчиками в ИТ и даже провожу эксперименты и опросы, я не знаю как будет выглядеть данный процесс. Но с другой стороны точно знаю, чего быть не должно:

  • Нельзя выносить отношения с Заказчиком в отдельную роль. Все люди команды должны быть в этом заинтересованы и система мотивации должна это поддерживать.
  • Нельзя изолировать Заказчика от проекта. Чем больше он знает и хочет знать, тем лучше с его точки зрения проходит работа.
  • Нельзя оставлять разные цели у людей, которые продают решения и их внедряют. Пока эти цели будут разными, одни будут пытаться продать с любыми оговорками, другие говорить о том, что задача нереальна.
  • Нельзя делать сервис по расписанию. Не получится поставить в календарь встречу «Сервис для Заказчика», которая сразу вознесет вашу компанию/команду на вершину сервисного Олимпа. Сервис – это «аналоговый» процесс и не может быть описан дискретными активностями.

Из примеров не-айтишного бизнеса ближе всего к систематизации процессов сервиса находятся Отели и Рестораны. Они ввели понятие «звезд», как классификации уровня ожиданий от сервиса, который они предоставляют.

И напоследок. Самое интересное состоит в том, что вопрос о возникновении процесса сервисного подхода стоит не в виде: «Нужен или нет?», а в виде вопроса «Когда конкурентная среда нас заставит это сделать?».

Принимаются идеи о том, каким будет этот процесс и насколько он изменит IT-шную жизнь :)

 

Mar 4th, 2011
  1. Techmind
    Mar 6th, 2011 at 06:38 | #1

    Так такие процессы, как ажайл и настроенны ж на постоянное взаимодействии и принесении пользы заказчику -сделали, часть функциональности, которая уже может принести заказчику пользу сейчас(профиты для него), выпустили, получили фидбэк, решили, что делать дальше(управление ожиданиями). Измерения счастливости и довольности заказчика, как части метрики проекта только не хватает.

  2. Mar 8th, 2011 at 22:20 | #2

    @ Techmind
    Аджайл (особенно Скрам) большой шаг вперед в процессе работы с Заказчиком. По крайней мере там точно _регламентировано_ время для общения с Заказчиком.
    Но, не хватает не только Метрики “довольности заказчика”. Скрам требует умелого заказчкика (Certified Product owner) и большой вклад со стороны этого человека. А это не всегда реально :(

Leave a comment