This note is about how to speed up the development of technologically complex Internet applications and not pay an excessive price for it. It was written to summarize and put in order the author’s own experience, but it can also be useful to other technical managers of Internet projects. The reader may be interested in the note as a source of information for making a decision about entering into such a project now or in the future — when he comes across a similar proposal.
The article also discusses the painful issue of difficulties with paying salaries and how they can be effectively solved.
Internet applications in the note are understood as websites in their pure form, as well as client-server systems with clients in a browser such as a single-page website or mobile application. Sometimes the specifics are important and it will be specified specifically.
Many of the thoughts expressed in the note apply to other types of IT projects. Be careful with this, since the author wrote only about what he had direct experience with. The reality of other IT projects may look similar, but their reality requires completely opposite steps to achieve success. Only a deep understanding of your project allows you to transfer techniques between neighboring types of projects and get significant benefits from this.
In the note, the role of the project manager is divided into the roles of technical manager and business manager. For IT projects, this is a traditional division. A business manager, depending on the type of organization, is usually referred to simply as a project manager, project manager, or CEO. A technical manager is usually referred to as a CTO, department head, architect, team leader, chief programmer or lead programmer — again depending on the type of organization and priority in favor of the organizational, programming or architectural abilities of the manager.
The business manager throughout the text could be called simply the project manager and it would be clear to everyone, but he will always be called the business manager. This is done so that you understand the simple truth: a technologically complex IT project always has two managers, one of them is a leader (business), the other is a slave (technical), but there are two of them. If the technical manager forgets that he is also a manager and also bears some responsibility for the success of the project, then in conditions of acute time constraints, this will most likely lead to the collapse of the project.
The note turned out to be about 80 thousand characters in size and will require about two and a half hours for fast reading. It will be of interest to project managers, investors and those developers who are interested in startups and the project approach to development.
About the author
The author of this note has some experience in implementing applications in the rank of a hired CTO of various startups, plus experience in implementing a couple of projects from scratch in integrators. Basically, this is the creation of Internet applications that actively communicate with servers: technologically complex websites and mobile applications.
A typical work scheme is “hiring from the market, architecture development, hiring a development team from the market, development by developers, self—implementation of the most complex functionality, launching an application and after a while exiting the project” – a real hardcore.
There is an experience of a successful exit from a project with a problematic end of financing.
What does lack of time lead to?
Miscalculations in planning. Deadlines and budget are pressing. They are fixed before the scope of work on the project is more or less accurately determined. This leads to the need to optimize time reserves and redistribute them from the management sphere in favor of direct work, since otherwise even the planned deadlines based on the network schedule of work will not meet the already sold deadlines for the completion of the project. The argument that there is not enough time will not suit the business manager absolutely. He usually understands this and is himself a hostage of the situation. Hence, there is an understanding that this is a project with an acute shortage of time. As a result, the schedule will be obviously unrealistic with the hope of all participants in this transaction that during the course of the project, time costs will be constantly optimized. Sometimes it works, sometimes it doesn’t.
Difficulties in hiring good developers at the beginning of a project. Deadlines are pressing. The developer market is not rich, especially not rich with those who want to work with an irregular working day. Therefore, there is a great desire to take more or less suitable developers from the market and start developing with them as early as possible. You should not give in to this urge. It is better to hire high—quality developers than to meet the deadlines for hiring – having disrupted the first and second reporting periods, the project management will get a much faster development speed by the end of the project. Your goal is a project, not interim reporting.
The increase in the difficulty of hiring with the development of the project. The longer the project is being developed, the more code is written, the more complex logic is implemented, the more a beginner has to understand the existing code. In addition, the constant postponement of refactoring, even in conditions of high-quality CodeReview, leads to the fact that the code sometimes becomes difficult to understand. This can lead to the fact that within three months after the start of writing the code, new hired programmers will quickly leave and the turnover for new developers will reach 100%. An experienced technical manager can cope with this difficulty in advance, a beginner cannot.
The problem of firing people. If you can’t hire people, then there are problems with dismissal. The person being fired needs to be replaced. Replacement means hiring a new developer, and they don’t linger. Therefore, the project management and the team may be forced to tolerate someone who would have been fired long ago in a normal project. Again, we return to the fact that despite the pressure of interim deadlines, hiring high-quality developers is more important than compliance with the first reporting periods.