Як розробник повинен відхиляти неможливі вимоги? [зачинено]

Ось проблема, з якою я стикаюся:

Hey Spark, я покладаю на вас завдання розробити рамки, які можна було б використовувати для багатьох додатків iOS. Ось такі вимоги:

• Він повинен бути в змозі виявити товщину великого пальця або пальців, які використовуються для маніпулювання користувальницьким інтерфейсом.
• З цією інформацією всі елементи інтерфейсу повинні бути упорядковані та розміщені автоматично .
• Для великого пальця елементи повинні розташовуватися ближче до центру екрана.
• Для великого пальця елементи слід розташовувати ближче до кутів екрана.
• Для великого пальця всі шрифти повинні бути меншими. (У цьому випадку ми припускаємо дорослу людину.)
• Для великого пальця всі шрифти повинні бути більшими. (У цьому випадку ми припускаємо молодшу людину.)

Підсумок:

Ця рамка необхідна для програмного створення зручних для користувача інтерфейсів. Рамки повинні бути розроблені таким чином, що ми можемо використовувати для необхідної кількості проектів, тому це також повинно бути дуже зручним для розробників.

Я розробник дав це завдання, тому мої запитання такі:

• Як я можу пояснити, що ці вимоги трохи смішні?
• Як я можу пояснити, що краще було б сконцентруватися на розробці реальних проектів?
• Як я можу пояснити, що навіть якби це було можливо, я б не рекомендував розробляти таке?
• Як я можу сказати "НІ" цьому проекту ввічливо, ніжно та з повагою?
• Як я можу пояснити, що навіть для розробника, який має 3-річний досвід, це може бути неможливим?

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

Ви повинні з повагою ставитись до пояснення, чому вимоги неможливо виконати (тобто сенсорний екран не може розрізняти великий палець, палець або стилус. У нього недостатньо роздільної здатності для визначення ширини пальця.) - зберігайте речі фактично , вказуючи на наявна документація, якщо така є.

Не вдавайтеся в якусь емоційну суперечку і тримайтеся круто і професійно. Сказати комусь, що їхні вимоги нерозумні - це ніколи не виграшна стратегія.

Подивіться, чи зможете ви зрозуміти фактичні цілі функції - чому це сприймається як вимога. Це може привести вас до іншої, кращої функції, яка вирішить потребу. (спасибі @spoike)

@ DarkStar33 пропонує у коментарях провести дослідження та надати фактичну оцінку, скільки коштуватиме проект та скільки часу це займе, з припущенням, що результат буде надто дорогим та тривалим, щоб його вартувати. Будучи озброєним номерами та даними для їх резервного копіювання, безумовно, може допомогти вашій справі, хоча я все-таки роздивлюся бізнес-цілі, щоб побачити, чи можна їх досягти (навіть частково) по-іншому.

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

Однак якщо ці вимоги неможливо здійснити, оскільки датчики пристрою не в змозі виміряти розмір пальця, просто напишіть це так: На жаль, наявні на даний момент пристрої не підтримують таку функціональність

Я трохи пограю тут «Адвокат диявола» і скажу, що думаю, що насправді технічно можливо виміряти розмір великого пальця людини. IPhone - це мультитач-пристрій. Для калібрування ви можете доручити користувачеві розміщувати великі пальці або два пальці на екрані поруч і вимірювати відстань між цими дотиками.

Звичайно, для цього знадобиться тестування та експерименти, щоб побачити, наскільки реальна моя інтуїція. Можливо, великі пальці доведеться перетягнути по екрану, щоб краще читати.

Однак, існують серйозні проблеми у використанні та впровадженні.

• Що робити, якщо пристрій спільний? Коли відбувається калібрування?
• Як можна динамічно визначати положення елементів інтерфейсу довільно в усіх програмах, побудованих за допомогою фреймворку? Очевидно, кожен додаток матиме інший інтерфейс користувача та інший макет.
• Просте опитування поточних додатків для iOS показує, що добре розроблені з них використовують увесь наявний горизонтальний простір, а вже елементи простору такі, що важливі кнопки є максимально великими та розміщені біля країв. Повна ширина пристрою, очевидно, використовується для списків та компонування.
• Навіть якби це було можливо, що таке аналіз витрат / вигод? Скільки б отримати від такої системи порівняно зі стандартними елементами управління інтерфейсом? Чи не було б простіше мати просте управління перемиканням розміру шрифту, як уже використовують багато програм?

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

