Я младший программист. Поскольку мой руководитель сказал мне сесть за клиента, я присоединился. Я видел неудовлетворенное лицо клиента, несмотря на успешную (с моей точки зрения программиста) доставку проекта!
Клиент: Вы могли бы включить это!
Нас: Не указано в спецификации!
Клиент: Общий смысл!
Как программист, как вы реагируете в этой ситуации?
Что вы должны сделать, чтобы избежать этой ситуации:
Четко укажите, что будет включено и что не будет включено.
Проблема, вероятно, сводится к неопределенным частям спецификации:
Для будущих спецификаций, которые у вас есть, вы должны иметь инструкцию catch, которая явно заявляет, что если что-то не указано в этом документе, это может быть сделано после того, как исходная спецификация будет выполнена за дополнительную плату.
Что вы должны делать в текущей ситуации:
Помимо изучения вашего опыта, вы должны прийти к компромиссу с клиентом.
Пример: я сделаю эту функцию, которая, по вашему мнению, является здравым смыслом, но для всех будущих дополнений/изменений она должна быть явно указана.
т.е. вам нужно будет немного поработать, но стоит взамен поймать все явно указанное соглашение, в которое войдет ваш клиент.
Плохая спецификация?
Неужели это была плохая спецификация? Нет.
Невозможно упомянуть все, что могут ожидать ваши клиенты, поэтому крайне важно, чтобы эта уловка, упомянутая выше, была четко и четко указана в вашем spec/contract.
Другие способы устранения проблемы:
Это было бы одной из многих причин, по которым я переключился на философию Agile development. Единственный способ, на мой взгляд, успешно избежать этого сценария - либо быть всеведущим, либо привлекать клиента в значительной степени и выпускать ранний/выпуск часто, чтобы получить обратную связь как можно скорее. Таким образом, вы можете разработать программное обеспечение, которое действительно хочет клиент, а не программное обеспечение, которое клиент говорит вам об этом.
Клиент: Вы могли бы включить это!
Нас: Не указано в спецификации!
Клиент: Здравый смысл!!
Нас: Мы не пытаемся выйти за пределы того, что указал клиент, - мы следуем спецификации. Это важно, чтобы НЕ реализовывать функции, которые не указаны, так как они предназначены для реализации указанных функций. Мы никогда не будем догадываться о наших клиентах, которые ценят тот факт, что они могут полностью зависеть от нас, чтобы правильно и полностью реализовать спецификацию вовремя и в рамках бюджета.
Как справедливо отмечают другие, ситуация почти всегда сложнее, чем простой обмен, описанный выше.
Однако вышеизложенное справедливо, если у разработчика есть спецификация с подписью клиента на нем, которая в основном реализует соглашение, в котором говорится: "как только программное обеспечение докажет, что все функции в спецификации будут считаться завершенными", и все, что угодно за пределами спецификации и, следовательно, вне договора.
Сам контракт может иметь некоторый вклад здесь - если у вас нет подписанного контракта, чем это не имеет значения, что в спецификации - все до сих пор было сделано в рукопожатии, а вся сделка (включая оплата) может спуститься в туалет на основе любого недовольства с обеих сторон.
Но если у вас есть контракт и спецификация, и клиент увидел и подписал оба, то у них нет комнаты для отговорок, чтобы попросить вас пойти дальше.
Теперь, что касается вопроса о том, следует ли вам его реализовать:
УДИВИТЕЛЬНЫЙ! Вы доставили продукт, и у них была только одна жалоба. Внесите эту функцию, назовите ее "халява" (убедитесь, что они понимают, что вы работаете за пределами спецификации и контракта и явно отправляете им счет за работу со скидкой, показанной в долларах) и попросите их подписаться на проект в целом.
Это явно продемонстрирует, что проект окончен, что вы пошли выше и не по вызову, и что любые дальнейшие "сюрпризы" находятся за пределами контракта/спецификации, что дает вам хороший уровень защиты, помимо того, что вы уже (якобы).
Если это проблема с пользовательским интерфейсом, то вы находитесь в более мрачной воде.
Является ли спецификация адекватным описанием пользовательского интерфейса? У него есть макеты? Я бы не стал винить клиента за эту жалобу в отношении пользовательского интерфейса, если спецификация не очень подробно описывает макет, использование и включает макеты.
В любом случае, я думаю, вы можете понять позицию клиента - если они не играли с макетами UI, тогда они будут разочарованы результатом независимо от того, нет ли психологически, что вы и ваш клиент возможно, имел в виду ту же идею (неважно, что здравого смысла нет!).
Совершенно откровенно, если это первый раз, когда клиент задумался о проверке пользовательского интерфейса до завершения работы, то это по крайней мере частично ваша ошибка, не объясняя им хорошие процессы проектирования пользовательского интерфейса. Это ключевая функция для их приложения, и она очень тесно связана с тем, что они себе представляли - никто не может быть удовлетворен в такой ситуации, если они не "выросли" с их внутренним представлением с течением времени, чтобы соответствовать реальности.
Это разъединение разрешается только посредством частых пользовательских и клиентских проверок, чего явно не хватает. Это проблема, связанная с обучением и связью клиентов, а не с выполнением спецификации или нет.
-Adam
Ожидайте изменения сферы действия в последнюю минуту - они всегда бывают, поэтому будьте готовы.
Часто просматривайте прогресс с клиентом - чтобы свести к минимуму неожиданности.
Контракт: функциональная спецификация, плюс время и материалы с начальной крышкой (поэтому клиент чувствует контроль). Затем, когда происходят изменения, переустановите колпачок, если необходимо.
Никогда говорят, что у них не может быть того, чего они хотят. Они могут получить этот ответ бесплатно!
Всегда дают им немного больше, чем они просили, поэтому они знают, что у вас есть позитивное отношение.
Относитесь к клиенту как к одной команде с ними. Не соглашайтесь с тем, чтобы легалистически расписываться как противник.
Они могут думать о том, что подрядчики не являются лояльными по сравнению с сотрудниками. Покажите им, что вы так же преданы своему успеху, как и их сотрудники, и вы пройдете лишнюю милю.
Классический случай...
Там нет определенного ответа на этот вопрос, но все это обходит общение. Должны были быть приняты превентивные меры (например, еженедельные обзоры или что-то в этом роде).
Конечно, вы не можете полностью переделать все это.
Два способа: или сказать им, чтобы они выключились или вы справились с этим.
Если вы решите иметь дело:
Используйте свой здравый смысл, он так распространен, его даже не смешно.
Это один из многих недостатков фиксированной договоренности. В любое время, когда деловые потребности или приоритеты меняются, или существует даже простое недоразумение, это приводит к чему-либо из неловкой ситуации, подобной этой, к вызову адвокатов. Если у вас есть договоренность о том, где вы получаете деньги за время разработки, вы всегда можете реагировать на любые изменять и получать деньги за любое время, которое требуется для внесения изменений. Кроме того, наличие почасовой договоренности не исключает наличия плана или оценки.
Однако, если вы используете фиксированную ставку, ваши варианты: 1) Делайте это за дополнительную плату. 2) Сделайте это бесплатно. 3) Не делайте этого.
Вариант 3 является наихудшим, и вариант 1 является лучшим. Если у вас хорошие доверительные отношения и приличное общение с клиентом, обычно легко прийти к Варианту 1. Если отношения плохие, у вас возникают большие проблемы. В этот момент просто старайтесь избегать laywers.
Конечная точка - любой проект, имеющий что-то известное как "Дата поставки", неизбежно сталкивается с описанной проблемой. Проекты с указанной датой обычно включают отступление в пещеру в течение нескольких месяцев, чтобы развиться в укрытии, а затем разворачивание продукта сразу перед заинтересованными сторонами. Это круто и оставляет много времени для ожиданий клиентов, а фактический продукт дрейфовать. Если вместо этого вы показываете промежуточные версии продукта и собираете обратную связь каждые несколько недель, происходят две вещи. Во-первых, вы получаете лучшую обратную связь, минимизируете недоразумения и делаете лучший продукт. Во-вторых, нет единого момента времени, на котором заложено огромное количество ожиданий. Разность потенциалов между тем, что воображает клиент, и тем, что на самом деле существует, намного меньше. Никаких сюрпризов.
Удачи.
Ну, он не был успешно доставлен. Где-то вдоль линии была недопонимание. Не зная специфики, я бы предположил, что это не проблема с разработчиками, и это, вероятно, не обвиняет клиента - задача сбора требований была недостаточной. Это классический пример того, что происходит, когда на стороне программного обеспечения нет экспертов домена или процесс обнаружения требований не делает все, что может...
Если бы это был я, я бы исправил проблему и выяснил, как избежать подобной проблемы в будущем.
Как вы справляетесь с этим, можно очень точно определить будущее этого контракта/бизнеса с клиентом. Ответственность и исправление проблемы - огромная возможность для вашей компании.
EDIT: Это подходящее время для оценки того, как это произошло, чтобы исправить это. Некоторые компании предпочитают полностью обновлять все, что они делают, что является ошибкой, я думаю. Так что игнорирует это. Обвинение людей в проблеме также является ошибкой.
Хорошее время для того, чтобы пройти через то, как это произошло, что такое процесс, и, может быть, его можно было поймать. Я бы не стал делать огромные изменения в правилах или изменения процесса, но придумать рекомендации для будущей работы - это отличная вещь. У вашей компании был ясный урок о недостатке. Потеря возможности исправить эту проблему и исправить ваш процесс будет пустой тратой хорошего шанса.
"как вы реагируете?"
Вопрос 1 - Вы хотите продолжить отношения с этим клиентом? Шутки в сторону. Если они собираются утверждать, что неопределенные функции являются "здравым смыслом", это может быть не очень хорошая связь для поддержания или улучшения.
Если вы хотите отключиться, тогда это легко. Попросите их выделить каждую часть спецификации, которую вы не соблюдали и не играли в эту игру. Получите конкретные критерии тестирования для каждой отсутствующей функции. Потяните зубы. Будьте конфронтационными в определении того, что отсутствует. Не спрашивайте, почему. Просто попросите все детали впереди. Это медленно и неприятно. Но вы все равно не хотите их.
Если вы хотите заниматься, ну, вам придется изменить отношения. В настоящее время у вас есть пассивный агрессивный клиент. Они не скажут, чего хотят, но они скажут, чего они не хотят.
Это может быть привычкой с ними; это может быть так, как они выигрывают уступки. Или это просто может быть неаккуратным спецификацией с их стороны.
Если вы хотите отношения, ваша реакция состоит из двух частей.
Краткосрочное. Получите то, чем они довольны. Они должны определить конкретные изменения. Вы должны забить каждое изменение с "стоимостью, чтобы сделать" и "соответствовать спецификации".
Долгосрочное. Удостоверьтесь, что они не PA'd снова. Просмотрите ранние и часто, используйте Agile методы. Общайтесь больше, прототип больше, выпускайте больше.
ZiG, мне приходилось иметь дело с этой проблемой несколько раз на моем нынешнем месте Занятости. Моя группа (3 разработчиков) пытается приблизиться к вещам в Agile. Мы привыкли получать запросы в середине потока и даже последние секунды (которые мы рассматриваем в каждом конкретном случае).
Однако мы даем понять, что ресурсы (особенно время) ограничены, и если это не в спецификации, мы не можем сделать promises. Если он считает важным и не может вписаться в текущую версию, мы обычно планируем последующий выпуск. Если это не важно, оно идет по списку.
Одна вещь, которую я нашел, это то, что вы можете заставить пользователей согласиться на Spec S во время T. Однако в момент T + N, заставляя их помнить, что они согласились на Spec S, или заставить их признать, что они это сделали (с документацией, которую вы держите, я надеюсь!) может быть сложнее, чем должно быть.
Разговор с предметом и вопросом OP:
Если вы нанятый программист, то я надеюсь, что другие ресурсы будут на встрече с вами. Возможно, "более высокие взлеты" в организации.
Если это так, тогда ваша задача - ответить на НЕПОСРЕДСТВЕННЫЕ вопросы и держать свои эмоции под контролем. Да, вы можете чувствовать себя раненными, потому что они не любят ваш код, но проявление эмоций с присутствием боссов - это не очень хорошо. Скорее, попробуйте выглядеть нейтрально и пусть остальные обрабатывают сеанс.
Теперь, если они "повесят вас на высыхание", я бы порекомендовал следующие вопросы:
a) "Хорошо, я понимаю. Почему именно вам кажется, что это здравый смысл, чтобы включить эту функцию? Я бы хотел узнать, почему мы ее не включили". (заставить их объяснить их мыслительный процесс. Здравый смысл для одного человека редко бывает здравым смыслом для кого-либо еще.)
b) "Ну, я уверен, что мы можем включить это в следующий выпуск. Я оставлю его до XXX (боссов), чтобы прийти к взаимоприемлемому подходу" (т.е. не говорить о стоимости или бесплатных с присутствующими боссами. КОГДА-ЛИБО.)
Опять же, это предполагает, что вы программист WORKING для компании, которая поставляла продукт. Теперь, если это больше, то есть вы являетесь одним из высших взлетов, то многие из предложений здесь превосходны.
Однако, если вы выше или являетесь программистом-консультантом, то сначала и formost
a) Извините за процесс, который не уловил этого требования. Обещайте работать с клиентом, чтобы это не повторялось.
Затем по другим стратегиям. Это действительно не имеет значения, если вы берете на себя ответственность за исправление или нет - извинение - это самое важное действие для клиента. Опять же, это повторяется - вы не извиняетесь за пропущенную функцию. Вы извиняетесь за ошибочный процесс проектирования, который позволяет ему проскальзывать. Клиенты обычно довольно удобны, когда вы начинаете этот путь, а затем ищите решение.
Приветствия,
-Ричард
Используйте методы SCRUM, чтобы избежать этого deathtrap: вовлекайте клиента в процесс dev раньше, часто и в неформальных, ограниченных коммитах → уменьшении риска и повышенной ловкости.
В терминах вашего буквального вопроса, как реагировать, лучший способ - игнорировать ваше эго ( "что?! После того, как я так много работал над этим и встретил спецификацию?!" ), и вместо этого сосредоточиться на каком-то активном прослушивании и работая на основе консенсуса.
Клиент: вы могли бы включить это!
Нас: не указано в спецификации!
Клиент: общее чувство!!
Нас: Я понимаю, что вы недовольны тем, что мы не вышли за рамки спецификации. Увидев, как вы к этому относитесь, как мы можем сделать вас счастливыми? Посмотрим, есть ли процесс, который мы можем создать вместе, который поможет всем.
По существу, вы не хотите превращать это в "вы сказали/я сказал" о смерти. Единственный способ разрешить их - это адвокаты, и тогда никто не побеждает. Если вы можете согласиться с тем, что спецификация или процесс были связаны с ошибкой, работайте вместе, чтобы исправить эти ошибки.
Этот подход на самом деле просто сработал у меня: ждать парня, которому не нравится, когда ваше программное обеспечение уходит и его заменяет парень, которому нравится это.
Очевидно, вы не можете действительно полагаться на это, но если вы уверены, что хорошо поработали и что ваше программное обеспечение действительно удовлетворит потребности бизнеса людей, которые наняли вас, он платит, чтобы подождать. Иногда первоначальная реакция клиента не будет их последней, особенно если вы можете быстро включить их проблемы.
Не пытайтесь заставить клиента почувствовать, что это их вина. Возможно, это их вина, но заставляя их чувствовать, что путь не принесет конструктивных результатов и может просто раздражать их.
Вместо этого вы должны понимать, что клиенты жалуются только на программное обеспечение, которое они используют, в большинстве случаев, потому что им это нравится. Никто не жалуется на программное обеспечение, которое никто не использует. Неизбежно, что клиент будет жаловаться на поставляемое вами программное обеспечение, даже если вы поставите именно то, о чем они просят. Так что не потейте. Программное обеспечение никогда не выполняется.
Общий сбой со стороны лица, ответственного за сбор требований, без сомнения. Дополнительный сбой управления проектом, чтобы не повторять доставку и иметь встречи с клиентом.
Однако у вас есть подписанная спецификация, и то, что вы поставили, соответствует спецификации. Таким образом, у вашей компании есть два варианта: списывать стоимость во имя развития бизнеса и делать изменения бесплатно или взимать плату за запрос на изменение.
Если это не в спецификации, это не в спецификации. Как разработчик без каких-либо конкретных знаний домена, "здравый смысл" - это не относящееся к делу понятие. Различные отрасли промышленности работают по-разному, и один подход может быть вполне уместным для конкретного домена, но совершенно неприемлем в другом.
Написание хороших спецификаций - это арт-форма. IMO, вы можете либо использовать гибкий подход "аналитик/программист", где вы делаете небольшие итерации, либо записываете и поддерживаете подробную, однозначную спецификацию. Оба являются высококвалифицированными задачами и по-прежнему являются итеративными. Вы все еще должны разработать спецификацию.
В любом случае это не так просто, как кажется, и оба требуют возможности установить хорошие рабочие отношения с клиентом.
Вы не можете знать, что думает ваш клиент в его голове. Эта ситуация часто возникает с клиентом, который не имеет опыта программирования. Я предлагаю вам просто показать ему, что "здравый смысл" не очень точен, как ответ в технике (или программировании, если вы предпочитаете).
Покажите ему другой пример в жизни, который покажет ему, что вы не можете построить что-то, что не написано. Пример: строительство нового дома, парень, который строит дом, нуждается в плане со всеми подробностями... он не ставит дополнительный электрический штепсель, потому что в гостиной более "здравый смысл" имеет дополнительные...
У меня это было однажды. И, к счастью, это не я создал дизайн, потому что это оказалось проблемой.
Жизненно важно, чтобы общение между вашей компанией и клиентом было максимально совершенным. Убедитесь, что вы понимаете друг друга. Задавайте вопросы и задавайте вопросы. Не позволяйте чему-либо открывать в дизайне. Это будет проблемой при доставке. И регулярно проводите встречи во время проекта (желательно с предварительной отправкой).
К сожалению, многие разработчики плохо относятся к общению, и многие клиенты не знают о своих собственных потребностях. Но если вы можете свести к минимуму разрыв, вы оказались счастливым (и возвращающимся) клиентом.
Вот почему я/команды, с которыми я работал, всегда использовали метод прототип-стиль, это означает:
Вы должны начать его на ранней стадии; расскажите клиенту, как часто, так и часто, о том, что спецификации/примеры использования/пользовательские истории - это контракт, который определяет, что будет доставлено. в гибкой среде есть много шансов, чтобы клиент наблюдал какую-то "здравую смысловую" функцию, которую они хотят и просят, что является одним из преимуществ гибкого подхода, но если вы начнете принимать дополнения "здравого смысла" на end, вы готовитесь к бесконечным расширениям, возможно, за свой счет.
Некоторые клиенты ожидают этого; тем больше и лучше вы им говорите, что они не могут, тем легче будут возможные аргументы.
Будучи младшим парнем, я понимаю, что вы не можете этого сделать, но пока один из трудных, но необходимых уроков заключается в том, что иногда вам приходится запускать клиента.
Вы учитесь - все учится, и ничто не является личным.
Мы являемся экспертами в нашей области, мы знаем лучше, чем клиент, в чем он нуждается. И в следующий раз для следующего клиента мы предложим все полезные функции заранее и сделаем его счастливым и заставим его платить больше денег, потому что мы эксперты, и мы знаем лучше.