{"id":230312,"date":"2022-11-18T14:48:00","date_gmt":"2022-11-18T11:48:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=230312"},"modified":"2022-11-09T21:05:06","modified_gmt":"2022-11-09T18:05:06","slug":"programmazione-orientata-agli-oggetti-in-wordpress-comprendere-le-aspettative-dei-clienti","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/programmazione-orientata-agli-oggetti-in-wordpress-comprendere-le-aspettative-dei-clienti\/","title":{"rendered":"Programmazione orientata agli oggetti in WordPress: comprendere le aspettative dei clienti"},"content":{"rendered":"\n<p>Mentre continuiamo a portare avanti la discussione <a href=\"https:\/\/tommcfarlin.com\/tag\/object-oriented-programming-in-wordpress\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">sulla programmazione orientata agli oggetti in WordPress<\/a>, \u00e8 importante assicurarci di non superare noi stessi quando si tratta di creare un prodotto per qualcun altro.<\/p>\n<p>Molto spesso \u00e8 facile:<\/p>\n<ol>\n<li>ascolta cosa dice un cliente,<\/li>\n<li>costruire qualcosa in base a ci\u00f2 che abbiamo sentito,<\/li>\n<li>consegnarlo a detto cliente.<\/li>\n<\/ol>\n<p>Ma c&#8217;\u00e8 molto di pi\u00f9. Ci ho ballato un po&#8217; nei post precedenti di questa serie; tuttavia, voglio iniziare a approfondire cosa significa ascoltare:<\/p>\n<ol>\n<li>Cosa dice un cliente,<\/li>\n<li>Sviluppare una serie di requisiti,<\/li>\n<li>E poi crea dei circuiti di feedback intorno a questo.<\/li>\n<\/ol>\n<p>In definitiva, vogliamo assicurarci che le persone per le quali stiamo lavorando e le soluzioni che stiamo costruendo siano davvero soluzioni e non ostacoli o ostacoli su cui devono saltare.<\/p>\n<p>Inoltre, non credo sia sufficiente che un cliente si goda semplicemente l&#8217;esperienza del prodotto finale, ma anche lavorare con colui (o quelli) che costruisce la soluzione.<\/p>\n<p>Detto questo, diamo un&#8217;occhiata a cosa significa ascoltare quello che dicono e andare da l\u00ec.<\/p>\n<h2>Comprendere le aspettative dei clienti<\/h2>\n<p>Ogni volta che leggi libri o altro materiale su questo tipo di cose, spesso una delle due parti diventa il &quot;cattivo ragazzo&quot;. Non sempre, ma a volte fa:<\/p>\n<ul>\n<li>il cliente sembra ignorare di cosa sta parlando,<\/li>\n<li>o fa sembrare lo sviluppatore un idiota per comportarsi come qualcuno che sa di pi\u00f9 sull&#8217;argomento in questione.<\/li>\n<\/ul>\n<p>Che ne dici di una terza opzione in cui il cliente ha un&#8217;idea chiara di ci\u00f2 che vuole, gli sviluppatori sono disposti ad ascoltare e lavorare insieme al cliente per costruire qualcosa?<\/p>\n<p>Certo, ci saranno dei chiarimenti lungo il percorso, e ci saranno dei termini che dovranno essere definiti, e qualche &quot;ricalibrazione&quot; del calendario di sviluppo potrebbe anche farne parte.<\/p>\n<p>Ma la linea di fondo \u00e8 questa: nessuna delle parti dovrebbe lavorare contro l&#8217;altra. Invece, si tratta di lavorare insieme per la soluzione. Certo, richiede comunicazione (in cui gli sviluppatori non sono sempre bravi, nella mia esperienza, ma non c&#8217;\u00e8 motivo per cui non possa essere migliore).<\/p>\n<h3>Cosa dice un cliente? (Cosa dice lo sviluppatore?)<\/h3>\n<p>Ogni volta che vi incontrate, probabilmente state pensando la stessa cosa perch\u00e9 ognuno di voi parla una lingua diversa e ognuno di voi pensa che quello che l&#8217;altro dice sia <a href=\"https:\/\/www.google.com\/search?client=safari&#038;rls=en&#038;q=define+jargon&#038;ie=UTF-8&#038;oe=UTF-8\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">gergo<\/a>.<\/p>\n<p>E non \u00e8 sbagliato.<\/p>\n<p>I clienti hanno un modo per parlare di ci\u00f2 che vogliono e gli sviluppatori hanno un modo per parlare di come consegneranno.<\/p>\n<h3>I termini che utilizziamo<\/h3>\n<p>Ma ci pu\u00f2 essere un obiettivo comune.<\/p>\n<blockquote>\n<p>Cerca una descrizione del problema che sta cercando di essere risolto. Cerca di farlo in parole povere in modo che il design sia in linea con l&#8217;obiettivo e la funzionalit\u00e0 della soluzione.<\/p>\n<\/blockquote>\n<p>Non credo che funzioner\u00e0 per tutti, ma questa \u00e8 la prima cosa che consiglio di fare ogni volta che ti siedi con il tuo cliente.<\/p>\n<p>Come vedrai pi\u00f9 avanti in questi post, aiuta a sviluppare alcune frasi che puoi usare all&#8217;inizio della tua dichiarazione di lavoro a cui puoi fare riferimento ogni volta che hai una decisione da prendere.<\/p>\n<p>In altre parole, tu (e loro) potete chiedere:<\/p>\n<blockquote>\n<p>Ci\u00f2 su cui sto lavorando contribuisce all&#8217;obiettivo comune?<\/p>\n<\/blockquote>\n<p>Ed \u00e8 qui che puoi determinare la serie di requisiti fondamentali.<\/p>\n<h3>&quot;Deve&#8230;&quot;<\/h3>\n<p>Quando si tratta di acquistare qualcosa, costruire qualcosa, richiedere qualcosa, volere qualcosa o qualsiasi altra cosa, \u00e8 abbastanza facile iniziare la frase dicendo &quot;Voglio che&#8230;&quot;<\/p>\n<p>Ma c&#8217;\u00e8 una grande differenza tra &quot;Voglio che faccia [fare qualcosa]&quot; e &quot;Ne ho bisogno [per fare qualcosa]&quot;, e quando lavori nel software, \u00e8 generalmente sicuro dire che le cose che sono necessarie sono fondamentali all&#8217;applicazione. E le cose che si desiderano sono ci\u00f2 che viene dopo che \u00e8 stata creata la base dell&#8217;applicazione.<\/p>\n<p>Cio\u00e8, \u00e8 una conversazione su &quot;must-have&quot; e &quot;want-to-have&quot;. Ed \u00e8 importante avere conversazioni in modo da poter arrivare a quella dichiarazione finale dell&#8217;obiettivo comune dell&#8217;applicazione.<\/p>\n<p>Una volta che \u00e8 a posto, puoi iniziare quindi a pianificare il tuo software in base al problema del cliente. Ed \u00e8 qui che entra in gioco la raccolta dei requisiti.<\/p>\n<h2>Requisiti in via di sviluppo<\/h2>\n<p>Ci\u00f2 che tu e il cliente avete una solida comprensione di ci\u00f2 che deve essere costruito, allora \u00e8 il momento di mettere insieme i requisiti.<\/p>\n<p>Questa parte pu\u00f2 essere pi\u00f9 divertente di quanto sembri. Lo so, lo so: suona come un compito o un compito, giusto? Ma non lo \u00e8. Invece, sta prendendo quello che vogliono, quello che hai capito, traducendolo in un linguaggio comune e poi scrivendo un documento che spieghi cosa far\u00e0 il software.<\/p>\n<p>A seconda della tua esperienza, per\u00f2, questo pu\u00f2 essere noioso. E per noioso, intendo una delle parti peggiori del tuo lavoro. Inoltre, i requisiti cambiano sempre, giusto?<\/p>\n<p>Non sempre.<\/p>\n<p>Se ti prendi del tempo per capire cosa vogliono dall&#8217;inizio, allora i requisiti non devono essere un documento di 50 pagine che delinei come ogni singolo modulo deve funzionare.<\/p>\n<p>Molti libri lo documentano dicendo che \u00e8 cos\u00ec che deve essere. Ma in quasi un decennio in questo modo, non ho mai avuto un arco di tempo cos\u00ec lungo e i clienti in genere sono stati incredibilmente grati di vedere un breve elenco che pu\u00f2 essere modificato tramite e-mail o Google Docs, firmato e quindi indicato come il progetto si sposta inoltrare.<\/p>\n<p>Ne parler\u00f2 di pi\u00f9 in futuro, ma qualunque sia la brutta esperienza che hai, la paura o la trepidazione che hai non devi sederti. E continueremo a parlarne attraverso questa serie.<\/p>\n<p><div id=\"PostUnique_PostSource\" style=\"padding-top: 50px\">Fonte di registrazione:  <a target=\"_blank\" rel=\"noopener nofollow\" href=\"\/\/tommcfarlin.com\" class=\"external external_icon\">tommcfarlin.com<\/a><\/div><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Comprendere le aspettative dei clienti \u00e8 importante tanto quanto i clienti capiscono cosa sei in grado di fare. Ed \u00e8 ci\u00f2 che \u00e8 trattato in questo post.<\/p>\n","protected":false},"author":1,"featured_media":165308,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[896,720,844],"tags":[1168],"class_list":["post-230312","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-codice","category-sviluppatore","category-tutorial","tag-affiai-it"],"_links":{"self":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/230312","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/comments?post=230312"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/230312\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media\/165308"}],"wp:attachment":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media?parent=230312"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/categories?post=230312"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/tags?post=230312"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}