Come può una persona non tecnica imparare a scrivere una specifica per piccoli progetti?

Vedo due buoni approcci possibili a questo problema. Tuttavia, è importante rendersi conto di due cose. In primo luogo, l'ingegneria dei requisiti è un duro lavoro: trasformare un'idea in una specifica formale che sia sufficiente per costruire un sistema richiede molto tempo, sforzi e pratica. In secondo luogo, se si hanno buoni requisiti (in qualsiasi formato, da una specifica formale a storie di utenti meno formali e casi d'uso), sarà molto più facile, economico e veloce realizzare realmente il software (e crearlo prima). / p>

Se il tuo amico chiederà la creazione di numerosi strumenti software o intende stipularli, dovrebbe imparare come scrivere i requisiti software, almeno a livello di obiettivi di business e concetto di operazioni. I due libri principali sull'ingegnerizzazione dei requisiti software sono di Karl Wiegers - Requisiti software (2a edizione) e Ulteriori informazioni sui requisiti software: problemi spinosi e consigli pratici . Mi aspetterei che la maggior parte delle persone che assumerebbe vorrebbe un qualche tipo di documento che descrive il sistema, almeno a livello di obiettivi di business o concetto di operazioni, e questi libri vanno in questo. Esaminano anche il come e il perché di altri aspetti dell'ingegneria dei requisiti che sospetto che un buon sviluppatore sarebbe passato presto nel progetto.

La seconda opzione sarebbe quella di assumere qualcuno con esperienza nello sviluppo di software e ingegneria dei requisiti (e forse anche qualche tipo di ingegneria dei sistemi o architettura di sistema) per capire lo spazio del problema e determinare dove sono necessarie le soluzioni software e dove le soluzioni software non essere utile, scrivere i documenti e forse anche supervisionare o portare avanti lo sforzo di sviluppo. Tuttavia, questo sarebbe probabilmente più costoso e richiederebbe uno sviluppatore di software a tempo pieno per un lungo periodo di tempo per sviluppare non solo il sistema richiesto, ma anche i requisiti e l'architettura necessari.

Onestamente, non penso che ciò che sta sperimentando il tuo amico sia così raro per qualcuno che non capisce il processo di sviluppo del software. Inoltre, non penso che la colpa ricada interamente su di lui. Se il primo progetto software non aveva buoni requisiti, lo sviluppatore (o gli sviluppatori) a cui era stato affidato in outsourcing avrebbe dovuto chiarire, perfezionare e documentare i requisiti. Francamente, non sono sicuro che tu sia la persona giusta per essere coinvolto, se non sei disposto a mettere il tempo o lo sforzo per lavorare con l'utente / cliente non tecnico e sviluppare buone specifiche tecniche (questo è un ruolo chiave di chiunque esegua l'ingegneria dei requisiti in qualsiasi disciplina ingegneristica).

Penso che la soluzione ottimale sia davvero una combinazione delle mie due opzioni. Penso che il tuo amico (e forse anche tu) dovrebbe conoscere ciò che è coinvolto nell'ingegnerizzazione dei requisiti e i vantaggi che un solido fabbisogno può portare a un progetto. Anche tu, come sviluppatore di software, dovresti acquisire maggiore familiarità con l'ingegneria dei requisiti e come ottenere, documentare, analizzare e gestire i requisiti in modo appropriato per i progetti software: è davvero un'abilità preziosa per chiunque lavori in qualsiasi parte del ciclo di vita del software.

Quando ho bisogno di specifiche da un cliente non tecnico, di solito chiedo loro di scrivere in un linguaggio semplice che cosa esattamente vogliono ottenere. Come in "l'app dovrebbe fare da A a B quando premo C, ma solo se D". Bonus extra per "perché D significa che ...".

In effetti "prendi questa colonna e gestisci una media su di essa." è un passo nella giusta direzione. Una spiegazione migliore sarebbe "La tabella contiene questo e quello" (se la struttura è predefinita); "Ottieni una media di X". Fondamentalmente, il modo meno tecnico possibile senza perdere i dettagli.

In altre parole, descrivi l'idea, non l'implementazione.

