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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU