<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Doing the job of the customer?	</title>
	<atom:link href="http://matteo.vaccari.name/blog/archives/833/feed" rel="self" type="application/rss+xml" />
	<link>http://matteo.vaccari.name/blog/archives/833</link>
	<description>Extreme enthusiasm</description>
	<lastBuildDate>
	Mon, 25 Feb 2019 15:18:16 +0000	</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.1.1</generator>
			<item>
				<title>
				By: matteo				</title>
				<link>http://matteo.vaccari.name/blog/archives/833/comment-page-1#comment-95907</link>
		<dc:creator><![CDATA[matteo]]></dc:creator>
		<pubDate>Sun, 31 Mar 2013 16:04:14 +0000</pubDate>
		<guid isPermaLink="false">http://matteo.vaccari.name/blog/?p=833#comment-95907</guid>
					<description><![CDATA[Sì Tommaso, hai centrato il problema. Se siamo d&#039;accordo che il cliente (di solito) non sa che cosa gli serve veramente, allora la cosa più sciocca che possiamo fare è *fare tutto quello che ci chiede* senza fare domande. 

Invece domande dobbiamo farne tante, per essere sicuri che quello che facciamo sia in linea con i reali obiettivi.  Dobbiamo fare saltare fuori le assunzioni nascoste e fare qualcosa per verificare se sono valide.

E poi tutto questo lavoro dobbiamo farlo *insieme* al cliente.  Non possiamo fare diversamente da quello che ci chiede, solo perché pensiamo di saperla più lunga.  Anzi, decidiamo insieme al cliente, in base a quello che sappiamo finora, quale sembra essere la maniera migliore di raggiungere l&#039;obiettivo di business.

E..... non ti dico che sia facile. :-)

Un libretto molto utile per approfondire questi temi è Impact Mapping di Gojko Adzik (http://www.impactmapping.org/).  Io nel mio piccolo ho già parlato di queste cose; oltre che quest&#039;anno al Codemotion, anche a Better Software nel 2011 (http://matteo.vaccari.name/blog/archives/628).]]></description>
		<content:encoded><![CDATA[<p>Sì Tommaso, hai centrato il problema. Se siamo d&#8217;accordo che il cliente (di solito) non sa che cosa gli serve veramente, allora la cosa più sciocca che possiamo fare è *fare tutto quello che ci chiede* senza fare domande. </p>
<p>Invece domande dobbiamo farne tante, per essere sicuri che quello che facciamo sia in linea con i reali obiettivi.  Dobbiamo fare saltare fuori le assunzioni nascoste e fare qualcosa per verificare se sono valide.</p>
<p>E poi tutto questo lavoro dobbiamo farlo *insieme* al cliente.  Non possiamo fare diversamente da quello che ci chiede, solo perché pensiamo di saperla più lunga.  Anzi, decidiamo insieme al cliente, in base a quello che sappiamo finora, quale sembra essere la maniera migliore di raggiungere l&#8217;obiettivo di business.</p>
<p>E&#8230;.. non ti dico che sia facile. :-)</p>
<p>Un libretto molto utile per approfondire questi temi è Impact Mapping di Gojko Adzik (<a href="http://www.impactmapping.org/" rel="nofollow">http://www.impactmapping.org/</a>).  Io nel mio piccolo ho già parlato di queste cose; oltre che quest&#8217;anno al Codemotion, anche a Better Software nel 2011 (<a href="http://matteo.vaccari.name/blog/archives/628" rel="nofollow">http://matteo.vaccari.name/blog/archives/628</a>).</p>
]]></content:encoded>
						</item>
						<item>
				<title>
				By: Tommaso Torti				</title>
				<link>http://matteo.vaccari.name/blog/archives/833/comment-page-1#comment-95894</link>
		<dc:creator><![CDATA[Tommaso Torti]]></dc:creator>
		<pubDate>Fri, 29 Mar 2013 14:46:31 +0000</pubDate>
		<guid isPermaLink="false">http://matteo.vaccari.name/blog/?p=833#comment-95894</guid>
					<description><![CDATA[Il discorso regge ed è sensato finché non entra in gioco l&#039;economia. 
Ovvero quando il cliente si lamenta che vengono fatti pochi progressi, senza considerare per l&#039;appunto che &quot;noi stiamo facendo il suo lavoro&quot;.]]></description>
		<content:encoded><![CDATA[<p>Il discorso regge ed è sensato finché non entra in gioco l&#8217;economia.<br />
Ovvero quando il cliente si lamenta che vengono fatti pochi progressi, senza considerare per l&#8217;appunto che &#8220;noi stiamo facendo il suo lavoro&#8221;.</p>
]]></content:encoded>
						</item>
						<item>
				<title>
				By: Uberto Barbini				</title>
				<link>http://matteo.vaccari.name/blog/archives/833/comment-page-1#comment-95877</link>
		<dc:creator><![CDATA[Uberto Barbini]]></dc:creator>
		<pubDate>Mon, 25 Mar 2013 16:05:25 +0000</pubDate>
		<guid isPermaLink="false">http://matteo.vaccari.name/blog/?p=833#comment-95877</guid>
					<description><![CDATA[Ah dimenticavo... standup quotidiani in situ! :D]]></description>
		<content:encoded><![CDATA[<p>Ah dimenticavo&#8230; standup quotidiani in situ! :D</p>
]]></content:encoded>
						</item>
						<item>
				<title>
				By: Uberto Barbini				</title>
				<link>http://matteo.vaccari.name/blog/archives/833/comment-page-1#comment-95876</link>
		<dc:creator><![CDATA[Uberto Barbini]]></dc:creator>
		<pubDate>Mon, 25 Mar 2013 16:04:36 +0000</pubDate>
		<guid isPermaLink="false">http://matteo.vaccari.name/blog/?p=833#comment-95876</guid>
					<description><![CDATA[Come ho scoperto recentemente, la ristrutturazione di una casa e&#039; un processo abbastanza agile. Inizi con un progetto... poi man mano che lo definisci scopri che devi spostare muri, finestre scale... allora magari fai un passo indietro e pensi ad un altra soluzione.. cosi&#039; per due o tre volte sul progetto.
Una volta iniziato chiaramente non puoi &quot;rifattorizzare&quot; un muro ma ogni giorno c&#039;e&#039; qualche sorpresa sui lavori e devi prendere decisioni su due piedi per spostare di qualche cm una finestra, alzare un muro, cambiare il verso di una porta ecc.
Infine devi gestire gli ordini per far si che i sanitari arrivino subito dopo che il tetto e&#039; stato rifatto, e le piastrelle arrivino prima della fine della posa dei sanitari, ma non troppo prima che poi intralciano... ecc.ecc..]]></description>
		<content:encoded><![CDATA[<p>Come ho scoperto recentemente, la ristrutturazione di una casa e&#8217; un processo abbastanza agile. Inizi con un progetto&#8230; poi man mano che lo definisci scopri che devi spostare muri, finestre scale&#8230; allora magari fai un passo indietro e pensi ad un altra soluzione.. cosi&#8217; per due o tre volte sul progetto.<br />
Una volta iniziato chiaramente non puoi &#8220;rifattorizzare&#8221; un muro ma ogni giorno c&#8217;e&#8217; qualche sorpresa sui lavori e devi prendere decisioni su due piedi per spostare di qualche cm una finestra, alzare un muro, cambiare il verso di una porta ecc.<br />
Infine devi gestire gli ordini per far si che i sanitari arrivino subito dopo che il tetto e&#8217; stato rifatto, e le piastrelle arrivino prima della fine della posa dei sanitari, ma non troppo prima che poi intralciano&#8230; ecc.ecc..</p>
]]></content:encoded>
						</item>
						<item>
				<title>
				By: Giovanni Asproni				</title>
				<link>http://matteo.vaccari.name/blog/archives/833/comment-page-1#comment-95869</link>
		<dc:creator><![CDATA[Giovanni Asproni]]></dc:creator>
		<pubDate>Sun, 24 Mar 2013 11:11:29 +0000</pubDate>
		<guid isPermaLink="false">http://matteo.vaccari.name/blog/?p=833#comment-95869</guid>
					<description><![CDATA[Sono d&#039;accordo con Matteo. Sono sicuro che anche gli ingegneri e gli architetti facciano lo stesso con i loro clienti. 
Infatti, per quella che è la mia esperienza, i team, agili e non, che pretendono che il cliente fornisca i requisiti senza nessun aiuto da parte del team di sviluppo finiscono per produrre software di valore limitato, se non inutile.
Io sono del parere che per essere dei programmatori seri (o professionali, se preferite) si debba essere in grado di conversare con i clienti nel loro linguaggio, e si debba fare in modo di capire il dominio del business cosicché si possano fare le domande giuste per capire che software si debba produrre. Chi non è in grado di fare questo non si può considerare un programmatore esperto, indipendentemente dalle conoscenze tecnologiche.]]></description>
		<content:encoded><![CDATA[<p>Sono d&#8217;accordo con Matteo. Sono sicuro che anche gli ingegneri e gli architetti facciano lo stesso con i loro clienti.<br />
Infatti, per quella che è la mia esperienza, i team, agili e non, che pretendono che il cliente fornisca i requisiti senza nessun aiuto da parte del team di sviluppo finiscono per produrre software di valore limitato, se non inutile.<br />
Io sono del parere che per essere dei programmatori seri (o professionali, se preferite) si debba essere in grado di conversare con i clienti nel loro linguaggio, e si debba fare in modo di capire il dominio del business cosicché si possano fare le domande giuste per capire che software si debba produrre. Chi non è in grado di fare questo non si può considerare un programmatore esperto, indipendentemente dalle conoscenze tecnologiche.</p>
]]></content:encoded>
						</item>
			</channel>
</rss>
