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

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

Un mio amico sta cercando di esternalizzare alcuni sviluppi su un progetto statistico.

In particolare, fa molto lavoro in Excel e vuole esternalizzare la creazione di script per fare ciò che ora fa a mano.

Tuttavia, il mio amico è estremamente non tecnico. È scarso nello scrivere le specifiche tecniche.

Quando scrive una specifica, è scritto nel modo in cui descriveresti di fare qualcosa in Excel (vai in questa cella e quindi copia il valore in quella cella). È anche eccessivamente prolisso e fa esempi più volte. Non sono sicuro che descriva correttamente i casi d'angolo.

Il primo progetto che esternalizzò fu un fallimento. Penso che abbia descritto in modo eccessivo alcuni dettagli, ma sottodescritto i casi d'angolo. Quello e / o il programmatore che ha assunto non ha riflettuto sui casi angolari e ha posto le domande appropriate. Non ne sono sicuro. Ho iniziato a lavorare con lui e mi ci è voluta mezz'ora per scoprire una descrizione che avrebbe dovuto impiegare almeno cinque minuti per descriverla. Alla fine ho scritto gli script per lui, ma non ho esaminato il motivo per cui il suo processo con il programmatore non è riuscito.

Mi ha chiesto aiuto. Tuttavia, mi rifiuto di essere coinvolto, perché prendere le sue specifiche e tradurle in requisiti chiari è 10 volte più lavoro rispetto all'esecuzione su specifiche chiaramente scritte.

Qual è il modo giusto per imparare? Ci sono risorse che potrebbe usare? Ci sono modi in cui può imparare da piccoli progetti di pratica a bassa pressione con programmatori?

La maggior parte dei suoi script sono orientati all'elaborazione statistica e dei dati. ad esempio prendere questa colonna e passarci sopra una media. Rimuovere queste righe in queste condizioni. Quindi la sfida è diversa dalla specifica di un'app web.

