Управление ползучести функций в графических интерфейсах

Ответ 1

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

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

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

Ответ 2

То, что я делаю, - это сохранить функциональные идеи на карточках индексов и размещать карты где-нибудь видимыми. Когда кто-то спрашивает: "Могло ли это также сделать XXX?" Я пишу новую карточку. Это лучший способ построения отношений, чем кричать "НЕТ!".:-) У него также есть преимущество не потерять потенциально хорошие идеи. OTOH, я не принуждаю его реализовать. Предвестник знает, что их слушали, я знаю, что не забуду, я могу вернуться к работе, и мы можем собраться вместе, чтобы принимать приоритетные решения в лучшем случае, чем когда мой мозг находится в CodeLand.

Ответ 3

Хорошо, тогда я буду голосом. Проблема не может быть решена в конце этого процесса, ее следует избегать, управляя проектом по-разному.

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

Кроме того, вы должны выполнять работу в небольших итерациях (от недели до месяца), чтобы у них были шансы перестроить между ними.

Мы используем SCRUM, и это было здорово. После нескольких итераций все элементы уровня бизнес-уровня и уровня процесса выработаны, и вы до конца доставляете именно то, что им нужно.

Ответ 4

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

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

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

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

Ответ 5

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

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

• Время задержки с задержкой
• Увеличение ошибок
• Неполные функции
• Напряжение персонала
• Отставки персонала.
• Дополнительные сборы за то, что ожидали большего от конечного продукта, чем было согласовано при объявлении цены (и это ДЕЙСТВИТЕЛЬНО ПЛОХО)

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

Ответ 6

Для менеджеров:

• чем раньше продукт будет выпущен на рынок (при условии, что он сократится), тем скорее компания сможет зарабатывать деньги и тем лучше поток денег.
• не исключать новую функцию, но балансируйте ее против ценности, которую вы можете извлечь из альтернативной работы; объясните альтернативные издержки.

Для всех:

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

Ответ 7

Лучшим способом ИМХО является четкое описание того, что будет стоить при реализации новых функций. "Было бы неплохо, если" действительно начнет сокращаться, когда пользователь начнет видеть стоимость таких дополнений.

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

Если вы объясните им и объясните, почему это не совсем хорошая идея, они обычно поймут. Не забывайте о всех разных факторах (время/деньги/стоимость добавления сложности к проекту/риск сокращения сроков). Разумный человек поймет, если вы нарисуете картину достаточно ясно, и вы можете, по крайней мере, сказать "Я так вам сказал" необоснованному человеку.

Ответ 8

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

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

Когда вы сможете доказать цифрами реального мира, что "эта маленькая кнопка" займет 2-3 дня, а не 5 секунд, клиент, вероятно, полагает, что вам будет лучше вступить в переговоры.

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

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

Ответ 9

Я сохраняю приоритетный список рабочих задач и свои оценки того, что будет в build X, и как долго (грубо говоря) я ожидаю, что он возьмет, чтобы писать тесты, внедрять код и делать что-то еще. Я всегда беру их вклад, обсуждаю то, что они действительно хотят/нуждаются, и настаиваю, чтобы мы определяли, где он вписывается в грандиозную схему вещей. Мы говорим о влиянии на планирование и другие задачи.

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

Ответ 10

Кажется, что ключ находится в вопросе.

' Управление функцией ползучести > ... вы делаете это, внедряя процесс управления, который необходимо соблюдать. Вы не можете избежать этого (в конце концов, часто клиенты, запрашивающие его и не кричащие на них, все время стремятся вытеснить бедных животных)... но это не значит, что это должно быть недисциплинированным. С процедурой, которая предусматривает, что лицо, поместившее запрос, дает простые вещи, такие как обоснование и предварительное расследование/прецедент для изменения, вы начинаете уменьшать число "было бы неплохо". После того, как у вас есть это место, ваша ползучесть функций управляется, и вы можете начать приоритизацию и обеспечить более последовательную обратную связь.

Ответ 11

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

Кроме того, посмотрите, как другие проекты успешно справляются с ползучести функций. Например, Google позволяет пользователям отправлять запросы функций, но также показывает список уже запрошенных функций. Затем пользователи могут проголосовать, чтобы запросить эту функцию. Не то, чтобы я сосать, но посмотрите stackoverflow.uservoice.com. У них есть аналогичная политика.

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

Ответ 12

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

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

С другой стороны, "ползучесть функции" часто является ответом программного продукта на развивающийся бизнес. Если ваш бизнес-клиент растет, вам повезло, потому что они потратят больше денег на вашу работу. Так что расслабься, они тебе платят! Им просто нужно понять, что чем больше система получает, тем труднее ее менять, а иногда новая небольшая особенность требует большого переписывания или всего нового пользовательского интерфейса, чтобы все работало плавно.

Ответ 13

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

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

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

