4 ms·

So: - a stream of tasks, prioritized by the project manager - WIP tasks, as few as possible - a ticket system for communicating with clients; tickets should

So: - a stream of tasks, prioritized by the project manager - WIP tasks, as few as possible - a ticket system for communicating with clients; tickets should be resolved eventually - a heap/knowledge base of unresolved issues that may never be fixed

atombender 6y ago
Pretty much! I'd personally argue that the only thing that really demands dedicated, centralized software here is the support system. That said, I also think that you could build a turnkey system catering to this type of workflow. It just shouldn't be "database"-oriented. For example, I'm a bigger believer in process (than issue trackers and so on), and I think there are better ways to support the processes. For example, why does a program have bugs? Whenever a bug comes around, try to systematize it. Was it because tests didn't exist? Was the bug caused by an vendor API and not your own? Sloppy programming? Etc. Collecting and measuring can uncover systemic issues. For example, you may eventually realize that 80% of bugs could have been avoided with tests. The only way to get better is to measure and record. But issue trackers like Github and Bugzilla don't help you with that. Same thing with support systems. If you collate data about support tickets you can start to understand why you're getting support tickets in the first place. It's not rocket science, yet it appears rare.
- Kinrany 6y ago
  > not rocket science Ha, this reminds me of that other thing that is not rocket science: https://graydon2.dreamwidth.org/1597.html https://graydon2.dreamwidth.org/1597.html Perhaps we need an "awesome" list of things that are not rocket science but strangely underused.
- Kinrany 6y ago
  > support system At the risk of making the same mistake everyone else makes, I wonder whether the support system and the task queue can be the same system. They're both distinct from issues because they are made for communication with the rest of the world. (Tasks are one-way until the description turns out to be incomplete.) Of course they're also distinct from each other in other qualities. Most importantly, having more tickets is generally bad.
  - atombender 6y ago
    Maybe! My point about the support system is that it represents the "outside state". You don't have that person inside your organization, so that's they need a channel into your process. A support ticket needs to be triaged, prioritized, and executed, but that belongs in project management land. I guess the overarching idea of my philosophy is that all pieces of a company's workings need to be owned by someone. Software like issue trackers don't work because you can't replace ownership with software. You may pretend that all issues going into the system are important, but they aren't, which is how we have ended up with Github bots that go around closing "stale" issues. Thanks for reminding me about Bors. It's something we've been thinking of using.

atombender 6y ago

Pretty much! I'd personally argue that the only thing that really demands dedicated, centralized software here is the support system. That said, I also think that you could build a turnkey system catering to this type of workflow. It just shouldn't be "database"-oriented. For example, I'm a bigger believer in process (than issue trackers and so on), and I think there are better ways to support the processes. For example, why does a program have bugs? Whenever a bug comes around, try to systematize it. Was it because tests didn't exist? Was the bug caused by an vendor API and not your own? Sloppy programming? Etc. Collecting and measuring can uncover systemic issues. For example, you may eventually realize that 80% of bugs could have been avoided with tests. The only way to get better is to measure and record. But issue trackers like Github and Bugzilla don't help you with that. Same thing with support systems. If you collate data about support tickets you can start to understand why you're getting support tickets in the first place. It's not rocket science, yet it appears rare.

Kinrany 6y ago
> not rocket science Ha, this reminds me of that other thing that is not rocket science: https://graydon2.dreamwidth.org/1597.html https://graydon2.dreamwidth.org/1597.html Perhaps we need an "awesome" list of things that are not rocket science but strangely underused.
Kinrany 6y ago
> support system At the risk of making the same mistake everyone else makes, I wonder whether the support system and the task queue can be the same system. They're both distinct from issues because they are made for communication with the rest of the world. (Tasks are one-way until the description turns out to be incomplete.) Of course they're also distinct from each other in other qualities. Most importantly, having more tickets is generally bad.
- atombender 6y ago
  Maybe! My point about the support system is that it represents the "outside state". You don't have that person inside your organization, so that's they need a channel into your process. A support ticket needs to be triaged, prioritized, and executed, but that belongs in project management land. I guess the overarching idea of my philosophy is that all pieces of a company's workings need to be owned by someone. Software like issue trackers don't work because you can't replace ownership with software. You may pretend that all issues going into the system are important, but they aren't, which is how we have ended up with Github bots that go around closing "stale" issues. Thanks for reminding me about Bors. It's something we've been thinking of using.