Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

Как добиться взаимопонимания с клиентом: 5 простых правил

Меня зовут Ольга, по призванию я Project Manager — влюблена в свое ремесло и всячески стремлюсь его совершенствовать. Как многие могли догадаться, большая часть моих задач так или иначе связана с коммуникациями, в том числе с клиентами. Будучи участником множества переговоров, начинаешь замечать паттерны, повторяющиеся ошибки, удачные/неудачные «комбинации».

Этот материал поможет разобраться, почему мы часто ведем себя определенным образом и к чему это может привести. Он даст базовое представление, чего стоит избегать в общении с заказчиками, а что стоит взять на вооружение. И будет полезен не только менеджерам, но и инженерам. Даже тем, кто пока напрямую с клиентами не пересекается.

Почему возникают проблемы

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

Во-первых, поди узнай, что взбредет в голову клиенту, какие вопросы он начнет задавать, и куда заведет вас разговор. Неопределенность ставит нас в неловкое положение.

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

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

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

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

Что делать? Можно, конечно, оставить все как есть. А можно взять на вооружение несколько правил/привычек, которые сильно упростят жизнь. Если тема покажется интересной, продолжим этот список в комментариях или отдельной статьей. Поехали.

1. Избегаем слова «невозможно»

Не употреблять слово «невозможно» — классика, об этом правиле слышали многие, если не все. И в его пользу можно привести множество аргументов.

Вопрос номер один: насколько мы уверены, что сделать предложенное действительно невозможно?

Мой коллега как-то делился кейсом. Пришел к ним клиент с несколько необычным запросом (упущу технические детали, они сейчас не так уж важны). Ребята сели, изучили, покрутили идею с разных сторон. И решили: «Сделать так, как вы хотите, не получится. Давайте мы предложим вам кое-что другое?». Клиент вежливо попросил паузу «на подумать». И через неделю вернулся с собственной технической командой, которая достаточно доходчиво и внятно объяснила, как реализовать задуманное. К счастью, сотрудничество на этом не закончилось. Но шансы на то, что дальнейшая работа не пойдет, были очень высокими. Понятно, что происходят такие истории нечасто, и тем не менее, оказаться в роли того, кому растолковывают способы исполнения идеи, от которой вы отказались, неприятно.

Вторая, более глубокая причина носит психологический характер. Представьте, что «невозможно» говорят вам. Вспомните ситуацию, когда вы не могли завести кота на съемной квартире или не могли получить желанную работу из-за недостатка опыта. Удовольствия мало, не правда ли?

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

Что делать

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

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

2. Не бросаемся на все, что пролетает мимо

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

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

Что делать

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

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

3. Помним о команде

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

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

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

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

Что делать

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

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

4. Разъясняем свои эстимейты

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

Я легко могу представить себе такой диалог:

— Как на что уходит время? На фичу, которую запросили.
— В идеальных человеко-часах или в реальных?
— Ну... В реальных. Наверное.
— То есть в них заложено время на стендап, обед или кофе? Хорошо! А клиенту сказали, что это время исключительно на разработку и что потом тестировщику еще предстоит проверить фичу, что возможен багфикс или расширение фазы стабилизации?
— ...

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

Что делать

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

Если вы сомневаетесь, боитесь напутать или сказать лишнее, отвечайте прямо: «Мне нужно проконсультироваться с тимлидом/командой, скоро вернусь». После этого нужно и правда не тянуть, а сразу отправиться уточнять детали. К слову, лучше такие запросы сразу отправлять в общий чат или рассылку, не дожидаясь, когда онлайн появится именно тот, кого вы думали спросить.

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

Я, конечно, не удивлюсь, если вы и так все это знаете. Но если вы этим правилам еще и следуете, низкий вам поклон и воздушная пятерочка!

5. Поддерживаем уровень

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

