Gathering Requirements | IT's time to talk #3

00:00 → 00:04

Gathering requirements is a crucial element

00:04 → 00:08

in any IT project because information

00:08 → 00:12

that IT team will be collecting in the beginning may

00:12 → 00:16

reflect in such factors as business goals or user feedback.

00:16 → 00:20

Today, I'm talking with two experts coming from Merixstudio,

00:20 → 00:23

Krzysztof Sikora and Kacper Świętkowski about

00:23 → 00:25

gathering requirements.

00:25 → 00:28

This is Merixstudio series. It's time to talk.

00:34 → 00:36

Hello, gentlemen. How are you doing?

00:36 → 00:39

Doing good, Mike. Glad to be here.

00:39 → 00:40

Hi. Hello.

00:40 → 00:43

So I'm super, super glad to have you on this beautiful morning.

00:43 → 00:44

Gentlemen,

00:45 → 00:48

please tell a few words about your professional experience,

00:48 → 00:49

about your background.

00:49 → 00:52

What are you bringing to the table today?

00:53 → 00:55

So I can start.

00:55 → 00:58

I am software engineer by education.

00:58 → 01:01

I have been coding on the Java stack for a years after my

01:01 → 01:02

university years.

01:02 → 01:06

And recently, I have been doing a lot of product

01:06 → 01:10

ownership, product management, as well as

01:10 → 01:14

helping the engineering teams to come up with the best

01:14 → 01:17

solutions to match the business

01:18 → 01:19

requirements.

01:19 → 01:23

So I kind of see myself as a person that sits between the

01:23 → 01:26

business and development, and this is where I find myself

01:26 → 01:28

contributing mostly.

01:28 → 01:31

At Merix, as a presales engineer,

01:32 → 01:36

I basically help customers to define their

01:36 → 01:39

problems and guide them through initial stages of

01:39 → 01:42

drafting the the solution architecture.

01:42 → 01:46

So today, I think I can bring a lot of experience

01:46 → 01:50

regarding product definition architecture

01:50 → 01:54

and, yeah, basically going with all of that through the

01:54 → 01:56

project to delivery.

01:57 → 01:59

And I'm Kacper.

01:59 → 02:03

I'm a software architect and a process engineer as well.

02:03 → 02:07

And I've got, like, fifteen years of experience

02:07 → 02:12

working commercially both as a product owner and product

02:12 → 02:16

manager developing my own projects as

02:16 → 02:20

well as for third parties as a vendor.

02:20 → 02:24

And, yeah, I tried to bring my experience to

02:24 → 02:26

help customers achieve their goals.

02:26 → 02:32

I'm business oriented, but same story as with.

02:33 → 02:36

I've got technical experience, technical education,

02:36 → 02:39

and I'm still an active developer.

02:40 → 02:43

Kate and gentlemen, thank you very much for this.

02:43 → 02:46

So it sounds like we have a very powerful expertise for

02:46 → 02:48

today's interview.

02:49 → 02:52

Okay. Let's start with starters.

02:53 → 02:58

What are the key factors in gathering requirements for the project?

02:58 → 03:01

What kind of assets are the most important in the beginning?

03:01 → 03:02

Yeah. Sure.

03:02 → 03:05

So, I mean, it's fair to say that books have been written

03:05 → 03:10

about gathering requirements, and even set of books have

03:10 → 03:13

been have been written about, doing it in a certain style,

03:13 → 03:17

like agile requirements gathering, user stories creation.

03:17 → 03:19

So it's such a big topic,

03:19 → 03:23

that it's really hard to kind of answer the

03:23 → 03:26

question in a couple of sentences.

03:26 → 03:30

But I think what is key to understand is that you

03:30 → 03:33

need to commit a certain amount of time.

03:33 → 03:37

And usually for organizations, means people,

03:38 → 03:43

to help the software house like Merixstudio understand what

03:43 → 03:45

is the problem you're trying to solve,

03:45 → 03:48

what is your business about, and then how we can help.

03:49 → 03:54

And then go through the process of capturing the

03:54 → 03:57

requirements in a more or less formal way depending

03:57 → 04:00

on on the problem that we are facing.

04:01 → 04:03

So I would start with that, like,

04:03 → 04:08

understand the high commitment, provide the right people,

04:08 → 04:13

and then, let yourself be guided, by the professionals,

04:13 → 04:15

