we have done a project, and we have finished the project and released, but after the release, the customer keep asking us to add new features, what should we do? how to handle this situation. say no to customer?
I think there are three considerations.
1) Have they paid for work already done? If not, they have an advantage over you. If you think there is risk of them holding payment, I suggest you offer to do a few small change requests in return for them first paying what's due.
2) Do you want to keep them as a customer? Offer them a service contract, or option to pay you a retainer for ongoing work. This could be time and materials, or just a fixed price for pre-agreed amount of labor.
3) Is there disagreement on what is a change request versus what is a bug fix? If so, spend the time with them explaining the difference, and get their agreement to the principle before arguing over specifics.
It's easy. More features, more money.
Depending on your contract, of course. But if the project is all signed off on and the new features are not included in the maintenance contracts, further development is going to have to cost them.
Related
Scenario:
Currently we are in the process of system and integration testing. Every day we get lots of defect raised by testers. Most of these defects do not match with requirement we were given. Lots of scenarios are new to developers. Requirement we had was signed off by business.
Could someone clarify how to distinguish between Defect vs CR?
Everything that was not a requirement is a change-request.
But live is unfortunately not that easy, so please read on.
Quarrels on what is a defect and what is a change-request are very common in projects. Managing the situation is difficult because you often have to make compromises.
I have seen project managers being removed by programme managers because they insisted to much that all the defects are really change requests. They often were right but still there behavior was not helpful for the overall progress of the programme. I have also seen project managers who killed themselves by accepting every defect and built castles though never originally required and effort estimated for.
I personally always make absolutely sure that my managers know that I am building features not originally required that came in under the disguise of defects. I also make sure the client/tester knows that this is my viewpoint. But also I am very tolerant in my consideration what a defect is.
Example: I recently joint a project where we developed a financial payments system and another programmer said to me "It is outrages what they want have that is not a defect this is a CR!". I looked at it and due to my background in this business domain I thought it actually is very fundamental requirement and asking for a CR for this is really laughable. So I decided we fix it without making a fuss about it.
Also the following questions are worth to consider:
Are you in a fix price project? Do you still have resources and show real greatness by adding features without moaning that will give you a good reputation and a future contract?
Do you get penalized if you accept a CR as a defect? Is a low-number of defects a KPI (Key Performance Indicator) and affecting your career?
Was the requirement definition poor at the beginning and you accepted it? Was the requirement mentioned in the defect real obvious and could be considered implied? E.g. never specified that amount field should only allow numeric values but still it makes sense.
Have you accepted requirements without asking about the whole big picture and are partially responsible?
Is the client ripping you off and exploiting your inability to say no and reject the defect?
In projects I always try to get the best for the client but make sure I am not being penalized undue.
Working at client (non-IT) place as a .net programmer (alone) and asked to develope a windows application. No project manager, no SRS, no technical people to lead..., etc.
Directly getting requirement from customer on-their-need basis. It keep changes and has lot of ambguity. As the client is not understaning need of freezing requirement, it becomes huge headache to deal with. Has to do self document of requirement, coding, testing, bug-fixing and delivering build, educating users for application use by myself only. Reporing to a Boss, who is non-technical guy and always not understanding these problems.
Now it becomes, single developer-to-do-all SDLC activities. How should I proceed with this work environment?
Start by making demands on your environment, and on what is asked of you:
Demand that requirements and deadlines are fixed and agreed upon, in writing, before you write a single line of code.
Demand that you are given enough time for testing and bugfixing in the development cycle.
Demand that you are given time to setup source control, automatic builds etc (whatever you feel like you need for your development environment to promote effective work).
Demand that you are given time to write documentation, so that you can spend more time writing code and less time doing application demos.
Continue with backing it up:
Document and show your boss some statistics on how you use your time. If it turns out you use much less on actually writing code, maybe he'll consider giving some of the less programming-related tasks to some other member of the department.
And finally, remember that this this is not the only company in the world:
Robert L. Lead has a very good point in his How to be a Programmer: A Short, Comprehensive and Personal Summary: under Recognizing when to go home, he simply states:
Quit if you have to.
This might not be a very compelling option, but should it come to it, leave the company for the greener grass on the other side. Even telling your boss you're ready to quit if your working conditions don't improve might help you actually get what you want. I doubt that your company want to be left with a software product that suddenly can't be supported or updated, because their only developer quit.
Count your blessings, I'd say. Usually all the people standing between the developers and the users are just getting in the way of making successful software.
I think it is a good idea to adopt some agile tooling to organize yourself, like a scrum whiteboard, and by defining sprint periods/iterations. That will allow to manage your boss's and users' expectations, and still give them control over what should get priority. Don't forget to schedule for SDLC tasks, so you can make them visible to your boss. You should feel free to consider agile tooling as a supermarket: take what you think is useful and keep the rest in mind for later consideration.
As far as requirements documentation is concerned, I'd keep it very high level. I would not mind skipping it altogether but I can imagine that it feels sloppy, and it is perhaps also a way to document your achievements.
A combination of educating both your customer and boss; and an agile approach could be helpful here. It depends on how this project is billed to the customer.
If the customer is getting a fixed price deal, yet is allowed to change the specs, then educate your boss (or whoever is accountable for the financial results of the project) about the implications of this project. It means that the customer gets to ask for whatever they want, without needing to pay more. If the project isn't time boxed, your boss is giving away unlimited developer time at a fixed price. Make that clear. If the project is time boxed, explain that changing means redoing and that there's only so much redoing before you run out of time. If he doesn't see this is a problem, document your time use.
It's the equivalent of going to a car-repair shop, agreeing a price and then pushing the mechanic to not only fix your airconditioning (the original scope), but also replace your oil, uprate your suspension and do a full engine overhaul. In the long run, expect the customer to be demanding that the car flies, solve world hunger and bring world peace.
If you're on a billable hours project, then you're in more trouble. Your boss may not have any incentive for the customer to make reasonable demands, he may just care about you being effectively contracted out to a customer and bringing in revenue. In that case take charge of the project by agreeing an agile methodology with the customer, so you can at least deliver something that will address some customer needs. Feel free to take charge, it seems you're the de-facto manager - just make sure you understand what the terms of the contract for this project and work within those boundaries. If the contract is a bad deal, alert your boss, but your company will need to ride it out or renegotiate.
Work in two week sprints, and show to both your boss and client the ratio of functionality/features delivered vs. overhead (rework) vs other work (training,...). It may become clear quite quickly that your project is under resourced, or the demands to high for the price agreed. Track in spreadsheet, or use a lightweight agile project management tool something like TargetProcess
If the customer is unworkable and your boss only sees you at somebody to pimp out, reconsider if you want to work in such a place and if there is any particular reason why you're spending your professional time at your current company over another company.
Keep in mind that you could be in a reasonably strong position to push for some change to improve the situation. If you're the only developer in a non-IT shop, and you quit, your company will struggle to fulfill its obligations to its customer - your boss, lest he's a halfwit, will be mindful of that. Of course, threating to quit, is the nuclear option, don't play that card lightly.
What I usually do in such situations — and these situations I come across much more than I'd like — is to demand a certain minimum. You can only demand something if you have something you can use to pressure your "Boss". In a single-developer-does-all-and-can-do-all situation, your means of pressure is yourself.
There are some countries in the world where employees are badly protected and you have to be careful. For any other country, this almost becomes a no-brainer: simply demand minimum working conditions.
This means: you make a short-list of things you need. Keep it simple. Keep it — almost — free. Don't come with all kinds of procedures. Use a simple bug-tracking system you can also use for planning, report, feature-tracking and new-development (Jira comes to mind). Both your Boss and your Client should be taught to use it. For yourself you probably want to add source control if you don't have it already.
Now comes the tricky part: for a short while, become very strict. Use the comment threads of your tracking system for communication. Your client will continue to call you or e-mail you. Let him. But copy everything to the comment threads and write your answer there. Send the guy a link to the thread as an answer.
You Boss may not like this because he things it will slow things down. Tell him it will become clearer what can and will be done. It will also become clearer where his money (i.e.: your time) went. Tell him that you want to keep an overview yourself, but that it's good for him too. If he's not convinced, tell him to give me a call and then propose to him to do it 100% your way for two months. He'll make it one month and then you have a deal.
It's a tough game out there. But it's doable. Propose a few simple steps towards bettering your environment, communication and tracking. If he refuses, you refuse to do anything more and he'll be stuck with an even worse situation.
In your opinion is it common and ethical to do custom software development for a Customer and then add that software to your base product which is available to your other customers?
My take on it is that:
It's a contractual issue between you
and the Customer.
It's done often (although maybe not 'common').
It's similar to the Customer paying to have their pet feature bumped up the development priority queue.
Can anyone point to any well known (or at least public) examples of this?
You are right, it should be a contractual obligation over who owns the source code. Many vendors will sell the finished product to the client but keep the source code, others will give the whole thing away (which is S.O.P. with our company)
I imagine it gets done, just not sure as far as the scope or depth of the copying.
I can't think of any well-known examples (primarily because business between two companies isn't often publicized), but a personal example is when we developed a much more flexible time-tracking system in one of our client applications and it turned out so well that we implemented it into our own personal time-tracking system (which wasn't that great out the gate).
From an ethical standpoint, I think it's actually quite simple: It's a matter of what your customer perceives you to be doing. Do they think you are customizing your product for them, or do they think they are paying for their pet requests to be bumped up in your feature queue?
As an extreme standpoint: if all custom made code could not be used anywhere else anymore then at some point you will not be able to continue your business anymore without violating that rule.
As the opposite extreme: if all custom made code would end up in a generic product then no customer would provide their specific problems to you anymore.
Of course both standpoints are quite extreme and are not likely to happen to that extent in my opinion.
Personally I would state very clearly to a new customer that in general all (custom) code could be used in other products and projects, unless it is agreed in advance to not do so for specific parts of the code. Then if it is really important to them that certain parts stay behind closed doors they will let you know.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
My company is floating the idea of extending our version numbers another notch (e.g. from major.minor.servicepack to major.minor.servicepack.customerfix) to allow for customer specific fixes.
This strikes me as a bad idea on the surface as my experience is the more branching a product does (and I believe the customer fixes are branches of the code base) the more overhead, the more dilution of effort and ultimately the less productive the development group becomes.
I've seen a lot of risk vs productivity discussions but just saying "I think this is a bad idea" isn't quite sufficient. What literature is there about the real costs of becoming too risk averse and adopting a heavy, customer specific, source code branching, development model?
A little clarification. I expect this model would mean the customer has control over what bug fixes go into their own private branch. I think they would rarely upgrade to the general trunk (it may not even exist in this model). I mean why would you if you could control your own private reality bubble?
Can't help with literature, but customer-specific branching is a bad idea. Been there, done that. Debugging the stuff was pure hell, because of course you had to have all those customer-specific versions available to reproduce the error... some time later, the company had to do a complete rewrite of the application because the code base had become utterly unmaintainable. (Moving the customer-specific parts into configuration files so every customer was on the same code line.)
Don't go there.
I agree its generally the overhead to handle customer fixes is high, but I wouldn't say don't do it.
I would say charge the customer an arm and a leg (and them some) if they want that much attention. Otherwise don't do customer branches.
You describe the changes that go into the customer branch as "fixes". Because they are fixes, I am assuming that they will also be made in the trunk and are really just advanced deliveries of future bug fixes. If this is the case, why not just create a new "servicepack" (from question: major.minor.servicepack) and give that version to the customer.
For example, you release version 1.2.3.
Customer #1 needs a fix, create version 1.2.4 and give it to Customer #1.
Customer #2 needs a fix, crate version 1.2.5, give it to Customer #2 and advertise that they also get interim fix "for free".
In my travels I haven't personally seen any definite literature for most of the good practices, although I suspect that there is a lot of stuff out there.
Versions numbers provide a really simple mechanism to tie back specific versions in the wild with specific sets of code changes. Technically, it doesn't matter how many levels are in the version number, so long as the developers are diligent in insuring that for every "unique" version released, there is a "unique" version number.
Logic dictates that to limit support costs (which are huge, often worse then development ones), a reasonable organization would prefer to have the least number of "unique" versions running around in the field. One would be awesome, however there are usually quite a few in the real world. It's a cost vs. convenience issue.
Usually, the first number indicates that this series of releases is not backward compatible. The next number says that it mostly is, but a few things have changed and the last number says some stuff was fixed, but the documents all hold true. Used that way, you don't need a fourth number, even if you've done some specific fixes at the request of a subset of your customers. The choice to become more client-driven shouldn't have any effect on your numbering scheme (and thus it's a bad idea).
Branching based on customer requests is absolute madness. One main trunk is essential, so each time you branch it creates massive technical debt. Branch enough, and you can't afford the interest anymore.
Not sure about the literature but... if there is even a chance that you are supporting customer specific fixes it seems sensible to at least have a branching and versioning strategy in place. Although I would be hoping for the strategy never to be used.
I guess the danger is you end up with a culture where customer specific fixes become acceptible and the norm, rather than addressing the true issue that resulted in the need for the fix.
I guess the real cost will largely be dependent on whether its just an interim bug fix to keep a customer happy prior to the next release or whether its more of a one-off customisation. If it is just the former, and the quantity isn't too high I wouldn't be too woried. However if its customisations i would be scared witless.
If you can find a way to compile your one product and turn on each client's features on/off in their "configuration" of a central build that might be something worth figuring out.
Something like this might best be done through a profile/config/role based setup.
You may have to secure one set of client's customizations from another, or maybe they can all benefit from it. That part is up to you.
This way you can build custom views, custom codes, custom roles, custom code, whatever. But, they're a part of one project.
Do not maintain multiple codebases of the same product at any cost. I did it once and doing an hour change takes at least 1 hour for each system if it's in the worst spot. It's suicide.
Do share what you end up doing!
In my experience, the tipping point is reached when it becomes difficult to explain how bugfixes should be propagated through the branches.
Branching hell is an issue because people lose track of what is in which branch. If propagation rules are too complex, people start making mistakes while propagating changes between branches, and that's how you create branching hell.
If the "Cisco" branch raised a defect and we fix it, should we propagate the fix to the current release of the "IBM" branch, or only to the next release of the "IBM" branch? What if IBM raised the same defect? What if IBM doesn't even use the feature that contains the defect? What if IBM later raises the same defect as high priority? With multiple customer branches propagation rules are never simple, so they pretty much guarantee branching hell.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How can our team gather requirements from our "Product Owner" in as low friction yet useable of a way as possible?
Now here's the guidelines- No posts that it can't be done or that the business needs to make a decision that it cares about quality, yada yada. The product I work for is a small group that has been successful for years. I just want to help them step it up a notch.
Basically, I'm on a 6 or 7 person team with one Product Owner. She does a great job but is juggling a few different roles (as I believe is common on extremely small teams). Usually requirements are given at sporadic times (email convos, face to face discussions, meetings, etc). They are never entered into a system and sometimes this results in features missing a release or the release getting pushed back since everyone forgot about the necessary feature.
If you're in a similar situation but you found a way to overcome this, I'd love to hear it. I'm happy to write code to help ease this situation but it can't be a web site that the Product Owner has to go to in order to get anything done. She is extremely busy and we need some way of working together as a team in order to gather these requirements.
I'm currently thinking of something like this: Developers and team members gather requirements discussed in face to face meetings and write some quick notes on the features discussed on a wiki page. Product owner is notified whenever these pages are updated and it then becomes her responsibility to ensure accuracy.
Pros: We'll have some record of the features. Cons: The developers are taking responsibility for something that they ordinarily wouldn't. I'm okay with that here. I think in this situation it's teamwork.
Of course once we do this, then we're going to see that the product owner probably doesn't have enough time to ensure feature accuracy. Ultimately she is overburdened and I think this will help showcase that fact, but I just need to be able to draw attention to that first.
So any suggestions?
P.S. her time is extremely limited so it is considered unreasonable to expect her to need to type in the requirements after discussion. She only has time to discuss them once and move on.
Although the concept of "product owner" is a littl ambiguous to me, I think I am working in very similar circumstances: the customer is extremely buzy and always is a bottleneck in developing requirements.
On the surface, what we try to do in this situation is quite obvious and seemingly simple: we try to make sure that the customer is involved in "read-only / talk-only" mode. No writing. Minimum reading. Mostly talking.
The devil, of course, is in details. So, here are some specifics about our process (in no particular order):
We often start from recording problem statements, which are the ultimate sources of requirements. In fact, sometimes a problem statement is all that we record initially, just to make sure it does not get lost.
NB: It is important to distinguish problem statements from requirements. Although a problem statement sometimes clearly implies some requirement, in general a single problem statement may yield a whole bunch of requirements (each having its own severity and priority); moreover, sometimes a given requirement my define a solution (usually just a partial one) to multiple problems.
One of the main reasons of recording problem statements (and this is very relevant to your question!) is that semantically they are somewhat "closer to the customer's skin" and more stable than requirements derived from them. I believe those problem statements make it much easier and quicker to put the customer into proper context whenever he has time to provide feedback to the development team.
We do record all the requirements (and back-track them to problem statements), regardless of when are we going to implement them. Priorities govern the order in which requirements get implemented. Of course, they also govern the order in which customer reviews unfinished requirements.
NB: A single fat document containing all requirements is an absolute no-no! All the requirements are placed in "problem tracking database", along with bug reports. (A bug is just a special case of a problem in our book.)
We always try to do our best to minimize the number of iterations necessary to "finalize" each requirement (or a group of related requirements). Ideally, a customer should have to review a requirement only once.
Whenever the first review turns out to be insufficient (happens all the time), and the requirement in question is complex enough to require a lot of text and/or illustrations, we make sure that the customer does not have to re-read everything from scratch. All the important changes/additions/deletions since the previous reviwed version are highlighted.
While a problem or requirement remains in an unfinished state, all the open issues (mostly questions to customer) are embedded into the document and highlighted. As a result, whenever the customer has time to review requirements, he does not have to call a meeting and solicit questions from the team; instead the customer can open any unfinished document first, see what exactly is expected from him, and then decide what's the best way and time (for him) to address any of the open issues. Sometimes the customer chooses to write a email or add a comment directly to the problem document.
We try our best to establish and maintain official domain vocabulary (even if it gets scattered across the documentation). Most importantly, we practically force the customer to stick to that vocabulary.
NB: This is one of the most difficult parts of the process, and customer tries to "rebel" from time to time. However, at the end of the day everybody agrees that it is the only way to make precious meetings with the customer as efficient as possible. If you ever attended one-hour meetings where 30 minutes were being spent just to get everybody on the same page (again), I'm sure you would appreciate having a vocabulary.
NB: Whenever possible, any changes in the official vocabulary get reflected in the very next release of the software.
Sometimes, a given problem can be solved in multiple ways, and the right choice is not obvious without consulting with the customer. It means that there will be a "menu of requirements" for the customer to pick from. We document such "menus", not just the finally chosen requirement.
This may seem controversial and look like an unnecessary overhead. However, this approach saves a lot of time whenever the customer (usually few weeks or months down the road) suddenly jumps in with a question like "why the heck did we do it this way and not that way?" Also, it is not such a big deal to hide "rejected branches" using proper organization/formatting of requirements documentation. Boring but doable. :-)
NB: When preparing "menus of requirements", it is very important not to overdo them. Too many choices or too many choice nesting levels - and the next review may require much more customer's time than really necessary. Needless to say that the time spent on elaborated branches may be totally wasted. Yes, it is difficult to find some balance here (it greatly depends on the always-in-a-hurry customer's ability to think two or more steps ahead and do it quickly). But, what can I say? If you really want to do your job well, I am sure that after some time you will find the right balance. :-)
Our customer is a very "visual" guy. Therefore, whenever we discuss any significant user interface elements, screen mockups (or even lightweight prototypes) often are extremely helpful. Real time savers sometimes!
NB: We do screen mockups exclusively for the customer, only in order to facilitate discussions. They may be used by developers too, but in no way do they substitute user interface specifications! More often than not, there are some very important UI details that get specified in writing (now - primarily for developers).
We are lucky enough to have a customer with a very technical background. So we do not hesitate to use UML diagrams as discussion aid. All kinds of UML diagrams - as long as they help customer to get into proper context quicker and stay there.
I am talking about requirements-level UML diagrams, of course. Not about implementation-level ones. I believe that even not very technical people can start digging requirements-level UML diagrams sooner or later; you just have to be patient and know what to put on a diagram.
Obviously, the cost of such process greatly depends on analytical and writing skills of the team, and of course on the tools that you have at your disposal. And I must admit that in our case this process appears to be quite expensive and slow. But, taking into account the very low rate of bugs and low rate of "vapor-features"... I think, in the long run, we get very good payback.
FWIW: According to Joel's nice classification of software products, this project is an "internal" one. So we can afford to be as agile as our customer can handle. :-)
"Developers and team members gather requirements discussed in face to face meetings and write some quick notes"
Start with that. If you aren't taking notes, just make one small change. Take Notes. Later, you might post them to a wiki or create a feature backlog or start using Scrum or bugzilla or something.
First, however, make small changes. Write stuff down sounds like something you're not doing, so just do that and see what improves and what you can do next. Be Agile. Work Incrementally.
You might want to be careful of the HiPPO in the room. The Highest Paid Person's Opinion is not always a good one. We've tended to focus more on providing great tools and support for developers. These things, done right, take some of the hassle out of development, so that it becomes faster and more fun. Developers are then more flexible in terms of their workload, and more amenable to late-breaking changes.
One-Click testing and deployment are a couple of good ones to start with; make sure every developer can run up their own software stack in a few seconds and try out ideas directly. Developers are then able to make revisions quickly or run down side paths they find interesting, and these paths are often the most successful. And by successful I mean measured success based on real metrics gathered right in the system and made readily available to all concerned. The owner is then able to set the metrics, which they probably care about, rather than the requirements, which they either don't care about or have no experience in defining.
Of course it depends on the owner and your particular situation, but we've found that metrics are easier to discuss than requirements, and that developers are pretty good at interpreting them too. A typical problem might be that customers seem to spend a long time filling their shopping carts but don't go on to checkout.
1) A marketing requirement might be to make the checkout button bigger and redder. 2) The CEO's requirement might be to take the customer straight to checkout, as the CEO only ever buys one item at a time anyway. 3) The UI designer's requirement might be to place a second checkout button at the top of the cart as well as the existing one at the bottom. 4) The developer's requirement might be some Web 2.0 AJAX widget that follows the mouse pointer around the screen. Who's right?
Who cares... the customer probably saw the ridiculous cost of delivery and ran away. But redefine the problem as a metric, instead of a requirement, and suddenly the developer becomes interested. The developer doesn't have to do 10 rounds with the CMO on what shade of red the button should be. He can play with his Web 2.0 thing all week, and then rush off the other 3 solutions on Monday morning. Each one gets deployed live for 48 hours and the cart-to-checkout rate gets measured and reported instantly. None of it makes any difference, but the developer got to do their job and the business shifts it's focus onto the crappy products they sell and the price they gauge on delivery.
Well, ok, so the example is contrived. There's a lot of work in there to make sure that the project is small, the team is experienced, hot deployment is simple, instant rollback is provided, and that everyone's on board. What we wanted to get to is a state where the developer's full potential is not wasted, so that's why they're involved not just from the start, but also in the success. Start out with an issue like the number of clicks during registration is too high, run it through a design committee, and we found that the number of clicks actually went up in the design specification. That was our experience anyway. But leave the developer some freedom to just reduce the number of clicks and you might actually end up with a patented solution, as we did. Not that the developer cares about patents, but it had merit - and no clicks!