Chat as a project management system

The easiest way to manage tasks is the one that isn't. Or the one you don't notice.

Let's be honest. Each task or issue in your project can be agreed upon or even solved in a chat. Well, some of them may be discussed not in the chat, but via the calls, but this thing highlights the main point. Any project management tool, like the monstrous Jira or the fancy Notion, has always been secondary in the management process. The such system only tries to keep up with the real world. To keep the management process actual company hires a separate employee who should be responsible for this. Also, they may create additional rules, for example, demanding an issue prefix in the branch name or issue number in the brackets before each commits message. Such things are not simplified debug porocess or bring order to the process. It allows us to be sure that the user creates the task before writing the code. As a consequence, a user creates the task, estimate it, and have a discussion with the managers and colleagues. That's it.

Next to the tasks are relentless time-tracking systems, multiple layers of decision makers, bug trackers, release notes, release flags, and many more things specific to a particular industry, but these are even further away from the actual process. Even if you imagine a perfectly spherical situation in a sterile project. For example, the bug tracker automatically got a new report, after that, an internal system created a new task by a trigger, picked the author of commits, and automatically assigned a responsible developer. Will that be the end of it? Of course not. The system should have feedback from the participants. Whether it's the developer, the tester, or the manager, they will ask in a chat channel, "Hey guys, look what happened. Who's to blame and what to do?". Then there's bound to be a discussion about the nature of the bug, free developers, and assigning responsibility. And when all these questions are solved, a developer can go to the tracker and fix the problem. Well, or create the new one. And there will be something rather dry in the title and formulaic in the task body. And all of that heated discussion, all those attempts to determine what is missing and transfer the folklore knowledge about this particular module will remain in the depths of chat and then disappear after 90 days in the free plan.

Chat is primary. Chat is the place where the most important and key things for a given task happen. Chat is where the decision maker makes the important decisions, where the person who will do the task points out potential problems and points out the shortcomings of the current solution. I will stipulate again that sometimes this happens in the voice chat, but it certainly does not lure in the comments to the task.

You just have to stop lying to yourself that the task tracker is the central place of the project, where all the data threads converge. Chat is where everything happens. There are no chance to change it except the way when the any chat in a team will be denied.

Some people objected to this and said that in their project, everything happens within the tasks of the project tracker. The arguments usually pointed to the remoteness of the team in space and the different time zones of various chat participants. Someone is sleeping or eating, and someone is working. It's better to read the comments, not the chats. But the slightest study showed that when it was really necessary to decide something, not just to write something formal, the discussion quickly moved to the chat room. In most cases in private chat room, which is worse. Then it was possible to discuss the details, so that then in the comments formal language to write not explaining anything, but only declaring the decision.

We choose the other way. We're trying to figure out what we needed that wouldn't fit into a regular thread in Slack. We came up with only three points.

1. Any message in a chat room can become a task. And correspondence in that message's thread becomes a discussion of that task.
2. The responsible person for the task is not always the one who writes or the one who gets written to. The person responsible can be tagged or simply tagged via the nickname.
3. It is obvious, but it is important to have a task performer. Sometimes (not in all cases) it is important to set deadlines.

It turned out that this is the minimum functionality that will not only meet our needs but will also suit the vast majority of project teams. At the very least, this is the right place to start any project, when you want some order to tasks that were chaotically solved simply in Slack.

As a result, we created the application in Slack with the telling title "Task for Slack" first for ourselves, and then we opened it for everyone who wants to use it. Use it, it's completely free without any restrictions, additional registrations, integrations, or external services. Everything is done without leaving Slack.

I would like to hear in the comments what is missing in the tool, and what should be added to your opinion.