like business analysts, product managers,

04:15 → 04:18

or owners that have went through the process and know

04:18 → 04:23

the traps and the techniques to capture it,

04:23 → 04:25

yeah, in the right way.

04:27 → 04:28

Okay. And, Kacper, any thoughts?

04:28 → 04:32

What I may add is

04:32 → 04:35

that usually enterprises are

04:35 → 04:40

much more complex that a product manager is aware

04:40 → 04:42

of in the beginning.

04:42 → 04:45

And as Krzysztof said, like,

04:45 → 04:49

presence of certain stakeholders,

04:50 → 04:54

And very often, what you can expect is during

04:54 → 04:56

the product analysis,

04:56 → 04:58

you'll learn something about your company,

04:58 → 04:59

and this is a good sign.

04:59 → 05:04

If it's not happening, probably it means that we didn't

05:04 → 05:07

go too deep, and

05:08 → 05:11

there's there should be some knowledge that is

05:12 → 05:15

extracted from those meetings.

05:16 → 05:19

What I would say is I

05:19 → 05:22

would focus not only on proper

05:22 → 05:26

requirements gathered, but as well

05:26 → 05:31

as creating good requirements in the first place.

05:31 → 05:34

So understanding how you want to achieve your goals and

05:34 → 05:38

focusing on your goals and limiting yourself to your goals

05:38 → 05:40

is is crucial.

05:40 → 05:44

So probably we'll dive deeper on this,

05:44 → 05:49

but having a good plan is a crucial

05:49 → 05:53

part for later processes.

05:54 → 05:55

Alright.

05:55 → 05:59

Like, a lot of people just come to us and say, hey.

05:59 → 06:02

I want the website or I want this and that.

06:02 → 06:06

And because they have seen it, at the competition,

06:06 → 06:08

they have used a similar product.

06:08 → 06:12

But what they don't realize is how this website

06:12 → 06:14

or any software product will fit their business,

06:14 → 06:17

their business model, their specific needs,

06:17 → 06:20

people that they work with, people that work for them.

06:20 → 06:22

So I think

06:22 → 06:25

one of at the very early stages,

06:25 → 06:28

what we do at Merix is try to bridge this gap and client

06:28 → 06:30

clarify customers

06:31 → 06:35

that they need to think it through so that in the end,

06:35 → 06:38

they just they don't get just a website.

06:38 → 06:41

They get something that solves their problem in the best

06:41 → 06:44

possible way, and they basically get the return on

06:44 → 06:48

investment on custom software because this is what we

06:48 → 06:50

what we excel at.

06:50 → 06:51

Exactly.

06:51 → 06:55

So, website is just a solution for

06:55 → 06:59

a certain need, and it's very important to distinguish

06:59 → 07:02

between solutions and actual needs.

07:02 → 07:05

Because very often, you can come to a software

07:05 → 07:08

house with some certain understanding of the

07:08 → 07:11

solution, but

07:12 → 07:18

maybe we can try to to build something better.

07:18 → 07:23

Or maybe there is already a solution for that existing on the market.

07:23 → 07:26

So focusing on your, like, basic needs,

07:26 → 07:28

basic goals

07:28 → 07:33

may lead to better solution at the end rather than

07:33 → 07:37

just focusing on, estimating a single

07:37 → 07:41

solution that you've already have in mind.

07:42 → 07:43

Alright then. Yeah.

07:43 → 07:47

I think that transferring the context is always a tricky part.

07:47 → 07:48

Yeah?

07:48 → 07:51

But sometimes this can be done with very simple words

07:51 → 07:54

like, I have, I don't know,

07:54 → 07:57

fleet managers who are not tech savvy,

07:57 → 08:01

and they require a service that will help them navigate,

08:01 → 08:05

let's say, trucks driving all around United Kingdom.

08:05 → 08:08

Yeah. Or I do have a this and that application.

08:08 → 08:12

And sometimes, I'm noticing that stakeholders are missing the part.

08:12 → 08:14

How what is the context of usage?

08:14 → 08:15

Yeah. Who will be using it?

08:15 → 08:19

And ironically, this this information,

08:19 → 08:22

which doesn't necessarily be very specific,

08:22 → 08:26

is very helpful for us as a supplier to understand

08:26 → 08:28

because we are able to give some recommendations.

08:29 → 08:33

But understanding who is the user,