Vedo due buoni possibili approcci a questo problema. Tuttavia, è importante realizzare due cose. Innanzitutto, l'ingegnerizzazione dei requisiti è un duro lavoro: trasformare un'idea in una specifica formale sufficiente per costruire un sistema richiede molto tempo, impegno e pratica. In secondo luogo, se si hanno buoni requisiti (in qualsiasi formato, da specifiche formali a user story e casi d'uso meno formali), sarà molto più semplice, economico e veloce costruire il software (e costruirlo subito prima).

Se il tuo amico chiederà la creazione di numerosi strumenti software o intende contrarli, dovrebbe imparare a scrivere i requisiti software, almeno a livello di obiettivi aziendali e concetto di operazioni. I due libri di spicco sull'ingegneria dei requisiti software sono di Karl Wiegers - Requisiti software (2a edizione) e Ulteriori informazioni sui requisiti software: problemi spinosi e consigli pratici . Mi aspetto che la maggior parte delle persone che assumerebbe vorrebbe una sorta di documento che descriva il sistema, almeno a livello di obiettivi aziendali o concetto di operazioni, e questi libri entrano in questo. Esaminano anche come e perché di altri aspetti dell'ingegneria dei requisiti che sospetterei che un buon sviluppatore avrebbe affrontato all'inizio del progetto.

La seconda opzione sarebbe quella di assumere qualcuno con esperienza nello sviluppo del software e nell'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 soluzioni software e dove soluzioni software non sarebbero utile, scrivere i documenti e forse anche supervisionare o svolgere lo sforzo di sviluppo. Tuttavia, questo sarebbe probabilmente più costoso e equivarrebbe ad assumere 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 vivendo il tuo amico sia così insolito per qualcuno che non capisce il processo di sviluppo del software. Non penso nemmeno che la colpa sia interamente di lui. Se il primo progetto software non aveva buoni requisiti, gli sviluppatori a cui era stato affidato in outsourcing avrebbero dovuto chiarire, perfezionare e documentare i requisiti. Francamente, non sono sicuro che tu sia la persona giusta per essere coinvolto, anche se non sei disposto a dedicare il tempo o lo sforzo di lavorare con l'utente / cliente non tecnico e sviluppare buone specifiche tecniche (questo è un ruolo chiave di chiunque esegua 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'ingegneria dei requisiti e i benefici che avere requisiti solidi può portare a un progetto. Come sviluppatore di software, dovresti anche acquisire maggiore familiarità con l'ingegneria dei requisiti e come ottenere, documentare, analizzare e gestire i requisiti nel 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 cosa vogliono esattamente realizzare. 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 passaci sopra una media". è 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 premuroso dovrebbe essere in grado di comprendere lo scopo reale di ciò che gli è stato commissionato e scegliere lui stesso i passi giusti, ponendo domande per qualsiasi cosa non ovvia.

Se non c'è nessuno che si preoccupi abbastanza e comprenda il processo, il progetto fallirà comunque.

Può provare a utilizzare l' approccio storyboard .

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

Può usare uno strumento come Asana per approfondire la portata e la funzionalità del progetto e persino interagire con il suo sviluppatore.

Tradurlo in requisiti chiari è 10 volte più lavoro rispetto all'esecuzione su una specifica chiaramente scritta.

Amen. Questo spiega anche perché:

il programmatore che ha assunto non ha riflettuto sui casi angolari e ha posto le domande appropriate.

Comprendere i requisiti è la parte più difficile (e più costosa) della maggior parte dei progetti di programmazione. Quando una persona non tecnica scrive requisiti, spesso documenta solo la soluzione 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 conosco per ovviare a questo è incoraggiare questa persona a scrivere Use Cases ("usa" fa rima con "loose"). Invece di scrivere i requisiti, descrivi come verrà utilizzato il sistema. Questo 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 aggravato da scarse abilità comunicative scritte da parte del tuo amico. Lui / Lei deve o impegnare il lavoro a comunicare efficacemente le proprie idee, o pagare il programmatore per ricavarne le informazioni. Entrambi i processi sono dolorosi e richiedono molto tempo, ma farlo da soli è 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 sono incapaci di descriverla in meno di un milione di parole. Questa persona dovrebbe cercare di trovare un programmatore estremamente paziente e perspicace che è disposto ad arrivare al fondo di ciò che sta davvero cercando di fare e farlo accadere.

il programmatore che ha assunto non ... ha posto le domande appropriate

Questa è una ricetta per il disastro. Questo, e anche l'aspettativa che coder sarà chiedere. Ai programmatori piace programmare, non comunicare, aspettandosi che rompano le loro abitudini senza incentivi è piuttosto irrealistico.

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

• Per un'introduzione, fornisci loro alcune panoramiche leggere delle metodologie iterative e di sviluppo Agile (faranno gli articoli di Wikipedia), in modo che possano avere 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 critiche - di nuovo, faranno gli articoli di Wikipedia) - questi in genere fanno un buon lavoro spiegando come sia generalmente difficile specificare le cose giuste in anticipo.

Nella mia esperienza, il modo più affidabile per far funzionare il software come desiderato con clienti non tecnici era comunicare in modo permanente e iterare le descrizioni delle funzionalità, senza cercare di specificarlo fino alla morte in un colpo solo.

La maggior parte dei suoi script sono orientati all'elaborazione statistica e dei dati. ad esempio prendere questa colonna e passarci sopra una media. Rimuovere queste righe in queste condizioni. Quindi la sfida è diversa dalla specifica di un'app web.

È diverso: sembra molto più semplice che specificare un'app Web. È un processo logico. Questa è roba facile.

Il tuo amico ha semplicemente bisogno di annotare i passi che prende quando esegue questo processo. Può farlo come vuole, ma le cose chiave su cui concentrarsi sono accuratezza, concisione e chiarezza. Non c'è motivo per cui non possa essere fatto semplicemente in un testo come un manoscritto; trarrebbe beneficio 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 impegnare i suoi servizi pezzo per pezzo. Ha bisogno di delineare le sue aspettative: quotidianamente o almeno più volte alla settimana il tuo amico dovrebbe incontrare lo sviluppatore e vedere una dimostrazione pratica dei progressi. Il tuo amico pagherà lo sviluppatore per il suo tempo durante queste dimostrazioni, ma ne varrà la pena per assicurarsi che il progetto venga eseguito secondo le specifiche. Eventuali modifiche alle specifiche, ovvero cose che il tuo amico ha omesso, devono essere negoziate e probabilmente aggiunte al prezzo indicato.

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

Il tuo amico deve semplicemente trovare la persona giusta. In qualsiasi progetto software sono necessari analisti, programmatori, amministratori di sistema, tester e project manager. Più di questi ruoli il tuo amico vuole "esternalizzare", più abile sarà il fornitore e più il tuo amico dovrebbe aspettarsi di pagare.

Mi dispiace essere quello di romperti questo, ma non è compito di una persona non tecnica imparare a scrivere specifiche formali. È compito dello sviluppatore intervistare la persona non tecnica, cercare di distillare ciò che la persona ti dice su ciò che stanno cercando, determinare ciò che il cliente vuole davvero (al contrario di ciò che pensano di volere, che non è sempre la stessa cosa), creare un documento di requisiti relativamente informali (uno 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 sui requisiti informali, è possibile utilizzarlo come base per redigere una specifica di requisiti più formale che inizia ad entrare in maggiori dettagli 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à la scrittura del 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 forte bisogno di comunicare con il cliente e mantenere un dialogo con loro durante l'intero processo per garantire che le cose rimangano sulla buona strada.

Per quanto riguarda la comunicazione con persone non tecniche, è di vitale importanza cercare di evitare di usare il gergo dei computer e dello sviluppo 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. Dopotutto stai lavorando per loro, quindi è importante capire da dove provengono.

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

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