Learnings on software development
http://www.taylor.se/reddit.html and Digg posted an article on the learnings from ten years of software development.
May I add:
2. The difficult part of software development is communication
Primarily, this boils down to both verbal and written communication. Both are used at different combinations at different scenarios. When you are discussing features or effort or schedule with your customer, it makes sense if these are written as it allows you to archive the information and refer to it at a later point of time. Who knows, six months down the lane, it would be you who would be scrambling down your e-mail chain trying to figure out why a feature has to be implemented the way it is.
Even if you have a verbal discussion, it is a good idea to follow up with the minutes or a gist along with a set of action items.
On the other hand, when it comes to appraisals, evaluation or goal setting sessions, it is primarily verbal communication followed with the action items.
3. Learn to say no
Timeliness is also an important factor. One of the fundamental mistakes that I did during my early stint of project management was accepting insane deadlines. Event if you did and later find getting it done an impossibility, let the customer or client know early on that you are having problems. Your clients will be more understanding if they get to know the problems early against the last minute and will be able to make amendments like dropping a few lower priority features or diverting more resources to move some activities off the critical path. The best advice is to simply so no in the first place or ask for re-prioritization.
9. It all comes down to working software
To create workable software, it does not merely take technical skills to accomplish the objective. You are also required to have adequate domain knowledge to understand and query your customers to make decisions.
Take the time to learn about the domain, the application and how your customer envision to use your application.
Few other things that I found useful:
# Get your team's buy-in
When you make up a schedule, before sharing the milestones with your customer, ensure that your team buys in the schedule.
# Share a common goal
When working with multiple functions (like QA, testing, development and so on), ensure that the common goal is communicated and all are in adherence to them. For example, the delivery goal will be to ensure the product is shipped with the promised features on time and matches the quality requirements. Teams should focus on amicably resolving issues rather than create problems and make things difficult within.
In addition, as already indicated, the team will have to ensure that the features that are developed will actually benefit and is usable by the customer. That would require the domain skills to play in.
http://www.taylor.se/reddit.html and Digg posted an article on the learnings from ten years of software development.
May I add:
2. The difficult part of software development is communication
Primarily, this boils down to both verbal and written communication. Both are used at different combinations at different scenarios. When you are discussing features or effort or schedule with your customer, it makes sense if these are written as it allows you to archive the information and refer to it at a later point of time. Who knows, six months down the lane, it would be you who would be scrambling down your e-mail chain trying to figure out why a feature has to be implemented the way it is.
Even if you have a verbal discussion, it is a good idea to follow up with the minutes or a gist along with a set of action items.
On the other hand, when it comes to appraisals, evaluation or goal setting sessions, it is primarily verbal communication followed with the action items.
3. Learn to say no
Timeliness is also an important factor. One of the fundamental mistakes that I did during my early stint of project management was accepting insane deadlines. Event if you did and later find getting it done an impossibility, let the customer or client know early on that you are having problems. Your clients will be more understanding if they get to know the problems early against the last minute and will be able to make amendments like dropping a few lower priority features or diverting more resources to move some activities off the critical path. The best advice is to simply so no in the first place or ask for re-prioritization.
9. It all comes down to working software
To create workable software, it does not merely take technical skills to accomplish the objective. You are also required to have adequate domain knowledge to understand and query your customers to make decisions.
Take the time to learn about the domain, the application and how your customer envision to use your application.
Few other things that I found useful:
# Get your team's buy-in
When you make up a schedule, before sharing the milestones with your customer, ensure that your team buys in the schedule.
# Share a common goal
When working with multiple functions (like QA, testing, development and so on), ensure that the common goal is communicated and all are in adherence to them. For example, the delivery goal will be to ensure the product is shipped with the promised features on time and matches the quality requirements. Teams should focus on amicably resolving issues rather than create problems and make things difficult within.
In addition, as already indicated, the team will have to ensure that the features that are developed will actually benefit and is usable by the customer. That would require the domain skills to play in.
Comments