Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




18 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

то, что вы меня назвали «недопсихологом», оставлю без комментариев.

Что касается всего вашего поста про будущее за универсалами, вы себе льстите.

К слову, налицо отсутствие каких бы то ни было навыков коммуникации — вам счастья с заказчиками, к сожалению, не видать.

Опыт говорит о том, что нужно быть профессионалом в своём деле, т. е. в чем-то одном, а не во всем понемногу. Т. е. заниматься чем-то одним. Программист — программировать, тестер — тестировать, аналитик — описывать требования, ПМ — управлять. Т. е. «завышенные ожидания» появляются как раз в командах, в которых бардак — «все занимаются всем», — из-за отсутствия процесса и понимания проектной деятельности (те же эстимейты), а также некоторых разработчиков, которые вдруг возомнили себя специалистами во всем. Если Вы аналитик, или ПМ, и при этом процесс обязывает Вас «кодить» — это ли не извращение? Когда-нибудь думали о том, зачем нужна команда проекта, если придет вот такой «универсал» -командос, и сделает всю работу? И кого Вы называете посредниками? Всех, кроме себя (простите, Гения)? Тут о какой-либо объективности говорить не приходится. Сама по себе команда разработчиков сегодня большой ценности не представляет, и создать серьезный продукт типа Windows уже не сможет.

В статье поднимается вопрос о том, что для работы с клиентом необходим новый уровень знаний и навыков. И знания эти нужно получать не на курсах/от ментора (хоть и это важно), как сегодня полагают многие «командосы», а в ВУЗах. О новом уровне сервиса для клиента можно говорить только тогда, когда мы перестанем рассматривать программиста, как специалиста во всем — сегодня почему-то это так. А те люди, которые могли бы решить эти проблемы, сегодня никому не нужны — их в IT просто не пускают, потому что «как же это они без 5 лет опыта программирования на джаве собираются управлять ожиданиями клиента? » — просто слов нет.

На правах стороннего наблюдателя:
Кросс-функциональность команды (когда все в курсе дела обо всем) — это сейчас тенденция развития. И это один из главных принципов Agile. В этом-то и сила Agile.
На правах автора статьи:
Да, вы абсолютно правы, что нужны новые подходы и процессы в области работы с Заказчиком. Будет ли это ментор или Вуз? — Не знаю. Должно произойти смена в сознании того, что мы не «кодим» абстактные классы, а делаем работу, которая нужна кому-то. И только благодаря этому «кому-то» у нас есть теплые места и вкусные бутерброды:)

Так «в курсе дела» и само «дело» это разные вещи.

Я в курсе того, как программировать на Java, и в курсе про blackbox testing, например. Но если я аналитик, и пытаюсь программировать вместо девелопера, — то это один из способов провалить проект. Теряется объективность. Тем более, если ПМ — в погоне за «всем» люди сегодня научились управлять джавой и дотнетом, но не рисками или ожиданиями. Т. е. от такой многостаночности профессионализм всегда в убытке.

Сергей, похоже, что вы в своей статье изначально взяли какой-то неудачно построенный тим, и, исходя из этого, делаете выводы.
Продажа услуг.
Маркетинг или сейлз никогда абстрактно не продает контракт. Другими словами, сразу после того, как заказчик отлавливается, выгружает свой поток подсознания, сейлзы сразу обращаются к технарям для упорядочения этого потока подсознания, облечения его в high level requirements и т. д. Другими словами, сейлз ничего не сможет продать (=получить контракт), не заполучив requirements (бывает дает заказчик, бывает — пишет тим) и главное — не заполучив от технических спецов эстимейта (и умножив его на 2 или на 3).
У вас этот момент упущен априори.

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

И что касается непосредственно цели статьи — сервис, предоставляемый заказчику. Здесь нет ничего сложного или невыполнимого, аутсорсинг как высококлассный сервис вполне достижим. Для этого надо всего несколько вещей:
1. Понять, что маркетинг/сейлзы — это не нелюди, продающие ваши души дьяволам заказчикам, а люди, достаточно неплохо разбирающиеся в технологиях и бизнес-анализе, чтобы понять, что именно хочет заказчик и спокойно объяснить техническим специалистам. Это психиатры сделки, осуществляющие коммуникацию с заказчиком на всех этапах развития проекта, достаточно дипломатичные, но, при этом, умеющие настоять на своем решении/предложении (=на предложении тима). Доступные для коммуникации в working hours заказчика, вне зависимости от его time zone.
2. Понять, что контроль прибыльности проекта — это всего лишь автоматизация учета производства, равно как и контроль реализации проекта.
3. Научиться грамотно составлять эстимейты (естественно в условиях ограниченной информации), далее правильно формировать план проекта и не лениться (не забывать) его постоянно апдейтить. И, естественно, через парламентария сейлза постоянно доводить суть и причины всех изменений до заказчика. Но это тоже все выполнимо — у нас ведь для этого есть опыт.
4. Поверить в то, что заказчик не монстр-детоед, а человек (или группа) людей с интересными (пусть даже не всегда реализуемыми) идеями, что они могут мыслить по-другому, и даже если это не вписывается в наше представление о жизни, они имеют право быть услышанными.
То есть сервис имеет 2 уровня — внутренний (профессиональный тим, качественно поставленный процесс производства и эффективная коммуникация внутри) и внешний уровень — умение слушать и слышать заказчика, способность его понимать, умение вести внешнюю коммуникацию на понятном для заказчика языке, всегда быть доступным для коммуникации.

В общем, ничего сложного:)