08:33 → 08:36

this is something that should come from the stakeholder,

08:36 → 08:39

and I think that this is a crucial element here.

08:39 → 08:40

Okay then.

08:40 → 08:44

So how can stakeholders support this process?

08:45 → 08:46

How can they, for example,

08:46 → 08:49

increase the accuracy of estimation,

08:49 → 08:53

or how can they help us make good decisions when it comes to

08:53 → 08:55

the tech stack?

08:56 → 08:58

The client comes to us.

08:58 → 09:01

I'll let you just client comes to us with a

09:01 → 09:05

business problem and with some information and how we can use

09:05 → 09:10

this information in order to give good guidance and proceed.

09:12 → 09:12

Okay.

09:12 → 09:16

So let me answer the first question with the accuracy.

09:16 → 09:20

So first of all, you need to understand that estimate

09:20 → 09:22

shouldn't be a single number.

09:22 → 09:26

Like, you can give a huge an estimate with huge

09:26 → 09:29

precision, but it won't be accurate.

09:29 → 09:32

And there's this difference between accuracy and precision.

09:32 → 09:36

And so I think you should understand that

09:36 → 09:39

there's some probability that we'll

09:39 → 09:42

end up with a given range,

09:42 → 09:46

and it's all about this probability and the

09:46 → 09:50

certain certainty we've got with those numbers.

09:50 → 09:54

And so there's a different

09:54 → 09:58

level that a customer can different level of

09:58 → 10:02

risk or different amount of risk that a customer can accept.

10:02 → 10:04

And this is very crucial.

10:04 → 10:08

If you're at the beginning of your journey and you need a

10:08 → 10:11

ballpark figure just to make sure that, okay,

10:11 → 10:13

this is more or less feasible,

10:13 → 10:16

then the process looks completely different when

10:16 → 10:19

you've got a strict number in your head and you've got your

10:19 → 10:22

budget already planned and you cannot exceed this amount.

10:22 → 10:27

So if you know your needs towards the risk

10:27 → 10:30

management, then we can apply a different

10:33 → 10:37

tools that will decrease the

10:37 → 10:41

uncertainty to a level that you are okay with.

10:41 → 10:45

And for instance, you can do a scoping session

10:45 → 10:48

where all of your requirements will be analyzed,

10:48 → 10:52

digested, and maybe refined in a way.

10:52 → 10:54

For example, we can do mock ups,

10:54 → 10:59

or we can do data flow for the architecture or

10:59 → 11:01

whatever the need is.

11:01 → 11:05

If sometimes it's not enough, then you can do, like,

11:05 → 11:09

whole UI and UX already planned and

11:09 → 11:14

maybe phase that out so that the more you

11:14 → 11:19

plan ahead, the less uncertainty we've got down the row

11:20 → 11:21

the road.

11:21 → 11:25

The third thing in very technical,

11:25 → 11:29

projects where there is a lot of integration and multiple

11:29 → 11:30

parties involved,

11:30 → 11:34

maybe even our working skeleton approach would be, beneficial.

11:34 → 11:38

So it means that we are going to

11:39 → 11:42

work for a sprint or two, so maybe a month,

11:42 → 11:46

just to make sure that every end of this

11:46 → 11:50

equation can be connected and everything

11:50 → 11:53

works more or less as we expected.

11:53 → 11:56

Because what

11:56 → 12:00

what you can learn along the way is, as I said,

12:00 → 12:03

answering the first question, that

12:03 → 12:06

things might be more complicated that

12:06 → 12:08

you anticipated.

12:08 → 12:11

And with such

12:12 → 12:18

tools involved, you can limit the risk on your end.

12:22 → 12:24

Think now you are muted, Mike.

12:24 → 12:25

Yeah.

12:25 → 12:28

I was asking you, do you have any thoughts on that?

12:28 → 12:29

I'm sorry for this.

12:30 → 12:34

I mean, I think I would add on that that

12:35 → 12:39

an estimation for me is already part of the project.

12:39 → 12:42

So I think it's good to understand once you get

12:42 → 12:45

involved yourself into building a software,

12:45 → 12:49

like custom software, is that a reliable,

12:51 → 12:55

more accurate estimation is part of doing the project.

12:55 → 12:56

So you cannot really

12:58 → 13:02

make the estimation before doing the project and expect

13:02 → 13:07

