Solving problems! Most of us would agree that is the ultimate goal of any software. It is especially difficult to create a tool that resolves several large problems. For example, effective project management is a huge problem that may be split into several smaller ones such as: easy planning, effective tracking, quality assurance, etc. What makes it extremely difficult is companies’ diversity. There are a lot of businesses with unmatched variety of processes, goals, people, cultures, tools and environments.
OK, we at TargetProcess have a niche, by supporting companies on "agile" road. However, we still face too many differentiators that need to be satisfied.
Some people want Gantt charts and Start/End dates for their tasks. To such requests we have been consistently saying “No”. Others want better high level planning, improved time tracking, easier UI, – the list is endless. We can't say “No” to all of them, since many of such requests are quite reasonable and most importantly - solve real-life problems. However, we can not add requests blindly into the Product. If we did, we would create a "bloatware scary monster" and people would start running from it.
What is the solution? The solution is to provide frameworks for solving problems. Sounds weird, but here are some examples to support this point.
Requests: "We badly need a report that includes all features, stories and bugs for current release", "I want to have a quality report that shows count of passed/failed/not run test cases for each user story in current iteration", etc.
You get the idea - people want and endless array of reports. One solution is to start implementing these reports as they coming — one by one. We feel the better yet solution is to simply allow people to build such reports without our help. Powerful reports engine resolves these types of concerns in a single hit. Moreover, people are creative and once familiar with the approach - will start to produce very useful reports that address all of their needs. The key is to make them feel in command and provide necessary tools!
Requests: "We want to group features by module! How come you don't have modules in a project?", "We have several teams in a project and want to plan and track them separately", "Your software really sucks! I can't even find all the bugs and user stories related to Safari easily!", "I played a little more with your software and I can't use it without relations between entities."
Did you get the problem? It is not an easy guess. They all look like different problems. Straightforward solution may include:
- Module entity in a project.
- Multiple teams concept implementation, including changes in relations, reports, etc. (will complicate product a lot).
- Custom fields for several entities at once.
- Dependencies between entities.
Wow, it will take time to implement all of the above features. Scary part is that these requests are just a tip of an iceberg. After implementation we will more likely receive even more "related" requests. Is there any magic bullet that hits all the targets in one shot?
Yes, there is! OK, all the requests are about categorization and relations. Categorize by module, categorize by team, categorize by browser, see all related entities that have the same value in a defined category. And the real solution is to provide an easy and flexible categorization. The answer is... tags and bundles! Let's see how all the problems above may be resolved with tags.
|We want to group features by module, why you don't have modules in a project|
|We have several teams in a project and want to plan and track them separately|
|Your software really sucks! I can't even find all bugs and user stories related to Safari easily!|
|I played a little more with your software and I can't use it without relations between entities.|
Common solutions for different problems. Tags and Bundles is a framework that will resolve almost all categorization problems. And be sure that people will find creative ways to solve other problems as well. If it is possible to plan with tags, I can't even imagine what tags will be used for (in a good way).
We at TargetProcess are trying to provide frameworks rather than straight-solution-to-one-problem. The latter approach works exclusively for the stand alone problems that cannot be grouped with similar issues.