Our company highly values the client’s time, that’s why it is our top priority to complete our work in time while meeting the quality requirements.
Web development, as well as many other IT directions, requires a lot of details and nuances to be discussed and fixed. While working with our local clients from 2005 till 2012 we gained a huge experience of face to face meetings, briefings, time consuming negotiations and long phone conversations. Eventually, we came to a conclusion that it DOESN’T work. Since then, for many years we have been applying a different approach to work with our clients. The new approach might seem a bit unusual, but after being used for over 10 years so far, it has proved to be really working. Let me introduce this approach to you.
Yes, we don’t support the phone calls. All communication is done through the text chat. It has drastically saved our and clients’ time and it also ensures both parties observe all conditions. Each member of either our or your team can refer to the history of discussion of the relevant issue at any time. All he needs to do to restore the communication thread is to just open the communication history and reread it. No other person like a PM or your developer needs to be disturbed in order to do that.
It allows storing all project details, all major and minor requirements, which gives a possibility to quote, refer to or raise another question based on the existing discussion. It allows saving both time and budget of the project. For example, we can handle an argument between a QA specialist and a developer simply by finding your explanation in the chat without having to bother you.
We can keep talking about the benefits of the history being saved. But the main advantage for you is that such approach guarantees that if you wanted the button to be red, it will be red, and you can have it all worked out ahead of time. But now let’s discuss how to make work comfortable.
We use Slack for our work (Slack Connect). The most important thing is that we are going to have two private channels with you: #mgm_ and #dev_.
#mgm_project_name_abz – this private channel is intended to discuss organizational and financial issues.
#dev_project_name_abz – this private channel where you can work with our guys and discuss any technical issues.
All communication is done via these two private channels only. This way, all questions discussed regarding our mutual work are always at hand, so you don’t have to waste time on lots of channels. Moreover, the management is always present in both channels. It would be fair to say that the management is not just one click away from you, but most likely is already aware of the issues that might have appeared. As all workflow is discussed in #dev_ channel only, it makes it easy to monitor all activities.
The chats are usually used only for quick questions. For all the rest questions we use GD (Google Docs). This is a well structured file where we store all project related data, such as links, technical requirements, technology stack, issues, work plan, project structure and functionality description and an SRC folder containing all project related resources.
In fact, GD is storage of all relevant project technical documentation. It is a huge advantage for further development and support of any project. And there is no need to spend any extra time.
For example, you wish to add some new functionality or to change the existing one. In the Questions section we discuss the features and figure out the details. After that we describe the changes and add them to the structure and then submit for your approval. Once approved, this task is added to the work plan or a project backlog. This ensures regular update of technical documentation, its relevance and availability to all participants of the project.
It has never been so easy to solve difficult issues. Chat and GD provide you with a possibility to work with our team when it is convenient to you. This is the major benefit. You are completely involved into project development, and at the same time you are free to manage your time as you wish.
How does it work? You came up with an idea while being stuck in a traffic jam. All you need to do is just open a chat (<) and write about it there. By the time you reach your destination, our guys will have made their comments in the chat or will have asked the questions in the GD which they will let you know about in the chat. So, now you are aware of the questions in GD and once you have free time, you can reply them. You will be receiving notifications to your email regarding all comments in GD, so that you will always be updated.
Both you and your team are fully involved into development process. You are always aware of what is going on in your project each day and during the day. It gives a possibility to be really agile and to do only those things which are necessary at that particular moment.
If necessary, you can use task trackers like Jira, Trello, Favro, redmine etc, where you or your team can easily place all current tasks or sprints and keep backlog.
For our work we use redmine as a time tracker. The management keeps a close eye on correspondence of time spent to time tracker. There are cloud cameras installed in the offices to ensure there is always working atmosphere during the working day.
Prior to starting our work on the task, we provide a rough estimate on this task which is +/-20%. In case there are some issues arising in the course of work, you will be informed about it right away. In order to make a decision on proceeding further work or finding possible solutions to the issues arisen, weekly or monthly, according to the contract, you will be receiving a detailed response on all the tasks and the time tracker report coupled with the invoice.
We use Design by Contract (DbC) approach to develop our projects. In simple words means that the project is a split into several parts (milestones) and every milestone represents as an independent functional block. It is close by meaning to potentially shippable increment term used in Scrum.
Once we have a complete project structure and very detailed wireframes we split project into milestones. Each milestone is estimated separately in hours needed for its development and can take around 2 weeks to be implemented. In the end client gets the complete functional block.
In the first week of the current milestone designer develops mockups, lead developer writes documentation in RAML format for that part of REST API which we are going to build in this milestone and QA engineer writes test cases which cover functionality from this milestone. After mockups was approved by client frontend developer starts with slicing mockups into HTML/CSS. In the second week a group of backend/frontend developers starts implementing functionality from the milestone. At this moment they already have RAML documentation for the REST API which regulates client-server communications and HTML/CSS for the UI. After server side and client side code was finished QA engineer starts verification of the functionality from the milestone using previously written test cases. If there are any bugs found by QA engineer, backend and/or frontend developers immediately fix them. When all test cases passed successfully milestone is considered to be finished.
In the second week the first group starts already working on the next milestone. In this way we ensure iterable parallelized development process which is easy to control and allows to detect flaws in initial design on the earliest stage of development.
We used this methodology approach on different projects, both smaller ones (3-4 months) and bigger ones (>12 months). It proved to be efficient for all sizes of projects. This approach allows everyone to stay focused on a small functional block and to keep in mind all the tiniest details related to this block. Unlike classical development processes, such as Waterfall or RUP, iterative approach makes it possible to make changes to functionality at any time. If something needs to be changed, we update wireframes firstly. Then we check what milestones will be affected by this change. If functionality that is already implemented needs to be modified, we create a new milestone to make the necessary changes. If the milestone has not been implemented yet, we will make changes to it at once and then keep them in mind when we start development of the functionality in this milestone.