<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Tue, 21 May 2013 14:17:26 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Cal Evans' Blog: Six ways to be a better client for your developer - Point 6]]></title>
      <guid>http://www.phpdeveloper.org/news/15811</guid>
      <link>http://www.phpdeveloper.org/news/15811</link>
      <description><![CDATA[<p>
<i>Cal Evans</i> has posted the <a href="http://blog.calevans.com/2011/01/26/six-ways-to-be-a-better-client-for-your-developer-point-6/">final point</a> in his "Six Ways to be a Better Client for your Developer" series seeking to make the client/developer relationship more stable and enjoyable for both sides. This latest tip involves the paperwork part of the relationship.
</p>
<blockquote>
Good fences make good neighbors just as good contracts make for good developer/client relations. At the very least your agreement with your developer should contain a complete description - in non-vague terms - of each feature to be built as well as a paragraph description of the overall project. 
</blockquote>
<p>
He emphasizes that, if the feature or change is not included in the documentation from the start, it's not a part of the project. Making assumptions on vague definitions will only cause problems down the road, so be specific in what you want. 
</p>
<blockquote>
If negotiating the contract with your developer is a hassle, consider it your last opportunity to walk away and find another developer.
</blockquote>]]></description>
      <pubDate>Wed, 26 Jan 2011 12:51:31 -0600</pubDate>
    </item>
  </channel>
</rss>
