Ask HN: What do engineers prefer in terms of project management? - antjanus
======
shubb
Don't do process for its own sake. Before you do any practice, understand what
it is for, and what you hope to get out of it. Trial it and abandon if is more
effort than reward.

Make doing the right thing easy. Commits to source control should be easy
because people do them a lot. Same with writing tests.

Make doing risky things slow. Deploying to live should involve some checklists
and "management sign off" because you want people to slow down and think about
whether they are about to fuck up. Ditto anything that could sink your
business or unexpectedly cost a lot of money.

If you are delivering contracts, and a lot of enterprise sales involve these,
then you signed up to deliver something. Track what that thing is, and have a
way of proving you delivered it.

Some people genuinely enjoy filling out repetitive forms. They also enjoy
writing them and getting doing one accepted as part of your project cycle.
Spot these people by boilerplate to content ratio in the documents they are
writing. Keep them away from core development.

Don't cargo cult. Don't re-invent the wheel. Use tools that don't get in the
way.

It is useful for teams of 4 or more / mixed abilities to have a process just
so everyone knows what they are doing and doesn't have to think about it. If
you are in that kind of situation, just do scrum with actual postit notes for
a couple months, then start dropping some bits and using tools for others.
Scrum is only a good estimating tool if your developers don't do operations
too. Less people than that (even as a team within a larger company), can
probably get away with just talking, shared todo lists.

------
sdegutis
"The simplest thing that works and still meets all legitimately needed
requirements."

