Printable View
I read what it is, and its methodology, philosophy and I have got an headache, all boring theories.
Real world experience aside, could you help me sumarize it ?
I understand it's main task is to draft and validate a specification of a required system then deliver the spec to members:
Upper boss: Hey Pumpo, we got a req from XXX customers of this system. Here are the requirements docs.
Pumpo: Do what ? OOA/OOD myself ? Senior and Junior coders will take over OOP ?
Have now spent a month in my new position as a Project Manager, and it's been a real eye opener..
Project managers buy definition, take ALL THE HEAT for the project, It's up to you to ensure that the project your assigned gets done in the timetable given..
The 'Upper Boss' does not want to be hassled with the day to day problems of project 'XXX', Just daily/Weekly updates of progress..
It's a tough position to have, and if the coders cant solve specific problems it's upto YOU to solve, Even if you need to code it yourself..
I've spent the last week Solving Big Bug's in a massive system, where i'm doing the coding myself...
In my opinion, it varies from place to place. Project Managers (i.e. PM) in companies that are very well structures, with each role carrying concrete responsibilities acts differently then in small companies, where PM has to wear many hats at the same time. However, the bottom line remains the same that PM will be the ultimate person responsible for everything that is related to project and that not only involves coding.
For example, suppose if your company gets a world bank funded multi million dollar project, that has to be further sublet to 2 other vendors in 2 different continents, who will be primarily develop systems for 2 different ministries of a government however the overall system has to be deployed in integrated form. Here suppose your company is overall in charge of everything and YOU are the project manager. You'll have to deal with the particular hardware vendors and see which hardware is best, you'll have to see their long term support, manage other logistics, facilitates ministries and the vendors to ensure that the requirements are successfully transferred and owned, also have to track the overall development (i.e. time lines) at different sites and if any issues that they are having. Time to time, the vendors will tell you that they are doing more then agreed and the price has to be re-negotiated (in one form or another :)) and tons of other issues that has nothing to do with coding.
On to the other hand, take the example of just 3/4 guys company, who develop small utilities for general public. In this particular case, they'll be working on some idea (and requirements will most likely always be vague) and they have to use their best judgement to deliver what can be accepted. Here, PM might be the senior developer looking after development as well as providing support (i.e. via forums/discussion boards), working directly with the clients and even testing (i.e. QA activities) himself before rolling out next release.