So, we've met. Most probably our next course of actions will follow these scenarios:
I have an idea!
Great projects start with great ideas. However, it's not enough to start development. Why not? Let's assume you want to build a house. You come to a good building company. If your requirements are settled in terms "Build me a house", the outcome most probably will not be satisfactory. The house can be of a wrong size (too small for a big family) or have some other functional flaws. At the end of the day, you simply may not like it (you wanted the same type your neighbour had).
Why is that happening? The answer is pretty obvious, noone expect yourself knows what kind of house you need. To get a satisfactory result the builders would have to learn mind-reading or they would have to ask right questions before the construction begins. The most clever thing to do is to call a skilled architect who would start with asking main parameters, such as total area, number of floors, room plans, etc. When this part is over, a building engineer is required to reckon exact dimensions and working load, choose proper materials, make a fine blueprint. Builders, who will come at last, will know exactly what to do then. And it's absolutely impossible that any link of that chain would make a decision based on its own preferences, not asking your opinion as a customer.
Software developers are the same builders. The field is a bit different, but problems are the same. Statistic shows that the majority of unsuccessful projects are due to unsatisfied customers, who got not what they expected. In our case the role of architect is taken by analysts, who conduct a number of phone, online or live meetings with the customer and write a document describing the concept of the system. That document is also called Vision. It contains only what is needed at this stage: the main purpose of the system (main use-cases), description of the projects's domain, approximate scope of the project.
What is needed from you as a customer? The main thing is understanding of what you need and willingness to answer questions. You can come up with complete Vision of the system you want to build, or you can just bring a peice of paper with a website address which you want your system to look like. On the first stage this information is enough to start asking right questions laying out the outlines for the future system.
It takes up to a week to write a Vision for a mid-range system. Looking at it we can make a rough estimations on length and cost of the project. Of course, since we don't know a lot of details, this estimation is going to be very approximate. But it helps understanding the range of project cost and make a decision whether you want to continue development. After this we can proceed further according to this chart.
I have a plan!
A great specification is like a great building plan. If builders have a good drafts they don't have ot think about the building as a whole, about its shape or about materials to be used. They don't have to think if the structure is strong enough, if the building is going to last 10 years, if it has fire alarms or enough vents. All those problems are handled by architects, engineers and designers on the first stage and clear and simple instructions are passed to the builders.
Some clients come to us with a finished specifications (we also call this document requirements). It can be FRD written by an outsourcing company or developed in-house.
This document really helps. It can be used to make quick cost estimations, and this estimation will be more accurate than estimation based on Vision. Well-settled requirements let us estimate the cost with 5% error. Also, it reduces the cost of the project, because the main part of expensive analyst's work will be already done.
Well written requirements reduce the cost and length of a project. Unfortunately, bad requirements increase both of those. What are good requirements? From our experience it's a document that describes the system's behaviour (what it must do, how it must react on various situations) and obeys two rules: comleteness and consistency. To write a good requirements special skills and experience are needed. In some projects we write the requirements with the customer, taking their documents as a start. We have written dozens of requirement documents, so we know well what requires specific attention to avoid problems in the future.
During development process we orginize meetings with analists who are not working on this project directly. This practice allow us to think out of the box, infuse good ideas from other projects and increase the overall quality.
Lets summarize: we are quite the requirements, the plan of your future home, quite seriously; we believe that at this stage mistakes are very expensive for our customers and they affect the quality greatly. We will be happy to build your house with your drafts and also will we help you improve the materials you've got, laying a strong foundation for it.
I have a system!
It's not very easy to build a large and well working system, that would be successful and popular amongst its users. However, it's even harder to improve and support such a system. When the project is in building phase, questions such as scalability, reliability, change control and monitoring are theoreticaly raised if raised at all.
But when it comes to production operation, it means a lot to think of:
— Increasing number of users
— Operating 24х7х365 without downtimes
— Increasing load on servers and network
— Increasing data volume
— Security and disaster recovery
— Improvements and new features
— Pro-active monitoring of the system and equipment to prevent failures
It is very important to think of all those aspects, understand potential problems, know how to prevent them. Otherwise your system reputation can be spoiled, your users will migrate to your rivals, and money for advertisement and marketing spent in vain.
Our teem has a broad experience supporting and improving large public projects. During four years we had been supporting and developing one of the largest online advertisement networks in Japan, so we are very familiar with high load, security, reliability, etc.
If you have such system, our experience will be very handy for you. We provide infrastructure, network and software security audit services, we are happy to share our knowledge of large systems, and we are ready to contribute to support and development of your projects.