Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm dealing with pretty stressful (in my opinion) situation in my current work place.

We've started developing new project, get some requirements, implemented it and then show to someone you can call a 'business advisor' (person who knows business requirements but will not use the program). That person is supposed to evaluate application from customers point of view, test it etc.

Here how the 'process' looks:

  1. business advisor talks in the evening with my boss for hour or two on windows messenger
  2. the next day I receive email with copy of that conversation. I am supposed to choose tasks from that, check reported bugs (which often aren't bugs, just poor testing and forgetting about past establishments)
  3. I implement changes, implementation gets accepted and then in a week or two it turns out that isn't want they want (they talked with some potential client that have seen software for 5 minutes and he suggested changes) - I have to do new changes

Don't get me wrong, I understand that sometimes requirements change. What upsets me is how often the change occur in my workplace and how easy for 'management' is two give new requirements or sometimes fundamental changes to existing features.

At the same we working on tight deadlines and I have impression that instead of going forward with our software we're running circles.

I seek advise from you how to deal with this situation? Is this normal situation and I'm just hypersensitive about it?

share|improve this question
    
As long as they don't say - "that blasted piece of #$@$# should have been finished last year, what takes you so long?", and pay on time, it's ok. –  Coder Mar 13 '12 at 22:45
    
In response to your last question: It can happen, is it normal - no, should you care - yes, should you try to improve the situation - yes. The success of the project should matter to all involved. For how to improve the situation - read my answer below. –  Danny Varod Mar 13 '12 at 23:30
    
This would be a really good question for pm.stackexchange.com any moderators here think it should be moved? –  Danny Varod Mar 13 '12 at 23:37
    
Sorry, couldn't resist: dilbert.com/strips/comic/2007-02-02 –  Heinzi Mar 14 '12 at 0:00
    
Randall over at xkcd has a clear flowchart that explains how to deal with changing requirements: xkcd.com/844 –  Jason Lewis Mar 14 '12 at 0:36
add comment

6 Answers 6

If at all possible, take the conversation you're emailed and turn it into a requirements document. List the tasks that you can glean from it and order them by what you perceive to be the priority and assign an estimate to each. Then ask which features they want for the next release.

Basically, force some kind of feedback loop where the management is aware what is it that you're going to build. Write your own requirements documents until such time as they get the message.

Story Cards

I think your situation is well suited to introducing user stories. They're really helpful in providing an ongoing, interactive way for your manager to set priorities and he can even throw them away when he comes back to the idea a week later and realises it's not workable.

share|improve this answer
    
You have nailed it : Don't write software without requirements. Requirements are like food..... You can eat without someone cooking them, but it won't be palatable. If "management" are not dishing requirements up on a plate, you need to go into the kitchen and start cooking. –  mattnz Mar 13 '12 at 23:27
1  
Requirements are like food? Requirements are like recipes. Actually, requirements are like a menu... The recipes are algorithms, and the food is the implementation of the software itself. –  Robert Harvey Mar 13 '12 at 23:33
    
I think using this approach will also help the manager to clearly believe he is wrong when conflicting requirements are provided, which happens all the time. –  Aadi Droid Mar 14 '12 at 6:47
add comment

In the real world, requirements change routinely. On the plus side, you find out about it before you finish building the software and ship it out - you have a tight feedback cycle from the direct user of the software, which is actually great.

It seems like the biggest problem here is the very ad-hoc way that change is managed. You have what agile / Scrum consider a "product owner", who gives feedback, but the process is poorly documented, and poorly thought out.

You probably want to look at the models in Scrum, and their view of what an effective product owner is, to help inform your next steps.

So, instead of having this ad-hoc process, aim to move to a world where you have a closer and more useful relationship with the "business advisor", and where everyone is on the same page about the outcomes of the changes they are discussing.

share|improve this answer
    
The fact that required changes are in my opinion poorly thought out is my biggest problem. It is not uncommon that in wednesday I have to change code that I wrote on monday - it is very frustating to me. Do you think maybe adding some wait time to each feature is good idea? (for example we wait two weeks before deciding if we implement it) It would help me to manage time also - now I have new requirements every day with no priority etc –  Peter Mar 13 '12 at 21:55
1  
I am serious: I think that the ad-hoc process is a bigger problem than the poorly thought out. If you have, eg, the business advisor work with you to update a document that lists the decisions, they can't change their mind without seeing that they are revising a previous decision. Adding more time without addressing the underlying problem isn't going to help. –  Daniel Pittman Mar 13 '12 at 21:56
    
I've talked to business advisor couple of times - for him revising previous decision isn't a problem at all ;) –  Peter Mar 13 '12 at 22:01
1  
@Peter, one of the things about scrum is you have defined iteration boundaries (usually two weeks) during which nothing is changed. It might be a very good fit for you. –  Karl Bielefeldt Mar 13 '12 at 22:01
1  
...then, if it is done in full knowledge that it is changing the requirements, and it is done in full knowledge of the cost of that change, they are paying you to put up with those changes. ;) –  Daniel Pittman Mar 13 '12 at 22:02
add comment