Приведу пару примеров:

  1. Проект закончился, у клиента остался ваш контакт (или именно на ваш он наткнулся в поисках). Он пишет вам письмо, а в ответ — тишина. Вам уже неинтересно, вы заняты и, может быть, даже перекинули письмо проджект-менеджеру. Кто же знал, что он в отпуске или на больничном. Но в итоге заказчика проигнорировали. Я даже слышала, что некоторые разработчики просто блокируют стейкхолдеров по окончанию работ, чтобы их в будущем никто не смог побеспокоить. «Работа выполнена, проект сдан, по всем вопросам к нашему менеджменту!»
  2. Проект непостоянный, либо лично вы вовлечены в него частично. Время от времени выполняете запросы и поручения, не вникая в мотивы клиента и особенности его бизнеса. Соответственно, выбираете самый быстрый и простой способ решения. Вносите правки строго по ТЗ, не задумываясь о будущем, и потребностях проекта. Наконец, когда клиенту понадобится помощь в подготовке промоакции, вы вспомните, что инициатива наказуема, и не станете спрашивать, выдержит ли система клиента возросшую нагрузку.
  3. И в полноценном проекте при полной загрузке можно игнорировать просьбы заказчика, самостоятельно выбирая точки приложения усилий. Или просто отвечать на любой вопрос односложно — да, нет, может быть. В конце концов он к нам за решением пришел? Сами и разберемся, что делать сейчас, все остальное подождет.

Что делать

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

Выводы

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

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

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

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

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

LinkedIn

49 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Дякую за файні поради)

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

карочи там оказывается есть продолжение ))

youtu.be/mokllJ_Sz_g

ЗЫ: если вы думаете что это только доля шутки там... ))

Да плевать. У таких манагеров всегда есть возможность сделать самим то, что им в бошку ебнуло.

С пунктом 1 ( про impossible ) все далеко не так однозначно. Не редко бывает что приходит клиент и ставит некую задачу. Тим лид или команда садятся и начинают Брейн шторм. И по ходу дела оказывается что в постановке задачи есть противоречия. Или что у каких-то штук есть зависимости и нельзя просто так взять и подкрутить чтобы обе были с некоторыми характеристиками , а можно только 1. Или что некоторые вещи в принципе невозможны в неких условиях (используем не real time OS, а хотим строгие гарантии по времени отклика)
На этой все лид /дев прямо скажет impossible.
А потом к клиенту приходит кучка менее компетентных девов, и гордо объявляют неработающую штуку работающей. И клиент им верит, потому что ему очень хочется верить. А проверить он не может....

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

Одной из причин подобного поведения является давление со стороны. Например, «Петя, нам очень нужен этот проект! Неужели действительно нельзя сделать как просят? Придумай что-то!». Вторая причина, халатность и безнаказанность. Мол «могу говорить, что хочу, все равно никто мне слова не скажет. И вообще этот проект не я пилить буду (メ ̄▽ ̄)». Третья, неопытность либо нехватка времени на полноценное изучение и анализ. Итог в общем-то один и тот же.

Как правило, клиенту нужно решить какую-то бизнес-задачу. Если ее невозможно решить в текущем стеке/технологии/ограничениях/whatever, об этом конечно нужно говорить. Но оптимально предлагать альтернативы и исследовать, чего хочет достичь клиент. Очень часто клиент озвучивает часть решения, которое он придумал в голове (и которое может вести к ответу impossible технически), а по факту его задача может быть успешно решена совсем другими средствами (ну или за другие деньги, тоже бывает =))

(ну или за другие деньги, тоже бывает =))

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

ЗЫ: как видно в прецеденте с боингом и индусами такой «правильный ответ» вполне себе находим в современных условиях глобализации и урбанизации и компьютеризации ))

Оттого что вы расскажете клиенту, что текущий стек технологий/языки/либки/фреймворки не способны решить ту задачу, которую поставили — ничего особо не поменяется.
Не редкость когда выбор фреймворка это что-то вроде ’ а у наших конкурентов именно этот фреймворк, мы его тоже возьмём’.
И никакие аргументы не работают.
Более того, если спросить напрямую а почему выбрали именно этот тул — то это вгоняет клиента в ступор. Это мы ещё даже не начали говорить про критерии выбора.
Кстати, менее компетентных левов никто не отменял. Они все ещё придут и объявят неработающую штуку работающей.
Иногда в роли таких девов сам клиент. И тогда вообще зашибись

