[how to end up a project?]

Question

0.00/5 (No votes)

See more:

I really am a bit confused and i wish to have some opinions about the following subject :
1.I run as a junior developer into a company.I expect for project to be well defined , with clear written specification,even a model and my project to have the associated code together with theoretical consideration about environment (it is about Microsoft platforms and frameworks).Instead, i receive a very unclear schema grid (3 pages) and nobody ask me to write a thing about solution,just code behind and views.Which way do you consider is more appropiate?

Posted 8-Aug-13 7:06am

Member 8237823

Add a Solution

Comments

Dholakiya Ankit 8-Aug-13 23:19pm

@Member 8237823 no can answer better than solution1 so kindly read it and get it

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-08-08T07:18:00

It's more appropriate to discuss the situation with the team members, not with us. Don't delay important discussions, try to clear things as soon as possible.

Remember that the team might have done quite a sloppy work on preparation for this project and documentation, by whatever reasons. Nevertheless, don't wait until people get it ready for you to proceed. Instead, try to actively participate. If the project goals, architecture or whatever else is not yet well shaped, consider this as an additional opportunity for you to contribute the way improving the work of the team. In all cases, ask a lot of questions.

One important detail: try to focus on fundamental ultimate goals of the project, not the decisions which are already made — they tend to change, and you are the one who want better decisions. Always try to realistically estimate your own limited experience, but it should not stop you from speaking out on the problems you can see; in this respect, don't be afraid of making mistakes: they are quite understandable.

Again, ask many questions. Try to get as far as to the understanding of the work of your end customers and their real need. Try to get your own independent understanding of those needs, as the companies tend to form their own vision which may be better than customer's, but in many cases misunderstanding is being developed, so try to make your own independent observations. One more thing: write down all your notes, especially on those starting (inception) phases of the project.

—SA