Checklist is such a crutch for human memory, which helps not to forget to do something or check something so as not to be mistaken during any activity. Although I think that everyone at least understand something about what is at stake.

At Wild Apricot, where I work, we use checklists as one of the tools to control the quality of releases widely. We have a list of actions that need to be performed in order for a feature to go into release . We have checklists of a developer, a tester (oh ... .. how many testers test sheets have ...), and even an analyst and designer checklist. More recently, I was engaged in its processing and I would like to share the lessons I learned.

We have an analyst called a person who understands what the user's problem is, makes a list of requirements and accompanies the development.
It works closely with the development team (including the designer), which, in turn, based on the requirements, offers exactly how to solve the problem. Those. prepares and describes specific changes in the product.

')

Sick

In relation to our roles, we did the checklist first of all in order not to forget about this or other rake, which we missed in the analysis or design and which were then followed during development / testing. It is clear that at the design stage and the search for a solution, and even better in determining the initial problem, it is easier and cheaper to correct the error than when half the feature already exists in the code.
But the checklist is useful not only as a list of checks. He still

1. Accumulates knowledge of the analysis / design process. This, of course, is a list of errors, but in many respects these are also the practices and techniques that we tried or came up with ourselves, and we consider it appropriate to apply further
2. It helps to answer the question of what to do next in terms of the feature, approximately estimate the overall progress, the remaining time of work. Those. This is one of the main working documents when working on a feature.
3. It is extremely useful to adapt new employees. Those. In many ways, the checklist is a fairly detailed and applied description of the workflow of both the analyst and the designer.

Medical history

The first version of the checklist solved all the problems described above, and solved them well for about a year. And then the idea arose (well, well, the chief set the task), - that it would be necessary to reduce it, because for the year it has grown to indecent size and has become almost indigestible to use. If we list the problems by items, it was:

• stupidly long
• half of the points were applicable to some features, and the second half to others. In an amicable way, only one stage (about writing the specification) was used always and everywhere.
  This is actually a bigger problem than it might seem, because the checklist from the working tool smoothly turned into a formality, i.e. its value disappeared.
• suffered from a bunch of descriptive texts, for example, why an item is important or how best to arrange a particular document

The first logical operation was an attempt to reduce the volume by striking out the lyrics. It was Fail, because the symptoms are gone, and the disease itself remains.



Here we must take a step back to the title of the article - that we are dealing with a checklist for creative, non-formalizable processes - for example, understanding the problem and developing an optimal solution (the work of the analyst and designer). Here, in my opinion, is hidden the key problem manifested in the original version of the checklist:

In the creative process there is no clearly defined action algorithm, which can be described as an action checklist.

Finding a problem / solution always looks like this:



Formally, such a process can be described (which we did in the first version), but use it in daily work - thank you)
Nevertheless, this description is necessary, if only to adapt new employees and spread knowledge within the company. I would also add that the creation of such a description in itself clears the brain on the subject of understanding the process.

The second important point is that although in general the creative process is not formalized, it is certain that it is either already there or it is possible to single out clearly defined work stages , especially if it lasts more than a couple of weeks. For example, we understood the problem and formulated the requirements (in terms of our company, we conducted an initial analysis). Further, understanding the problem, we move on to the next stage - we start looking for a solution, etc.
And although each stage is still incomprehensible how it works (see picture above), such a division into stages fairly brings order to the chaotic process, adds transparency and helps to find errors earlier.

Therefore, a complex and long (even creative) process is necessary

• break into stages and
• for each stage, use the checklist to check for lice.

Treatment

The solution to the problem has already come up with a clever doctor Atul Gawande in his book Checklist Manifesto . It describes two types of checklists (in my very loose presentation):

• action checklist (Measure pulse and temperature, give a pill, put an enema), i.e. instructions on what to do. Used directly in the process .
• and a check checklist, which is performed after the completion of the next stage of work (check that the patient was taken to the ward, all the tools are in place, etc.).

In our original document, we actually tried to make a detailed checklist of action, which turned out to be completely inapplicable to our work process.
After understanding this, it remains for us to unravel the original checklist into two types of documents in accordance with the tasks to be solved:

• Checklist features
• Descriptive how-to with best practices.

Check list

This is actually the main working tool of the analyst and designer when working on features. It is used always and without exception , formally, each item on the list, one by one. If some item is not applicable to the feature - this is an occasion to think about changes in the checklist.

Purely in terms of ease of use, this checklist is one per feature, i.e. includes all stages of the feature life cycle. Nevertheless, it is rather short (as far as possible), i.e. includes only hi-level things:

• whether the description posted features on the wiki,
• Has the decision been agreed with the customer?
• I checked the integration with other circuits: for example with the API or with the mobile application.

In fact, every time we make a copy of the checklist for a particular feature and in it “physically” checkmarks are placed opposite each item.

• Current copy of our checklist

How-to

In these documents (one for each stage + several special ones), that “unformalized” knowledge about the process of work that we have accumulated is hidden. Here we reveal what and how we are doing, we describe in more detail the importance of certain items that we should take into account when creating new artifacts. It is this document that is, in fact, a human readable description of what we are doing, so it is extremely useful in adapting employees.

However, an experienced analyst discovers how-to is relatively rare - it is assumed that he already knows everything. Nevertheless, the document should always be on hand to refresh, for example, why and how the acceptance of the feature is done before merging the development branches. Or in order to make additions to the description of a process when fresh thoughts appear.

• Example of how-to for initial analysis

Prevention

A couple of important notes that stand out separately. Perhaps, they are applicable not only to checklists, but in general to any working tool.

It must always be clearly understood for whom and for what purpose the instrument is made.

For example, a checklist is a working document, first of all, an analyst and a designer, and it is as sharp as possible for effective use of these roles. However, the checklist is also useful for the manager to quickly understand current progress. In the checklist, there is even a separate section with the stages of work, which immediately shows where we are now.

On the other hand, how-to is more useful for beginners. However, when we make changes to the checklist, each team member becomes their newcomer, and it is from how-to that he can understand what is behind the new item, why he was introduced, what problems he was supposed to solve. This is very important until you yourself “try” a new activity with “hands”.

Checklist, like any work tool, must be alive.

Let me repeat it once again - if you believe in the value of the tool and it proved its usefulness (as we do) - then use it in your work always and without exception. If you do not use a checklist, then you do not need it. And if you don’t need it - why do it? After all, the creation of a good working checklist is a good piece of work in itself.

The second point - it is important not only to use the checklist, but also to constantly update it if something has changed. I met a new problem - do not be lazy, think it may be worth it to bring in how-to? Or maybe immediately to the checklist? Well, do not forget to notify the team about the change.

And third, if, despite persistent reminders, the checklist does not use it, then this is a good reason to talk with people or (which I hope is more likely) take a closer look at the checklist. Is it really a convenient working tool?

Statement

• There are two types of checklists: action checklist (what to do next?) And checklist (what not to forget to check?)
• For a complex creative process, only the check Chekist is applicable and it is really useful.
• If you need a detailed description of the process, best practices - put it in a separate document (how-to).
• When developing a checklist, always remember about the users and purposes of the document.
• Constantly use and update the checklist, otherwise why bother to contact him at all?