Люди в Apple вже глибоко подумали про всі ці речі, і вони не придумали змінний інтерфейс залежно від розміру пальця / пальців.

Як користувач, я б ненавиджу рухомі цілі під пальцями.

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

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

Один із способів переадресації необґрунтованого запиту - це допомогти клієнту зрозуміти суть проблеми, яку вони намагаються вирішити. Завдяки техніці інтерв'ю з планування, розмовно відомій як " вискакує стік чому ", ви продовжуєте запитувати "чому" рекурсивно (звичайно, ввічливо, розумно):

Одним з важливих інструментів як для отримання комунікацій, так і для вирішення конкретних проблем є те, що Барретт називає проскакуванням стека "чому". Це просто, щоб продовжувати задавати питання "чому це робиться саме так?" про вимоги проекту. Він наводив архетипний приклад того, що може виявити методика: "Я колись працював з клієнтом, де була вимога, щоб дані були надруковані на певному етапі процесу, тому я запитав, чому", - сказав він. "Відповідь полягала в тому, що департамент отримує дані, необхідні для його введення. Ніколи їм не приходило в голову, що дані можуть передаватися автоматично до їх програми".

Мета полягає в тому, щоб досягти основної вартості бізнесу:

• Захистіть дохід
• Збільшити дохід
• Управління витратами
• Збільшити вартість бренду
• Зробіть виріб чудовим
• Надайте більше цінності своїм клієнтам

(Предмети з огіркової вікі)

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

Щоб використовувати ваш приклад сканування розмірів великого пальця:

Клієнт: Ми хочемо виявити товщину великого пальця або пальців, які використовуються для маніпулювання користувальницьким інтерфейсом.

Dev: Чому ти хочеш це робити?

Клієнт: Тому що, намагаючись натискати ці маленькі кнопки, я часто натискаю неправильну річ, і наше програмне забезпечення використовується багатьма будівельними робітниками з великими руками, як я. Якщо вони могли б відкалібрувати інтерфейс користувача за розміром пальця, це полегшило б його використання.

Dev: Простота використання, безумовно, була б корисною для замовника, але чому вони хочуть калібрувати інтерфейс користувача? Якщо люди, які використовують це, мають великі руки, чому б не налагодити дизайн для цього випадку використання?

Клієнт: Я ніколи не думав про це так, я вважаю, що більш чистий дизайн спрацював би так само добре і для людей з маленькими руками!

Відмова від відповідальності - я не знаю, чи можливий ваш запит, і якщо це можливо, вам потрібно визначити, скільки часу це займе, і надати цей зворотній зв’язок вашому менеджеру. Але я пишу цю відповідь з припущенням, що це неможливо, принаймні, використовуючи стандартний фреймворк, - і я поширюю свою відповідь на більш загальний випадок, коли ви дійсно не можете чи не повинні щось робити.

Просто скажіть "НІ".

У цій темі є багато відповідей "ніколи не кажи", що, на мою думку, є м'яким і покірним ставленням. Подумайте про це так - я технічний експерт у цій команді, а інші мої члени команди намагаються зробити щось, що, на мою думку, нездійсненне, надскладне, потенційно не можливе. Це моя відповідальність сказати "ні".

Звичайно, я можу & слід сказати ніжно; Я "настійно рекомендую проти цього", пропонуючи "дослідити, чи можливо це", перш ніж сказати "ні". Але я врешті-решт скажу ні, тому що це моя робота.

Настільки багато аналогій на це

• Мій бухгалтере, я хочу, щоб ви відклали мою вечерю Подяки як пільгу з податку
• Пане шеф-кухаре, я хотів би, щоб моя курка залишалася на прилавці протягом ночі і подалася, будь ласка, сирою.
• Мій юрист, я хочу подати до суду на своїх дітей за те, що вони не прибирали їхні спальні
• Пане Механік, будь ласка, встановіть турбокомпресор на мій електромобіль

Ви можете попросити всіх цих людей виконувати завдання, які вони будуть знати, що вони дурні, марнотратні, небезпечні чи неправильні. І ви б очікували, що всі вони порадять проти цих дій і в кінцевому підсумку відмовляться (принаймні, я сподіваюся, що так). Якщо хтось із цих професіоналів відповів «Хм добре, я думаю, ми можемо це зробити» - не даючи мені прямо «Це погана ідея» - тоді, відверто кажучи, я б не хотів їх наймати.

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

