On an effective software development process

How does one company differ from another? Why customers are happy to order from one company, but do not notice the other? 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 efficiency of a company based on its individual components in this article.

Infrastructure and tools
')
Typical infrastructure issues:

- there is no server and mobile devices for testing applications;
- there is no required database or software version or it is not configured;
- no accounts, no services are used to manage projects, tasks, accounting, customer records and orders.

Such problems are 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, rent or (you would not believe it!) To buy.

The main goal of this whole process is to give the first answer to a potential client to his request as quickly as possible. 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 was leading, but it can be said that I needed it. I acted as 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 my superiors, which was done immediately. It took a little more time (about a month) when I received a letter saying that I had not convincingly substantiated the need for a server. Then I wrote that, in principle, I don’t really care about the server, and the laptop, in general, is overkill, and I want to distract from the important activities with my stupid queries. Three months later, the server was found (they took an old computer, to which the department employees stored porn), and the project with this approach, of course, safely turned down after some time.

At a lower level, it is important to use proven tools, libraries, development environments that will help you save a lot of time, and, accordingly, money.

The work is in full swing in the department - just a bit is left before the deadline, and it’s impossible to deploy the product on the test server. The best minds - two architects, technical leader and senior developers - are puzzled over this problem. The whole snag is in memory - when deploying to a test server, it is simply not enough and the script, debugged on local servers, is replete with error messages. This has been going on for several days already and the authorities, to put it mildly, are not in humor ... The problem turned out to be that one of the modules was incorrectly configured, which resulted in the generation of a lot of debugging information that “hammered” all the available memory. Manual debugging did not help identify the correct module. This was done by a special program - a debugger of 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 - this is difficult at first, but very effective later practice allows you to automate part of the work, get rid of the routine, find problems quickly and in the initial stages. Many companies have already appreciated the importance of automation by opening relevant vacancies and preparing their own cadres on automation.

We started to make a new project for one of the largest customers. It was necessary to configure the server for CI, test and deploy a version control system. All anything, but we did not have a server. A letter was written to the authorities asking for a server (or at least a regular computer). Two weeks later, another letter, a month later - another one. The return message 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, an 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 hundreds of people and twenty projects using Google Docks is possible, but difficult. On the other hand, installing Sharepoint if 5 people work for you is also not comme il faut. Always need to be friends with the head and reality.

Expertise

Nowadays, 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) can be a unique experience. Knowledge of a particular mainstream language, technology or CMS cannot be a competitive advantage.

To whom, other things being equal, will the potential customer go - to a company that has 25 programming languages ​​and technologies indicated on the site, or one that has expertise related to its task? I think the answer is obvious. Although, in fairness, it should be noted that many customers are bought for an extensive portfolio (not related to his task), big names and professional sales people who are able to sell snow to the Eskimos. But let's not talk about such customers now ... The presence of specialization is an effective way of positioning the company without additional efforts and marketing.

Remout

The world is changing, but not all companies are changing as quickly. At a time when state borders in the virtual world have long since been erased, and people can work even from home, even from a bungalow on the Seychelles Islands, in my opinion, it’s just silly not to use it.

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 the 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 “freelancer” are different people.

Are you worried that the employee will be filing? Worried about what will finish the clock? I have bad news for you: you just do not know how to adequately estimate the amount of work and labor costs. The truth is that an employee who sets as a goal nothing to do will be phony though remotely, even if you are equally close.

And companies that insist on a relocation to another city or country just because they are so accustomed to distrust their remote employees, cause me sincere confusion.

In general, we buy the book of Remout, we read, we stop worrying and we begin to live.

Communication

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

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

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

The effectiveness of rallies in our time is greatly increased, especially when the number of protesters is more than three. There were days when from an 8-hour working day six hours were occupied by meetings. While two solve a not very critical issue, several people have to listen to all this.

But is it 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 came a daily report, and then at 10:00, tell everyone what you, my friend, I did yesterday and what will you do today between filling out reports and rallies.

Samurai code

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

1. Each ordinary employee must have no more than two supervisors, 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, most likely, will do is not true due to the lack of all the necessary information and knowledge.
2. On any project, each team member should know his / her 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 should know who has the right of the final decision, who will accept the project, whose orders are advisory, and whose orders are binding.
3. For each type of project, it is necessary to have a list of prepared questions in order to outline the TK at a high level. For a mobile application, this list may look like this: 1) which platforms and their minimum versions need to be supported 2) is there already a ready API and if not, when will it be ready 3) will the executing company take part in the publication / support of the application and etc.
4. The clarity and detail of the TZ should depend on the clarity and adequacy of the customer. If the customer clearly knows what he needs, then the TK may be minimal. If the customer floats and often changes his decisions - the TK should be as detailed as possible. Attitude to new customers should be more critical than to current ones, and the best way to test the adequacy and speed of the decisions made is to receive an advance payment. It is at this stage that you test the entire work process, but in miniature. And if there are difficulties at this stage, it means that difficulties will not be avoided in the future.
5. Murphy's Law, I hope everyone knows :-) There are a couple more that I would like to remember. 1) Parkinson's Law 1: the work fills the time allotted to it. So, according to Parkinson, if a team can write a draft year, then it will write it a year. 2) Pareto's law (or Pareto principle): 20% of efforts give 80% of the result, and the remaining 80% of efforts - only 20% of the result. 3) in case of reassessment of the budget and terms of the project, the price of the error will grow linearly, and in the case of underestimation - exponentially. 4) 9 women cannot give birth to a child within a month, and the maximum time limit is no more than 25%. Next - only overtime and reduced overall efficiency.

Results

The result will surprise you: depending on the efficiency of the processes, the product of the same person can change 2-5 times. That is why small companies are always more efficient than corporations or large bodyshops. It is the efficiency of the processes that makes the project 2-3 times faster than the competitors. That is why the cost of an “effective” employee per hour is higher than that of bodyshops, but the total cost of a project will always be lower.