Quindi un programmatore caring dovrebbe essere in grado di comprendere lo scopo effettivo di ciò che è incaricato di fare e scegliere da solo i passi giusti, ponendo domande per qualsiasi cosa non ovvia.

Se non c'è nessuno a cui importa abbastanza e capisce il processo, il progetto fallirà in ogni caso.

Può provare a utilizzare l'approccio storyboard .

Invitali a scrivere un elenco di cose ( storie ) che l'applicazione dovrà fare e all'interno di tale elenco, approfondire ulteriormente la funzionalità di ciascuna storia.

Può utilizzare uno strumento come Asana per arricchire lo scopo e la funzionalità del progetto e persino interagire con il suo sviluppatore.

Translating it into clear requirements is 10x more work than executing on a clearly written spec.

Amen. Questo spiega anche perché:

the coder he hired didn't think through the corner cases and ask appropriate questions.

Comprendere i requisiti è la parte più difficile (e più costosa) della maggior parte dei progetti di programmazione. Quando una persona non tecnica scrive i requisiti, spesso documenta solo il work-around che desidera sostituire ("apri Excel, fai clic sulla cella B3 ..."). Il meglio che possono sperare è un duplicato esatto della loro attuale difficoltà!

Il modo più produttivo che conosca per aggirare questo è incoraggiare questa persona a scrivere Use Cases ("use" fa rima con "sciolto"). Invece di scrivere requisiti, descrivi come verrà utilizzato il sistema. Ciò lascia allo sviluppatore un po 'di spazio per suggerire una soluzione migliore rispetto a ciò che l'utente sta facendo ora.

Sembra che questo problema sia esacerbato da scarse capacità di comunicazione scritta da parte del tuo amico. Lui o lei deve mettere il lavoro in modo efficace per comunicare le loro idee, o pagare al programmatore di pescare le informazioni da loro. Ciascun processo è doloroso e richiede tempo, ma farlo da solo è meno costoso che pagare qualcuno per farlo con te.

In ogni caso, questa è una difficoltà comune e frustrante in cui le persone creative hanno un'idea incompleta o non sono in grado di descriverle in meno di un milione di parole. Questa persona dovrebbe cercare di trovare un programmatore estremamente paziente e perspicace che sia disposto ad andare fino in fondo a ciò che sta realmente cercando di fare e farlo accadere.

the coder he hired didn't... ask appropriate questions

Questa è una ricetta per il disastro. Questo, e anche l'aspettativa che il programmatore chiederà . I coder amano codificare, non comunicare, aspettarsi che spezzino le loro abitudini senza un incentivo è piuttosto irrealistico.

Se il tuo amico vuole ottenere un lavoro, è meglio che stabilisca un processo che implichi una comunicazione continua con il programmatore - ed è tuo amico che deve svolgere un ruolo attivo in questo, non nel programmatore. "Mostrami cosa viene fatto ogni lunedì e imposta due ore per discuterne ogni martedì", cose del genere.

• Per un'introduzione, fornisci loro alcune panoramiche leggere di metodologie di sviluppo iterative e agili (gli articoli di Wikipedia lo faranno), in modo che abbiano un'idea di come dovrebbe essere.
  
• Per aiutarli a capire i fallimenti passati, fornisci loro alcune panoramiche leggere di Waterfall / Big Design Up Front (quelli che includono le critiche - di nuovo, gli articoli di Wikipedia lo faranno) - questi in genere fanno un buon lavoro spiegando come è generalmente difficile specifica le cose in anticipo.

Nella mia esperienza, il modo più affidabile per far funzionare il software come desiderato con i clienti non tecnici era quello di comunicare in modo permanente e iterare le descrizioni delle funzioni, senza tentare di specificarlo a morte in un colpo solo.

Most of his scripts are statistical and data processing oriented. e.g. take this column and run an average over it. Remove these rows under these conditions. So the challenge is different than spec'ing a web app.

È diverso - sembra molto più semplice che specificare un'app web. È un processo logico. Questa è la roba facile.

