Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As a very new software PM/Team Leader, I just want to know what is the best practice of a way to deliver a full required information about a task to the developers in my team.

In this time, I just provide them with:

  • GUI Interface (if it used)

  • DB Schema (if it is used)

  • Blueprint of main classes.

I think that's not enough. We usually have long discussions about the details; I just want to decrease the area of the discussion. What should I do? Do you think we should at least have a code review process?


migration rejected from Mar 8 '14 at 17:50

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, MichaelT, Bart van Ingen Schenau, GlenH7, Michael Kohne Mar 8 '14 at 17:50

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Mock up the interface in Excel / Access / other if you are any good at it, then start talking to the developers, as scrum preaches. Often business issues come up that would never have been anticipated. "Waterfall approach" has some holes. – Job Jun 20 '11 at 2:51

Have you tried writing specs? They make sure everybody gets to know what you want to convey, and you gotta say it (write, if you please) only once!

Read this from joel: Painless Functional Specifications - Part 1: Why Bother? (read the rest of the series too)

And as pointed by Scott, try letting the developers think/discover too.


Solving your problem will require a learning process for you and your team.

Take a look at agile development practices, for example Scrum or Kanban. Agile processes have clear guidelines on how to provide your developers with new requirements of your software.

You should focus on requirements and features instead of implementation details. The developers should make the decisions about how to implement your features.

To answer your comment:

However, key for all of this is trust. You have to trust your team that it's doing the best it can to deliver good, working software and the team hast to trust you that you know what the software needs most at the given time.

Of course you can do code reviews but the team should do this itself. If your programmers are not experienced enough, I think you have to train them and encourage them to read blogs etc. to beef up their software development skills.

The main benefit of agile software development for a project manager is that you get a working piece of software every 2-4 weeks. You can easily spot mistakes, wrong interpretations, unsuitable features and correct the planning on the fly.


If you do not want to discuss details, you have to delegate problem solving.

You have to trust your team and keep an eye on it. The best you can do is to educate your team about a few basic things you like and better about what you do not.


I think mock up is necessary for programmer as a basic requirement. From that, we can discuss how to solve and finish it with programmers. I am trying to do it on my software development project. Hopefully it works.


Not the answer you're looking for? Browse other questions tagged or ask your own question.