Надя,
Спасибо большое за интересный ответ. Просто пока реалии отечественного аутсорсинга явно недотягивают до того, что вы написали. Возьмем только главные «глаголы» из пунктов вашего комментария:
1. Понять...
2. Понять...
3. Научиться...
4 Поверить...
Очень хотел бы я увидеть реальную команду программистов, которые легко «верят» и «понимают».

Я сам работал «сейлзом» и знаю, как делаются сделки. И идеальный мир «взаимпонимания» и сотрдуничества недостижим, пока сейлы не будут отвечать за успешную реализацию (а не продажу) проекта.

По поводу уровней сервиса — тут я бы поспорил:). Сервис имеет 1 уровень — Команда осознает, что она делает сервис и все решения принимает исходя из этой предпосылки. И только тогда это будет проявляться как внутри команды, так и при общении с ЗАказчиком.

«При этом многие процессы (PMBoK, SCRUM... »
_____
PMBOK — это фреймворк
SCRUM — методология

процессы, например, унифицированные — RUP, Agile

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

Качественный сервис может обеспечить связка «знания — опыт». Это и знания в области управления ресурсами, и мотивации, и риск менеджмент. Т. е. в том случае, когда, например, менеджерами будут работать люди с образованием и опытом менеджера, а не «программисты-тестеры-на-все-руки-мастера», то и сервис будет выглядеть значительно лучше.

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

Я думаю, что если бы руководитель проекта занимался тем, чем должен заниматься руководитель проекта, то у него все бы получилось.

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

Но практика показывает, что даже такие команды теряют клиентов по многим причинам... думаю из опыта вы сами вспомните примеры.

К вопросу о тестировании как одноразовой активности: я, честно говоря, до сих пор удивляюсь, почему в отечественном аутсорсе так долго был (а кое-где и остается) популярен waterfall, причем в самой «мифической», кондовой своей ипостаси. Известный, наверное, каждому PMу Фредерик Брукс критиковал эту модель еще в 1995 м году.

К вопросу о предоставлении сервиса: ты все правильно пишешь с точки зрения ПРЕДЛОЖЕНИЯ, но вот меня не оставляют «смутные сомнения» на тему того, насколько велик в аутсорсинговом бизнесе СПРОС на разработку, как говорится, «soup to nuts». Уверен, слова «team extension» тебе знакомы так же хорошо, как и мне:)

К вопросу о взаимодействии с заказчиком: ну Agile как раз хотя бы пытается что-то предложить на эту тему, в частности «Все люди команды должны быть в этом заинтересованы» и «Нельзя изолировать Заказчика от проекта. Чем больше он знает и хочет знать, тем лучше с его точки зрения проходит работа» — очень даже в духе правильного аджайла.

К вопросу о пропасти между целями маркетинга и delivery: вот это, согласен, реальная проблема. С другой стороны, в нормальной (!) компании у delivery не так уж чтобы не было контроля за этим процессом — техническую часть пропозалов не маркетинг же пишет, а именно delivery. И пропозалы, опять-так, в нормальных компаниях, проходят тщательные technical review на уровне CTO / Development Director, чтобы не наобещать заказчику чего попало.

Ну и, в конце-концов, никто не запрещает delivery начать размахивать красным флагом и эскалировать проблему, как только они увидели, что маркетинг «напел» заказчику лишнего.

Дима, спасибо за комментарий. На примерах будет легче объяснять:)
1. Тестировани==пример. Пример превращения из «кондового процесса» в полноценный непрерывный процесс.
2. Agile мне очень нравиться хотя бы тем, что там эпизодически вспоминают про Заказчика и его нужды. Но системного процесса кроме концентрации на shippable code (который приносит value) — нет.

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

Придется писать отдельный дисклаймер.
Я очень люблю тестировщиков и уважаю их работу. Ребята, которые работают со мной в команде это могут потдвердить:)

Посто называется «... ЧТО НАС ЖДЕТ ДАЛЬШЕ? ». Я не претендую на экспертную оценку будущего процесса тестирования. Я высказываю свои мысли о будущем процессов общения с Заказчиками!

Я — тестировщик. Мои заказчики — разработчики.

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

В свою очередь разработчики предоставляют услуги по имплементированию фич нашему product owner. Иногда делают даже больше чем просили — прикручивают всякую красоту и вау-контролы. Чтоб и их клиент был доволен.

А R& D отдел предоставляет услуги маркетингу/продажам. А маркетинг/продажи — конечным потребителям.

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

Это прямо закон природы какой-то.

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

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

Про тестирование... неужели никто не учил V-образную модель тестирования, трассировку требований... не проходил роль тестирования в RUP и OpenUP. Как бы лет 15 уже прошло как все это было... короткая память однако у отечественного ИТ-специалиста — все старые знакомые вещи под новым соусом протягивают и особенно почему-то тестировщики активизировались, слава Панкратова спать спокойно не дает?:)

Не язвлю, просто за специальность обидно:)

По сути, я делаю акценат на развитии процесса тестирования из фаз проекта (детерминированных) в постоянный процесс. Вы же не станете спорить, что тестирование не всегда было системым процессом? 15 лет — не такая и большая история:)

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

И всю эту аналогию я привожу всего-лишь как прелюдию или образ того, каким есть и будет взаимоотношения с Заказчиком. Вот это и является сутью поста.

P.S. Слава Славы Панкратова (каламбур вышел) не является для меня беспокойством. Он мой хороший товарищ и нам с ним делить-то нечего:)

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

Хорошо, а сможете ли вы отверждать, что работа с Клиентами ВСЕГДА была в вашей команде?

Підписатись на коментарі