it to be to be accurate accurate in a sense that you

13:07 → 13:08

can fix the budget.

13:08 → 13:11

Of course, there is a certain

13:12 → 13:15

set of projects that can be done that way that follow a

13:15 → 13:19

certain template that are kind of either be

13:19 → 13:22

based on building blocks that we put

13:22 → 13:25

together and configure or are basically more kind of

13:25 → 13:26

integration projects.

13:26 → 13:30

But if we speak strictly about custom problems and custom

13:30 → 13:33

software, I think the estimate is kind

13:33 → 13:37

of an ongoing thing, an ongoing

13:37 → 13:39

process in the project.

13:39 → 13:44

And in the end, you only know how long it will take after you are done.

13:44 → 13:48

And with software projects that are part of the of the

13:48 → 13:50

business, that are really at the core of

13:50 → 13:54

the business, you are you are not really done.

13:54 → 13:54

Never.

13:54 → 13:54

Right?

13:54 → 13:58

Because they kind of live on and have to be maintained,

13:58 → 14:01

extended, and adjusted to your ever changing business needs.

14:01 → 14:07

So I think this is important to kind of understand that

14:08 → 14:11

we are not really kind of copy pasting

14:12 → 14:17

code base across industries and customers.

14:17 → 14:20

It's all customs and real projects.

14:21 → 14:23

Alright then. Thank you very much, gentlemen.

14:23 → 14:26

So next question would be,

14:26 → 14:29

what kind of resources and assets do we use in the process?

14:29 → 14:32

Is the Figma prototype the best asset you can imagine,

14:32 → 14:34

or is this something else?

14:34 → 14:36

How does it look like?

14:38 → 14:42

I I think my thoughts on that is that and it kind of connects

14:42 → 14:43

to your previous question.

14:43 → 14:47

Is that what we usually try to do for any more complex project

14:47 → 14:51

is we try to approach the problem from many different angles.

14:51 → 14:54

So we don't only look at the UI.

14:54 → 14:57

And when you mentioned Figma prototypes,

14:57 → 14:58

they really help a lot.

14:58 → 15:01

They help a lot especially at bridging the gap between the

15:01 → 15:05

users or stakeholders, customer, and us.

15:05 → 15:10

And they are kind of playing a key role in

15:10 → 15:13

understanding what has to be built, how it has to work.

15:13 → 15:17

But from that or even in parallel,

15:17 → 15:19

we do other things, like already mentioned.

15:19 → 15:21

So prototypes,

15:22 → 15:26

checking the API documentation, verifying nonfunctional

15:26 → 15:30

requirements, and then building architecture drafts based on

15:30 → 15:34

that as well as providing

15:35 → 15:40

the future team that will develop it, acceptance tests,

15:40 → 15:43

simple calculations for any project that has kind of

15:43 → 15:48

a a model and produces some numbers, for example.

15:48 → 15:52

So I would look at the whole process of

15:52 → 15:56

identifying what the system is as a kind of

15:56 → 15:57

multilayered

15:58 → 16:00

approach.

16:00 → 16:01

And

16:02 → 16:05

it's I think it's one of the traps where we see some

16:05 → 16:09

customers coming with a very fine detailed Figma

16:09 → 16:14

prototypes and assuming this is all we need to build the system.

16:14 → 16:15

And,

16:17 → 16:21

of course, one thing is that this will evolve over time as

16:21 → 16:24

the understanding changes and people use the system and see

16:24 → 16:26

it in action rather than just on the screens.

16:26 → 16:28

But other than that,

16:28 → 16:31

I think as the teams kind of build it and approach it from

16:31 → 16:33

engineering perspective,

16:34 → 16:38

the requirements and the ways the way how things can be done

16:38 → 16:40

and integrated with the outer world change.

16:40 → 16:42

So, I mean, for me,

16:42 → 16:45

a key thing is to look at things from different angles

16:45 → 16:49

and use different tools because they will very quickly get

16:49 → 16:53

you accelerated in the process.

16:53 → 16:56

And don't push any of the techniques to the extreme

16:56 → 17:01

because the you will be basically caught by this

17:01 → 17:04

diminishing results trap.

17:04 → 17:08

So, yeah, I I think that's that's how I see it.

17:09 → 17:11

Yeah. So I couldn't agree more.

17:11 → 17:14

When it comes to the tools composition,

17:14 → 17:18

