Как обрабатывать запросы на нелепую функциональность в вашем программном обеспечении?
Конечно, большую часть времени этот тип запроса поступает от руководства, которое не имеет ни малейшего представления о том, чего на самом деле хотят пользователи, и не имеет понятия о технических аспектах создания конкретного программного проекта или программного обеспечения в целом. См. Дилберта заостренного босса для более подробной информации.
Однако это только один аспект. Как насчет запросов на элементы, которые, как вы знаете, повлияют на общую производительность системы, которую вы строите? Или как насчет технического идиота, которому по глупости даны полномочия, и все же почти все, что они делают, превращается в чертову голову? (Смотрите этот пост для удивительного примера)
В конечном счете, как вы красноречиво, профессионально и аккуратно справляетесь с запросами или указами о том, что вы строите, и знаете, что в конечном итоге повредит проекту?
14 ответов
Хороший разработчик программного обеспечения воздержится от того, чтобы называть запрос на функцию нелепым. Вы должны доверять своим внутренним чувствам, но это лишь хороший признак того, что вы хотите тщательно рассмотреть проблему.
Я предлагаю простую модель:
Постарайтесь понять, в чем заключается проблема, а не решение, которое запрашивает пользователь. Золотое правило дизайна " Не обсуждайте решение с клиентом, обсуждайте требования".
Уметь объяснить, в чем, по вашему мнению, проблема с предложенной функцией. У Пола Грэма есть отличная пьеса под названием " Как не согласиться".
Эти два простых шага помогут вам и пользователям углубить понимание актуальной проблемы. Программное обеспечение не имеет смысла без пользователей, большинство из нас зависит от пользователей, которые за него платят. Работайте с пользователями, а не отталкивайте их с отношением, которое может показаться оскорбительным.
Некоторые "нелепые" запросы на функции имеют корни в очень интересных и трудных для решения проблемах.
Всегда относите любой запрос к деньгам. Люди, которые приходят с этими запросами, обычно больше заботятся о деньгах, поэтому убедитесь, что они знают, что это будет стоить им дороже, потому что:
- это займет больше времени
- это может привести к большему количеству ошибок
- это может замедлить обслуживание
- это замедлит разработку новых функций, связанных с этим
Я нахожу фразу "мы сделаем это на втором этапе?" творит чудеса, возможно, подкрепленный словами: "Я думаю, что мы можем обойтись без этого для начала - давайте сначала что-нибудь выберем".
Ваше оружие выбора должно быть оценочным. Смешная функциональность, как правило, идет с нелепой оценкой. Когда функция X должна получить оценку в 3 человека в год, она волшебным образом превращается в функцию X.
Если это клиент и технически возможно сделать, и вы можете это сделать, получите техническое задание - и сделайте это.
Если это ваша работа, вы делаете то же самое, что и все остальное. Вы говорите: "Да, сэр (или мэм), я буду счастлив сделать это. И я совсем не против. Я просто подумал, что вы, возможно, захотите узнать, как это повлияет на наши другие системы или бюджет. Не говоря, что вы не правы, просто говоря, что, может быть, мы должны немного подумать об этом. Это нормально?"
Если они говорят "нет", они подписывают это, и вы делаете это. Если вы действительно обеспокоены, запишите ваш разговор, где ваш совет не был услышан. Помните, если вы не задокументируете это, этого не произойдет. Если они слушают, то вы выиграли друга.
Это было бы то же самое для любой работы - компьютер, строитель, что угодно.
РЕДАКТИРОВАТЬ:
Я взял это из моего комментария ниже:
Никто не смотрит Star Trek больше TNG или TOS? Помните, что номер один сообщал капитану Пикарду о том, что что-то не так, и иногда Жан-Люк соглашался, а иногда - нет. Это все что я говорю
Я бы потратил время, чтобы выслушать вежливо, если есть более одного запроса, попросите их расставить приоритеты и получить запрос в письменном виде, в идеале "подписать" или любую другую процедуру, которую вы используете. Затем сообщите своему менеджеру / клиенту, что вы рассмотрите запросы и ответите на них с оценками и влиянием, которое это окажет на ваше расписание. Объясните, что для получения этих данных вам потребуется X часов (или дней), и поэтому ваша другая работа будет отложена...
Затем вернитесь с оценками - если запрос был нелепым, то ваша оценка, вероятно, отразит это:-)
Если ваш менеджер / клиент хочет продолжить и тратить много времени и денег, то, по крайней мере, вы четко дали понять и сделали все возможное, чтобы помочь им.
Если это вообще возможно, вы должны попросить их отложить такие запросы до следующей фазы, предложите вам взглянуть на это в следующей версии (я думаю, что несколько других ответов уже упоминали эту идею).
Это все хорошие ответы. Вам нужны точные данные (если это возможно), "невероятно смешные" оценки и, прежде всего, уважение.
Ответ Джонни был по сути правильным, если не точными словами (я бы прокомментировал, если бы собрал достаточно репутации). Однако в некоторых случаях использование этих точных слов может вызвать диссонанс, чтобы податель запроса мог еще раз взглянуть на содержание ваших возражений. И да, это относится к любым проектным усилиям: программному обеспечению, дизайну рекламы, даже (задыхаясь!) Строительству. Не то, чтобы у ворчания, несущего раствор, были основания или влияние, чтобы возражать против ошибочного проекта, но руководитель строительства обязан сообщить архитектору, если его планы не строятся.
Если все остальное терпит неудачу, документируйте обсуждение и постройте его так или иначе Это больше не ваша ответственность.
Смешные запросы о функциях попадают в два лагеря для меня при ответе на них.
- Функция приведет к тому, что приложение перестанет функционировать должным образом, то есть нарушит его, слишком сильно замедлит, сделает его неработоспособным
- Функция, которая не приведет к тому, что приложение перестает функционировать должным образом, но я не понимаю, зачем вам такая функция
Для типа 1 я проанализирую запрос и отвечу либо объективными фактами, либо профессиональным мнением. Если анализ показывает, что это возможно с дополнительными усилиями по существующему коду, тогда оцените и оцените высоко!
Для типа 2, во-первых, я попрошу, чтобы запросивший объяснил функцию более подробно, в конце концов, они могут работать в той области бизнеса, которую у меня нет четкого понимания за пределами проблемного пространства для исходной спецификации приложения. Если я все еще не понимаю, и я действительно не вижу цели функции, тогда я оцениваю высоко, чтобы препятствовать им.
Если они принимают оценку, или я, наконец, получаю ее, тогда я делаю это.
В конце концов, они являются клиентом, и если клиент входит в портного и просит брюки с 4 ногами, портной может поспорить некоторое время, но в конце концов это обычная работа и гораздо дороже. Так что, если они видят достаточную ценность в функции, которую они готовы заплатить, будьте готовы взять их деньги; только то, что вы не видите значения, не означает, что они ошибаются.
Требования, созданные заказчиком, могут быть основной причиной этой проблемы. Проблема в том, что клиент иногда пытается выполнить работу разработчика программного обеспечения.
У них есть проблема, а затем решить, какие функции они решат эту проблему. К сожалению, некоторые (большинство) из этих бедных людей не очень хороши в разработке программного обеспечения, поэтому в конце вы получите очень любопытную особенность.
Чтобы удалить некоторые из этих запаздывающих функций, просто используйте рекурсивную функцию.Why(). Продолжайте спрашивать, почему, пока не найдете их проблему, а затем разработайте эту функцию самостоятельно. Во многих сценариях вы можете изменить его дизайн так, чтобы он был простым, недорогим и удовлетворял все стороны.
Также бывают случаи, когда то, что кажется нелепым запросом функциональности, действительно оказывается удачным. Бывают случаи, когда разработчики программного обеспечения (и я поймал себя на том, что делаю это в прошлом) отказываются от довольно сложной, но очень полезной функции, которая принесет компании большие деньги. Поэтому, когда вы сталкиваетесь с "нелепой" функцией, обязательно просчитайте ее потенциальную ценность для бизнеса, прежде чем немедленно от нее отказаться.
Я обнаружил, что большую часть времени люди, просящие невозможного, не понимают, почему то, что они просят, является такой проблемой.
Как правило, я просто прошу все больше и больше разъяснений о требовании и все больше и больше деталей, пока:
У меня в голове вспыхивает лампочка, я понимаю, к чему они стремятся, и могу сказать: "А, ты действительно хочешь это X, а не Y". В этот момент они обычно говорят: "Да, это то, что я говорил все время".
Они понимают, насколько они нереалистичны, и они забирают запрос
Вы вместе понимаете, что это было бы действительно хорошо, но это невозможно. Обычно, по моему опыту, это происходит потому, что вам нужно внести изменения в большое приложение с закрытым исходным кодом - в этом случае вы просто отправляете запрос функции поставщику, что является более приятным для нетехнических специалистов, которые для технарей; Microsoft не вносит изменения в Excel, потому что одна маленькая фирма попросила их об этом!
Существуют разные виды "нелепости".
- Это слишком дорого: я утверждаю, что клиенты должны стоить потраченных денег
- Это просто ненужный материал: я пытаюсь объяснить, что клиент не может его использовать. Если они все еще хотят это, они могут иметь это.
- Это противоречит существующим концепциям: на самом деле это "слишком дорого", как "недоступно". Они не получат это.
Мне нравится обсуждать требования:-)
Редактировать:
Типичная дискуссия
- Маркетинг Гай: Рядом с этой таблицей нам нужна кнопка, чтобы предоставить функцию X для выбора.
- Разработчик: Но нам нужен дополнительный параметр P для функции X
- М: Параметр Р очевиден во многих случаях
- Д.: Но мы должны охватить все случаи. Нам нужно подсказать для P
- М: Нет! Пользователи не любят, когда их запрашивают очевидные значения! Они просто хотят "щелкнуть и уйти".
- Д: Это невозможно в этом случае. Нам нужно подсказать.
- М: (любезно) Разве вы не можете догадаться об этом и только подсказать, если это действительно необходимо?
- Д.: Трудно угадать. На самом деле это занимает недели или даже месяц, и это высокий риск. Что если мы угадаем неправильно? Нам нужен искусственный интеллект для этого.
- М: Но это очень просто: всегда в случае, бла, мы знаем
- Д: Да, конечно, но мы не знаем, что знает пользователь.
- М: Хм. Вы, разработчики, всегда такие сложные.
- Д:...
- М: Так ты можешь это сделать или нет?
- Д: Нет.
- М: Почему?
- Д.: (раздраженно) Я только что объяснила. В конце концов, как вы думаете, пользователю нравится, что система угадывает P, если он действительно хочет решить?
- М: Вам просто нужно угадать, что решит пользователь.
- Д.: Но откуда я знаю?
- М: Это ситуация, бла-бла...
- Д: Я знаю, но это не так просто.
- М: Хорошо, я иду к руководителю проекта, он даст вам задание.
- Д:...
Я думаю, что единственное, что вы можете сделать, это очень кратко описать основные проблемы, которые запрос на изменение затронет вовлеченных людей. У меня на работе такая же проблема, как и у вас.
Некоторые запросы на изменение вынуждают разработчиков перепрыгивать через обручи просто для того, чтобы сделать это, и в конце концов это приводит к менее поддерживаемому коду для функции, которую кто-то наверху считал хорошей функцией.
По моему опыту, вы ничего не можете сделать, чтобы остановить это, и в конечном итоге руководство начнет жаловаться на то, сколько времени занимает разработка и т. Д. И т. Д. Это ужасный дерьмовый цикл, который либо закончится тем, что сайт будет перестроен, либо ваша команда потратит вечность на код ад
Удачи.
Иногда вы можете объяснить, почему функциональность нелепа, а функциональность отброшена.
Иногда вы можете попросить кого-нибудь постарше сказать "нет" за вас.
Иногда вы достаточно взрослый (или влиятельный), чтобы сказать "нет" себе.
Иногда вы можете сказать "да", но дать задаче низкий приоритет (и никогда не делать этого).
Иногда вам просто нужно с этим покончить.
В последнем случае, вы должны сделать это очень и очень хорошо. Зачем? Вы будете сиять, и когда вы это сделаете, тень нелепости окажется в фокусе.
Иногда такие запросы поступают от менеджеров по продукту.
В одном случае я объяснил, что будут проблемы с производительностью, и старший парень подтвердил, что мы победили.
В следующий раз и поднял аналогичную проблему, но старшего парня не было в наличии, так что я просто сделал то, что они хотели, потому что никто не заботился. Я решил, что нет.
Вы, вероятно, имеете в виду такие вещи, как отправка запроса по нескольким критериям в базу данных, показ результатов и в то же время показ того, какой из этих критериев имел успех. Догадались?