@yuno_miyako
, thank you for this article; I think you offered sensitive insights that can really improve the client<>developer relationship.
Over a ~20 year career of successful web projects with clients (both enterprise and small businesses) I have seen the most important aspect for success is visibility into progress. As you note:
Because the functions are limited to one, you can do it in a week. Show the owner a product that will move in a week. The owner can confirm that the book can be registered, so he must be glad to know the progress, rather than looking at the source code.
And you're very correct, that in our eagerness to provide weekly visible progress, we must not stumble in the show-and-tell delivery:
No matter how quickly you deliver a product that moves, products of low quality will lose the trust of customers.
As a PM/front-end UX/designer, I have seen too many times that the programmer I partnered with did not due enough testing on their own (with their own well-developed process), so it jeopardized the weekly demo day. The burden of testing was only on me, and there was not enough time to resolve before the demo time. The best developers have a test-driven process as they go, or as I used to say, an "inline testing flow" -- as opposed to after-the-fact.
Might I add a comment about what you wrote here:
When I try to touch moving things, there are more and more requests that did not appear when discussing on the desk... Refactoring is essential for the agile handling of feature additions and modifications.
It's worth noting (and I'm sure you know this): this reminds me of "feature creep", which happens when the client gets very excited about seeing progress (their dream is coming true!) and they ask for more and more mini-features to enhance the vision.
What this conveys to me is that the Project's Feature Scope was not actually thoroughly outlined, in the beginning; if something was not in the Scope, then its time + cost wasn't quoted, and thus we have feature creep and missed budgets. It's so tempting to keep saying "yes" to each request (after all, the product is getting better!) but, the client is almost always not prepared for the price increase (or you have to swallow the extra costs).
So what we do is then document any good ideas that emerge from the dev process, and ask to defer them until the first scoped project is completed... then the "AAs" (which mean "author's alterations" can be started when the client has the budget to complete them. It's always better for you to ship a v1 than to get bogged down in continual feature additions under the first Scope.
Hope that helps!
Paul
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@yuno_miyako , thank you for this article; I think you offered sensitive insights that can really improve the client<>developer relationship.
Over a ~20 year career of successful web projects with clients (both enterprise and small businesses) I have seen the most important aspect for success is visibility into progress. As you note:
And you're very correct, that in our eagerness to provide weekly visible progress, we must not stumble in the show-and-tell delivery:
As a PM/front-end UX/designer, I have seen too many times that the programmer I partnered with did not due enough testing on their own (with their own well-developed process), so it jeopardized the weekly demo day. The burden of testing was only on me, and there was not enough time to resolve before the demo time. The best developers have a test-driven process as they go, or as I used to say, an "inline testing flow" -- as opposed to after-the-fact.
Might I add a comment about what you wrote here:
It's worth noting (and I'm sure you know this): this reminds me of "feature creep", which happens when the client gets very excited about seeing progress (their dream is coming true!) and they ask for more and more mini-features to enhance the vision.
What this conveys to me is that the Project's Feature Scope was not actually thoroughly outlined, in the beginning; if something was not in the Scope, then its time + cost wasn't quoted, and thus we have feature creep and missed budgets. It's so tempting to keep saying "yes" to each request (after all, the product is getting better!) but, the client is almost always not prepared for the price increase (or you have to swallow the extra costs).
So what we do is then document any good ideas that emerge from the dev process, and ask to defer them until the first scoped project is completed... then the "AAs" (which mean "author's alterations" can be started when the client has the budget to complete them. It's always better for you to ship a v1 than to get bogged down in continual feature additions under the first Scope.
Hope that helps!
Paul