Come dovrebbe uno sviluppatore rifiutare requisiti impossibili? [chiuso]

Se si ottiene un insieme di requisiti che fisicamente non è possibile implementare in quanto il dispositivo non supporta e non supporta la funzionalità desiderata, è necessario spiegarlo alla persona che crea i requisiti.

Dovresti essere rispettoso e spiegare perché non è possibile implementare i requisiti (ad esempio il touch screen non è in grado di distinguere tra pollice, dito o stilo.) Non ha una risoluzione sufficiente per rilevare la larghezza delle dita. em> factual , che punta alla documentazione esistente se ce n'è.

Non entrare in alcun tipo di argomento emotivo e mantenere la calma e la professionalità. Dire a tutti che le loro esigenze sono stupide non è mai una strategia vincente.

Verifica se riesci a comprendere gli obiettivi effettivi della funzione, perché è considerata un'esigenza. Ciò potrebbe portare a una funzionalità diversa e migliore che risolverà la necessità. (grazie @spoike)

@ DarkStar33 suggerisce nei commenti di fare la ricerca e fornire una stima reale di quanto costerà il progetto e quanto tempo ci vorrà, con l'ipotesi che il risultato sarà troppo costoso e lungo per essere valsa la pena. Essere armati di numeri e dati per sostenerli può sicuramente aiutare il tuo caso, anche se guarderei ancora gli obiettivi di business per vedere se possono essere soddisfatti (anche parzialmente) in un altro modo.

Questi requisiti non sono sciocchi, stupidi o ridicoli. Questo è in effetti un problema molto importante per gli utenti dei touch screen, per cui le persone con dita più grandi hanno difficoltà a individuare il bersaglio, che spesso non viene compreso dai mignoli.

Tuttavia, se ritieni che questi requisiti siano impossibili da implementare perché i sensori del dispositivo non sono in grado di misurare le dimensioni delle dita, scrivi semplicemente così: Sfortunatamente, i dispositivi attualmente disponibili non supportano tale funzionalità

Vado qui a giocare a Devil's Advocate e dico che penso sia tecnicamente fattibile misurare le dimensioni del pollice di una persona. L'iPhone è un dispositivo multitouch. Per la calibrazione, puoi istruire l'utente a posizionare i pollici o le due dita sullo schermo affiancati e misurare la distanza tra questi tocchi.

Naturalmente ciò richiederebbe test e sperimentazione per vedere quanto sia fattibile il mio intuito. Forse i pollici dovrebbero essere trascinati sullo schermo per ottenere una lettura migliore.

Detto questo, ci sono seri problemi di usabilità e implementazione.

• Che cosa succede se il dispositivo è condiviso? Quando avviene la calibrazione?
• In che modo puoi determinare dinamicamente la posizione degli elementi dell'interfaccia utente arbitrariamente in tutte le applicazioni create con il framework? Ovviamente ogni app avrà un'interfaccia utente diversa e layout diversi.
• Un semplice sondaggio delle attuali app iOS mostra che quelli ben progettati utilizzano tutto lo spazio orizzontale disponibile e già elementi spaziali tali che i pulsanti importanti siano il più grandi possibile e posizionati vicino ai bordi. Ovviamente l'intera larghezza del dispositivo viene utilizzata per elenchi e layout.
• Anche se fosse possibile, qual è l'analisi costi / benefici? Quanto si otterrebbe da un tale sistema rispetto ai controlli dell'interfaccia utente standard? Non sarebbe più semplice avere un semplice controllo a levetta per le dimensioni del carattere, come molte app già usano?

Quello che fai è trattarlo seriamente e tornare indietro con una stima di quanto tempo ci vuole per fare e assicurarsi che la stima sia molto alta e molto dettagliata in modo che non possano contestare i numeri alti. Una volta che avrai dimostrato che non sarà economico, ti lasceranno in pace. Assicurati di indicare che le attività specifiche non sono attualmente supportate dall'hardware e potrebbero anche non essere fattibili. Non dimenticare di aggiungere costi per qualsiasi tipo di specialista, persone aggiuntive di cui potresti aver bisogno per un progetto di questa portata.

Le persone di Apple hanno già pensato profondamente a tutte queste cose e non hanno trovato un'interfaccia ridimensionabile a seconda delle dimensioni di pollice / dita.

Come utente, odio muovere bersagli sotto le dita.

Se sei preoccupato di metterti nei guai per aver ricevuto requisiti impossibili, allora la scelta migliore è dirgli immediatamente che è impossibile. Più tempo lascerai loro costruire un business plan su un progetto impossibile, più è probabile che ti incolpano per il fallimento del progetto.

Soprattutto, cerca di non preoccuparti di cose che non sono colpa tua, abbiamo tutti abbastanza da preoccuparci che abbiamo la capacità di controllare. Se qualcuno dovesse ritenervi responsabile di un tale fallimento del progetto, allora è un'ingiustizia nei vostri confronti. Credi nel Karma?

