Dear Students,
Great discussion yesterday! Here’s our preliminary brainstorming of shared values and obligations… in some instances I’ve rephrased them to fit with one another a little more readily. I’ve also divided them up into 3 categories:
Qualities that make someone a “bad” web-developer/designer/programmer:
- Propensity toward overcharging
- Propensity toward Plagiarism, stealing intellectual property, borrowing code or platforms without acknowledging this.
- Refusal or inability to meet the client’s (reasonable) demands
- A propensity to falsely represent one’s abilities
Qualities to be valued – things that make one a “good” web-developer/designer/programmer
- Creativity (but not at the expense of Efficiency)
- Efficiency
- The ability to set appropriate boundaries
Obligations: things good web-developers/designers strive to do (or more accurately, are obligated to do)
- Understand the client’s needs
- Respect the client’s wants
- Avoid “scope creep" i.e. show respect for, and obligation to, the original project scope
- Maintenance? Fix bugs? -- this latter one was still up for discussion when we ended class...
Valued quality additions:
ReplyDelete-Ethical
-responsible
-quality work (always provide best work)
Obligation Additions:
-follow contract don't push deadlines
-do best work and in timely fashion
-present information in format client can interpret
I think valued qualities are mutually exclusive. Things that are obligations tend to be what we are looking for the programmer to do as clients. If they are doing what they are supposed to do that means we value the work they are doing. For example, say the programmer has an obligation to have a working prototype going by the end of the year. A valued quality may be to meet deadlines. This if looked at through the right angle, can be seen as the same thing.
Maintenance and Fixing bugs: I think that this is something the client needs to think about when writing up a contract. If they are expecting that the programmer will be reconcilable and able to be contacted regarding bugs and maintenance, it needs to be agreed upon in the original contract. The alternative is to agree on it upon completion and funds for a maintenance contract need to be paid to the programmer. The contract is a description of the project. If it says “design and develop a website to sell products A, B and C” then this is the final product at X date. If the client wants maintenance that needs to be included and agreed upon as well as be reflected upon in the final price.
As, think about some of my other classes that were talking about about how to present data to clients in a way they can understand it. I find this to be true when I am at work and create technical help manuals. I find deadlines and expectations needs to be said and monitored.
ReplyDeleteSo, I agree with Matt in his response to the blog. I do think that contracts are important in a business sense and need to be used and mutually written. I also think the shorter and simple the contract the better. It leaves less room for interpretation.
After reading Hutch's response I wonder why Honesty is missing from the lists? Honesty could fall under qualities to be valued and under obligations. I guess honesty could be considered an expectation of all people in society, but sometimes it needs to be reiterated I think. Not everyone follows the golden rule, and sometimes they need to be reminded of it.
ReplyDeleteMaintenance is a sticky situation. If it is not outlined in the original contract, the web developer could be liable to fix things when they go haywire with new product releases. It would be safest to include at the bottom of every contract that the development of a website does not include fixing or maintaining the website for the length of it's life. Protecting oneself in all manners is the best and safest thing to do.
I think that this list, in conjunction with Matt and Melanie's additions, covers a lot of what is important in the web development profession.
ReplyDeleteExpanding on what Jon mentioned regarding explaining information to clients in a manner that they understand: I think that it is important that developers avoid throwing around web jargon for the sake of inflating their abilities and experience level or of potentially increasing the client's perception of the monetary value of the services provided.
When developers need to use industry-specific language, they should make sure that the client knows what is being discussed and why it is important, thereby providing clients with enough knowledge to conduct independent research and not rely solely on what is relayed to them by the developer. If you make search engine optimization sound like a spaceship, clients are going to pay spaceship prices for the service. When someone is completely overwhelmed with terms that they don't understand, they find themselves agreeing to and paying for things that they might not need or even want. That goes along with respecting and understanding the client's needs, one of the obligations mentioned above.
Alternately, though along the same subject, some clients want all the bells and whistles because they heard some terminology thrown around in another context and have decided that they can't live without having everything considered the latest and greatest on their site. In these instances, it is important that the developer explain the benefits--or lack thereof--and costs associated with the implementation of these technologies on a client's project. If the client understands that the contributions of such technologies might be minimal at best and still wishes to proceed, the developer should implement them at the appropriate cost.
I think that Matt's emphasis on clearly defining, agreeing upon, and respecting a formal contract is one of the most important parts of having a successful relationship with clients in this industry. This is especially important because of the slightly ambiguous nature of the responsibilities of a web developer and the time at which our involvement with a project ends. Contracts are an excellent method for reducing the potential for disputes with a client and are a responsibility developers owe to both clients and themselves.