Хм, я имела в виду, что важно не только объяснить клиенту, почему нельзя что-то сделать в заданных рамках, а еще и предложить варианты решения ситуации. А в идеале — раскопать, какую именно бизнес ценность он хочет получить, и поискать другие альтернативы) Это все часто лежит за пределами чисто технического анализа, и может давать неожиданные результаты :) это не отменяет ситуаций, где «клиент хочет на луну за 5 минут» ©, но бывает полезно докопаться, а реально ли ему надо на ту луну за 5 минут, и для чего, что он получит по итогу, и можно ли это желаемое получить другим путем)) может он на девушку впечатление хочет произвести, и ему хватит большим телескопом затариться xD
PS а вот ситуации, где неработающее объявляют работающим — это вообще жесть, и конечно это не ок))

Ну, во-первых донести что ’такой-то тул не подходит для решения такой-то задачи’ это уже сложно. Во-вторых, вариант с накидать на коленке альтернативу вообще-то не работает. И это даже хуже чем рандомный выбор кастомера.
Потому что для начала надо сформулировать задачу (ее как правило нет сформулированной на этом этапе).
Потом определиться с критериями выбора тулов/фреймворков/языков/технологий. Это уже долго. А потом надо ещё и проевальюировать пол рынка, чтобы найти хотя бы первый годный тул.
На коленке такое не делается. Штатного времени на такое тоже как правило не дают.
А вариант предложить на коленке альтернативу — он местами хуже варианта кастомера. Как минимум потому что ,на свой собственный вариант кастомер уже был согласен

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

... ну либо продавать этот выбор и помощь к нему почасово по $400 в час не считая командировочных ))

Ту надо ставить вопрос ’кто принимает решения и насколько принимающий решения компетентен ?’ можно ещё добавить ’кто будет нести ответственность’. Если расклады таковы, что решения принимает клиент, при этом он не компетентен в области, но платит деньги и несёт ответственность, то все вопросы отпадают. Нет смысла ему что-либо объяснять про ’неработающие штуки’.
А вот если часть ответственности на исполнителях, то тут все сложно. Тут или предлагать только заранее годные варианты, и так чтобы клиент выбирал только из них. Самодеятельность не позволять. Ну или сразу оговаривать — на ком ответственность тот и принимает решения

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

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

Не стоит отказываться от каких-либо действий убедив себя заведомо в «не разрешат» и «не получится» =)

лучше бы он их знать не знал

А что изменится если пытаться что-то объяснять клиенту? Експертизы у него как не было так и нет. Проверить ваши слова он не может. решения принимает все ещё клиент. И он все ещё хочет верить в то что хочет верить.

Не стоит отказываться от каких-либо действий убедив себя заведомо в «не разрешат» и «не получится» =)

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

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

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

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

т.е. вы конечно всё это рассказываете это всё и правда хорошо это всё и правда правильно но есть нюанс... ))

если бы б так всё было хорошо и правильно то и вопрос бы б не стоял.

ЗЫ: ладно бы б это работало бы б скажем «в отечественных условиях галерных обыкновенных» или там «наша советская коррупция» или там «низкий EQ у наших советских инженеров» так ведь ролик про красные линии снят даже не нами не «нашими» ))

ЗЫ: плюс некоторые общемировые тенденции «we like nice people not smart» и как результат маемо тэ що маемо (к) (тм)

ЗЫ: последнее например актуально вообще как никогда вот только что видел вакансию где-то в соц.сетях мол удалённая работа какой-то так бэкэнд процесс «найма» предполагает

1. полтора часа интервью с менеджером
2. 5 дней тестового задания
3. час интервью с командой
4. финишальный 1 день (один день) онсайт для... х.з. для чего я честно не догоняю зачем вот это всё если нужен бэкэнд программист который будет просто писать код )) или непросто и код не главное? ага ага ))

Ну ты ж понимаешь, сейлзы продали невозможное, а вы крутитесь

Хочется обратить ваше внимание — речь не идет о потакании прихотям (луна, 5 коп и тд). Мы четко понимаем, что мы можем и за что готовы взяться, и открыто говорим об этом с клиентами. Если нам не по пути, набираемся мужества и озвучиваем это, объясняем на каких условиях готовы сотрудничать, какие следующие шаги.

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

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