Un modo per deviare la richiesta irragionevole è aiutare il cliente a capire la natura del problema che stanno cercando di risolvere. Attraverso una tecnica di intervista di pianificazione colloquialmente nota come " spuntando lo stack di motivi ", continui a chiedere " perché "ricorsivamente (in modo educato, intelligente ovviamente):

One important tool for both getting communications going and "cutting to the chase" of specific issues is what Barrett calls popping the "why" stack. This is simply to keep asking the question "why is it done that way?" about project requirements. He gave an archetypal example of what the technique can unearth: "I once worked with a client where there was a requirement that data was printed out at a particular stage in the process, so I asked why" he said. "The answer was that the department receiving the data needed to key it in. It had never occurred to them that the data could be transferred to their application automatically."

L'obiettivo è arrivare al valore aziendale principale della funzione:

• Proteggi entrate
• Aumenta le entrate
• Gestisci costo
• Aumenta il valore del marchio
• Rendi il prodotto straordinario
• Fornisci più valore ai tuoi clienti

(Articoli da Cetriolo wiki)

Se la caratteristica non si adatta a una di queste categorie, può aiutare il cliente a vedere che ci sono cose più importanti su cui concentrarsi, o attraverso questo processo di pensiero potresti essere in grado di consigliarle su come affrontare il problema problema che stanno cercando di risolvere in un modo più significativo. Spesso il vero problema si trova ad un livello più alto di astrazione rispetto al problema che ti hanno richiesto di correggere.

Per utilizzare il tuo esempio di dimensioni dei pollici di scansione:

Client: We want to detect the thickness of the thumb or fingers being used to manipulate the UI.

Dev: Why do you want to do that?

Client: Because when I try to tap these small buttons I often hit the wrong thing, and our software is used by a lot of construction workers with big hands like me. If they could calibrate the UI for their finger size, it would make it easier to use.

Dev: Ease of use would certainly be valuable to the customer, but why would they want to calibrate the UI? If the people using this are known to have big hands, why not adjust the design for that use case?

Client: I never thought of it that way, I suppose a cleaner design would work just as well for people with small hands too!

Dichiarazione di non responsabilità - Non so se la tua richiesta è possibile, e se è possibile, devi determinare quanto tempo ci vorrà e fornire quel feedback al tuo manager. Ma sto scrivendo questa risposta supponendo che non sia fattibile, almeno usando la struttura standard - e sto estendendo la mia risposta al caso più generale quando davvero non puoi o non dovresti fare qualcosa.

Basta dire NO.

Ci sono molte risposte "mai dire no" in questa discussione, che ritengo sia un atteggiamento morbido e sottomesso. Pensaci in questo modo: sono l'esperto tecnico di questo team e gli altri membri del nostro team stanno cercando di fare qualcosa che ritengo sia irrealizzabile, complicato, potenzialmente impossibile. È mia responsabilità dire no.

Certo che posso & dovrebbe dire no gentilmente; Posso "raccomandare vivamente contro questo" mentre offro di "indagare se è possibile" prima dire no. Ma alla fine ho intenzione di dire di no perché quello è il mio lavoro.

Ci sono così tante analogie a questo

• Il mio contabile, voglio che metti giù la mia cena del Ringraziamento come detrazione fiscale
• Signor Chef, vorrei che il mio pollo fosse lasciato sul bancone durante la notte e servito crudo, per favore.
• Il mio avvocato, voglio citare in giudizio i miei figli per non aver riordinato le loro camere da letto
• Signor meccanico, per favore installa un turbocompressore sulla mia macchina elettrica

Puoi chiedere a tutte queste persone di svolgere compiti che sapranno essere sciocchi, dispendiosi, pericolosi o sbagliati. E ti aspetteresti che tutti loro sconsiglino queste azioni e alla fine rifiutino (almeno lo spero). Se qualcuno di questi professionisti ha risposto "Hmm ok, immagino che possiamo farlo" - senza darmi una dritta "Questa è una cattiva idea" - quindi francamente non vorrei assumerli comunque.

I tuoi colleghi apprezzeranno e rispetteranno la tua onestà, e risparmierai molto tempo e denaro se fornirai un feedback utile piuttosto che andare d'accordo con qualcosa che sai non funzionerà.

Non dovrebbe essere troppo difficile dire al tuo cliente che non è possibile implementare qualcosa che la piattaforma di destinazione non ti consente. Ma fai un passo indietro e chiediti, qual è la logica dietro a questi requisiti piuttosto ridicoli? Da quello che posso leggere sono molto preoccupati per la facilità d'uso. Poi chiedi loro, scava un po 'più a fondo fino a quando ti dicono la stessa cosa: "vogliamo un'interfaccia user friendly". Quindi guidali in ciò che è fattibile e cosa no. Spiega loro che se vogliono un'interfaccia utente facile ci sono modi semplici (e meno costosi) come lasciare che l'utente imposti le dimensioni di carattere / icona (presumo che sia possibile su IoS). Forse puoi consentire all'utente di controllare la dimensione del carattere / la dimensione dell'icona e la disposizione per l'applicazione attraverso una scheda delle impostazioni? Questo dovrebbe essere più facile (e più accurato!) Di cercare di indovinare l'età di una persona con le dimensioni del pollice! L'ultima cosa che il tuo manager vorrebbe è un codice superfluo, gonfio, difficile da mantenere che raggiunge la stessa cosa che l'OS già fornisce. Dì al tuo cliente che gli utenti preferirebbero controllare l'applicazione piuttosto che l'applicazione controllandoli in modi che potrebbero farli infuriare.

