Skip to main content

First meeting - MVP

Team Meeting — Task Management in the Cargo Flight System​

Scene​

We are in a modern conference room with a large table and several comfortable chairs. A presentation screen hangs on one of the walls, and notebooks, laptops, and coffee mugs lie on the table. The atmosphere is relaxed but focused. Four people participate in the meeting:

  • Developer — focused on the technical aspects of the solution, taking notes on her laptop.
  • Tester — asks questions about quality and testing, ensuring clear requirements.
  • Business — represents operational needs and system users.
  • Visionary — looks to the future, pointing out scalability and system expansion.

Dialogue​

Business:
Alright, let’s start with the basics. We need a simple system to manage tasks related to cargo flights — for example, preparing the airplane, documents, or maintenance. For the MVP, we want: title, description, creation date, modification date, author, assigned user, and task status.

Developer:
Okay, so the task has basic fields. What about edit permissions? Who can change what in the task?

Business:
Only the author can edit the title and description. Assigned users can assign or unassign themselves from the task. We have three statuses: open, done, and closed.

Tester:
And who can change the statuses?

Business:
The author can close the task, and both the author and assigned users can mark the task as done. The open status is the initial state.

Visionary:
I understand we want a simple workflow at the start. But we should also think ahead — for example, automatically creating tasks based on system events, like adding a new flight, right?

Developer:
Yes, but let’s leave that for later. For the MVP, we’ll focus on manual management. Then we’ll add event-driven task creation.

Tester:
Are we planning any roles? Because if users can assign themselves, we should test this thoroughly to avoid misuse.

Business:
Not for the MVP. Roles and more advanced permissions come next.

Visionary:
By the way, we should also think about task comments and task dependency chains. That will be useful for more complex processes.

Developer:
Agreed, but for the MVP let’s keep it simple. Good that we have a roadmap for the future.

Tester:
To summarize — the author creates the task, has the right to edit title and description, assigns themselves or others can assign or unassign themselves, and status can be changed by the author (to closed) or by the author/assigned user (to done). Simple but clear rules.

Business:
Exactly. We start with this, and then expand.

Visionary:
Alright, let’s decide which system events will trigger automatic task creation at later stages.

End of meeting​

Prompt​

We have a cargo flight management system. The system is being developed with a microservices and microfrontend architecture.

We need a task management system for things like preparing the airplane, preparing documents, scheduling maintenance work, etc. For the MVP, the system should be simple:

  • A task contains a title, description, creation date, modification date, author, assigned user, and status.
  • Only the author can edit the task’s title and description.
  • Users can assign or unassign themselves from tasks.
  • We have three statuses: open, done, and closed.
  • Only the author can set the status to closed.
  • The assigned user or the author can mark the status as done.

In the future, several additional features are planned:

  • Some tasks will be created automatically by system events — for example, when a new flight is added, a task to prepare the airplane should be created automatically.
  • Introducing roles that can manage tasks.
  • Adding comments to tasks.
  • Adding more statuses.
  • Linking tasks together to create dependency chains.
  • Allowing assignment of other users.