<?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>Commentaires sur : Présenter un visuel en cours de réalisation (1)</title>
	<atom:link href="http://demontiers.com/2009/08/presenter-un-visuel-en-cours-de-realisation-1/feed/" rel="self" type="application/rss+xml" />
	<link>http://demontiers.com/2009/08/presenter-un-visuel-en-cours-de-realisation-1/</link>
	<description>Consultant web //// Ergonomie et Design d&#039;interfaces</description>
	<lastBuildDate>Sat, 28 Jan 2012 14:26:58 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Par : Bruno N</title>
		<link>http://demontiers.com/2009/08/presenter-un-visuel-en-cours-de-realisation-1/comment-page-1/#comment-166</link>
		<dc:creator>Bruno N</dc:creator>
		<pubDate>Tue, 29 Dec 2009 22:08:52 +0000</pubDate>
		<guid isPermaLink="false">http://demontiers.com/?p=28#comment-166</guid>
		<description>Tout à fait d&#039;accord, c&#039;est exactement pareil pour l&#039;intégration/développement.

Je travaille en agence et les chefs de projets, ainsi que les boss, ne pensent qu&#039;à cela : donner la possibilité au client de voir l&#039;avancement du travail au fur et à mesure, chose à laquelle je suis totalement opposé évidemment. Surtout que je bosse d&#039;abord en local et environnement de dev, donc avec l&#039;affichage des erreurs, parfois des variables de sessions ou autres... Combien de mails de clients n&#039;ai-je pas déjà reçus, me disant qu&#039;il y avait des erreurs, des blocs du wireframe qui ne s&#039;affichaient pas, du texte en latin (lorem ipsum),... Venant du client, qui ignore bien souvent le processus d&#039;intégration/développement) c&#039;est compréhensible, mais quand ces remarques me sont faites par les chefs de projet ou par les boss (si si c&#039;est arrivé)... No comment !

Mais cela arrive la plupart du temps (donc souvent dans mon cas) quand les délais sont totalement farfelus, voire inexistants. Si les délais de livraison sont bien définis avec le client, et que surtout on laisse à la prod l&#039;occasion de les tenir, le client ne demandera pas de voir quoi que ce soit avant la finalisation du site, ou s&#039;il demande à voir, c&#039;est très facile de lui rappeler que les délais seront tenus pour le rassurer.</description>
		<content:encoded><![CDATA[<p>Tout à fait d&#8217;accord, c&#8217;est exactement pareil pour l&#8217;intégration/développement.</p>
<p>Je travaille en agence et les chefs de projets, ainsi que les boss, ne pensent qu&#8217;à cela : donner la possibilité au client de voir l&#8217;avancement du travail au fur et à mesure, chose à laquelle je suis totalement opposé évidemment. Surtout que je bosse d&#8217;abord en local et environnement de dev, donc avec l&#8217;affichage des erreurs, parfois des variables de sessions ou autres&#8230; Combien de mails de clients n&#8217;ai-je pas déjà reçus, me disant qu&#8217;il y avait des erreurs, des blocs du wireframe qui ne s&#8217;affichaient pas, du texte en latin (lorem ipsum),&#8230; Venant du client, qui ignore bien souvent le processus d&#8217;intégration/développement) c&#8217;est compréhensible, mais quand ces remarques me sont faites par les chefs de projet ou par les boss (si si c&#8217;est arrivé)&#8230; No comment !</p>
<p>Mais cela arrive la plupart du temps (donc souvent dans mon cas) quand les délais sont totalement farfelus, voire inexistants. Si les délais de livraison sont bien définis avec le client, et que surtout on laisse à la prod l&#8217;occasion de les tenir, le client ne demandera pas de voir quoi que ce soit avant la finalisation du site, ou s&#8217;il demande à voir, c&#8217;est très facile de lui rappeler que les délais seront tenus pour le rassurer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Jacques Bodin-Hullin</title>
		<link>http://demontiers.com/2009/08/presenter-un-visuel-en-cours-de-realisation-1/comment-page-1/#comment-36</link>
		<dc:creator>Jacques Bodin-Hullin</dc:creator>
		<pubDate>Thu, 22 Oct 2009 20:03:29 +0000</pubDate>
		<guid isPermaLink="false">http://demontiers.com/?p=28#comment-36</guid>
		<description>Ce principe est également valable en développement.

Je pense surtout au passage lié à l&#039;intégration du design et aux différents tests sur certaines parties du projet.
Montrer l&#039;avancement avec des éléments non intégrés, des bordures rouges, des fonds jaunes/violets/bleus ou encore pire des « erreurs » en haut des pages (un simple debug pour le développeur qui n&#039;apparaîtra pas en production par exemple), peut rendre le développeur/intégrateur peu crédible sur ses compétences, même s&#039;il s&#039;agit là d&#039;un passage obligé lors d&#039;une intégration/d&#039;un développement.
De plus le client, s&#039;il n&#039;est pas connaisseur, peut vite avoir peur et la mission risque d&#039;être un peu secouée.
S&#039;il le projet est gros et qu&#039;il nécessite une validation partie par partie du client, pour être certain que ça avance comme il le souhaite par exemple (une application peut vite devenir très complexe et on a parfois besoin de se dire « ça c&#039;est fait »), il faut le faire mais il faut se contraindre à ne montrer que des parties terminées.

C&#039;est mon avis !</description>
		<content:encoded><![CDATA[<p>Ce principe est également valable en développement.</p>
<p>Je pense surtout au passage lié à l&#8217;intégration du design et aux différents tests sur certaines parties du projet.<br />
Montrer l&#8217;avancement avec des éléments non intégrés, des bordures rouges, des fonds jaunes/violets/bleus ou encore pire des « erreurs » en haut des pages (un simple debug pour le développeur qui n&#8217;apparaîtra pas en production par exemple), peut rendre le développeur/intégrateur peu crédible sur ses compétences, même s&#8217;il s&#8217;agit là d&#8217;un passage obligé lors d&#8217;une intégration/d&#8217;un développement.<br />
De plus le client, s&#8217;il n&#8217;est pas connaisseur, peut vite avoir peur et la mission risque d&#8217;être un peu secouée.<br />
S&#8217;il le projet est gros et qu&#8217;il nécessite une validation partie par partie du client, pour être certain que ça avance comme il le souhaite par exemple (une application peut vite devenir très complexe et on a parfois besoin de se dire « ça c&#8217;est fait »), il faut le faire mais il faut se contraindre à ne montrer que des parties terminées.</p>
<p>C&#8217;est mon avis !</p>
]]></content:encoded>
	</item>
</channel>
</rss>

