News for hackers. Stuff that matters.
Re:A PM's guide to communicate effectively with software eng... by Clubber on Monday February 21, 2022 @04:20PM (#30420769)
I really depends on why they're having trouble shipping, so that should be the first task: find out why.

The first thing to try most of the time is to create well written tasks that can be completed in less than a couple of days, preferably a day.

This is an attempt to solve these issues:

  - Tasks that are too vague.
  - Developers that get stuck in the weeds.
  - Developers that aren't that great.
  - Identifying where the friction is.
Re:A PM's guide to communicate effectively with software eng... by cudgy on Monday February 21, 2022 @05:06PM (#30421254)
Good point that it depends.

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.

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.

Re:A PM's guide to communicate effectively with software eng... by beckingz on Monday February 21, 2022 @05:30PM (#30421569)
Agreed that getting more specific with tasks is helpful.

Unfortunately, it's hard to leave the engineering approach for larger projects to the developers when their productivity (and apparent satisfaction) increases significantly with task specificity.

Maybe this just indicates an issue with developer experience/seniority.