About an Effective Software Development Process

How is one company different from another? Why are customers happy to order from one company, but do not notice another? Why is one company developing software for a year and a half, and another is managed in just six months? There are many reasons, but they all share one feature - successful companies are effective. We will talk about how to increase the effectiveness of a company based on its individual components in this article.

Infrastructure and tools

Typical infrastructure problems:

- no server and mobile devices for testing applications;
- there is no necessary version of the database or software or it is not configured;
- there are no accounts, services are not used for project management, tasks, accounting, customer accounting and orders.

Such problems can be solved (should be solved) very simply: you must have an account on Microsoft Azure or Amazon to deploy your web projects and APIs, you must have test devices on all popular (and, ideally, not very popular) operating systems. Software can be obtained by subscription, leased or (you will not believe!) Buy.

The main goal of the whole process: as quickly as possible to give the first answer to a potential client to his request. The less time you spend on deployment and evaluation - the better.

Somehow I needed a server. Well, not that I personally needed it, but rather, for the project that I conducted, but we can say that I needed it. I acted like a true Aryan and wrote to my boss about what I needed and why. After a short pause (two weeks) I was asked to write the same thing, only to the higher authorities, which was done immediately. A little more time passed (about a month) when I received a letter stating that I had not convincingly substantiated the need for a server. Then I wrote that, in principle, I do not really need a server so much, and a laptop, in general, is an excess, and I want to distract from my important activities my silly requests. Three months later, they found the server (they took the old computer, on which the department employees stored the porn), and the project with this approach, of course,

At a lower level, it is important to use proven tools, libraries, development environments that can greatly save you time and, consequently, money.

Work is in full swing in the department - there is very little left before the deadline, and it is not possible to deploy the product on a test server. The best minds are puzzling over this problem - two architects, technical experts and a senior developer. The whole snag in memory - when deploying to a test server, it simply is not enough and the script debugged on local servers is full of error messages. This has been going on for several days and the authorities are no longer in humor, to put it mildly ... The problem turned out to be that one of the modules was incorrectly configured, which led to the generation of a lot of debugging information, which “clogged” all available memory. Manual debugging did not help identify the correct module. This was done by a special program - a debugger for one vendor, which was installed on the local machine and after five minutes showed which of the modules refused to work normally. The authorities appreciated my modest contribution to solving the problem and after a few days I bought licenses for this product for all developers.

Automated testing, continuous integration, tools for remote debugging, scripts for deploying environments and images are difficult at first, but very effective practice later allows you to automate part of the work, get rid of the routine, and find problems quickly and in the initial stages. Many companies have already appreciated the importance of automation, opening relevant vacancies and preparing their own personnel for automation.

We started to do a new project for one large enough customer. It was necessary to configure the server for CI, testing and deploy a version control system. Everything would be fine, but we did not have a server. A letter was written to the authorities with a request to provide a server (or at least an ordinary computer). Two weeks later, another letter, a month later - another. The return came in the style of “why do you need a server?”. Two months later, when the correspondence turned into a theoretical discussion of the need for hardware and software in an IT company, some old half-working computer was found, which became that server. Although, as you might have guessed, even the initiative “from below” did not save this project from failure.

And yes, the tools must match the level of your company. Managing a hundred people and twenty projects with the help of Google Dox is possible, but difficult. On the other hand, installing Sharepoint if 5 people work for you is also not comme il faut. You always need to be friends with your head and reality.

Expertise

Nowadays, a unique expertise can be a rare, specialized or new technology (Tizen, Xamarin, Unity, AutoCAD), domain domain (development of mobile applications for banks) or specialization (acceleration of Wordpress, automation of UI tests). Knowledge of a particular mainstream language, technology or CMS cannot be a competitive advantage.

To whom, with other things being equal, will the potential customer go to a company with 25 programming languages ​​and technologies indicated on the site or one with expertise related to its task? I think the answer is obvious. Although, in fairness, it should be noted that many customers buy an extensive portfolio (not related to its task), big names and professional sales that can sell snow to the Eskimos. But let’s not talk about such customers now ... Specialization is an effective way to position a company without additional efforts and marketing.

