Почему мы не любим заказчиков (не умеем их готовить)

05.07.21

Управление проектом

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

Проблемы, которые возникают при работе с требованиями, чаще всего возникают из-за того, что вы себя сами заказчиком не воспринимаете.

Хотя – вы же ходите в кафе? Заказываете доставку чего-нибудь на дом? Делали ли когда-нибудь ремонт? Отвозили ли машину на СТО и т.д.? Это значит, что в своей ежедневной жизни вы наверняка выступаете заказчиками.

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

 

 

В видео показан пример того, как можно работать с заказчиком. Можете ли вы похвастаться таким же отношением к клиентам?

 

Проблема клиентоориентированности

 

Слайд3.JPG

 

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

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

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

 

Мы работаем на разных уровнях

 

Слайд4.JPG

 

Выясняется, что мы работаем на разных уровнях.

В первую очередь, мы пытаемся ответить для заказчика на вопрос «Что?»

Что необходимо сделать:

  • необходимо разработать определенную функциональность;

  • необходимо обучить пользователей;

  • необходимо внести изменения в систему и т.д.

После этого мы обсуждаем с заказчиком, как мы будем это делать – «Как?»

  • наш аналитик приедет к вам в офис;

  • мы будем обсуждать детали в формате телефонных разговоров

  • программисты будут делать какой-то объем своей работы,

  • потом тестировщики выполнят свою работу и т.д.

И только после всех этих действий мы начинаем выяснять корневую причину – «Почему?» – почему нам необходимо сделать именно это?

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

Очень важно разобраться на первоначальном этапе, почему же заказчику необходимо сделать ту или иную функциональность (будь то внедрение 1С, какой-то ERP-системы или простого сайта-визитки). Нужно понять – почему ему это нужно, что человек формирует.

Здесь можно использовать «идеологию луковицы», чтобы послойно подойти к корневым причинам:

  • только тогда, когда мы поймем, что движет заказчиком, когда он формирует свои требования, и ответив на вопрос «Почему»,

  • мы сможем предположить, «Как» именно мы будем эту задачу решать,

  • и уже после этого мы сможем понять, «Что» предложить.

Зачастую мы решаем задачи наших заказчиков по теории молотка: «Если у вас в руках молоток, значит всё вокруг – это гвозди», и предлагаем те решения, в которых мы уверены, или которые мы умеем делать. При этом вполне возможно, что заказчику нет необходимости в том количестве функциональности, которую мы хотим ему предложить, либо мы предлагаем ему ту картину мира, которая ему не подходит.

 

Портрет заказчика

 

Слайд5.JPG

 

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

  • Культура заказчика. Имеется в виду не персональная (хотя это тоже очень важный элемент), а корпоративная культура – в какой компании он работает.

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

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

Второй слой – личностный. Требования заказчика зависят от того, какой у него:

  • Жизненный опыт

  • Экономическое состояние

  • Образ жизни

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

Для людей с опытом, которые уже понимают, что если все сделать очень быстро, то вполне возможно, это серьезно отразится на качестве, то уже с высоты этого жизненного опыта они понимают, что лучше не спешить, а сделать сейчас одну-две-три функции, но 100%-работающие. С такими людьми мы уже обсуждаем требования гораздо более подробно. Мы готовы останавливаться при первом же возникшем вопросе – давайте здесь мы копнем глубже. Когда мы работаем с людьми на личностном уровне и понимаем психологию их опыта и образа жизни, мы можем уже задавать другие вопросы

И третий уровень – это уже глубинные личностные ценности:

  • Общение – как человек коммуницирует с миром;

  • Способ познания – как человек познает мир;

  • Восприятие – как человек воспринимает информацию;

  • Поведение – какие шаблоны поведения уже замечаются вами и вашей командой;

  • Мотивация – что человека мотивирует

Если человек хочет, чтобы у него была система, как у конкурентов, только потому, что она есть у конкурентов, то, скорее всего, он в своих требованиях будет мотивирован только тем, что: «Мне надо, чтобы было лучше, чем у конкретных конкурентов».

Такого рода заказчики очень часто приводят в пример некоторые сайты или системы: «Смотрите, как, сделайте мне, чтобы было лучше».

И вы уже понимаете, что работая с таким заказчиком необходимо задавать более личностные вопросы: «Что именно позволит нам здесь победить конкурента?»

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

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

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

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

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

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

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

 

Любите своих заказчиков!

 

 

… иначе их полюбят другие!

 

Слайд7.JPG

 

Любите своих заказчиков, иначе их полюбят другие!

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

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Инструментарий руководителя проекта".

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Гибкая разработка 1С:Бухгалтерии

Agile Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    2349    0    user1853337    8    

22

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2930    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14525    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5934    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4864    0    andironenko    2    

31

Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

Компетенции и навыки РП Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5477    0    MariaTemchina    28    

22

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

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

27.12.2022    2821    0    MariaTemchina    28    

24

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4306    0    user1576201    10    

17
Оставьте свое сообщение