Con i tuoi discorsi su sviluppatori e proprietari di prodotti, mi sembra che tu non abbia una persona di mezzo responsabile delle funzionalità della tua organizzazione.
Bene, nella mia organizzazione, sono quella persona. Sono l'ingegnere dei requisiti, colui che ha imparato a definire buone specifiche e a scegliere funzionalità che si traducono in un software di alta qualità con un design di interazione intuitivo. (In altre organizzazioni è la persona UX che ottiene lo stesso lavoro, potresti avere più familiarità con quel termine).
E posso dirti: ottenere una buona specifica è difficile. Naturalmente, gli sviluppatori odiano farlo. È un peso per loro: sono lì per costruire un software, non per pensare ai giochi di potere tra le parti interessate e ai modelli mentali degli utenti pigri. Ma sai una cosa? È un onere anche per i proprietari dei prodotti. Non conoscono meglio quali funzionalità dovrebbero contenere i loro software rispetto agli sviluppatori o agli utenti. La creazione di una specifica valida è un'abilità appresa e se non l'hai mai imparata, non puoi esserne brava. Certo, ci sono molti sviluppatori e proprietari di prodotti che possono farlo, perché hanno dovuto farlo in progetti precedenti. Ma il proprietario o lo sviluppatore medio del prodotto lotta con esso, perché naturalmente non è compito suo farlo. Non tutti coloro che possono guidare un'auto possono progettare un'auto; allo stesso modo,
Puoi sviluppare software senza un ingegnere dei requisiti? Certo che puoi. Mettere l'intero peso delle specifiche sulle spalle del proprietario del prodotto non è giusto e non va bene per il risultato del progetto. Soprattutto perché si trova di fronte a un compito insolitamente difficile per lui, ottenere input e supporto dagli altri è molto utile. Se ti trovi in una situazione del genere, non guardare il tuo povero proprietario del prodotto e dire "dimmi cosa devo fare per te e io ti farò", non sa davvero di cosa ha bisogno. Ma una discussione con te lo aiuterà ad articolare i suoi pensieri ed esplorare le sue idee.
Quando non c'è nessun ingegnere dei requisiti nella struttura del progetto, c'è un altro problema: non c'è un moderatore. Tutti gli sviluppatori sono dal punto di vista tecnico, tutti i proprietari di prodotti sono dal lato degli affari. Quando le due culture si scontrano, possono sorgere conflitti, con ciascuna parte che giudica l'altra stupida e irragionevole (perché usa il proprio sistema di valori per giudicare). Quindi, parla con il proprietario del tuo prodotto delle possibili funzionalità, ma sii educato e paziente anche quando pensi che non se lo meriti; il successo del progetto dipende dal modo in cui voi due potete andare d'accordo, e talvolta prendere la decisione non ottimale è meglio che non prendere alcuna decisione a causa del conflitto. Potrebbe essere utile stabilire una gerarchia e dare a uno di voi due l'ultima parola, in quanto ciò impedisce conflitti in stallo. Se ottiene l'ultima parola, rimanda ad essa anche se ritieni che sia ingiusto.
Informazioni sulla parte "passiva": se non hai idee, non cercare di inventare qualcosa solo per mostrare attività. Se il proprietario del prodotto è già insicuro e non conosce buoni criteri per valutare le proprie idee, strane idee "solo per avere qualcosa" renderanno ancora più difficile una situazione già difficile. Elaborare idee utili non è magico, ma richiede conoscenza. Se non l'hai imparato dai libri di testo, probabilmente avrai bisogno di alcuni anni di esperienza degli sviluppatori, specialmente in progetti in cui sei esposto agli utenti o ai dati di usabilità generati dagli utenti (analisi, misurazioni della soddisfazione) prima che il tuo cervello risolva i modelli da solo e inizi a notare: c'è un problema che possiamo risolvere qui. Sembra che agli utenti manchi qualcosa in questa pagina, cosa può essere? Quindi avrai buone idee da condividere.
Conclusione 1: nei progetti senza ingegnere per i requisiti, è bene fornire suggerimenti quando sono disponibili. Fallo con sensibilità e tatto: è indispensabile evitare conflitti anche se ciò significa che la tua buona idea viene stroncata sul nascere.
E se fai parte di una squadra con un ingegnere requisiti?
Adoro ascoltare le idee delle caratteristiche di tutti! Sì, a volte le idee degli sviluppatori sono terribili (quando vogliono far sì che l'interfaccia utente segua la logica di programmazione). Le idee dei proprietari dei prodotti sono spesso terribili (quando vogliono il sole e la luna con un budget ridotto - oh, e l'utente dovrebbe inserire pagine di informazioni personali con la massima qualità dei dati, senza ottenere nulla in cambio). Ma il mio compito è quello di elaborare una specifica che faccia bene a tutti i membri del team. E anche se la tua idea non funzionerà mai, sentirla mi rende consapevole che hai delle preoccupazioni. Potresti aver scelto la soluzione sbagliata da suggerire, ma ciò non rende la tua preoccupazione meno valida. Se l'hai notato, probabilmente deve essere affrontato (o devo trovare un motivo per cui non è una minaccia). Se hai un ingegnere dei requisiti responsabile della specifica, non esitare mai ad andare da loro con suggerimenti. Se non ti ascoltano, stanno facendo qualcosa di sbagliato (nota che "considerare" non significa "accettare").
Un ingegnere dei requisiti deve visualizzare il progetto dal punto di vista di ciascun stakeholder separatamente (e talvolta allo stesso tempo). Siamo solo umani e spesso non ci riusciamo. Se sei lì per fornire il tuo vero punto di vista, invece del punto di vista che pensiamo di avere, allora il tuo contributo è molto prezioso.
Puoi essere più libero nel tuo comportamento qui. Il mio compito è di ballare la sensibilità. Non essere apertamente aggressivo, questo ostacola il mio lavoro, ma hai bisogno di meno autocontrollo e consapevolezza culturale / comunicativa, perché posso prendere il controllo. Inoltre, non stai fluttuando, in una situazione in cui ci sono due idee contrastanti e nessuno può giudicare quale sia il migliore. Dovrei saperlo, e se non funziona, è la mia testa nel cappio.
Conclusione 2: se nel team è presente un ingegnere dei requisiti, consultare i suggerimenti sulle funzionalità del prodotto. Questa volta non hai bisogno di guanti di velluto.
E infine, se non ci fosse un ingegnere dei requisiti, il proprietario del prodotto è sopraffatto e in cerca di idee, il capo ti sta puntando e non hai idee da offrire?
Hai alcune opzioni. L'unico è, come hai detto, smettere. Non tutte le organizzazioni funzionano in questo modo e se questo ambiente non è adatto a te, trovane uno migliore. Ti farà bene a lungo termine.
Puoi anche aspettare e vedere se qualcosa cambia. Il prossimo progetto può avere un product owner più esperto (o uno con più leadership). Ma non puoi fermarti per sempre.
La terza opzione è quella di imparare da soli alcuni requisiti tecnici. Questa è un'abilità molto ricercata in questi giorni. Anche se non hai mai intenzione di assumere posizioni in cui sei un ingegnere dei requisiti a tempo pieno, avere questa abilità migliora il tuo valore come sviluppatore, in quanto ti consente di capire meglio gli altri membri del tuo team (e dei tuoi utenti) e rende il processo di sviluppo procede più agevolmente. E non devi andare fino in fondo. Un libro di testo entry-level che spiega attività, flussi di lavoro, modelli mentali e modelli di dati centrati sull'utente ti consentirà già di individuare molte opportunità di miglioramento in un software progettato da un team di uomini d'affari e sviluppatori. Don' Andiamo per i libri più spessi intesi come riferimento per gli accademici (come la recente traduzione di Pohl in inglese): sono più un elenco di tutti i metodi possibili per ogni piccolo passo, senza una spiegazione su come eseguirli. Scegli qualcosa orientato alla pratica.
Se lo provi e scopri che non hai alcun interesse personale nella zona, va comunque bene. Non forzarti a fare qualcosa che non ti piace. Ma probabilmente dovresti cercare un lavoro in un'organizzazione con una diversa struttura del team.
Conclusione 3: invece di aspettare anni per avere una comprensione intuitiva, leggi un libro o due e avrai già buone idee da fornire