4 ms·

Dont use todos or tickets or issue trackers! It takes too little effort to write a todo/ticket item. Your engineers will spend time doing work that are unneces

by z3t4 6y ago

Dont use todos or tickets or issue trackers! It takes too little effort to write a todo/ticket item. Your engineers will spend time doing work that are unnecesary and they will spend hundreds of hours implementing shitty ideas that only took 10s to come up with. Instead write down a project plan, write down the vision of the product. Write down what your goals are, and what you stand for.

taftster 6y ago
Um yeah. I mean, I appreciate your ideals. But back down here in the real world, part of that "project plan" is the part about taking a bite off the elephant. You've got to start somewhere. Defining and tracking the progress you've made eating the elephant allows you to know when you've fully consumed it. And remember, most (all?) software projects are not defined in a singularity. They evolve. As users use the product, the understanding of what you built changes. There is no ability to define a project of any significant size in a box the first time. We aren't pulling rabbits from a hat.
- randomdata 6y ago
  > Defining and tracking the progress you've made eating the elephant allows you to know when you've fully consumed it. You can also simply keep track by keeping tabs on the work you are doing, which also leads to a better product as you're familiar with what the product does rather than simply knowing that X, Y, and Z issues are closed. Non-technical stakeholders will not be able to follow it that way, having their focus on other important parts of the business, but that's why you have project managers who can follow what the technical side is doing and provide the necessary non-technical communication to them. Ultimately, you're both right. There is just some conflation going on. What is useful for some segments of an organization does not make it useful for everyone.
  - deleted 6y ago
    [deleted]

by z3t4 6y ago

taftster 6y ago

Um yeah. I mean, I appreciate your ideals. But back down here in the real world, part of that "project plan" is the part about taking a bite off the elephant. You've got to start somewhere. Defining and tracking the progress you've made eating the elephant allows you to know when you've fully consumed it. And remember, most (all?) software projects are not defined in a singularity. They evolve. As users use the product, the understanding of what you built changes. There is no ability to define a project of any significant size in a box the first time. We aren't pulling rabbits from a hat.

randomdata 6y ago
> Defining and tracking the progress you've made eating the elephant allows you to know when you've fully consumed it. You can also simply keep track by keeping tabs on the work you are doing, which also leads to a better product as you're familiar with what the product does rather than simply knowing that X, Y, and Z issues are closed. Non-technical stakeholders will not be able to follow it that way, having their focus on other important parts of the business, but that's why you have project managers who can follow what the technical side is doing and provide the necessary non-technical communication to them. Ultimately, you're both right. There is just some conflation going on. What is useful for some segments of an organization does not make it useful for everyone.
- deleted 6y ago
  [deleted]