The following are some concepts I wish I knew at the beginning of my career. Even though PM is not an alternative to healthy software development practices, I think it can help to make our dev lives easier and more fun :-).
Scope
A project is born to resolve a problem, improve something, or bring an idea to life. Regardless of how it’s started, the boundaries of a project need to be defined. Make sure you know what the requirements are. Sometimes it is necessary to specify what’s out. Depending on the team, requirements will be in a document, a board, some sticky notes, etc. What matters is to have them defined, communicated, and agreed-upon.
Communication
For each role within a team, there are activities and deliverables: A diagram, a design, source code, tests, etc. Letting know the status of your work to the rest of the team will help to keep the project moving forward. There will be ups and downs but, with proper communication, agreements can be made, changes will be complete, risks mitigated, and issues resolved.
Risks
Take some time to think about what risks you may face along the road and what would be the best way to eliminate them. Whether technical, administrative, or financial, risks need to be identified, prioritized, have a mitigation plan, and distributed among the team to be tracked and eliminated.
Schedule
We'll be asked all the time how long is it going to take to build feature X. You may be able to give a decent estimate if it is something that done before. If not, and you rush to provide a number, most likely, you'll get "past educated guess and into wild speculation" as mentioned in the Pragmatic Programmer. Break feature X into sub-features until you have an estimate that makes you feel comfortable. Keep in mind estimating is a refining process. Explain the team whenever the estimate needs to be updated.
Stakeholders
Our work (designs, code, tests, etc.) will be used by someone else or influenced by others’ work. It’s good to know what the expectations from the rest of the team are. What they want to know from our deliverables and when. Recognize improvements, let know what the risks and issues are, anything you think it should be informed. You’ll see the majority of people want to bring ideas to find a solution for problems, support progress made, and celebrate achievements.
I was not fully aware of this information at the beginning of my dev career. Then I had the opportunity to have a good grasp when I moved to a PM role. Nowadays, these concepts are making a difference on my journey to become a full-time dev again.
I hope this brief intro is helpful. Let me know if there are other concepts from Project Management that have helped during your career.
Top comments (0)