I would say that it's all about the uncertainty cone.

17:18 → 17:22

So for instance, if the aim of our

17:22 → 17:25

project is to acquire a user from the

17:25 → 17:30

Internet, and we want pass him through

17:30 → 17:34

the CTR and other metrics,

17:34 → 17:38

then a Figma file is great because we can conduct a study

17:38 → 17:40

even before writing a software,

17:40 → 17:45

and we can see how certain screens

17:47 → 17:51

operate and what's the overall outcome from them.

17:51 → 17:55

So this is, like, great tool to achieve that.

17:55 → 17:56

But on the other hand,

17:56 → 18:00

if you've got an embed project with limited

18:00 → 18:03

resources on it, and then, like,

18:03 → 18:06

Figma file is just a very small part of it,

18:06 → 18:09

and may it may happen that you will encounter

18:09 → 18:14

significant obstacle in a technical realm.

18:14 → 18:19

So, still, it may take some of the

18:19 → 18:23

experience to be able to assess the risk where

18:23 → 18:24

they actually are.

18:24 → 18:29

So I cannot tell that Figma file is is

18:29 → 18:32

one tool for all of the projects.

18:32 → 18:35

But this is a very good tool,

18:35 → 18:38

and it's you you usually,

18:38 → 18:43

it's a huge benefit when it is done correctly.

18:45 → 18:47

K. Thank you, gentlemen.

18:48 → 18:51

So as we can hear, Figma may be good for some things,

18:51 → 18:53

but for some other things, not.

18:53 → 18:54

I believe that sometimes diagrams,

18:54 → 18:58

good description of of of how, for example,

18:58 → 19:00

how the back end's supposed to look like.

19:00 → 19:03

In a couple of projects that I've been working with,

19:04 → 19:07

the prototype was made using Excel file.

19:07 → 19:07

Yeah.

19:07 → 19:10

Like, one of our projects,

19:10 → 19:14

we built an offering tool for field sales representatives,

19:14 → 19:17

and the client originally came to us with Excel file

19:17 → 19:19

explaining all of the, let's say,

19:19 → 19:23

calculation mechanisms standing behind the cost of service that

19:23 → 19:28

the service provider was offering in their area.

19:28 → 19:29

Alright then.

19:29 → 19:30

Another would be,

19:30 → 19:34

how important is it to describe business goals of the project?

19:34 → 19:37

Do you appreciate, for example, such things as, for example,

19:37 → 19:38

quantifiable data?

19:38 → 19:42

Like, hard numbers that need to be achieved.

19:43 → 19:43

Yeah.

19:43 → 19:47

I think this is very helpful and actually

19:47 → 19:50

allows you to focus on

19:51 → 19:55

problem solving, sometimes even better just than

19:55 → 19:58

focusing on requirements

20:00 → 20:02

provided by the customer.

20:03 → 20:04

And

20:05 → 20:07

you can learn a lot of

20:07 → 20:10

non functional requirements as well.

20:10 → 20:15

And what I can tell from my experience is usually

20:15 → 20:18

when, there's a business goal,

20:18 → 20:21

then there's a more focus

20:21 → 20:24

on measuring what matters.

20:24 → 20:27

So very often, if you gather requirements,

20:27 → 20:32

the focus is on core functionality of given platform.

20:32 → 20:36

But, if you understand how the success is going to be

20:36 → 20:38

measured, then you understand that, oh,

20:38 → 20:43

there's a different pool of tools that you have

20:43 → 20:47

to use, for instance, for advertising to reach

20:47 → 20:51

those goals and for analytics to understand if this

20:51 → 20:54

goal is going to be met,

20:54 → 20:58

if there's some changes that you need to make to the

20:58 → 21:00

process to reach that goal.

21:00 → 21:05

And it's completely different paradigm and focus shift

21:05 → 21:10

if you've got, like, real business goals and KPIs to achieve.

21:10 → 21:14

So to me, it's a very good idea to focus on

21:14 → 21:17

things that you're going to measure and make sure that

21:17 → 21:22

you're measuring those in the first place and then later on

21:22 → 21:26

following the numbers along the way.

21:27 → 21:29

Alright. And thank you for this.

21:30 → 21:31

Okay.

21:31 → 21:34

We've been talking a little bit what kind of knowledge,

21:35 → 21:38

the stakeholder, the client may bring, what kind of,