Il tuo amico ha semplicemente bisogno di annotare i passaggi che prende quando esegue questo processo. Può farlo comunque, ma le cose fondamentali su cui concentrarsi sono accuratezza, concisione e chiarezza. Non c'è ragione per cui non possa essere fatto puramente nel testo come un manoscritto; trarrebbe vantaggio da una divisione logica di componenti o attività e probabilmente funzionerebbe bene come diagramma di flusso o diagramma.

Ora il tuo amico dovrebbe trovare un analista / sviluppatore competente e coinvolgere i suoi servizi pezzo per pezzo. Ha bisogno di esprimere le sue aspettative - ogni giorno o almeno più volte alla settimana il tuo amico dovrebbe incontrarsi con lo sviluppatore e vedere le mani sulla dimostrazione dei progressi. Il tuo amico pagherà lo sviluppatore per il suo tempo durante queste dimostrazioni, ma ne varrà la pena per garantire che il progetto venga eseguito secondo le specifiche. Eventuali modifiche alle specifiche, ad esempio le omissioni dei tuoi amici, devono essere negoziate e probabilmente aggiunte al prezzo quotato.

Nota che ho detto "competente" - questo non è lo stesso di "media", perché ci sono molti sviluppatori "medi" che non sono competenti. Se il tuo amico ottiene solo il programmatore più economico, o trova qualcuno online, dovrebbe aspettarsi dei problemi. Non suggerire che le persone che trovano lavoro online non sono buone, ma non darei lavoro a qualcuno senza una raccomandazione.

Il tuo amico deve semplicemente trovare la persona giusta. In ogni progetto software c'è bisogno di analisti, programmatori, amministratori di sistema, tester e project manager. Più di questi ruoli il tuo amico vuole "esternalizzare", più esperto sarà il fornitore e più il tuo amico dovrebbe aspettarsi di pagare.

Mi spiace essere l'unico a dirti questo, ma non è compito di una persona non tecnica imparare come scrivere le specifiche formali. Il compito dello sviluppatore è di intervistare la persona non tecnica, cercare di distillare ciò che la persona ti dice su quello che cercano, determinare che cosa desidera realmente il cliente (al contrario di ciò che pensano di volere, che non è sempre la stessa cosa), costruisci un documento dei requisiti relativamente informale (uno che è ben strutturato ma che cerca di evitare il gergo che il cliente non capirà) e rivedere quel documento con il cliente.

Una volta che il cliente è soddisfatto del documento informale sui requisiti, è possibile utilizzarlo come base per la stesura di una specifica dei requisiti più formale che inizia a fornire dettagli più tecnici su ciò che è necessario.

L'intero processo è noto come "acquisizione dei requisiti" e costituisce il primo passo nel processo di ingegneria del software. In realtà scrivere il software è solo una parte relativamente piccola dell'ingegneria del software, un fatto che purtroppo molti sviluppatori di software dimenticano. Un'altra cosa che sembrano dimenticare è che c'è un strong bisogno di comunicare con il cliente e mantenere un dialogo con loro durante l'intero processo per garantire che le cose rimangano in pista.

Per quanto riguarda la comunicazione con persone non tecniche, è di vitale importanza cercare di evitare l'uso del gergo dei computer e dello sviluppo del software quando si parla con loro. Se usano termini gergali dal proprio campo, è importante capire cosa significano questi termini, quindi potresti voler redigere un glossario del progetto per ottenere definizioni formali per questi termini. Dopo tutto, lavori per loro, quindi è importante capire da dove provengono.

invece di gergo, dovresti provare a usare metodi non intimidatori per comunicare con il tuo cliente, i documenti scritti in inglese semplice sono di aiuto, ma molte persone nel business del software sono abituate a scrivere per computer piuttosto che per umani e così potrebbe trovarlo difficile Inoltre, ai clienti non piace leggere grandi cumuli di carta, non importa quanto sia semplice la loro lingua, quindi potresti voler ricorrere ai sussidi visivi. Diagrammi, wireframe e storyboard sono strumenti utili qui.

Ma in breve, il punto centrale è che non è compito del tuo cliente imparare la tua lingua, è tuo imparare la loro lingua.