Work on the bugs in the footsteps of one project

A bit of background

I want to tell the distinguished community about my first project, on which I spent this summer, and about the findings in his footsteps. Not that I had never led any projects before, but they were done on a residual basis, and the deadlines were very free. For example, I slowly sawed the project on switching to the Universal Transport Adapter for sharing files with the Central Bank of the Russian Federation for over a year (in the end, everything worked on time and works well).

It should be noted that I do not specify the name and some details, because otherwise I will touch on information related to the DSP.

But this year I changed the job from support to project management and rushed. At the new site, work on all kinds of implementations and improvements is going on downright in the pipeline mode, in a very short time. Less than a week, I was handed a ¹ partly developed project for the implementation of software designed for ummm ... collecting and structuring information from different sources on different objects - physical and legal persons. They handed it to me with the promise "this thing can do everything, implement it, it's the right thing." The developers also said “we can do everything!” And in confirmation they confidently hit themselves with the heel in the chest. I was fascinated and started working. ²
')

Stages of the project

Previously, the project was successfully transferred to one unit, but the price turned out to be very heavy and they decided to divide the cake into all. It was necessary to recruit customers from different departments. Then I ran into a previously unknown support activity called “cold calls”. People, until now, have not heard anything about me, about the proposed project, are generally busy and have no time. Almost no one wanted to participate in the testing. ³ I cut in the fantasy and under the motto “this thing can do anything” wrote a presentation about theoretical possibilities for various tasks. My boss got the administrative resource, moved things over, began to appoint volunteers. So two weeks have passed.

After people voluntarily-compulsorily became interested in the project, it was necessary to convince them of its usefulness. To do this, they came up with all of them to collect tasks that they could solve with the help of the system I advertised, send them to the developers so that they could prepare and show them. About a week went by (or maybe two), the results of which resulted in a list of about twenty tasks. I sent the list to the developers, they virtually nodded their heads - “yes, we can, we will do it”. The boss advised me to see what they got ⁴

Here I was waiting for the first bummer and the first bell. Why are there a bell - the whole alarm and ship siren. Despite assurances, something approximately similar to the solution was demonstrated on 2 of 20 tasks. For the rest, there was nothing but the words "you tell us how we will refine you." I was already ready to swear with the developers and wrap up the project, but then the higher forces intervened and said: “show it as it is, you need to implement it, estimate the cost of the improvements”. Ok, do not send the same new bosses for half the trial period. ^five

Send impressions for potential users. The results were from slight bewilderment, to complete disappointment, and one of the test participants still does not answer my calls and letters (no, he did not quit and was not on vacation). What struck the imagination was the cost of improvements, which was 4 (four) times higher than the cost of the software itself (also very big).

Results of the project

Shows have ended, negotiations have gone on and finding out why. Somewhere managed to win a few percent discount, but in general, developers stood to death, appreciating their product. In the process, we managed to figure out the architecture of the system (which we should have done, of course, much earlier). In fact, it turned out that to obtain information in a more or less readable form, the system must be manually programmed for each source, and it is impossible to use search engine output, for example, due to the architectural features of the system. Moreover, developers will have to program (and pay them again), because, despite the presence of the SDK, it is absolutely impossible to understand anything at once in the system, and performance with handwritten modifications is not guaranteed and is not included in technical support.

Having carefully recorded the results and conclusions, I wrote a conclusion on the project. After reading all this, the IT director executed a quad facepalm and the project was closed.

______
¹ It's not that it’s wrong to immediately give a big project, I myself am a supporter of the principle “you will get the rifle in battle”, which worked perfectly in support when training new employees. But in projects I would give “for overclocking” which is simpler and less epic.
² In fact, it was worth starting with delving into the system itself and its functioning, and not into second-hand presentation materials and opinions.
³ There is an error, perhaps, in the fact that at first “they came up with a cool idea,” then they began to look for who needs it.
⁴ And I was right, I always do that now. Helps avoid sudden disappointments.
⁵ "Saw further, instead of understanding the reasons" Here, for sure, there was a mistake of the authorities, which led to another month and a half of work being wasted.
_____

findings

The project initially went somehow crookedly - not from the needs of users, but from the ideas of the design department. Not from the architecture of the system, but from stories and ideas about it. Yes, and it was not started by me, which also left its mark. Total:

• Do not believe the presentation materials, see for yourself how everything works, on a live system.
• Do not let others interfere with your project. Customers / bosses may have requirements for results and deadlines, but how you get results is not their business.
• Do not delay the process - kick, accelerate everyone you can reach. To whom you will not reach - look for levers of influence and also kick. It is better to have a reserve in excess of the plan than to go strictly according to plan and find yourself in an unforeseen situation without reserves for time, etc.
• Do not be fascinated by the idea, see how it is implemented.
• Do not invent people for their needs - ask.

I would like to hear the opinion of a respected community - have I not forgotten anything, have I made all the conclusions? This is my first post on Habré, so please do not kick too much, if something goes wrong :)