21:38 → 21:42

let's say, knowledge we can bring to the

21:42 → 21:44

table, what are, let's say, the procedures.

21:44 → 21:47

But I was wondering a little bit bit about

21:47 → 21:52

the tools and techniques of gathering requirements.

21:52 → 21:56

What we are having at our belts that that

21:56 → 22:00

can help us make those sessions with the clients more effective?

22:03 → 22:07

I think, I mean, we do a lot of agile kind of

22:07 → 22:09

requirements gathering.

22:10 → 22:13

Especially when we sit down together on the workshops

22:14 → 22:16

and have a more time,

22:16 → 22:21

we kind of invite the stakeholders from the customer.

22:21 → 22:25

We have someone representing product design,

22:26 → 22:29

technical development expertise from Merix.

22:29 → 22:30

And then

22:31 → 22:34

what we start with apart from understanding the

22:34 → 22:39

motivation, the goals, and KPIs are user journeys

22:39 → 22:44

that we translate into epics or user stories.

22:44 → 22:47

So well known after so many years,

22:47 → 22:50

but often misused at the same time.

22:51 → 22:55

But either way, that's basically how we try to

22:55 → 22:58

capture the requirements in the first place.

22:58 → 23:01

So go from the very high level

23:01 → 23:04

understanding of what the user is trying to achieve,

23:04 → 23:08

write it down to understand who, why,

23:08 → 23:11

and then what's the end result,

23:11 → 23:15

and then kind of deep dive into individual

23:15 → 23:19

areas or epics of the system

23:20 → 23:25

that are either really of high value or are

23:26 → 23:29

kind of tough to understand.

23:29 → 23:33

And maybe we kind of perceive them as complex to implement.

23:34 → 23:38

So, again, kind of approaching the problem from a

23:38 → 23:41

couple of different different angles.

23:41 → 23:42

So

23:43 → 23:46

that's that's one of the techniques that we use to

23:46 → 23:49

capture the requirements.

23:51 → 23:55

And I'm a great advocate for event storming.

23:55 → 23:59

So event storming is a technique that we try to

23:59 → 24:03

put all of events within a given

24:03 → 24:08

company on a board, and we've got all of the

24:08 → 24:12

stakeholders in the same place so that we

24:12 → 24:18

can make sure that everyone understand the entire process.

24:18 → 24:22

And this is very interesting part,

24:22 → 24:24

and the the collaboration is huge.

24:24 → 24:28

And as I said, this is usually the moment when you learn

24:28 → 24:31

something about your company that you didn't know before.

24:31 → 24:33

Because if you got, like,

24:33 → 24:36

different departments on the same

24:37 → 24:39

room talking about the companies,

24:39 → 24:42

then very often you learn that there are different

24:42 → 24:47

perspectives, and maybe you're doing some marketing product.

24:47 → 24:48

Yeah.

24:48 → 24:49

Exactly. Exactly.

24:49 → 24:50

And then very often,

24:50 → 24:53

you you'll learn that maybe you're doing something twice or

24:53 → 24:56

something is not needed or etcetera.

24:56 → 24:58

There are very different conditions in different

24:58 → 25:01

companies, but,

25:01 → 25:06

usually, it's very beneficial to have a session like this.

25:07 → 25:10

So we are not, like, talking

25:12 → 25:14

with the client in silences,

25:15 → 25:18

but it's very important to have a meeting where where

25:18 → 25:22

everyone can talk with everyone.

25:23 → 25:23

Yes.

25:23 → 25:27

One of my reflections is that

25:27 → 25:30

in my personal experience, because I am,

25:30 → 25:34

until some point, involved in gathering requirements,

25:34 → 25:38

one of the things that I noticed is that

25:39 → 25:42

business people are busy, and they claim

25:42 → 25:44

themselves to be busy.

25:44 → 25:47

And sometimes the gathering requirements process looks

25:47 → 25:51

like like a long email ping pong,

25:51 → 25:53

which sometimes, in some cases,

25:53 → 25:55

may even last for a couple of weeks, if not months.

25:55 → 25:59

And, what I

25:59 → 26:03

like and what I'm hearing today is that,

26:03 → 26:07

sometimes it's better to make a stop and sit together for just one day.

26:07 → 26:11

And, those, let's say, six or eight hours spent together,

26:11 → 26:14

they are an equivalent of, let's say,