Requirement changes are not always bad. The key thing is to remember your customer. Likely your boss is your customer in this case. You need to notify your boss that you thing these constant requirement changes are limiting your ability to produce the product which is most useful to him. It is entirely possible that the business benefits from you constantly reacting to changes. If so, that is their business model, and you are doing nothing wrong, though I recommend running for the hills in that case!

People who are frustrated with requirement changes are often valued by how well they manage each change. This metric of "number of changes sufficiently handled" is probably the source of your real trouble. Consider discussing better metrics with your boss. When I am facing constantly changing requirements, I strive to write content that lets me adapt to constantly changing requirements. Instead of running a simulation and analyzing the data every day, I will write tools which make the process of running the simulation and analyzing the data cheaper, and reap the rewards over time. If that is still too crazy, I might even write a tool to write tools!

share|improve this answer
add comment

The phrase "Requirements change" is sometimes abused by IT people. What you are describing is indeed change of requirements but this may be because one or more of the following (I don't know enough about your case, so the following may or may not apply):

  1. Management's ambition to make the end user happy as quickly as possible and show quick progress.

  2. Lack of detailed analysis. Remember that Analysts need to ask questions about why not only what. The analysts needs to "think" with the end user about a "solution" not only take orders.

  3. Lack of a formal process for requirements verification and confirmation, followed by approval.

  4. Asking the incorrect person to perform one or more roles they are not necessarily trained for such as Business Analyst or Systems Analyst roles.

  5. Limited prototyping.

  6. The assumption/fear that it has to be done quickly and if not its IT to blame.

Unless one addresses all of the above properly, the relationship between IT and the business/end user will be stressful. Please note that this does not imply that the above point are conclusive. There are other factors that leads to stressful situations similar to your situation but I think this list should get you going.

share|improve this answer
add comment

I think you should approach this from a few directions:

  1. Have all the stake holders (including the entire development team) meet (offline/online) with the business advisor and try to understand the domain, the vision and then brainstorm requirements together.

  2. Formalize requirements/user stories, grading each one's:
    a. Priority (urgency/importance)
    b. Maturity (how well defined it is - understood and agreed on by majority of stake holders *)
    c. Complexity (rough estimate)

    When choosing which requirement/user storie to work on next, taken all three factors into account. If the requirement has low maturity, add a research mission before it, in which you contact all stake holders, investigate the reasoning behind the requirement and better define the requirement (write use cases and/or create wire-frames and present them) before acting upon it.

  3. Try to think a few steps ahead while designing before each implementation - design a flexible architecture that has room to accommodate changes.

  4. Try to adapt an agile development process e.g. SCRUM or Kanban - this will provide you with a toolkit for developing a product with changing requirements.

You should also consider asking the moderators to move this question to PM.stackexchange.com (by flagging it) as even though this question fits here, it would fit there better.

(*) Stake holders for agreement: business, marketing, project management, development and QA.

share|improve this answer
add comment

Your current process makes it too easy for these people to just brainstorm ideas with no reguard for the resources and money this will consume. If they want all these features, they need to get some "skin in the game."

Take that email of the conversation and put it into some sort of feature/bug tracking application even if it is just a spreadsheet. Send the new additions back to the business advisor and ask him/her to sign off on each item or provide corrections. Along with the sign-off, they should prioritize (Which ones do you want first?).

After they approve, send them back your schedule on when the items will be completed for testing and get them to commit to a time to do the testing/approval of completion.

I know creating this type of documentation is not why you became a programmer, but you can either risk throwing these lists away or keep throwing your hard-earned code away.

Push back. Those in charge need to see how much these requests are costing.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.