Read next
Developing
business software
Our services
A conversation with new clients usually starts with discussing their needs. We talk about what they want to achieve and how precisely these requirements have already been defined. This is important because clients come to FINGO with projects at various stages of development: sometimes with just the idea, sometimes with a ready documentation, graphics and detailed descriptions of functionality, sometimes with extensive, formal specifications.
At the first stage of the conversation we try to understand the company we're talking to, its profile and what business goals we can help them accomplish. It is very important that both parties understand how our expertise can translate into their success.
I ask about the goals the application is expected to fulfill. I want to understand what the system is intended for. It also helps if the clients lists their requirements and provide a concept of the application. Of course, the form and the complexity of the application description vastly depends on its type. If we believe that the description needs to be clarified, we will ask further questions to grasp the essence of the problem.
The answer to the question about the business objective behind creating an application is really crucial. This allows us to make the right decisions as to selection of functional and technical solutions at all stages of cooperation. The second question concerns the application functionality, i.e. how our client imagines the way in which the application is expected to work.
It is important that the question „why?” is not perceived as challenging the idea of our client. This is not the crux of the question. In FINGO, we ask „why?” because we want delve deeper into the issue, the challenges and the goals to be met with the support of our software. This allows us to understand the consequent choices of the client concerning functionality and gives us valuable clues to offer the right solution.
Let's not forget about the questions concerning the behavior of the application and its functionality. The answers give me the knowledge about the processes of the client's company and the idea how it wants to realize its objectives. If there is no confidence that it will achieve the business objectives and we are faced with a completely new challenge, our method at the stage of designing would usually involve making hypotheses and verifing them by creating prototype solutions.
Prototyping usually makes sense and helps us avoid expensive mistakes when we undertake to develop complex applications. It pays to create a prototype when the software is expected to support a completely new process.
Prototypes are created for three reasons: firstly, to verify the correctness of assumptions regarding the functioning of the application as a whole; secondly to see how the users use applications and eliminate imperfections at the interface level; thirdly - where applications process big amounts of data, to test performance.
We use whichever tools let us do it quickly, but there is no single standard that fits all - the choice of the method depends on a particular situation. It is best when the prototype is created with a tool, which the prototyping person is familiar with - this allows to achieve results quickly. Of course, if you want to check performance, we use the target technology - the one a system or application is being developed in.
As an example, when preparing an application for a computer wholesaler recently, I went to work in this business for one day to delve deeper into the nature of tasks of people for whom the system is prepared. Understanding the process and what is important in this job, and which activities take the most time allowed us to prepare a much better solution than if I had spent that day speaking to the client.
Depending on the client's expectations we take the role of either a counselor or a contractor. When developing a system to exact specification of the client, we are expected to be a contractor. We simply have to implement whatever was detailed in the specification. In a majority of the projects, however, we also act as counselors whenever our clients expect an experienced partner to talk details of the software design, the expected functionality and the preferred technology. They just expect us to share our experience with them. Of course, we are always happy to do it.
Whether software development is expensive or not is quite relative - are we talking expensive compared to the client's turnover, compared to performing the work manually, or in absolute terms?
I think you should rather think about how to best optimize spending money on software. A minimum viable product is often a good choice - the basic version of the product, as it should be delivered to users. This approach also allows you to launch applications without incurring excessive costs on features that may not turn out very useful in the future. The users, after the initial few weeks or months of use, will show us the best direction of further development. This is much more efficient than detailed planning at an early stage application development.
Versioning allows you to spread the cost in time and avoid developing redundant features.
When choosing the technology, we take into account several factors. The first one is the maturity of the technology. Then comes the suitability of the technology for the purpose. Node.js serves an obvious example here - a web-based technology suits best for developing a web application.
Another factor is what devices the technology has be compatible with. If an application is expected to work on non-Windows computers, it should not be developed in .NET, and a cross platform technology is needed instead.
We factor in client's preferences too. This may involve existing resources - e.g. if the client is currently using an Oracle database and does not want to switch to other databases. The competence in the team plays a role too.
Finally, there is another criterion. It may not seem obvious, but we prefer technologies we have confidence in. We choose friendly technologies. This makes application development much faster and more efficient.
The design is complete when all key issues concerning how the software is to be made have been settled. The details like the position of the fields on each screen will obviously be agreed later in the application development process, but areas such as business objectives, functional requirements, user interface, technology, ways to exchange data with other systems and the development plan are critical and allow us to move on to the implementation phase.