26:14 → 26:18

several emails, diagrams, dashboards, shared documents

26:18 → 26:21

that will be exchanged between the teams.

26:21 → 26:24

But it's sometimes it's just basically better to sit

26:24 → 26:28

together, brainstorm, ask ourselves sometimes even uneasy

26:28 → 26:32

questions, and then push things forward with much greater pace.

26:33 → 26:36

Speaking about stakeholders, speaking about clients,

26:36 → 26:39

there are different verticals, industries

26:39 → 26:40

that we serve.

26:40 → 26:41

Yeah?

26:41 → 26:45

What we need to take into consideration while working with them?

26:45 → 26:46

Yeah?

26:46 → 26:49

Are there any standards that we need to take into consideration?

26:49 → 26:50

What is the difference, for example,

26:50 → 26:54

between serving a solar panel company and

26:54 → 26:57

logistics company and manufacturing company?

26:57 → 26:59

How can we

27:00 → 27:04

increase our commitment to each one of them keeping in mind

27:04 → 27:06

that they are different?

27:08 → 27:09

I mean, at least from my experience,

27:09 → 27:12

I haven't seen different

27:12 → 27:15

horizontal techniques applied by software teams or software

27:15 → 27:19

houses to gathering requirements across verticals.

27:19 → 27:20

Like

27:20 → 27:25

Mean, you can apply scrum or prints to or any

27:25 → 27:30

other methodology pretty pretty much with a success

27:31 → 27:35

At different types of products in different verticals.

27:35 → 27:38

What I have seen working for different companies and

27:38 → 27:42

industries is that once you go very deep into

27:42 → 27:46

one industry like telecom, you will come across,

27:46 → 27:50

of of course, the the the knowledge,

27:50 → 27:54

the a lot of acronyms, the language people speak, and then

27:55 → 27:57

the standards that follow.

27:58 → 28:02

And, usually, what happens is that these teams kind of built

28:02 → 28:04

on top of that certain processes.

28:04 → 28:06

So I would say, like,

28:06 → 28:09

you have different templates to gather requirements,

28:10 → 28:13

and there is some kind of

28:14 → 28:18

entry phase into this required by,

28:18 → 28:22

for example, Merixstudio to understand and process.

28:22 → 28:25

But other than that, I mean, it's kind of, I would say,

28:25 → 28:31

transcultable between what you can encounter in a big telecom company

28:31 → 28:34

to what we do on a daily basis.

28:34 → 28:38

So I think usually what we do applies across

28:38 → 28:40

verticals from my experience.

28:42 → 28:44

Right. So, Krzysztof?

28:44 → 28:47

One note that I may add is usually a company has,

28:47 → 28:51

like, core domains which are differentiators

28:51 → 28:56

of which of what given company is actually

28:56 → 28:59

doing and what is known for.

29:00 → 29:04

But there is a huge number of generic domains

29:04 → 29:06

or supportive domains.

29:06 → 29:10

So it actually means that if you're in

29:10 → 29:14

ecommerce, then you still need to place an

29:14 → 29:15

invoice or something like this.

29:15 → 29:20

So the there is a huge space that is shared

29:20 → 29:24

across of different companies, and they share the same needs.

29:24 → 29:27

And you you usually, this is, to some extent,

29:27 → 29:29

the the easy part.

29:29 → 29:33

And there's these things that actually

29:33 → 29:36

differentiate you from the market,

29:36 → 29:42

and most effort usually goes into that space.

29:44 → 29:44

Yeah.

29:44 → 29:48

But, usually, the way you're going to acquire

29:48 → 29:52

requirements is very similar with the

29:52 → 29:57

exception of industries that are strictly formalized.

29:57 → 30:01

For instance, there are very different standards for

30:02 → 30:06

banking industry for instance, and there's different

30:06 → 30:09

needs when it comes to the

30:09 → 30:14

transport trans transparency, how things work,

30:14 → 30:17

and how the process are defined in those environments.

30:17 → 30:23

It's not up just up to the client

30:23 → 30:25

how things may be done,

30:25 → 30:29

but there's some external requirements that sometimes

30:29 → 30:32

they need to be gathered as well

30:33 → 30:37

in order to fulfill the project goals.

30:38 → 30:41

Alright then. So we need to keep in mind legal regulations.

30:41 → 30:44

We need to keep in mind industry standards.

