[eluser]Kyle Johnson[/eluser]
Hey everyone,
I'm having issues with the application I'm developing. Most of the stuff turns out just fine the first time, maybe a bit of tweaking afterwords, but I keep running into problems with conflicting goals.
I am wondering, what different methods are used to ensure that the user understands what information the programmers need to develop their application?
For instance, I usually have them give me the paper version of forms they need information from, and samples of reports that they want the application to be able to produce. How do you get the end users to dump their hearts and minds out the first time rather than requiring me to change everything at the end?
I'm interested in the horror stories of this problem too.
[eluser]TheFuzzy0ne[/eluser]
A client that doesn't change their mind? I think you're living in a dream world. 
It's up to you to code in such a way that you can implement just about any change fairly easily.
[eluser]Kyle Johnson[/eluser]
Well luckily for me, most of their changes are rather small, but sometimes they just come up with ludacris changes. For instance, I was 3 months into the front end development when they decided they wanted something else. I am able to change most of it via CSS, but... Can we just teach them how to program their own stuff?
I love CI because frameworks are SO MUCH BETTER than writing line by line code. I started to realize that when they were demanding changes to the database structure.
[eluser]slowgary[/eluser]
I agree. Also, make sure your contract is based on the initial specifications and that the client understands that changing the specs or scope requires a written change order and additional costs. Then at least it's worth your while to implement the changes because you're being paid more for it. If you're billing hourly to begin with then you really just need to change your frame of mind (changes = additional income).
In the end you'll never stop clients from making changes as they don't always know what they want until they begin using the software. Asking a lot of questions up front and trying to exhaust the possibilities yourself is the best you can do. I usually find myself asking a client, "Would you also need the software to ___fill in the blank___?".
I had a first weekly meeting with a pro-bono client recently (a non profit group) and we discussed their needs. During the discussion the boss lady said, "... and then at next week's meeting when you bring it in, we can see if it needs anything changed". Client expectations are ridiculous sometimes, you just gotta learn to roll with the punches. I especially find that the client's perceived value of your work is exactly what they're paying for it. If they're paying nothing for it, they usually do not value it (or the work you put in). If they paid $10,000 for it, then "We have a $10,000 website!".
Bottom line - make sure you're compensated for all the work you're doing, even when the client changes their mind.
[eluser]Kyle Johnson[/eluser]
That's kinda my problem. I have asked all these questions. The "client" is my employer. I am the person in charge of keeping the computers running, servers, mail, tech support, etc. For about 50-70 users. My boss is head of engineering, but he is more of a hardware guy, give him a broken motherboard, and he'll fix it. Give me a computer that is getting constant blue screens and I'll fix that.
It's super hard for my company to see the value of what they are getting because they are already paying me (a very low salary for what the average of my field makes), but I enjoy the opportunity to learn all these new things. I am only 22 years old, still in school for computer science.
It helps being involved with the company as much as I have been, because when I sit down with them I get about 5 minutes of requests from them, and during our 30 minute meetings the other 25 minutes are of me asking.. "Ok, well, I can do that, but won't we also need ____ and ____." Since none of the people in the meeting seem to understand what the average end user in the company will go through.
It's hard to display to them that progress is coming when their requirements change on a day to day basis. I mean, really. Some of the changes they are requesting become extravagant. "I want to be able to map a best route for one of our technicians that is out in the field, and also be able to send text message updates with his cell phone for the services they performed." and I'm like.. "Ok, that comes way later in development."
[eluser]tomcode[/eluser]
I am working like this :
First step is to know what the app is supposed to do.
A good way to fix the project is to have a visual of every main page, Powerpoint, PDF.
Some projects require the structuring of the data. This is an additional, often very time consuming job.
The client must be aware that the app will be built based upon this visual / data structure and that any later change require renegotiation of the project.
Once the data structure is set up and the visual is validated :
I prepare the production : technologies, data structure, domaine, hosting, etc...
the client prepares a sample content set, better gives me all the content already available. I try to avoid creating one myself.
After this is done I assure with the client that the validated visual / data structure is still up to date.
Then I start the production, usually I implement part after part and publish every step so the client can play with it.
Depending the project, I let validate the steps before continuing.
[eluser]Colin Williams[/eluser]
Part of being professional, in fact the most crucial part, is demanding professionalism from your clients/employers and accepting nothing less. This involves clearly defining expectations, deliverables and milestones up front and having solid agreements and contracts.
More to your scenario, simply do not start programing until everything has been completely defined and agreed to on paper (this is why wireframing and other forms of documentation are so important).
[eluser]slowgary[/eluser]
None of this applies to you though Kyle, as this is your job. I would just consider it all good experience and don't let it get you down. If you like what you do then you tend to be better at it and likewise, people who dislike their job are usually not very good at it. So I say just consider it the hardest client you'll ever work for, and if you take on freelance clients this experience will help you be more prepared foir their expectations.
[eluser]Kyle Johnson[/eluser]
I love learning all of the challenges that get thrown my way, but I think they are expecting me to be able to do anything (I've only been learning PHP for about 7 months now, hardly enough time to learn EVERYTHING).
I think they know that so much can be accomplished with advanced database applications, but as their wish list gets longer and longer, so do the demands for the other parts.
I like hearing of all the advice and guidelines. We started in the beginning with wireframe (i'm guessing that is a way of drawing out forms they want?) and samples. However, they expect me to be able to infer everything from a 30 minute meeting or two. Unrealistic expectations really, but I don't mind challenges.
How do you get management in the company you work for to provide sample forms? I can ask them directly, email them, and get zero response. So much of what the company does is "on-the-fly" so I understand they are all usually very busy (which is what this application I'm developing is hoping to curb).
I suppose I could start a long list of the goals they have wanted to achieve and track progress using that. When a new wish is added, it goes at the bottom of the list at 0% completed. Sort of a bug tracking system, but for goals.
[eluser]Jondolar[/eluser]
I'm reading a book called Object Oriented Analysis and Design which discusses the responsibility of a programmer/designer when working with clients. It talks about how to gather requirements by using use cases. The interesting tone of the book is that if you don't deliver what your customer wants "even if they don't tell you what they want the first time" it is really your fault/issue. The goal of the book is to get you to find out what your clients "really" want and to build them an application that will actually work for them.
|