Remout

The world is changing, but not all companies are changing as fast. At a time when state borders in the virtual world have long been erased, and people can work even from home, even from bungalows in the Seychelles, not using it, in my opinion, is simply stupid.

How often did you have to look for employees? Well, if you are an international corporation a la Microsoft or Google, or you are in big cities - Kiev, San Francisco or London. And if you live in a small town and have a narrow specialization? In this case, the only right decision is to work with remote people. I do not specifically speak with “freelancers,” because the “remote employee” and the “freelancer” are different people.

Are you worried that the employee will filon? Are you worried about adding hours? I have bad news for you: you simply do not know how to adequately assess the amount of work and labor. The truth is that an employee who sets a goal to do nothing will filon at least remotely, even if at your side equally.

And the companies that insist on relocation to another city or country just because they are so used to and do not trust remote employees, cause me sincere misunderstanding.

In general, we buy a book Remout, read, stop worrying and start living.

Communication

Perhaps the easiest and most difficult item at the same time.

On the one hand, a lack of communication is bad, on the other hand, a lot of communication does not help either. I am already silent about the endless rallies, correspondence for 25 people and other delights of “communication”.

As they say, do not know what to do, do a rally.

The effectiveness of rallies in our time is greatly exceeded, especially when the number of protesters is more than three. There were days when out of an 8-hour working day, six hours were occupied by rallies. While the two resolve a not-so-critical issue, several people are forced to listen to it all.

But is this familiar? Please fill in the hours in the time tracking system, then the hours spent on tasks in the project management system, update the documentation and the gant chart, in the evening a daily report will come, and then at 10:00 all the same tell everyone what you are, my friend, Yesterday I did and what you will do today between filling out reports and rallies.

Samurai Code

There are several rules and recommendations on how relationships with your customers should look, as well as within the company itself:

1. Each ordinary employee should have no more than two bosses, and the tasks and the time of their implementation should not contradict each other. Otherwise, the employee will be forced to independently determine the priority of tasks, which he, with a high degree of probability, will do wrong due to the lack of all necessary information and knowledge.
2. On any project, each team member must know their role (or list of roles), as well as the role of each person on the part of the customer. In other words, each member of the team must know who has the right to make the final decision, who will take the project, whose orders are recommendatory, and whose are binding.
3. For each type of project, it is necessary to have a list of prepared questions in order to outline TK at a high level from the very beginning. For a mobile application, this list can look like this: 1) what platforms and their minimum versions need to be supported 2) is there a ready-made API and if not, when will it be ready 3) will the implementing company take part in publishing / supporting the application and etc.
4. The clarity and detail of the statement of work should depend on the clarity and adequacy of the customer. If the customer clearly knows what he needs, then the technical specifications may be minimal. If the customer swims and often changes his mind - TK should be as detailed as possible. Attitude towards new customers should be more critical than current ones, and the best way to test the adequacy and speed of decisions is to get an advance payment. It is at this stage that you test the entire process of work, but in miniature. And if there are difficulties at this stage, it means not to avoid difficulties in the future.
5. Murphy's Law, I hope everyone knows :-) There are a couple more that it would be nice to remember. 1) Parkinson's Law 1: work fills the time allotted to her. So, according to Parkinson, if a team can write a project for a year, then it will write its year. 2) Pareto law (or the Pareto principle): 20% of the efforts yield 80% of the result, and the remaining 80% of the efforts give only 20% of the result. 3) in case of revaluation of the budget and terms of the project, the price of the error will increase linearly, and in case of underestimation - exponentially. 4) 9 women can’t give birth to a baby in a month, and the maximum limit of time compression is no more than 25%. Further - only overtime and a decrease in overall efficiency.

Summary

The result will surprise you: depending on the efficiency of the processes, the productivity of one and the same person can vary 2-5 times. That is why small companies are always more effective than corporations or large body shops. It is the efficiency of the processes that makes the project 2-3 times faster than competitors. That is why the cost per hour of an “effective” employee is higher than that of body shops, but the final price of the project will always be lower.