La mia risposta sarebbe che vorrei iniziare a esaminare alcune di queste tecnologie non sperimentate e fargli sapere se è possibile. Sulla base di tali scoperte, è possibile avviare un potenziale piano di sviluppo.

Non penso che sarai in grado di distinguere il pollice di una persona da qualcun altro, ma potresti essere in grado di ottenere abbastanza dimensioni dalle dita per sapere quando stanno usando il pollice. Il vero problema è dovuto all'angolo del pollice che potrebbe non toccare più spazio sullo schermo rispetto ad altri. Nessuno usa mai un telefono con il pollice e lo posiziona sullo schermo come se avessi preso il pollice.

Lascia la compagnia. Scopri come farlo. Vendilo per molti più soldi di quelli che stai facendo ora.

Quando si tratta di requisiti, di solito lo faccio in questo modo: cerco di stimare quanto tempo ci vorrebbe per realizzare un requisito specifico.

In caso di requisiti che potrebbero essere impossibili, richiedere alcuni giorni o il tempo necessario per scoprire se è possibile. Nel tuo caso la domanda è: "È possibile determinare quanto è grosso il dito dell'utente?"

In realtà questa domanda è anche un po 'più complessa: "È possibile determinare quanto spesso il dito dell'utente dopo il primo tocco in meno di 200 millisecondi per consentire un'interazione immediata?" (sostituisci prima con 2nd o ...; e 200 ms con 300 ms o qualsiasi altra cosa ...)

Forse anche rispondere a questa domanda richiede un mese. Forse anche se questo è più o meno fattibile, ci vuole un algoritmo super complesso che funziona solo nell'80% dei casi.

Vedi dove sto andando?

Le persone spesso fanno ipotesi sbagliate sulle possibilità perché hanno scarse competenze ed esperienze riguardo al campo in questione. Quindi non puoi discutere con l'intuizione, ma hai bisogno di fatti.

Se gli altri stakeholder si rendono conto che questa funzione richiederebbe 2 anni-uomo e richiede l'arrivo dell'iPhone 10 prima del 2014, i requisiti saranno rapidamente ridotti.

Sembra complesso ma non impossibile; il punto che il touch screen non è in grado di distinguere tra un pollice, un dito medio o uno stilo è discutibile; all'utente viene chiesto di inizializzare (avvio della sessione, qualunque cosa) per posizionare un pollice, poi un dito medio, ecc. per calibrare le dimensioni (fare alcune medie statistiche) usando diversi movimenti, ecc.

Potrei considerare di provare a risolvere il problema di root in un altro modo prima di dire che non può essere fatto.

Ad esempio, se l'utente prova spesso a fare clic su un pulsante di piccole dimensioni e non riesce, puoi guardare l'area intorno al pulsante e utilizzarlo per ricalibrare tutti gli altri clic.

Presentare una soluzione creativa come questa è probabilmente quello che stanno cercando più che chiedere di calcolare magicamente la larghezza di un dito (che puoi informare non è nell'API).

Potrebbe essere ancora difficile - posizionando un'area intorno ai pulsanti per rilevare le miss, quindi stimare più ore.

Non dire di no, in quanto ciò danneggerebbe i suoi sentimenti. Basta chiarire che a causa dei vincoli tecnologici, il 60% delle volte funzionerà sempre.

E una volta che si rende conto dell'impraticabilità e dei costi coinvolti in tale impegno, suggerire un approccio più pratico all'interno del suo budget, come avere un'impostazione che permetta di cambiare la dimensione del testo. E i russi hanno preso una matita nello spazio.

Cerca di fargli indicare il problema e i requisiti e non la soluzione e la progettazione per i progetti futuri.

Quello che mi piace fare è affrontare il problema dal punto di vista del team. In questo caso, il project manager e io abbiamo bisogno di trovare una soluzione. Mi piace anche mostrare che vengo con una mente aperta. Se sento ciò che penso stia sentendo l'impossibilità, c'è una possibilità che ci sia un malinteso tra me e il project manager. O forse non abbiamo raggiunto questo aha momento.

Una volta che decidiamo di fare un salto e avere una conversazione aperta, trovo più semplice trattare il problema come economico. Nella tecnologia quasi tutto è possibile data una quantità infinita di risorse. Discutere di ciò che sarebbe necessario fare, molte volte è il modo più semplice per rispettare "dire di no". E questo sarebbe il modo di eliminare ogni possibile equivoco. Anche se, a essere onesti, non stiamo affatto dicendo di no. E qual è lo scopo di non dire comunque. Se il lavoro non vale la pena farlo, non importa se lo vogliamo fare o no.