30:45 → 30:48

We need to keep in mind formalities.

30:49 → 30:52

Okay, gentlemen. Last question today.

30:52 → 30:57

Believe it or not, what kind of advice you

30:57 → 31:01

I believe forty years of combined professional experience.

31:01 → 31:04

What kind of advice you gentlemen would give to

31:04 → 31:07

stakeholders aiming to hand over a project?

31:07 → 31:09

How can we help them avoid mistakes,

31:09 → 31:13

make the work effective, and onboard handover project

31:13 → 31:16

and IT project efficiently?

31:17 → 31:21

I would say come open minded if you knock on Webex door

31:21 → 31:26

and expect different result that you originally intended.

31:26 → 31:29

And usually, for the better, I mean,

31:30 → 31:35

it's it's the whole journey and discovery that is so much important.

31:35 → 31:37

Remember that

31:38 → 31:42

software house doesn't mean, like, only coding.

31:42 → 31:46

It's building the whole product and develop an engineering,

31:46 → 31:50

which I think I would say is even more important

31:50 → 31:53

than than just writing the code.

31:54 → 31:55

Other than that,

31:55 → 31:59

be transparent and provide as much information as as possible.

31:59 → 32:03

Like, we we want to partnership on building

32:03 → 32:07

and solving the problem rather than be handed over

32:07 → 32:10

documents and the things that have to be built.

32:10 → 32:14

Like, we have so much expertise with different technologies and

32:14 → 32:18

different products as the team and even as

32:18 → 32:22

individuals that we can really provide insights provided

32:22 → 32:26

that we are given the opportunity and information.

32:27 → 32:28

And,

32:29 → 32:33

yeah, I think these are the three things that come from

32:33 → 32:35

from top of my head at the moment.

32:36 → 32:38

So for me,

32:39 → 32:44

I will I would advise to go extremely lean,

32:44 → 32:48

usually much leaner than the initial

32:48 → 32:52

request for proposal is, and leave yourself

32:52 → 32:57

room for, what you're going to learn along the way.

32:57 → 33:01

And the other thing is to use already

33:01 → 33:05

made software as much as possible.

33:05 → 33:09

Define your core domain, define what differentiate you from

33:09 → 33:14

the market, and then spend your money building your custom solution.

33:14 → 33:18

But don't spend your money building something that is already built.

33:18 → 33:22

This is a very common mistake that

33:22 → 33:25

I think is made.

33:26 → 33:31

And be very focused on risk management

33:31 → 33:35

and try to reduce the risk as much as

33:35 → 33:38

possible and maybe sometimes

33:38 → 33:44

prioritize towards those areas

33:44 → 33:48

that brings most of the risks.

33:48 → 33:51

So, usually, I will tackle those areas first and make sure

33:51 → 33:56

that later on, we've got only easy part that is left.

33:58 → 34:01

Alright then. Thank you very much for this.

34:01 → 34:06

Gentlemen, I think it was a very insightful fall talk to

34:06 → 34:07

stakeholders.

34:07 → 34:10

We dedicate this conversation to stakeholders,

34:10 → 34:13

business founders, managers, decision makers,

34:13 → 34:18

people who want to build an IT product or service,

34:19 → 34:22

using software development company like ours or even

34:22 → 34:24

perhaps with their own in house team.

34:24 → 34:24

Yeah?

34:24 → 34:27

Because, in some cases, the process may be quite similar.

34:27 → 34:30

Yes. We need to introduce what are the business goals.

34:30 → 34:33

We need to introduce who are the final groups of users.

34:33 → 34:34

We need to

34:35 → 34:37

elaborate, for example,

34:37 → 34:41

the legal requirements of a product or service that we will be building.

34:41 → 34:42

So, nevertheless,

34:42 → 34:45

you will be building this in house or outsourcing this to

34:45 → 34:46

another company.

34:46 → 34:48

Those rules apply.

34:49 → 34:52

Krzysztof, Kacper,thank you very much for joining today.

34:52 → 34:55

I hope that there will be a chance to see each other

34:56 → 34:57

some other time.

34:57 → 35:02

This was it's time to talk conversation from Merixstudio.

35:02 → 35:04

Thank you all. Thank you for watching.

35:04 → 35:06

Have a great day. Bye. Likewise.

35:06 → 35:09

Thank you. See you. Bye. Bye.