Вместо этого немедленно примите обратную связь и запрос функции (или функцию) по номиналу. Уходите, подумайте об этом открыто на время. "Может ли это быть ценным?" "Я что-то упустил, когда генеральный директор спросил об этом?" "Это так сложно, как я это делаю?" Задайте себе такие вопросы и придумайте конкретные ответы. Затем всегда вернитесь к генеральному директору с последующими вопросами. Продемонстрируйте, что вы подумали о запрошенной функции и на самом деле придумали некоторые идеи, настройки, улучшения или возражения и т.д. Это создаст открытое обсуждение. Тот, который генеральный директор не ожидал, но что он, скорее всего, не возражал бы, поскольку он не был прямым сопротивлением его идее изначально.

Ответ 14

Один из наших финансовых спонсоров постоянно запрашивает функции. Иногда он говорит, что мы можем заставить программное обеспечение "х". Если возможно, мы скажем ему "да", а затем спросим его, какие временные рамки он имел в виду. Если он вернется с КАК МОЖНО СКОРЕЕ - тогда мы скажем ему, что какая-то другая особенность должна будет дать или продлить наши сроки. К счастью, он обычно меняет свое мнение на какое-то время в будущем.

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

Мы используем Bugzilla для отслеживания ошибок, но также и запросов функций. У нас есть рабочий список "функций" (или целевая версия)... таким образом, каждый может видеть, какие функции мы хотели бы развивать в будущем, и поскольку у людей больше идей по функции, которые они могут просто добавить в элемент в bugzilla.

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

Эта обратная связь помогает людям понять, что мы признаем запросы своих функций, и мы ОБРАЩАЕМСЯ к их реализации, а не просто сидим в списке, который становится все больше и больше.

Ответ 15

1) Увеличено время до выпуска.

2) Увеличение стоимости.

3) Экспоненциальная стоимость обслуживания

4) Повышенный потенциал ошибок

Чтобы управлять запросом функции, попросите их отправить заказ на изменение. Периодически проверяйте заказы на изменение и отправляйте выражение о каждом запросе: "Это займет X, чтобы сделать это, подразумевая эту дополнительную стоимость. Это приемлемо?" После того, как запросчик примет дополнительную стоимость, тогда это a-ok. Ваши руки стираются.:)

Ответ 16

Вы объясняете: "Конечно, это выполнимо, хотите ли вы оценить, сколько он вытолкнет дату завершения проекта? Кроме того, если вы дадите эту оценку, то добавьте около дня к концу проекта".

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

Ответ 17

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

Это, конечно, упрощение, но на самом деле большинство пользователей будут использовать лишь небольшую часть функций вашего продукта.

Прочитайте несколько хороших книг по разработке программного обеспечения и дизайну пользовательского интерфейса, а также попросите своего менеджера прочитать их. Книги Джоэла Спольского - хорошее место для начала - www.joelonsoftware.com

Ответ 18

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

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

Ответ 19

Мы следим за каркасами в моем офисе. Любое изменение после подписания должно пройти процедуру управления изменениями.

Ответ 20

Функция блокировки в течение короткого периода времени (Scrum/iteration/agile). По мере того, как пользователь начинает видеть что-то работающее, необходимость или недостаток функций станут более очевидными.

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

Ответ 21

Показать, как эффективны простые графические интерфейсы. Примеры: Google Chrome, программное обеспечение Apple. Вы также можете показать примеры раздутого программного обеспечения, например Eclipse, Netbeans, Visual Studio... нормально, это на самом деле все программные IDE, но все они имеют загроможденный интерфейс.

Ответ 22

Трюк заключается в том, чтобы определить проект как последовательность версий. Ваш первоначальный дизайн предназначен для версии 2.0, но предполагаемая первая версия - версия 1.0. Все новые идеи (функции) приветствуются, но поскольку из-за планирования версия 1.0 заморожена, новые идеи должны идти в версии 2.0.

Конечно, как только выпущена версия 1.0, вы начинаете исправление ошибок и кодирование для версии обслуживания версии 1.01 и так далее... Возможно, версия 2.0 никогда не была фактически выпущен, но используется как неуловимая цель и место для парковки объектов которые хороши, но недостаточно хороши, чтобы отложить выпуск рабочей версии.

Ответ 23

Правильный вопрос: "Как я могу дать разработчикам среду стабильной, а отвечать только на запросы с высокой выгодой." Подобным подходом SCRUM будет:

Стабильная среда:

Попросите разработчиков работать с небольшим фиксированным набором функций во время небольшого фиксированного итерационного интервала.

Реагирование только на запросы с высокой выгодой:

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

Ответ 24

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

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

Ответ 25

Возможно, не удастся избежать всех запросов функций.

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

Ответ 26

ЕСЛИ вы не являетесь менеджером или владельцем проекта, я предписываю следующее:

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

Ответ 27

Ответ на ваш вопрос шире, чем просто графические интерфейсы. Ползучесть функции/области всегда будет иметь место, когда кто-то не обращает внимания на то, что предусмотрено договором, и когда нет формального процесса обработки запросов на изменение.

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

Ответ 28

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

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