Re:A PM's guide to communicate effectively with software eng...
by Clubber on Tuesday February 22, 2022 @08:40AM
(#30427773)
>What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks.
>due to project scope and/or lack of resources
The product scope will at least be clearer with well written tasks. If it's a scope thing, then it will force the biz to be precise in what they want, lowering the back and forth between dev and the pm and biz. If it's a lack of resource thing, the biz needs to learn to prioritize and come to the realization that they want way more than they have the manpower to produce. Once this becomes evident, it will get bounced to a higher level.
>number of developer hours and/or expertise level of developers
These are two different things. The first is a resource availability problem and was addressed (see above). The second is a resource ability problem. This is where the smaller tasks come in. "Build a queueing system with grids that sort and search" is a lot bigger than "Create these tables," "Create this grid," "Add sorting," "Add searching." It's the divide and conquer strategy. A lower ability developer might get stuck understanding the task as a whole, but if you break it up into bite sized chunks, they might be able to accomplish each individually, or at least show better progress on some of them.
You also have to understand, you might have someone who isn't up to the task for a particular subset of skills (say database design, backend design, or UI design, etc). This will at least show you where your devs have holes in their ability/toolset. You can then decide to train them up, or just put a different developer who has that skillset on that particular task, or replace some of them.
Say you have one developer that is good at database modeling and backend and one dev that is good at UI. That's easy. Have the first do the backend / db modeling stuff and the second do the UI stuff. This allows devs to do what they are good at and ship times should improve.
>due to project scope and/or lack of resources
The product scope will at least be clearer with well written tasks. If it's a scope thing, then it will force the biz to be precise in what they want, lowering the back and forth between dev and the pm and biz. If it's a lack of resource thing, the biz needs to learn to prioritize and come to the realization that they want way more than they have the manpower to produce. Once this becomes evident, it will get bounced to a higher level.
>number of developer hours and/or expertise level of developers
These are two different things. The first is a resource availability problem and was addressed (see above). The second is a resource ability problem. This is where the smaller tasks come in. "Build a queueing system with grids that sort and search" is a lot bigger than "Create these tables," "Create this grid," "Add sorting," "Add searching." It's the divide and conquer strategy. A lower ability developer might get stuck understanding the task as a whole, but if you break it up into bite sized chunks, they might be able to accomplish each individually, or at least show better progress on some of them.
You also have to understand, you might have someone who isn't up to the task for a particular subset of skills (say database design, backend design, or UI design, etc). This will at least show you where your devs have holes in their ability/toolset. You can then decide to train them up, or just put a different developer who has that skillset on that particular task, or replace some of them.
Say you have one developer that is good at database modeling and backend and one dev that is good at UI. That's easy. Have the first do the backend / db modeling stuff and the second do the UI stuff. This allows devs to do what they are good at and ship times should improve.