Suggestion: development schedule.

Just a suggestion, and I\'m not sure how easy it is to implement, but something I would like to see is a development schedule. What I mean is the ability to quewe jobs, so to lay out a schedule for your designers so that upon the completion of one development stage on a component, they can then shift to another. 

Simon

Not sure what you mean Simon - you can vary the rate of developement by how many designers you have working on the components.  Is that what you mean?

The way development works now, the you can maximise your returns on designers by moving them around a lot. For example, you might have two parts you want to develop, and the development time for putting 10 on one part, and then swapping these to the next part when completed is often a lot quicker than putting 5 on both simultaneously.

What I would like to be able to do is, say, put 10 designers on suspension, and then when that part is developed to the next stage, have them scheduled to then start development on chassis. In other words, I generally have the next few stages of development planned out in my mind, and would like to be able to tell them a sequence of developments to make in advance without having to manually swap them over once the notification comes through.

To be honest, I think the development system is a bit broken right now. If I stick 10 designers on a certain part that will be ready on the 20th, it makes no difference if I put them on that part now and leave them there working on it, or move them there on the 19th. In effect, there is zero development time, merely a block on when the next part can be updated. I think a better way of doing it would be to have a progress bar for the developent of each stage of each part, so if you have some designers working on a part for 3 days and then move them to another part, that 3 days of development actually counts for something, and can be returned to and completed at a later date. It seems to me right now that time spent on a part by designers doesn\'t actually mean very much; what is in place right now seems to be \"if x designers are on this part, the next part will be ready by y\". In other words, it isn\'t the case that you need a given number of designers working on a part for a certain amount of time, rather you just need to stick that many on a part before the due date and it will be completed by then.

It has always felt like a system I\'m cheating/exploiting, rather than a logical one that makes any real sense!

Cheers,
Simon

To clarify a bit (if necessary), I think a better way for the system to work would be to say \"this development needs x mans hours to complete\". That way you could have 2 designers on the job, and for every unit time they spend on it, that is taken off the time to completion. It could be a non-linear system is deemed more realistic (i.e. 4 designers will complete a job more than twice as quickly as 2 designers, etc.) or whatever, but what I think needs to be implemented is a \"time/work to completion\" system rather than a \"date of next update\" system as is now implemented.

It seems that an earliest-next-update scheme is in place right now, but what seems far more sensible is to say the next update requires x amount of work, where x is a product of men and hours, be it linear or otherwise.

Simon

like....

i wouldnt even have to be as linear as that....

i.e. 1 designer can complete in 8 hours, 2 in 6, 4 in 4, 8 in 2, 16 in 1.....

that way, you are making quick development, (whilst worthwhile) penilised by the fact you have to spend unproportionally more for quicker results...

i.e. 1 designer will be 100% productive,  the second, only 90%, 3rd 80% etc....

(note to developer) this could be an oppertunity to review membership package, with a view to allowing \'bought\' (real money) development perks, such as instant level up or something.....

Yes Dean, I think your weighting system would make more sense; i.e. more designers simultaneously is less efficient than fewer. That way you have a proper balance to strike: more resources in one area for a more immediate result, but at the detriment to longer term development of a wider array of components. Indeed it is also probably more realistic in that, assuming all things equal, two heads are not twice as good as one since you need have \"communication/coordination time\" between the members.

As it stands, the quickest way to develop 5 components with 10 designers is to put 10 on one, and then move them to the next as they are completed.

What would be better is if (roughly speaking) the quickest way to get *all 5* components updated would be to put 2 on each, though obviously each component\'s individual development time would be longer. But also having the ability to put more designers on one part (speeding up that part\'s development), but at the detriment to the overall time to develop *all* of the components.

That would lead the way to a much more strategic development of components, as prioritising the development would be much more meaningful, as well as potentially more rewarding/costly to bad strategy.

Another thing I seem to see in the current system (that ties in a lot with my above observations), is that development works on a 12 hour cycle. I.e. there are two \"update times\" per day where new developments are completed (this may be related to me racing in a once-per-week league, I don\'t know). I think a more dynamic system with a higher fidelity of timing would benefit the system greatly, and also such a system would be where my initial suggestion of a schedule would really become a huge benefit.

Whilst this might sound complicated, I don\'t think it is, and actually think it\'s a very intuitive system, more so than the current one.

Thank you for clarifying your suggestion - and I like what you are saying.
I certainly think it is something worth looking at for the future.

note: i assume you refer to the \'fees\' section, to which i will no longer make comment on...

i too agree with simon, would make development much more involved, and woudl required thought, rather than bunging any resourse you have at it...

No problem Jake/Jack. 

The system currently in place certainly works, so it\'s not \"broken\" in that sense. I look forward to seeing how it develops!