Архитектор vs Пресейл

В одной ИТ-консалтинговой компании принят такой подход к организации работы с заказчиком: выделена специальная группа специалистов для предконтрактной работы с клиентом. В нее набираются специалисты  высокого уровня, способные разработать архитектуру предлагаемого ИТ-решения в соответствии с требованиями клиента. Эдакий эскизный проект, который затем войдет в технико-коммерческое предложение (ТКП) клиенту. Такую группу специалистов компания называет пресейлом, а самих людей - пресейл-менеджерами. 
При  этом подходе предконтрактная работа завершается подписанием договора с клиентом, и зона ответственности пресейл-менеджера заканчивается. В сухом остатке имеем архитектора, разработавшего некое ИТ-решение на основе "быстрых" данных клиента и своего опыта предыдущих проектов. Далее это ИТ-решение передается на реализацию, а архитектор привлекается только как консультант. 

Самый очевидный недостаток этой схемы: архитектор решения работает вне команды проекта. Более того, передав архитектуру исполнителям, он больше не влияет на результат проекта. Строго говоря, архитектор в данном случае заинтересован только в "получении" проекта (в согласии клиента подставить подпись под договором), но никак не в правильном решении.  

 А должен ли архитектор быть заинтересованным в Результате проекта? И правильно ли ставить архитектора на роль пресейл-менеджера?

Разберемся с терминологией. Для определения роли пресейл-менеджера придется обратиться к англоязычным источникам, поскольку сам термин нам как бы намекает. И тут оказывается, что в англоязычной литературе нет понятия presale manager, но есть понятие Sales Engineering.  Здесь узнаем, что сэйлз-инжиниринг - это гибрид инжиниринга и продаж, обеспечивающий клиентам производителя продуктов (вендора) техническую поддержку этих самых продуктов от дистрибьютора, или провайдеров услуг. Здесь же читаем: "цель [работы сэйл-инженера] заключается в оказании помощи потенциальным клиентам понять, сравнить и сопоставить  выбранные решения (роль пресейла); устранить проблемы с их  реализацией, то есть, как только было принято решение о покупке, помочь убедиться, что решения успешно работают (роль постсейла)" (перевод вольный, передана суть).

Таким образом, пресейл – это инженер, имеющий достаточно знаний и опыта работы с разными линейками вендоров (ПО, либо оборудования) по какому-то конкретному направлению (сетевая инфраструктура, серверное оборудование, системы анализа данных и поддержки принятия решений), способный выявить и адекватно оценить проблему клиента и ПРЕДЛОЖИТЬ ВАРИАНТЫ РЕШЕНИЙ. Типовые готовые варианты. Не разработка. И уж тем более не проектирование архитектуры решения.

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

Отсюда делаем вывод, что архитектор может выступать в роли пресейл-менеджера, будучи специалистом, владеющим конкретными технологиями и способным объяснить другим, как применить эти технологии для решения конкретных задач. Но пресейл-менеджер с ролью архитектора вряд ли справится.

Вернемся к нашей компании и предположим, что худшее все-таки произошло:  в группе специалистов по предконтрактной работе собраны архитекторы ИТ-решений разного уровня сложности. Этап пресейла завершен, архитектура ИТ-решения создана и включена в ТКП, заказчик подписал договор. Архитектура "передана на реализацию". Далее архитектор участвует в процессе только в качестве консультанта.

Здесь может быть два варианта развития событий:

1. В команде реализаторов есть «свой» архитектор. Его работа начинается во время фазы сбора и формализации требований к проекту. По ходу выясняется, что существующая архитектура требует доработки, а то и кардинального изменения, поскольку появились новые заинтересованные лица со своими требованиями, либо старые требования значительно изменились – условий масса. И архитектор принимает решение отправить старую архитектуру в корзину и начинает все заново. При этом неизбежно увеличение сроков и стоимости проекта (ночной кошмар PM'а). И  хорошо, если соответствующий риск  был просчитан заранее, и есть соломенная подстилочка.  
2. В команде реализаторов нет архитектора (все остались на пресейле). Некому следить за тем, что разработчики в своих решениях соблюдут все принципы (или хотя бы один). Некому контролировать соответствие разработанного решения модели требований. У архитектора роль только консультанта. А кто же из команды к нему обратится за консультацией? Только тот, кто задастся вопросом: может быть нужно что-то поправить в архитектуре? ведь заказчик сегодня озвучил, что "эта штука обязательно должна летать"....  И в отсутствии контроля целостности всей разрабатываемой системы  высока вероятность испытать всю мощь ярости заказчика, когда он получит подводную лодку вместо космического корабля.

Получается, что архитектор должен быть частью команды. Более того, архитектором должен быть человек, который пользуется уважением в команде, и способен решать возникающие по ходу работы проблемы. Эту роль в комплексных  интеграционных ИТ-проектах трудно переоценить. Все-таки архитектура – это область высокого риска.

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