search

ianyong / pe

0 stars 0 forks source link

No link between contacts, deliverables, and meetings #7

Open ianyong opened 3 years ago

ianyong commented 3 years ago

Productiv is a one-stop desktop app for product managers like yourself to organise your deliverables, meetings and contacts so that you can track your product’s development easily.

Productiv aims to be a one-stop desktop application. However, there is no link whatsoever between contacts, deliverables and meetings. This means that if the user wishes to look up a contact that is described in a deliverable or meeting, they would need to manually go over to the contacts mode and use the find command. Even then, there is no guarantee that the contact actually exists, as well as no way to disambiguate between contacts with the same name (in deliverables and meetings, only the name of each contact is meant to be recorded as per the user guide). This significantly reduces how helpful the application is in being a "one-stop desktop application".

nus-se-bot commented 3 years ago

Team's Response

The merits of this design is to increase the flexibility of the user. It allows the user to add contacts to deliverables and meetings when the user does not have or want the non-existing contacts to be in the contact list. This is compared to requiring the user to add the non-existing contacts before adding it in the deliverable/meeting, which is troublesome. Additionally, the app utilizes the benefits of it being a one-stop app through the Calendar feature, where deliverables and meetings are combined. Lastly, this flexibility outweights the issue of having to find items in its respective mode, since finding them require only two steps (switch to respective mode + execute find command)

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: > The merits of this design is to increase the flexibility of the user. It allows the user to add contacts to deliverables and meetings when the user does not have or want the non-existing contacts to be in the contact list. This is compared to requiring the user to add the non-existing contacts before adding it in the deliverable/meeting, which is troublesome. Additionally, the app utilizes the benefits of it being a one-stop app through the Calendar feature, where deliverables and meetings are combined. Lastly, this flexibility outweights the issue of having to find items in its respective mode, since finding them require only two steps (switch to respective mode + execute find command)

Thank you for taking the time to explain your design choices to me.

It allows the user to add contacts to deliverables and meetings when the user does not have or want the non-existing contacts to be in the contact list. This is compared to requiring the user to add the non-existing contacts before adding it in the deliverable/meeting, which is troublesome.

I understand the rationale behind not wanting to force the user to add non-existent contacts before adding them in deliverables/meetings as it can be inconvenient to the user. However, this does not justify the fact that it is entirely impossible to link contacts in deliverables/meetings to contacts in the contacts mode. The possibility should be there, although whether it is compulsory or not is up to the team.

Additionally, the app utilizes the benefits of it being a one-stop app through the Calendar feature, where deliverables and meetings are combined.

This is the only interaction between deliverables and meetings. Other than on the dashboard mode, deliverables, meetings, and contacts do not interact with each other at all.

Lastly, this flexibility outweights the issue of having to find items in its respective mode, since finding them require only two steps (switch to respective mode + execute find command)

This statement is a matter of opinion which I disagree with. It does not address the issue of contacts having the same name which was brought up in the original bug report.

type.FeatureFlaw is defined as:

Some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance-testing bug that falls within the scope of v1.4 features. These issues are counted against the product design aspect of the project.

It is in my opinion that not having any kind of meaningful interactions between deliverables, meetings, and contacts is a feature flaw because the features become less useful to the intended target user for the reasons highlighted in the original bug report. In particular, the features do not fit together to form a cohesive product. Rather, Productiv feels like three AB3s glued together with the dashboard mode that displays deliverables and meetings together being the only form of cohesion present.

:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

Reason for disagreement: severity.Low is defined as:

A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

I disagree that this flaw is unlikely to affect normal operations of the product and appears only in very rare situations. The lack of cohesion between the various features of the product poses inconvenience to the user whenever the product is being used. However, it is not a major flaw and the user can continue using the product. Hence, my classification of severity.Medium:

A flaw that causes occasional inconvenience to some users but they can continue to use the product.