Мой клиент недавно обнаружил, что такое перезапись URL, не полностью понимая, что это такое, как это работает, а также плюсы и минусы этого. Теперь он просит много странных изменений в реальных требованиях текущих проектов и изменений в старых проектах, чтобы реализовать то, что он считает перезаписью URL.
С одной стороны, меня раздражает то, что меня просят делать вещи, которые не имеют никакого смысла, вместо того, чтобы заниматься реальной работой. С другой стороны, я не могу сказать своему клиенту, что он ничего не понимает в предмете, несмотря на его интерес к нему.
Я думаю, что у многих людей были ситуации, когда их менеджер или их клиент только что выучили новое модное слово или новую технологию, и он любил его так сильно, как хотел использовать его в каждом проекте, везде, переписывать всю кодовую базу просто для использования этого нового вещь и т. д.
Кроме того, я недавно прочитал кое-что, связанное с Programmers.SE, где люди рассказывали о своем опыте, когда вокруг XML было огромное ажиотаж, и некоторые менеджеры просили вводить XML в каждый проект, просто чтобы показать всем, что они его использовали.
Итак, те, кто был в подобной ситуации, как вам это удалось?
источник
Ответы:
IMO, у вас должна быть дискуссия «Вы не понимаете переписывание URL» с вашим клиентом.
Очевидно, вы не должны прямо говорить своему клиенту: «Вы не понимаете». Вместо этого я бы начал с: «Прежде чем мы что-то инвестируем, я думаю, что мы должны обсудить X, чтобы убедиться, что мы находимся на той же странице о том, каковы плюсы и минусы X и его альтернатив».
Если окажется, что он на самом деле знает то, что вы делаете, но в любом случае хочет внедрить X, тогда вы спросите его, какого цвета он хочет.
Вы должны убедиться, что вы выбираете свою формулировку очень тщательно. В конце концов, есть шанс (хотя и незначительный), что он знает о X больше, чем вы (и есть очевидный момент - вы говорите с управлением ), поэтому убедитесь, что вы избавились от любых снисходительных тонов.
источник
Именно здесь помогает список приоритетных задач, возникающих в команде. Если бы я был вами, я бы оценил экономическую выгоду перезаписи URL-адреса и показал бы клиенту, как его можно добавить / удалить из общего опыта.
Думай о себе как о докторе. Люди постоянно обращаются к врачам со списком лекарств, которые они видели на рекламе / симптомах, которые они себе представляют. Задача врача - убедиться, что человек действительно получает то, что должен получить.
Кроме того, строго используйте контроль версий и ветвление для каждого изменения. Таким образом, вы можете откатиться вовремя и показать клиенту, что он упустил, на тот случай, если он забудет, что навел это на себя.
Наконец, расшифруйте все ваши встречи. Когда-нибудь они пригодятся.
источник
Разбейте его на доллары и центы. Дайте ему реалистичные оценки того, сколько времени потребуется для реализации его капризов, и включите влияние на другие функции. Переведите это в обсуждение приоритетов и спросите, где это подходит. Оттуда вы можете перейти к обсуждению, чтобы убедиться, что он действительно понимает, что он просит. Это гарантирует, что:
Во многих случаях после этого обсуждения ему будет легко согласиться отбросить его или сделать его очень низким приоритетом (читай: никогда не ожидайте, что это будет сделано).
источник
Откуда вы знаете, что вас спрашивают так мало? Возможно, есть скрытые мотивы, которые на первый взгляд могут быть неясны, почему что-то делается. « Воск на, правой рукой. Воск, левая рука. Воск на, воск. Вдохните через нос, из рта. Воск на, воск. Не забывайте дышать, очень важно. » Будет линия от «Малыш каратэ» стоит отметить здесь в некоторой степени.
Где у меня был опыт работы с компаниями, которые задаются вопросом: «Почему вы делаете это так?» бывают случаи, когда я спрашиваю, какая выгода нужна, и есть ли другие способы ее получения. Ключ здесь должен быть открытым и любопытным, а не осуждающим и самодовольным, что, по-видимому, «реальная работа» подразумевает для меня довольно сильно.
источник