Сегодня я расскажу о том, как устроен консалтинг в IT на примере Big Data, поделюсь личным опытом, как я попала в эту сферу, и кейсами из практики, а также дам совет, кому и зачем стоит пробовать себя в консалтинге.
Я закончила мехмат Харьковского национального университета имени В.Н. Каразина, попала в DataArt на позицию Java Trainee и проработала там следующие 6 лет. Карьера моя развивалась быстро за счет того, что вместе сошлись любовь решать сложные головоломки, мое врожденное желание учиться, постоянно находить для себя что-то новое и команда мега-профессионалов. Однажды меня привлекли на внутренний IoT проект, где мы вместе с другими энтузиастами разбирались в том, как подключать сенсоры к микроконтроллеру, где хранить (а главное, нужно ли?) этот огромный объем данных, как его потом обрабатывать, как в режиме реального времени отслеживать состояние системы, предсказывать поломки, где и как все это хостить и т.д. Так мы очень быстро пришли к вопросам и задачам BigData.
Это дало сильный толчок в моем развитии и позволило поработать в 15+ IoT and BigData проектах, регулярно участвовать в pre-sales, выступать на конференциях и с образовательными курсами. Позиция моя за это время поменялась с Senior Developer на Big Data Architect. По началу было интересно, но со временем это превратилось для меня в рутину. В большинстве случаев я заходила на проект, первые месяц-два было очень активно, я налаживала процессы, коммуникацию с клиентом и продумывала архитектуру, а после этого становилась в одном лице тех. лидом, ПМом, бизнес-аналитиком и еще много кем)) Через полгода это все превращалось в бесконечный день сурка.
Поэтому в поисках нового опыта и новых челенджей я перешла в SoftServe. Спустя почти год я могу поделиться своим опытом и видением того, как тут все устроено.
Для начала давайте рассмотрим, как устроен процесс консалтинга. Ведь большинство IT-шников привлекается к проекту, когда уже есть контракт, бюджет, менеджер и относительно понятно, что, когда и какой командой нужно делать. Мало кто задается вопросом, как новые проекты в принципе попадают в компанию и что с ним происходит на начальном этапе.
На самом же деле в жизни каждого проекта можно выделить такие фазы:
- Presales
- Discovery
- PoC/MVP
- Implementation
- Support
Discovery фаза – это и есть тот самый консалтинг, ради которого мы все здесь собрались. Как только подписывается контракт, кто-то из consulting группы едет к клиенту. В идеале к нему присоединяются бизнес-аналитик с UX дизайнером (заинтересованным в вопросах методологии советую почитать про Design Thinking подход, эффективность которого я уже не раз испытала на собственной практике). В идеальном идеале едет еще и engagement manager, который берет на себя все вопросы организации процесса, и узкопрофильный специалист.
- Onsite – в режиме реальной коммуникации с клиентом собираем как можно больше информации;
- Offsite – вместе с командой анализируем все, что удалось накопать, дизайним систему, прописываем риски и план реализации.
На выходе эта группа предоставляет клиенту документ, который содержит:
- Высокоуровневое описание текущего состояния системы;
- Сценарии использования будущего продукта;
- Приоритезированные архитектурные и бизнес драйвера;
- Требования по объему данных, скорости их обработки, допустимой задержке;
- Архитектурное видение, отражающее все предыдущие требования;
- Выбранный стек технологий (выбор которых базируется на trade-off анализе возможных вариантов имплементации в разрезе на требования к системе);
- Эстимейты и беклог (список задач) на следующую вазу, план разработки;
- Риски и возможные способы их избежать.
Если все складывается удачно и клиент подписывает следующую фазу, то архитектор какое-то время (чаще всего part-time) работает на этом проекте. До тех пор, пока процесс не будет налажен, скоуп работы понятен, а клиент доволен. Если и тут все довольны и хотят продолжать сотрудничество, далее следуют Proof of Concept(PoC), Minimum Viable Product(MVP) и дальнейшие Implementation и Support.
Казалось бы, весь этот процесс – четкий, структурированный и понятный. Но на практике все не так просто. Давайте рассмотрим возможные сценарии.
Вот к нам приходит потенциальный клиент. Команда, которая занимается продажами, проводит первые звонки/митинги, чтобы понять, какого рода проблему нужно решить, и обращается к более узким специалистам. Если проект требует знания Big Data-стека, то потенциальный клиент заходит ко мне в группу.
Следующий шаг – понять уровень сложности задачи и определить, какие эксперты нужны. Тут есть несколько вариантов.
Клиент совсем не знает, чего он хочет
Чаще всего это бывает у больших и взрослых энтерпрайз компаний, которые понимают, что теряют деньги, но не понимают почему. Либо же понимают, но совершенно не представляют, как это можно исправить.
Из своего опыта могу сказать, что зачастую в такой ситуации нужно сначала решать проблемы бизнеса, и только потом технологий. Нужно быть готовыми к тому, что это непросто и могут появиться заинтересованные лица, которые попытаются втянуть вас в свои политические игры.
Например, один из CTO, с которыми мне повезло быть знакомой, привел меня однажды на стратегический митинг по обсуждению покупки лицензии на один популярный продукт. Официальной причиной моего появления было просто знакомство. Борд директоров был в восторге от предстоящей сделки и пел дифирамбы своим будущим партнерам. Будучи человеком честным и думающим, я задала пару более предметных вопросов о том, как они собираются интегрироваться. Ответа не последовало, а сделку отменили. Выходя из зала совещания, я спросила у того самого CTO, не перегнула ли я палку со своими вопросами и стоило ли мне вообще во все это лезть. На что «тайный кардинал» ответил: «Все супер, я тебя за этим туда и привел».
Как этого избежать? Никак, это и есть консалтинг. Надо быть к этому готовым, в чем лично мне помогают знание психологии, более опытные коллеги и личный опыт, конечно же.
У клиента есть видение конечного продукта, но ему нужна наша экспертиза, чтобы убедиться в своей правоте
Наверное, самый выгодный вариант с точки зрения временных затрат. Намного меньше усилий будет тратиться на поиск проблемы, намного продуктивнее пройдет общение с заказчиком, для которого ваше мнение все еще авторитетно.
Однако и тут бывают подводные камни. Для одного из наших клиентов в финансовой сфере Discovery фаза была рассчитана на 4 недели, по 2 недели на onsite и offsite. Клиент за 2 недели онсайта ни словом не обмолвился о том, что у него уже есть свое собственное видение архитектуры. Было обсуждение каких-то концептуальных вещей, но ни разу не было разговора про стек технологий. И вот в середине 4ой недели проекта, когда мы уже наработали тонну материала, собрали, приоритезировали и отразили в конечном решении основные требования, во время презентации архитектуры клиент начинает возмущаться и говорить о том, что мы его не услышали. Оказалось, что наша задача была не столько придумать что-то новое, сколько угадать то, что уже было в голове у нашего главного стейкхолдера. Спасибо моему биг боссу, который был на том звонке и быстро сообразил, в какую сторону дует ветер. Пара ключевых слов и клиент снова доволен, а мы за оставшиеся дни полностью меняем концепцию, заново отражаем все требования и риски, но уже в согласованной с клиентом архитектуре.
Как избежать этого? Валидировать, валидировать и еще раз валидировать свои решения с клиентом, чем раньше и чаще, тем лучше. Лучше несколько раз проговорить по частям то, что все и так уже поняли, чем спустя 4 недели в первый раз показывать финальную архитектуру. Причем это касается не только архитектуры, но и подхода к Discovery в целом.
У клиента есть очень точное и детально описанное видение продукта, от вас ему нужно только исполнение
С одной стороны это удобно. Не нужно выяснять требования, возиться с документацией, ехать к клиенту, в конце концов. Бери и делай. Но зачастую так не получается. С первых дней становится понятно, что видение клиента далеко от идеала, поскольку учтены далеко не все риски и требования, эстимейты явно занижены, а донести эту мысль крайне сложно, ведь клиент твердо уверен в своем решении.
Как вести себя в этой ситуации? Мое мнение – нужно изначально оценить прибыльность проекта в соотношении к ресурсам команды, которые на него нужно будет потратить. Ведь такие проекты не всегда приносят много профита, а сил на него потратить нужно очень много. Если все-таки решаем взять на себя этот коммитмент, я стараюсь донести клиенту мысль, что мы как опытные консультанты, которые реализовали множество проектов, стремимся использовать свой опыт, чтобы найти наиболее рациональное решение его проблемы, а не просто слепо реализовать предложенную идею. Также доношу, что обязательная часть нашей работы – это предупредить его о всех возможных рисках и при необходимости дать рекомендацию, как их избежать. То есть, нужно заработать авторитет и добиться того, что клиент начнет к вам прислушиваться.
Нужно всегда уметь слушать и слышать, как клиента, так и коллег по проекту. Ведь вызовы, с которыми мы сталкиваемся, часто носят нетехнический характер.
Резюмируя, могу сказать, что консалтинг – это для тех, кто не сидит на месте и не боится пробовать что-то новое. Если вы не первый год работаете на одном и том же проекте, работа вам наскучила, но страх что-то поменять не дает покоя – попробуйте взять на себя чуть больше ответственности. Заплатите за образовательный курс, придумайте и предложите клиенту оптимизацию, донесите до него ее ценность, продайте ее. Возьмитесь за что-то новое, выйдите из зоны комфорта. Вспомните, что плохого опыта не бывает и даже неудача несет в себе урок, а значит делает нас лучше. Если эксперимент будет удачным, то страх пропадет и вас наполнит гордость и желание двигаться дальше, сделать еще лучше и больше. В этот момент можно смело приходить к нам!
