Discovery Phase is a service that our company provides for the development of PRD (Product Requirement Document)
Let's figure it out together. Firstly, you want to develop a project that
will provide direct profit or bring you value by becoming an instrument
for your company. So the solution should work specifically as you intend
it to work. To achieve this, you, as a customer, and we, as developers,
must be on the same page and understand exactly how and what should be
done. You may say: “You are professionals - you must know how to
develop projects”, we know how to complete the project on time and with
the required quality. But if you just tell us an idea, we will not be able
to read your mind and develop exactly what you want. We need to be
realistic about this issue.
Discovery Phase is not just the development of technical documentation. During
the Discovery Phase our team carries out a lot of work in different directions
The discovery phase can be roughly divided into several stages. These works are carried out in parallel, but nevertheless, for better understanding, we will divide them into parts. So to say, we will show the process of work in the context.
Project manager starts by asking from 50 to 100 initial questions related to the project
At this stage, we are actively supplementing the project brief. We form
the sections Terminology and Technical requirements.
Often, after the first few days of discussions, the brief grows 5-10-20 times
from the original. Thus, the client himself, answering questions, tells much
more than was previously described in the brief by him. Also, our deep questions
allow you to think about the core business logic of the project as a whole.
Note
The start of the development of the project structure is the main part of the PRD
During this part each small detail, button, notification, background process is described. Our task is to sort out all the pitfalls of the project by analyzing and describing the full logic of the project. Then we find technical solutions to all the challenges before development starts.
Note
Many companies are content with simply describing everything they see on WF or Mockups in their documents (I can't bring myself to call it PRD). This is extremely problematic.
If we take 100% of the work of the development team and QA specialists, then only about 15-30% of the time is spent on developing and testing positive cases. 70% is spent on negative cases, processing of exogenous factors, data integrity checks, optimization, processing of background call-backs and webhooks.
Note
Imagine a situation. You have received a pretty estimate and an optimistic deadline. At the end of the term, the product will be rolled out to the production server. You launch a high-profile advertising campaign, invest the entire remaining budget in marketing. Drive traffic to your service/website/extension/app and suddenly a negative case (for example, a third-party API does not work, and you do not have retry set up) or an exception (for example, a negative case was not taken into account with a positive response from your own API) wastes the majority of spent resources.
We have 21 hidden tasks in the test for our front-end specialists. And one of these tasks is a negative case with a positive API response. There is a registration form where all fields are required and one of the fields is a list of positions that arrive by GET request. For example, 200 status arrived with 0 entries and all exceptions. Which shows the difference between an experienced developer and a developer with rich expertise. Even moreso, when guys with 2-3 years of experience complete a test and out of 21 hidden tasks they find only 3-5 tasks. Imagine what they were delivering at a previous job. And when you ask why this task has not been done, they say that they did not demand it from them at a previous place. We have to retrain the guys during the internship to take a self-test seriously and consider not only positive cases, but also take into account negative cases and experiences.
This is the difference between estimates and terms. It is one thing to do 30% of the work, and another thing to do 100% of the work. I think you can see the difference with the naked eye.
Let's imagine a situation
You are developing a general plan for building construction. The task is
to place an outlet and a switch for the main lighting source. And the
project document just mentions a socket on the wall, a switch on the wall
and a lamp on the ceiling without further elaboration. But wait, where are
the wires from the distribution block? What is the cross section of the
wiring for the outlet and for lighting? Where is the description of the
RCD for the outlet, what category A B C will it be. Is it a bathroom,
children's room or a socket for a power tool? I hope you understand me.
With a common example, I would like to convey to you the meaning of
describing even the simplest background processes.
A background process is what happens after some of your actions or triggered
by an event or timer (cron command, queue). And it is very important for you
and the developer to understand exactly how this process should take place.
This is not a black box, nor is it Schrödinger's box. Here the customer and
the performer must know exactly what and how everything should work.
For example, let's consider a complex purchase when goods from different suppliers
are sold on your site and each has its own internal conditions for mutual settlements,
fees and deferrals for them. All conditions of transactions be it monetary,
logistical and notifications should be accurately described in the documentation.
At this stage of WF development, you can get a "tactile feel" of your future project
Our task at this stage is to show not only the UI, but also all derivatives.
Usually we prepare WF in only two screen sizes: desktop and mobile. Already at the mockuping stage, we make 3-4 sizes (2K, desktop, tablet, mobile).
Note
Many companies just show one screen and that's it. This is not correct because in this way you and the developer do not see the real amount of work, which will then cause problems in the project and these will be your problems, not developer’s. You will not receive your project on time, and the developer will simply disappear (especially if it is a freelancer or outstaffer).
You need to forget all the Hollywood fantasy scenes where the hero's
assistant hacks the main server while sitting in the toilet of some
building while the main character attaches a piece of plastic with an LED
to a randomly selected wiring in the server room and it lights up green.
You understand that if you jump from the roof even if you believe in
yourself you will not fly like Neo (from The Matrix). Therefore, let's go
down to the earth by elevator or stairs and figure out what is Discovery
Phase, PRD, WF, GD, DO, CF, WPT, PS, UX, CR, ....
Now let's debunk the second myth - just because you see a button it doesn't
mean it works properly. Consider a classic example. When our company started
in 2005, customers often asked for a quick copy of Google: “That's one page,
a search field, and a search result. What is so difficult here?” Later in 2007,
we were constantly bombarded with requests to make a copy of Facebook, also
in a quick way, where “clients” counted up 5-10 pages. Well, this is an obvious
complex example of a complex underestimated project. Let's do something simpler
and closer to our time. 2021, the client claims that in order to accept payments
on the site, it is enough just to add a Paypal button on the site and in a
magical way the user will be able to make a payment, and the database will
be updated, web hooks will be processed, actions will be taken into account,
goods will be written off on balances, the balance will increase and the client
will receive an SMS and email notifications from the site. Now we are on the
same page that doing this is not so simple. Right?
The third myth is that an agile approach can coincide with a fixed price which
is in reality not possible neither in scrum nor in kanban, at least in our
universe.
Forth one is that a 3-5 or even 15 page brief is enough to estimate a project.
But it is not a PRD, it's just a brief. PRD is 150-300 pages in 9 kegel + High-Fidelity
Wireframes.
Last thing. Just using big words does not help to create a really high-load
project. For example, you need to create a “noSQL Mongodb project with SSR
(Server Side Rendering) based on node.js and react native”. What? It's just
a set of words like those used in Hollywood when the main character in the
film says a set of complex terms from some area. But if you understand at least
something in this area, it becomes clear to you that this is just a set of
unrelated terms.
Let's look at an example
As you know, our guys work in 7 offices of the company (2 in Tallinn,
Estonia and 5 offices in Kyiv, Ukraine). Recently we greatly expanded our
team and needed more space to fit everyone in, so in early January we
found a new bigger office space which needed a renovation. As everyone we
encountered questions of the deadline and estimate for the repairs. You
can’t just show the foreman and office manager the premises, tell them
what we want and expect to receive a deadline and estimate.
Therefore, we took it upon ourselves to develop a 3D model of the new office
in SketchUp. We thought of every little thing up to every lightswitch, camera,
even all the posters on the wall and their prints. Then we prepared a complete
and detailed document where we described all the work that needs to be done,
provided the screenshots with precise technical measurements of what and where
should be installed. We also made a list of all furniture, equipment and materials
necessary for the new office. Painstakingly described every small detail like
wall color, furniture color, location of cameras, lighting fixtures, antibacterial
lamps, alarms, electronic locks, etc. Once we made sure that we covered everything
we sent all the information for estimation. And when we met with the foreman
and furniture maker in the premises, they provided us with a full estimate,
a repair plan and a deadline in a couple of days. They guaranteed an accuracy
within +/-10-30% which is not different from our approach.
As the real practice of successful projects shows, everything should start
from the PRD.
The work team always consists of at least three people: a developer (frontend, backend or full stack), a Project Manager or a Lead Dev (hereinafter PM) and a QA. It is often the case that if a project is very dynamic there are involved two QAs or even more in order to ensure better performance and flexibility.
PRD (Product Requirement Document) is an engineering document (referred to as GD below), which includes a complete technical description of the project and High-Fidelity Wireframes (referred to as WF below). In Discovery Phase we work closely with the client to develop the project and technical documentation (PRD).
