I recently was assigned to a task, but it says only a couple of words, like, do it as it made there, with no actual spec attached. What is the best thing to do in that circumstances?
Your situation is quite common and when I was developing things for non-technical clients it happened to me all the time.
When those people hire you they most often don't know what they really want. They just know they want "something like that" or "something that can help me with this".
Part of a job of a competent software developer is to help those people make up their mind. That means that maybe you should think about the project and come with some specs yourself. Then you can finalize them with the other side. The specs are essential because with them you can clearly say if you completed the task or not.
Get the specifications! If that is not possible, reject the task! It is your responsibility as a programmer to force the person asking you to do this job to provide you with sufficient information. This is not only in your best interest but also in the best interest of said person. Otherwise you risk that your client will be unhappy of the results, and as a consequence, that will make you downright miserable.
Well, your question seems a little bit vague to me because you really didn't mention what you need to know and what you get from the client, however, I always try to be realistic and think like the client in these situations.
Let say you have money and you want to order a sport car, or a big house or the nicest leather jacket in the planet or whatever else you think it's nice to buy. The question is, when you're ordering something that you're not expert in that field, can you specify the materials, specifications, etc. or not? For example, if you have to choose the gate for your big house, will you specify where they have to place the lock and the keyhole size or you just simply leave it up to them and you will choose the shape of the gate and its color? Again, if you're not an engineer, can you specify all the characteristics and specifications of the car you're gonna order or not?
Simply you can't specify them because you don't have any idea what they are and how they should be. As a client/buyer, you just need to draw the outlines of the final product and it's their job to make it work in a way that fits your needs.
Imagine if you feel your client needs some level of extra security for their web application, or if they mention that clearly, then it is your job to offer them to use
SSL. You don't need to make them understand what is SSL, how it works and why it's necessary for them. You have to tell them what is the added benefit of using that thing (in this case SSL), the extra effort needed to implement it and its price, and then it will take up 30 seconds for them to make up their mind and decide whether they want it or not.
However, I agree that in some working situations you might probably receive vague tasks, mostly from your supervisor or the project manager. The only thing I can recommend in these situations is:
- First, make them clearly understand that they didn't provide sufficient information (make it official, send them email so you can referrer to that in the future).
- Second, ask for the information you need in a nice way, let them knows that you will work better if they give you the proper information or at least as much as they have/know (make it clear that it's for their benefit, not because you are lazy or unexperienced).
- If the information is not provided or it's not sufficient in the end, try to do it as normal and as usual as possible. Try to understand them and their needs. If you didn't specify your preferences on the light colors for your new house, you probably want warm or pure white (something usual) not anything red-ish/blue-ish.
It depends on how much your process is flexible.
If your process is agile, you can start prototyping it and get various aspects either approved or clarified along the way. It is what agile process was created for. But it requires that somebody (customer delegate, product manager or such) is available to approve it and that you won't be blamed for delays caused by them changing their mind over and over.
If your process is not agile, responsible person to approve the realization is not readily available or you risk being blamed for delays, you have to insist on getting the specification clarified before you accept the task.
If your employer/supervisor/client didn't give you a specification, you will have to write one yourself and get them to sign off on it.
For every project, there are three things you need to know:
- What is the problem you are trying to solve?
- What are the deliverables?
- How will you know when you are finished?
Until and unless you have the answers to these three questions, WRITTEN DOWN AND SIGNED OFF, you are not ready to start doing ANYTHING but getting the answers to these three questions, written down and signed off.
The answers to these three questions form the core of your spec and your statement-of-work.