DEV Community

Ben
Ben

Posted on

How do limit the application behaviour for change

As chanage is inevitable, how would you prevent change in a specific period in order to make project completed.

Top comments (7)

Collapse
 
xlebenny profile image
Benny Leung
  1. Make some prototype ensure no difference between you and client
  2. If user want more function, place in Prase 2
  3. If user want add into current prase, trade off some a little bit hard function, because you not enough time estimate new function how difficult

Sorry of my English

Collapse
 
imben1109 profile image
Ben

Do you mean we should force user to accept the function as soon as possible?

Collapse
 
xlebenny profile image
Benny Leung

No, make sure user know the business logic + calculate formula then accept, because some business logic only they know, they will help you too much, and they will know why need more man day

Thread Thread
 
imben1109 profile image
Ben

In Most Cases, Users do not know what they want to do so. It is the worst case. You may say User must know it and thus the project can be completed.

However, in real case, the situation is far from ideal.

Thread Thread
 
xlebenny profile image
Benny Leung • Edited

Yes, you can ask user some real situation
Then new system, will bla bla bla, because bla bla bla
Don't let user think they should use which function before know business & system operate, they will create some useless / conflict logic waste our time.
Not everybody has systematic and logical mind set

Collapse
 
cescquintero profile image
Francisco Quintero πŸ‡¨πŸ‡΄

By saying: "if we change this now, then.."

  • we'd have to delay X requirement delivery
  • it'd need more time to be done
  • this other things also would change

Both the customer/management and development need to embrace and accept change. Sometimes it keeps them from asking changes, sometimes they just don't matter.

It's my approach.

Collapse
 
kr428 profile image
Kristian R.

Depends upon how your project is managed and how you interact with your customer(s) I suppose. In an agile understanding, it would be good to embrace change early - as it might be better to change a project rather than completing something that apparently might not meet changed requirements anymore. I'd really try going through small iterations, coming closer and closer to what the customer needs and, in each iteration, talk about requirements, effort needed to implement them - and whether feature X or Y is really required or worth the effort. But again this really depends upon your customers expectations and your contract. ;)