Вот так корректнее, а не что ты выше написала.

Выше писала «Не бросаемся на все, что пролетает мимо».
Рада, что коммент помог расставить все на свои места :)

Можно было еще добавить в стаю элементы оценки адеватности клиента.

Если клиент адекватный, то с ни в самом деле нужно обсуждать, что можно сделать и в какие сроки и за какие деньги. И клиент будет сам участвовать и корректировать свои хотелки.

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

Нет ничего невозможного — главный вопрос в цене

Завтра на Луну хочу слетать и обратно через 30 мин после прилета и гулять там без скафандра. Сколько?

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

Да ладно, мы его пихнем в анабиоз а потом разморозим взад

Это был мой 1000 комментарий

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

Полтора миллиарда долларов, если желаете остаться живым после прогулки — еще четыре сверху на установку павильона с кислородно-гелиевой смесью.

Согласен. Но если завтра не вылетаю неустойка 15.

Пять неразменных купюр по сто баксов

включить некоторые изменения в спринт/релиз вне плана

Кхгм... Это вы небось называете скрамом?

Обратите внимание на историю. Там сам тимлид явно не соот. своей должности. Умение говорить нет — одно из необходимых качеств людей.
а там — тим лид начал свое время бесплатно дарить заказчику.

Та то другой вопрос и как раз об этом пишет автор. Но! упоминается артефакт скрама «спринт» и тут же говорится что в него вносят изменения. Но все это мы называем скрамом. А потом все плюются от таких методологий. Да, и ТЛ тоже как то к скарму не имеет отношения.

По пунткам:
1. Когда украинский разработчик говорит «it is impossible to implement» в 99% случаев это означает «мы не знаем как возможно это сделать» или «мы не хотим это делать, потому что считаем это неправильным», «мы считаем это затратным реализовать, и потому считаетм что не стоит идти этим путем».
Просто это не проблема заказчика разбираться в хитросплетениях «славянской души». Один разберется и просто перестанет серьезно относится к таким заявлениям, другой свернет сотрудничество из-за «слишком негативной команды».
2. Я правильно вас понял? Вы что предлагаете украинскому аутсорсу быть честным с клиентом? Может еще предложите перестать продавать вчерашних студентов как синьоров?
3. Ух ты ж блин, оказывается не все клиенты эльфы! Есть и редиски, довели тимлида-то как!
4. А вот и источник всех проблем. Стендап, кофе и обед. А ДОУ? А котики в интернете? А пинг-понг столы вы для кого ставили? ЗА ВСЕ ЭТО ПУСТЬ ПЛАТИТ КЛИЕНТ!
5. Ну это уже слишком! ВЫ еще хотите чтобы все хорошо делали свою работу, чтоли?

общение с отечественным заказчиком:

— я хочу нейросеть чтобы распознавать эмоции людей на камеру. это же big data? вот 100 баксов.

Умножай на 1000 и будет.

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

Ну не 100 баксов, но прикрутить решение от MS не так уж и дорого
docs.microsoft.com/...​vices/emotion-recognition

А с оплатой сервиса от MS клиент пусть разбирается сам. За винду же на компьютерах платит.

Хочу завтра слетать на Луну за 5 копеек. Как будешь работать с таким клиентом?

Да в ML таких клиентов море.

Якщо фріланс, то пускати мимо таких клієнтів, якщо контора, то перенаправляти таку розмову на менеджера, а якщо ти менеджер, то маєш бути підготовлений до таких питань.

Это был вопрос опытной в таких делах ТС.
Я же клоунов подобных просто отпраляю на хутор за бабочками.

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

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

Про уеб я и не пишу. Там возможно можно удовлетворить любые хотелки клиента.

любые хотелки клиента.

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

простите, тупой вопрос: а как эти люди называются? Эти самые «ПМ»?

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

К примеру, приходит к вам человек и говорит, что ему нужен сайт, чтобы американцы покупали. Что делать будете?

Да в ML таких клиентов море.

Так, це правда.

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