Слід сказати клієнту, що ви не можете реалізувати те, що ваша цільова платформа не дозволяє. Але зробіть крок назад і запитайте себе, в чому полягає логіка цих досить смішних вимог? З того, що я можу прочитати, вони дуже стурбовані зручністю у користуванні. Потім запитайте їх, копайте трохи глибше, поки вони не скажуть вам те саме: "ми хочемо інтерфейс, зручний для користувачів". Потім вкажіть їх на те, що можна зробити, а що ні. Скажіть їм, що якщо вони хочуть легкого користувальницького інтерфейсу, існують прості (і дешевші способи), такі як дозволити користувачеві встановити розмір шрифту / значка (я вважаю, що це можливо на IoS). Можливо, ви можете дозволити користувачеві контролювати розмір шрифту / розмір значка та розташування програми на вкладці налаштувань? Це має бути простіше (і точніше!), Ніж намагатися вгадати вік людини за розміром великого пальця! Останнє, що хотів би отримати ваш менеджер, - це непотрібний, роздутий, важко підтримуваний код, який досягає того самого, що вже пропонує OS. Скажіть своєму клієнту, що користувачі вважають за краще керувати програмою, а не програмою, якою вони керують.

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

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

Залиште компанію. З’ясуйте, як це зробити. Продай це за набагато більше грошей, ніж зараз заробляєш.

Що стосується вимог, я зазвичай це роблю так: я намагаюся оцінити, скільки часу знадобиться для реалізації конкретної вимоги.

У разі виникнення вимог, які можуть бути неможливими, попросіть декілька днів або скільки часу потрібно, щоб з’ясувати, чи це можливо. У вашому випадку питання: "Чи можна визначити, наскільки товстий палець користувача?"

Насправді це питання є навіть трохи складнішим: "Чи можна визначити, наскільки товстий палець користувача після першого дотику менше ніж за 200 мілісекунд, щоб дозволити негайну взаємодію?" (замініть спочатку на 2-е або ...; і 200 мс на 300 мс або що завгодно ...)

Можливо, навіть відповідь на це запитання займає один місяць. Можливо, навіть якщо це більш-менш здійсненно, він потребує надскладного алгоритму, який працює добре лише у 80% випадків.

Ви бачите, куди я їду?

Люди часто роблять помилкові припущення щодо можливостей, оскільки вони мають низький досвід та досвід щодо даної галузі. Тому ви не можете сперечатися з інтуїцією, але вам потрібні факти.

Якщо інші зацікавлені сторони зрозуміють, що ця функція потребує 2 чоловічих років і вимагає, щоб iPhone 10 з'явився до 2014 року, вони швидко знизять їхні вимоги.

Це звучить складно, але зовсім не неможливо; Справа в тому, що сенсорний екран не може розрізнити великий палець середнім пальцем або стилусом; Користувача просять при ініціалізації (запуск сеансу, будь-який) розмістити великий палець, потім середній палець тощо, щоб відкалібрувати розміри (зробити деякі статистичні середні показники) за допомогою декількох рухів тощо.

Я б спробував вирішити кореневу проблему іншим способом, перш ніж сказати, що цього неможливо зробити.

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

Представляючи подібне креативне рішення, напевно, це те, що вони більше, ніж просити вас магічно визначити ширину пальця (про що ви можете повідомити їх, немає в API).

Все ще може бути складно - розміщення області навколо кнопок для виявлення пропусків - тому оцінюйте більше годин.

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

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

Спробуйте змусити його вказати на проблему та вимогу, а не на рішення та дизайн майбутніх проектів.

Що мені подобається робити, це підходити до проблеми з командної точки зору. У цьому випадку менеджеру проекту і мені потрібно придумати рішення. Мені також подобається показати, що я приходжу відкрито. Якщо я почую те, що, на мою думку, чує неможливість, є ймовірність виникнення непорозуміння між мною та керівником проекту. А може, ми не досягли того часу.

Після того, як ми вирішимо зробити стрибок і відкрити розмову, мені здається, що найпростіше розглядати цю проблему як економічну. У техніці практично все можливе з урахуванням нескінченної кількості ресурсів. Обговорюючи, що потрібно було б зробити, багато разів - це найпростіший спосіб з повагою "сказати". І це був би спосіб усунути всі можливі непорозуміння. Хоча, чесно кажучи, ми не зовсім говоримо "ні". І яка мета - сказати ні в якому разі. Якщо роботу не варто робити, не має значення, хочемо ми її робити чи ні.