August 21, 2012 at 10:45 pmIndustrial production of happiness
My article will be more of a set of stories from life and some conclusions from them. The main problem that worries me now: how to make customers and developers happy, and the profit and karma are whole. I don’t have a concrete final recipe; there are several negative examples and intended goals that I want to share.
I have been developing since 2003 (mainly web applications), before that for 4 years I taught at Omsk State University the basics of programming for the first year of the Faculty of Mathematics. At the moment, I have gone 3rd year in the role of co-owner of my own small outsourcing company. I will talk exclusively about my experience for two reasons: I managed to visit three different types of companies that I can compare, and I believe that retelling someone's experience does not give a complete picture.
Perhaps for someone I will look like this:
At the end of 2003, on the one hand, I realized that I really lacked the real development practice, since one teaching and learning tasks do not give a full picture of the life of the industry, on the other, the question of earnings rose upright. The problem of isolation of programming teachers from life is known to everyone firsthand. This is one of the reasons for the perception among programmers that the study at the university is completely useless and you just have to go and start working. I can talk for a long time on this topic, so now I’ll just say: I do not agree with this opinion, and leave the discussions for later. I decided that I had to go, gain experience in practice and then return to the university already possessing a certain body of knowledge in order to bridge the gap between academic education and the needs of the industry.
This was expressed in the fact that since 2009 I have been reading a special course at Omsk State University for 3-5 year students entitled “Modern software development practices”, where I teach them in practice many of the skills that are required in real work and which fresh graduates lack when they are looking for their first job. In particular, these are: teamwork, development processes, tools (version control systems, automated assemblies, task trackers, continuous integration). A lot of attention is paid to writing high-quality code, reasonable documentation and logging, unit testing, etc. As part of the course, students carry out a team project for 2-3 people, using various web frameworks in Java, Python and Ruby, which we also compare along the way.
So, in 2003, I quit OmSU and got a job in the software development department in a rather successful company engaged in the design of oil and gas pipelines, where I was engaged in the automation of internal work.
At that time in Omsk it was one of the largest taxpayers. In addition, there were 2 large departments for the development of software for internal automation. One of them even developed software for an external customer - Transneft. There I found out what the internal policy with a focus on personnel is and how it all collapses with the transfer of control to people who did not create a company, but simply invested in a ready-made enterprise, having received a controlling stake. Reading much later the book of Di Marco and Lister “The Human Factor”, I laughed through tears when they described a similar situation where completely demotivated people quit, and those who have not quit still sit and think: “Everyone has already left, I’m alone I’m still an idiot, I’ll go and quit too, and burn with a blue flame. ”
In 2009, against the background of the departure of a huge number of excellent design specialists and surveyors - the foundation of the company - I received an offer to work in a nascent outsourcing company, which at that time consisted of less than 10 people.
I was the 3rd developer accepted there. I was immediately a little alarmed that there were only 3 developers, but on the staff, apart from the general director, there was a lawyer, marketer, personnel officer, accountant and project manager. Unfortunately, the sad history of this office in the end turned out to be a lot associated with a similar distribution of posts throughout its existence.
The most anecdotal was hiring a resource manager, when the profitability was already on the verge of a foul, which pestered everyone every day with countless questions, what we are doing and could we not use the half hour that we suddenly form to help the guys on another project . I think programmers do not need to explain what this led to. We did not succeed in explaining to the management that these measures are meaningless.
Nevertheless, it was here that I got a very interesting experience in communicating with foreign customers and also thanks to my friend Mikhail Podgursky ( kmmbvnr habrayuzer) - which kindly allowed me to use the slogan of my profile as the topic of the report - significantly expanded the range of technologies that, if I don’t know deeply, I have a pretty good idea in order to assess the applicability of one or another approach to solving the tasks set by customers.
In 2010, our notorious company far beyond Omsk crashed and was declared bankrupt, the customers with whom we were working at that time were very discouraged by this state of affairs and asked the developers who worked with them to continue without an office. So in Omsk, several freelance associations were born, including my current small company, which began with this order, on which we worked until the end of 2011.
In parallel with the organization of my own company, I got a job in one of the largest outsourcing companies now not only in Russia but also in Europe.
Everything was here: large customers, quite high salaries by Omsk standards, a full social package. On that project where I worked, there was peace and quiet, no rush for you, no overtime. On the contrary, often we had to figure out for ourselves what to do with ourselves. The situation is best illustrated by the following picture:
The paradox is that there really are a fairly large number of very good programmers. One of them, which was our team leader, in my opinion is the best of those with whom I have ever worked. And they don’t leave, they just find something to do besides their main job. For example, they give a lot of valuable advice to beginners who constantly turn to them.
However, I got a rather boring project, which is described below, the sense of my work there I saw less and less, and combining company management and their own wage labor became increasingly difficult. Therefore, in January 2011, I finally decided to quit and finally take up only my own company.
There are not many of us in the company, we do not have - except for me and Ivan Nemytchenko ( nem habrayuzer) - no managers, an outsourced accountant, no personnel officers and resource managers. In this, of course, there are pros and cons, but for now we live like this. Ivan and I are still writing code, designing the architecture of web applications, conducting internships, managing projects as managers, communicating with customers. It looks something like this (there was no picture with a large number of tools, but a pity):
Sometimes even like this:
Besides the fact that I was able to get an idea of the various types of custom development, I took part in start-up parties, Ivan and I worked on several of our ideas, we tried to launch a couple of start-ups - so far not very successfully for obvious reasons - in addition to creating the actual code, all this is also to promote and attract users, for which we currently do not have resources.
My team and I regularly attend various IT conferences in Moscow, Novosibirsk, Yekaterinburg, and Samara. And recently, I began to be tormented by one question that I constantly want to ask the speaker who talks about general approaches to the development process, about some kind of application of a combination of technologies, etc. etc.: “Okay, this is all great, but what problem did you solve for the customer?”
The speaker with codefest-2012 Maxim Tkachuk finished off with his report “Hard rock design” codefest.ru/program/2012-03/hard-rock-design. It is a pity that his report was announced to the PM + HR section and not all the developers who were there came to listen to him, but mostly managers and designers. And he talked about the fact - from his bell tower, of course - that the designer should take part in the entire process of working on the project, starting from the initial collection of requirements, take a proactive position, deeply understand the purpose of the developed product and the audience of users (consumers). He spoke very emotionally, it was felt that the problem was suffered and constantly had to deal with designers who do not understand this. And I sat in the hall and mentally changed the word “designer” to “developer”, “tester”, etc.
Actually, the very problem that I finally formulated only recently sounds like this: the bulk of the team members do not want to delve into the problems of customers and users, and management and customers do not consider it necessary to inform the team about many aspects of the problem being solved, considering it optional.
Symptoms of the problem are:
● the customer believes that the team is not required to know about some problems with attracting users, financing, presentations, etc., the team’s job is to write code, and other people should have a headache about business issues;
● at the beginning of negotiations on the project, the customer is more interested in having formal certificates like CMMI than in getting to know real team members, often prefers to communicate only with the manager and analysts;
● the developers say: “I just want to write code, give me a clearly defined task and I will do everything. About the customer’s problems, let the analyst and manager have a headache ”(“ telepaths on vacation ”);
● the team acts on the principle: we do exactly what they asked, they will pay us, and then it does not concern us;
● managers consider creatures divorced from life as creatures that need to be entertained and motivated somehow, since their main job is mortal boredom and special measures are needed to prevent them from becoming acidic;
● the developers themselves consider the main work to be mortal boredom and, to preserve their motivation, they are engaged in third-party open-source projects and small startups aimed not so much at earning, but at getting vents from the routine;
● the development of the project is accompanied by a ton of documents, but most ordinary employees are not able to describe typical users of the product and have never seen them;
● communication between any representatives of various roles resembles a battlefield;
● a representative of any role can immediately name what exactly he is dissatisfied with the work of the manager and the representative of any other role in the team;
● First of all, each member of the team can formulate someone else’s responsibility and only then call his own;
● The first and main task of any team member is to cover one place with a frying pan by overstating and pushing responsibility for the breakdown on others.
The consequences for the team (in the long run):
● motivation is reduced to a critical point, no one seeks to do the task as best as possible;
● any decisions are made according to the principle “if only it did not fly in”;
● in especially severe cases, decision-making is accompanied by several stages of signing papers;
● no initiative to improve the code, architecture, internal processes is welcome; in most cases, the initiator receives the question “Do you need more?”
● at the first opportunity, the most promising team members change the project;
● the only motivation is money and career, for a sufficiently long period of time, the team may be gathered by the most mercantile market analysts or those who are not interested in anything other than a stable salary and the opportunity to leave home at 18:00.
Consequences for internal management:
● special measures are needed to monitor the implementation of tasks;
● for a long period of time, the most initiative leave the team, those who remain no longer take it out;
● Responsibility for failure to meet deadlines lies mainly with the manager; motivating the team to prevent failure is possible only with a carrot and stick.
Consequences for customer management:
● the customer repeatedly overpays for overstated periods and staff turnover;
● the quality of the product is excellent only on paper, in fact, the code and architecture can be terrible, therefore, the customer overpays for unsatisfactory quality;
● if users are a wide range of people who voluntarily choose a product, it is possible to reduce their number for the reasons described below.
Implications for end users:
● there is no direct contact with performers and the ability to quickly give feedback;
● Needs are not fully satisfied; most often, users have to be specially trained to use the product, since it is far from their standard usages;
● the procedure and deadlines for completing tasks to add new functionality does not meet the needs of users.
To illustrate the above, I’ll tell you about some projects that I had to work on as a developer or manager.
So, the company is engaged in the design of trunk pipelines. The software development department was given the task of writing a small program for the ecology department. Initial data:
A little more about the department:
A separate library of 2D graphics was written, in 3D plans (OpenGL and all that is already in the yard). Its own cunning structure of storing data in memory is written - a sort of combination of a linked list and a structure with direct access, i.e. array. For access, a very low-level approach is used, there is no abstraction at all, solid address arithmetic, not only in giblets, but also at the API level. A grid is written, which receives an address in memory at the input and takes all its data using address calculations regarding this beginning. A shift somewhere inside of 1 byte destroys everything. Most epic is its name: “myGrid”.
To a young fighter - i.e. to me - they propose to use all this as components of a future program on Builder, which will replace the current zoo of Excelsian calculations. Customers - aunts from 45 and above (bosses) and girls about 25 (ordinary performers) - think exclusively in the categories of calculations, which they perceive as unrelated parts and from their point of view, the development is incremental - the calculations are repeated one by one and take approximately same time.
For about a month, I honestly did everything on Builder, the data entered through the mega-grid fell into the mega-structure in memory, which when saved to the disk simply dropped as it was into the binary file and then rose when reading from the file into memory as it was. But I rebelled. She told the head of the department that the task frankly involves the use of a database - especially considering the required multi-user mode. Another month of fighting and I got permission. They were just about to create a corporate information system (CIS) in Java + Oracle, and I got the opportunity to make the system as part of this CIS.
The more I plunged into the task, the more I realized that the calculations were not only interconnected, but for the most part the data for them was either in various normative and reference books, or they came from employees of other departments. There was an understanding of what kind of system ecologists really needed and it looked a little like what they described. I stuck in their department, asked questions that went far beyond the framework of the calculations given to me, as a result, gradually I delved into the mechanics of the entire institute.
I did what they really needed, much more than what they asked, but it took a lot more time than was supposed at the beginning. Six months for the first version with the basic calculation for the rest and 2.5 years to complete. During this time, I was almost fired for the lack of a visible result in the first 1-2 months (I don’t remember exactly already) and relations with the head of the department and the then IT director, who was not from programmers, but from design engineers, were significantly spoiled.
Then I began to upholster the thresholds of my superiors, trying to start the process of automation and building a model of the entire process of research and design, because at that moment, as I thought, I was practically the only person who purposefully studied the work of all departments of the institute in terms of input and output data flows at the level of a digital project model. There was also a CIS department, but they were more interested in types of text documents, and drawings were considered as ordinary binary files. For me, the main one was the model, and all the drawings and text documents were just reports that can be built at any time, having a model.
As a result, this global system never appeared due to a bunch of bureaucratic and economic reasons, and I quit. By the way, piecewise automation of this process is available in other design institutes, and one of the IT companies makes money on a commercial product that covered at the time of my last knowledge about it (2010) 60 percent of what I imagined in 2006. There are several products covering survey work (surveying, geology, etc.) that use the model inside, and drawings in AutoCAD format receive as a report. But they, unfortunately, have no continuation in the design of the pipeline.
Let's get back to the task. It seems that everything was done correctly - users received a product that met their needs even more than they could count on. But. They received it much later than they wanted. What did it turn out for them? Big losses of time for routine and, as a result, overtime work for an extra year.
What mistakes were made:
1. Collection of requirements through surveys of superiors and the study of Excel files.
2. The choice of development technology, which was little studied by the developer at that time, delayed the appearance of the first version.
3. An attempt to make the first version of the system immediately mega-universal.
The global cause of all these errors was that I was too carried away with my goals, forgetting about the goals of the customer. I wanted to make a good and universal system, while studying new technologies for me. And the customer just wanted to reduce the time to perform calculations and leave home on time.
What the ideal spherical developer should have done in a vacuum:
1. Start by examining the business domain by completely immersing the department for some time with the goal of studying all the processes from the inside, right through to the basic jusky of the ordinary employee of the department yourself.
2. Within a week, a maximum of two, write several macros in Visual Basic, which would ensure the use of the results of some calculations as source data for others, as well as digitize the most frequently used directories in Excel, which would give an acceleration of work by about a third.
3. Having a partially happy customer nearby, calmly develop a real system, already understanding all the juskeys and the main risks, which would also accelerate the development process by no less than a third.
At first glance, the example does not fit into the problem and symptoms described above. At second glance, the way it is. Since there was a presence of a developer very motivated to study the problems of the customer and attempts to solve them in the best possible way (apart from the initial error with macros, more precisely, with their absence). The problem is that everyone else who was around was completely not motivated to improve the overall situation in the company. The question is whether I really need more than anyone else I heard regularly. And at one point, patience snapped.
What are the conclusions from this whole story?
1. The user must know in person. And not only the manager and business analysts, but the whole team.
2. The whole team should participate to the maximum in the process of creating functional and interface requirements.
The presence of these conditions will give the team the opportunity to be creative, and a personal acquaintance with users and their tasks will allow them to best solve these problems. When the user is abstract and impersonal, no one puts his soul into the product for him.
But what to do when there is no access to the real user?You can have a rubber user.A joke, of course. For this, special practices for developing user portraits were invented. The team creates a real portrait of a person with a name, age, profession, even habits, as well as fears that may arise when using the product, and what benefit this product can bring to them. There are gaming moments, jokes, internal memes. The practice shows up pretty well at the Scrumtrek AgileCamp training.
On the topic of meeting with users and studying their specific needs, I can name two more cases. Just recently, we were sitting in the customer’s office and had the opportunity to chat with live users of the future system. And the girl-designer of the interfaces repeated the phrase several times: “Oh, how cool it is all the same that you can talk with users like that! Usually you don’t know who it is and how exactly they will eventually use the product. ”
Actually, the fact was that while we were communicating with the customer’s management, they proposed to create a super-universal analytical system that would allow us to show diagrams and summary data for any conceivable cuts and would somewhat resemble a large Excel, in which users are now working with tables charts. It so happened that we flew to Moscow and got together to discuss the requirements that have already been finalized and to sign an agreement. There were 2 problems: on our part, the lack of a clear understanding of the timing, since some universal something is more difficult to evaluate, the requirements are more vague, and on the part of the team developing the user interface - the feeling that most users will not need such a universal interface and is incomprehensible.
From the very beginning, we were going to offer to invite end users and stand with them at the blackboard with stickers and markers, conduct story-mapping (again, I refer to AgileCamp from Scrumtrek). Although this did not work out, we nevertheless invited users and talked to each of them, trying to understand what his main juskeys and expectations of using the system are. The result of this was that the super-versatility was dismissed and received several clear juskeys that covered 80% of the most important functionality. All this will make it possible to release a working prototype much faster, which will already benefit the business.
A similar story happened recently with our other customer. He is a good programmer who, from some point on, became a technical director. Therefore, he set us, in fact, not business tasks, but proposed specific architectural solutions. He tried to get from us, again, a super-universal and super-modular system that does everything. We could not really get any concrete cases out of it and we were not presented with end users either.
Six months ago he was in Omsk and we spent half a day composing Lean canvas and doing Story-mapping. As a result, we chose a case for the first prototype and everything seemed to go almost perfectly the first few iterations. However, at some point, an unexpected demand suddenly arrived, about which there was not even a hint of story-mapping, to create some directories: organizations, geolocations, etc. The team did not ask why - and the customer did not consider it necessary to explain. And after another 2 weeks, it suddenly became clear that the customer was facing an urgent important event, for which he needed a product to prepare for. He wanted to put users in advance to fill the system with data in order to be in time, but since he had not warned about it in advance, the system was not ready for users to work precisely on those jusseys that they needed at the moment.
What are the conclusions from these two stories:
1. It is necessary not only to know your users in person, but also to get information from them about the most important options for using the system, which cover 80% of their needs and should be realized in the first place.
2. It is better to limit the influence of technical management on the part of the customer as much as possible; insist on communication with people from the business and end users for the best understanding of the goals of creating the product.
3. It is necessary to ask the customer questions regarding the timing of the scheduled demonstrations or other important events, since he may not think about it himself. It is important to understand that sometimes the date of the event, when the product will be used for display, must be preceded by a week or two for alpha testing by end users.
Immediately after the design institute, I worked in a stupidly bankrupt small subsequently outsourcing company, in which one of the first tasks with the manager and I joined forces together. The system consisted of two parts: recording a video stream from surveillance cameras with streaming in two modes - online and recording - and a web admin panel for configuring camera settings, storage systems for recorded video, and all kinds of event notifications.
The manager knew that we had one big technical risk - video recording and streaming. There were serious concerns that in a month the developer would not have time to study the formats of the main cameras and write something digestible to demonstrate to the customer the possibility of recording a video stream. Therefore, he hoped that I would quickly rivet the admin panel, which could be used to blur the eyes of the customer, he would be carried away by comments and wishes and for a while forget about the video, which would give the second developer time to maneuver.
However, all these considerations were only in the manager’s mind. The developers saw the deadline - 3 months - and were not particularly worried. We practically didn’t communicate with the customer personally; the manager was engaged in this. The information was already reached to us in the form of instructions, with which we argued and in some places did it in our own way, delaying the deadlines set by the manager. We would surely meet the total deadline (plus or minus, of course). But we did not have any working system after the promised month, because both I and the second developer pursued their goals, not very caring for the customer - for us he was just a skype and email address. Therefore, I chose to develop a new framework for me to kill two birds with one stone. The manager did not stop this matter, although he suspected that I would not have time to meet the deadline with the study.
As a result, the authority of the manager and the company as a whole in the eyes of the customer was greatly shaken, interruptions in communication began, and the first monetary tranche was postponed.
One could say that the problem is the lack of a proper development process. That would be a scrum and happiness would come. However, the point here is still not the process itself or its absence - we had iterations with the described scoping with any acceptance criteria - the fact is that we did not solve the customer problem together. I absolutely certainly didn’t have a headache about the profits lost by the customer due to the shift of the deadline.
Considering the previous experience with environmentalists, I would absolutely definitely get into and think in the direction in which I would not even like the manager, but the customer, since the manager was more interested in the issue of covering the loin with a frying pan than launching a prototype to test and possibly even commercial use with disabilities. But - he did not file properly, and I did not show enough curiosity. The new framework with its technical features at that time interested me much more. His choice, too, was unsuccessful in the end, the study took a prohibitively long time. For this task, you could choose one of the dynamic languages and a framework like Django or Rails.
What are the conclusions from this story?
1. The team should be aware of all the risks and problems of the customer’s business (why should he launch it and exactly at these times, what kind of functionality will suit him for the prototype).
2. The team should be aware of the motives of their own company (how important is the project for reputation, portfolio or financial well-being).
3. When discussing and choosing technical solutions, technical management should first of all be guided by business problems, and explain to developers that it is inhumane to practice new frameworks on customers. So that developers nevertheless do not lose interest in learning new things, you need to give some opportunities to apply new technologies, but on your internal projects or give time for open source development.
This will lead to the fact that the developers will no longer be able to frankly ignore both the customer and the manager, since they will feel to some extent in the same boat with both the one and the other, realizing how much the success of the project will affect them, since successful the project in the portfolio is a reason for pride, not to mention the possible improvement in the financial situation of both the company and the specific developer.
Two weeks before the bankruptcy of a small outsourcer, I went to work in a branch of a large outsourcing company.
I got there interesting. I came for an interview just out of curiosity, in order to check my skills against the needs of a highly respected company in the city. And I was completely fascinated by the interviewer. We talked very nicely with him about various technical issues, and I realized that he was very cool, you can learn a lot from him. He, as it turned out, also appreciated me high enough that the headhunters began to actively lure. The final decision was influenced by the fact that my interviewer would be the team lead of the development team I was to join.
I honestly warned the branch director and manager that I have my own small team, which I will deal with in parallel, received consent and began to join the team. The project team of 45 people, of which fewer than a third of developers, surprised me a little. In this case, there were significantly more testers, several distinguished analysts, each team has its own leader and over all - the architect, project manager and program manager.
The project turned out to be a long-liver. It existed for 30 years on Fortran, then in 2000-2001 it was rewritten, making it a web project in Java + Oracle. At the same time, the appearance of the interface was completely preserved. Not so much because users are used to it, but because not a single developer fully understood what the essence of the system was and what all these screens for data entry mean. During the existence of the project in the company, more than 100 developers have replaced it, how many testers and analysts I do not know. As a result, in the team that I got into, there was not a single person who would fully understand the system. Even the analysts, who cheerfully showered with obscure terms to me, could not answer most of the questions about the goals and needs of users.
All this led to the fact that the development was carried out by the method of applying patches. Documents on the system, created by analysts and testers, often did not correspond to the current state of the code, since not every developer had the patience to read them and execute everything that was written there. For some user stories, the customer and the development team had two different pictures of the same functionality.
It was on this project that I observed most of the symptoms voiced by me above. My desire to understand the business domain was puzzling. After all, it is much easier to perform a small task, without delving into the fact that supposedly it does not concern it. What bothered me was that the system, in terms of usability, was the worst example I had ever seen. The time to train the user to work with it was enormous. The user was forced to keep in mind a huge number of valid parameter values and their combinations, since the system did not give any hints and even the huge form validation often gave just the message “Error!”, Overloading the page with clearing all the entered data, after which the unfortunate user was forced to enter All over again.
At the same time, basically the people who worked on the project were technically very competent, versed in the huge number of subtleties of the used and related technologies. Nevertheless, in the eyes of many I saw longing. The company, which brought together almost the best developers of the city, very strangely disposed of these resources. There were projects where a small development team and literally 1-2 testers worked overtime in a constant mode, while we often wandered from corner to corner, not knowing what to do when the code was given for testing, and the next iteration had not yet begun. But program managers at their meetings did their best to keep their people away, not giving them to those who urgently needed it, because they understood that they might not be given back to them, even if necessary. So many developers sitting inside the company,
The result was the departure of several fairly proactive employees who eventually took up leadership positions in the dynamically developing companies of the city or left it. They were ready to implement their ideas within the previous company, but these initiatives were left without the attention of the leadership, because at a high level of management, the problems of end users and even internal problems of the development team are no longer visible.
For myself, I made the following conclusions, which in this case are highly controversial, since there are a huge number of people who feel completely comfortable in a large hierarchically built structure:
1. In such a structure, a mass of people who prefer not to take responsibility and value “stability” becomes critical. This leads to the fact that in those rare moments when it is required to quickly brainstorm a new project with checkers, no one is ready for this type of activity. Therefore, projects that come to such companies are as boring and long-playing as those that are already under development.
2. If projects of a different type nevertheless leak out, everything seems to be fun and interesting at first. Most often, the developers there are newly arrived employees or passionaries who have fled from other projects. However, the proximity of half-asleep teams from other projects that are constantly going to chat in the corridors or have tea time in the kitchen, or those who obviously go fishing during working hours, very quickly makes you wonder - why actually I have to work hard, when around a lot of people get paid almost for nothing which has a lot of free time. This reduces motivation pretty quickly. Further, only salary and promotion prospects begin to hold people. However, very many in the end still go to startups, small but fun teams, or freelance.
3. The percentage of happiness per capita of the programmer population in small teams that do not have several levels of the management hierarchy is much higher. Personally, I am impressed by such teams much more. Being among people with burning eyes is much nicer. Therefore, I would not recommend combining the mentioned types of teams and projects within one company.
4. The reaction rate to the wishes of the customer in small teams is higher, which increases the level of customer happiness. Not every customer is ready to take a chance and hire a small but proud outsourcer. However, there are those for our happiness.
Formula of
For me and my partner, it consists of the following components:
• Developing a product that is primarily intended to help users solve some very important problem, and making a profit is a side effect - just such a useful service cannot fail to become popular. Ideally, the product should be so interesting that they even want to do it for free in their free time. Therefore, the ability to work on it for money is a real happiness for the team. Ideally, the product is your own.
• A small, but very high level skill team, in which there are simply no extra people. Each enthusiast and evangelist, in addition to the main work, is actively engaged in self-development, has an educational blog, contributes to an interesting open source project, or makes his own.
• The team delves into the customer’s business or the problems of end users so that they can speak the same language with them and view the product from the point of view of business value, adapting all processes and technical solutions to the needs of the business / users.
• The customer is so adequate that he trusts the team in choosing technical and process solutions, allowing them to decide how to meet the needs of the business within the specified budget.
• A large number of routine operations such as deploy and running diverse tests are so automated that the team has enough time to work on really interesting and complex things that require the application of the brain.
• The team has time to test hypotheses ondogsprototypes and carry out debriefing at the end of each development phase, exchanging experiences of successful and unsuccessful decisions with other teams both within the company and beyond - for example, at conferences. If it is possible to conduct parallel development of several solutions with the possibility of comparative analysis and the choice of the most successful in the end - this is generally a fairy tale.
Nice collection in the style of "Thank you, cap!" Actually, for us this is still some kind of ideal, to which we are striving with all our might. I by no means pretend here to the ultimate truth. There are many successful companies in terms of profit that do not have any of the items mentioned. Or bits from one or two of them. But I want to emphasize that I'm not talking about maximizing profits, but about completely different things. This is a largely philosophical moment. Money alone is not really needed. A bag of money on a desert island is useless. A person needs a feeling of happiness, which is by no means given by money as such.
Actually, the purpose of my speech at conferences and this article is to discuss with my colleagues the aspect of the interaction between the business and the development team, the relevance of the problem of misunderstanding and mistrust in this interaction. Therefore, first of all, I am ready to ask the readers a question - is what I was talking about relevant for you? Is there a desire to discuss these topics in more detail?
The question is not idle. We are going to hold a conference based on slightly different principles than those conferences that we attended the last couple of years. In particular: dump.it in Yekaterinburg, codefest in Novosibirsk, devconf in Moscow, agiledays and agilecamp. The conference is scheduled for September 29th.
The idea is to break up the reports into sections not according to team specializations: developers, testers, designers, managers, and not according to the technologies used. I would like to unite people in sections according to the types of business tasks, having examined specific cases in the complex on each section. People working in the enterprise, at banks and other large companies are not interested in listening to those who have limited budget startups who need to quickly make a prototype to get a round of investment or to test the hypothesis and measure KPI. I want people to share their approaches to organizing development processes and choosing technical solutions based on the needs of the problem being solved.
Thanks to everyone who took the time to read. I would be glad to any tricky questions and advice on the topic.
I have been developing since 2003 (mainly web applications), before that for 4 years I taught at Omsk State University the basics of programming for the first year of the Faculty of Mathematics. At the moment, I have gone 3rd year in the role of co-owner of my own small outsourcing company. I will talk exclusively about my experience for two reasons: I managed to visit three different types of companies that I can compare, and I believe that retelling someone's experience does not give a complete picture.
Perhaps for someone I will look like this:
About work experience
At the end of 2003, on the one hand, I realized that I really lacked the real development practice, since one teaching and learning tasks do not give a full picture of the life of the industry, on the other, the question of earnings rose upright. The problem of isolation of programming teachers from life is known to everyone firsthand. This is one of the reasons for the perception among programmers that the study at the university is completely useless and you just have to go and start working. I can talk for a long time on this topic, so now I’ll just say: I do not agree with this opinion, and leave the discussions for later. I decided that I had to go, gain experience in practice and then return to the university already possessing a certain body of knowledge in order to bridge the gap between academic education and the needs of the industry.
This was expressed in the fact that since 2009 I have been reading a special course at Omsk State University for 3-5 year students entitled “Modern software development practices”, where I teach them in practice many of the skills that are required in real work and which fresh graduates lack when they are looking for their first job. In particular, these are: teamwork, development processes, tools (version control systems, automated assemblies, task trackers, continuous integration). A lot of attention is paid to writing high-quality code, reasonable documentation and logging, unit testing, etc. As part of the course, students carry out a team project for 2-3 people, using various web frameworks in Java, Python and Ruby, which we also compare along the way.
So, in 2003, I quit OmSU and got a job in the software development department in a rather successful company engaged in the design of oil and gas pipelines, where I was engaged in the automation of internal work.
At that time in Omsk it was one of the largest taxpayers. In addition, there were 2 large departments for the development of software for internal automation. One of them even developed software for an external customer - Transneft. There I found out what the internal policy with a focus on personnel is and how it all collapses with the transfer of control to people who did not create a company, but simply invested in a ready-made enterprise, having received a controlling stake. Reading much later the book of Di Marco and Lister “The Human Factor”, I laughed through tears when they described a similar situation where completely demotivated people quit, and those who have not quit still sit and think: “Everyone has already left, I’m alone I’m still an idiot, I’ll go and quit too, and burn with a blue flame. ”
In 2009, against the background of the departure of a huge number of excellent design specialists and surveyors - the foundation of the company - I received an offer to work in a nascent outsourcing company, which at that time consisted of less than 10 people.
I was the 3rd developer accepted there. I was immediately a little alarmed that there were only 3 developers, but on the staff, apart from the general director, there was a lawyer, marketer, personnel officer, accountant and project manager. Unfortunately, the sad history of this office in the end turned out to be a lot associated with a similar distribution of posts throughout its existence.
The most anecdotal was hiring a resource manager, when the profitability was already on the verge of a foul, which pestered everyone every day with countless questions, what we are doing and could we not use the half hour that we suddenly form to help the guys on another project . I think programmers do not need to explain what this led to. We did not succeed in explaining to the management that these measures are meaningless.
Nevertheless, it was here that I got a very interesting experience in communicating with foreign customers and also thanks to my friend Mikhail Podgursky ( kmmbvnr habrayuzer) - which kindly allowed me to use the slogan of my profile as the topic of the report - significantly expanded the range of technologies that, if I don’t know deeply, I have a pretty good idea in order to assess the applicability of one or another approach to solving the tasks set by customers.
In 2010, our notorious company far beyond Omsk crashed and was declared bankrupt, the customers with whom we were working at that time were very discouraged by this state of affairs and asked the developers who worked with them to continue without an office. So in Omsk, several freelance associations were born, including my current small company, which began with this order, on which we worked until the end of 2011.
In parallel with the organization of my own company, I got a job in one of the largest outsourcing companies now not only in Russia but also in Europe.
Everything was here: large customers, quite high salaries by Omsk standards, a full social package. On that project where I worked, there was peace and quiet, no rush for you, no overtime. On the contrary, often we had to figure out for ourselves what to do with ourselves. The situation is best illustrated by the following picture:
The paradox is that there really are a fairly large number of very good programmers. One of them, which was our team leader, in my opinion is the best of those with whom I have ever worked. And they don’t leave, they just find something to do besides their main job. For example, they give a lot of valuable advice to beginners who constantly turn to them.
However, I got a rather boring project, which is described below, the sense of my work there I saw less and less, and combining company management and their own wage labor became increasingly difficult. Therefore, in January 2011, I finally decided to quit and finally take up only my own company.
There are not many of us in the company, we do not have - except for me and Ivan Nemytchenko ( nem habrayuzer) - no managers, an outsourced accountant, no personnel officers and resource managers. In this, of course, there are pros and cons, but for now we live like this. Ivan and I are still writing code, designing the architecture of web applications, conducting internships, managing projects as managers, communicating with customers. It looks something like this (there was no picture with a large number of tools, but a pity):
Sometimes even like this:
Besides the fact that I was able to get an idea of the various types of custom development, I took part in start-up parties, Ivan and I worked on several of our ideas, we tried to launch a couple of start-ups - so far not very successfully for obvious reasons - in addition to creating the actual code, all this is also to promote and attract users, for which we currently do not have resources.
About problem
My team and I regularly attend various IT conferences in Moscow, Novosibirsk, Yekaterinburg, and Samara. And recently, I began to be tormented by one question that I constantly want to ask the speaker who talks about general approaches to the development process, about some kind of application of a combination of technologies, etc. etc.: “Okay, this is all great, but what problem did you solve for the customer?”
The speaker with codefest-2012 Maxim Tkachuk finished off with his report “Hard rock design” codefest.ru/program/2012-03/hard-rock-design. It is a pity that his report was announced to the PM + HR section and not all the developers who were there came to listen to him, but mostly managers and designers. And he talked about the fact - from his bell tower, of course - that the designer should take part in the entire process of working on the project, starting from the initial collection of requirements, take a proactive position, deeply understand the purpose of the developed product and the audience of users (consumers). He spoke very emotionally, it was felt that the problem was suffered and constantly had to deal with designers who do not understand this. And I sat in the hall and mentally changed the word “designer” to “developer”, “tester”, etc.
Actually, the very problem that I finally formulated only recently sounds like this: the bulk of the team members do not want to delve into the problems of customers and users, and management and customers do not consider it necessary to inform the team about many aspects of the problem being solved, considering it optional.
Symptoms of the problem are:
● the customer believes that the team is not required to know about some problems with attracting users, financing, presentations, etc., the team’s job is to write code, and other people should have a headache about business issues;
● at the beginning of negotiations on the project, the customer is more interested in having formal certificates like CMMI than in getting to know real team members, often prefers to communicate only with the manager and analysts;
● the developers say: “I just want to write code, give me a clearly defined task and I will do everything. About the customer’s problems, let the analyst and manager have a headache ”(“ telepaths on vacation ”);
● the team acts on the principle: we do exactly what they asked, they will pay us, and then it does not concern us;
● managers consider creatures divorced from life as creatures that need to be entertained and motivated somehow, since their main job is mortal boredom and special measures are needed to prevent them from becoming acidic;
● the developers themselves consider the main work to be mortal boredom and, to preserve their motivation, they are engaged in third-party open-source projects and small startups aimed not so much at earning, but at getting vents from the routine;
● the development of the project is accompanied by a ton of documents, but most ordinary employees are not able to describe typical users of the product and have never seen them;
● communication between any representatives of various roles resembles a battlefield;
● a representative of any role can immediately name what exactly he is dissatisfied with the work of the manager and the representative of any other role in the team;
● First of all, each member of the team can formulate someone else’s responsibility and only then call his own;
● The first and main task of any team member is to cover one place with a frying pan by overstating and pushing responsibility for the breakdown on others.
The consequences for the team (in the long run):
● motivation is reduced to a critical point, no one seeks to do the task as best as possible;
● any decisions are made according to the principle “if only it did not fly in”;
● in especially severe cases, decision-making is accompanied by several stages of signing papers;
● no initiative to improve the code, architecture, internal processes is welcome; in most cases, the initiator receives the question “Do you need more?”
● at the first opportunity, the most promising team members change the project;
● the only motivation is money and career, for a sufficiently long period of time, the team may be gathered by the most mercantile market analysts or those who are not interested in anything other than a stable salary and the opportunity to leave home at 18:00.
Consequences for internal management:
● special measures are needed to monitor the implementation of tasks;
● for a long period of time, the most initiative leave the team, those who remain no longer take it out;
● Responsibility for failure to meet deadlines lies mainly with the manager; motivating the team to prevent failure is possible only with a carrot and stick.
Consequences for customer management:
● the customer repeatedly overpays for overstated periods and staff turnover;
● the quality of the product is excellent only on paper, in fact, the code and architecture can be terrible, therefore, the customer overpays for unsatisfactory quality;
● if users are a wide range of people who voluntarily choose a product, it is possible to reduce their number for the reasons described below.
Implications for end users:
● there is no direct contact with performers and the ability to quickly give feedback;
● Needs are not fully satisfied; most often, users have to be specially trained to use the product, since it is far from their standard usages;
● the procedure and deadlines for completing tasks to add new functionality does not meet the needs of users.
Tales from life
To illustrate the above, I’ll tell you about some projects that I had to work on as a developer or manager.
So, the company is engaged in the design of trunk pipelines. The software development department was given the task of writing a small program for the ecology department. Initial data:
- o a department where everyone writes desktop applications for the automation of design and survey work on Borland C ++ Builder;
- o a newcomer who has just settled down and is able to write not very complex desktop applications;
- o Department of Ecology, which performs calculations of pollutant emissions during construction work using a set of Excel tables.
A little more about the department:
A separate library of 2D graphics was written, in 3D plans (OpenGL and all that is already in the yard). Its own cunning structure of storing data in memory is written - a sort of combination of a linked list and a structure with direct access, i.e. array. For access, a very low-level approach is used, there is no abstraction at all, solid address arithmetic, not only in giblets, but also at the API level. A grid is written, which receives an address in memory at the input and takes all its data using address calculations regarding this beginning. A shift somewhere inside of 1 byte destroys everything. Most epic is its name: “myGrid”.
To a young fighter - i.e. to me - they propose to use all this as components of a future program on Builder, which will replace the current zoo of Excelsian calculations. Customers - aunts from 45 and above (bosses) and girls about 25 (ordinary performers) - think exclusively in the categories of calculations, which they perceive as unrelated parts and from their point of view, the development is incremental - the calculations are repeated one by one and take approximately same time.
For about a month, I honestly did everything on Builder, the data entered through the mega-grid fell into the mega-structure in memory, which when saved to the disk simply dropped as it was into the binary file and then rose when reading from the file into memory as it was. But I rebelled. She told the head of the department that the task frankly involves the use of a database - especially considering the required multi-user mode. Another month of fighting and I got permission. They were just about to create a corporate information system (CIS) in Java + Oracle, and I got the opportunity to make the system as part of this CIS.
The more I plunged into the task, the more I realized that the calculations were not only interconnected, but for the most part the data for them was either in various normative and reference books, or they came from employees of other departments. There was an understanding of what kind of system ecologists really needed and it looked a little like what they described. I stuck in their department, asked questions that went far beyond the framework of the calculations given to me, as a result, gradually I delved into the mechanics of the entire institute.
I did what they really needed, much more than what they asked, but it took a lot more time than was supposed at the beginning. Six months for the first version with the basic calculation for the rest and 2.5 years to complete. During this time, I was almost fired for the lack of a visible result in the first 1-2 months (I don’t remember exactly already) and relations with the head of the department and the then IT director, who was not from programmers, but from design engineers, were significantly spoiled.
Then I began to upholster the thresholds of my superiors, trying to start the process of automation and building a model of the entire process of research and design, because at that moment, as I thought, I was practically the only person who purposefully studied the work of all departments of the institute in terms of input and output data flows at the level of a digital project model. There was also a CIS department, but they were more interested in types of text documents, and drawings were considered as ordinary binary files. For me, the main one was the model, and all the drawings and text documents were just reports that can be built at any time, having a model.
As a result, this global system never appeared due to a bunch of bureaucratic and economic reasons, and I quit. By the way, piecewise automation of this process is available in other design institutes, and one of the IT companies makes money on a commercial product that covered at the time of my last knowledge about it (2010) 60 percent of what I imagined in 2006. There are several products covering survey work (surveying, geology, etc.) that use the model inside, and drawings in AutoCAD format receive as a report. But they, unfortunately, have no continuation in the design of the pipeline.
Let's get back to the task. It seems that everything was done correctly - users received a product that met their needs even more than they could count on. But. They received it much later than they wanted. What did it turn out for them? Big losses of time for routine and, as a result, overtime work for an extra year.
What mistakes were made:
1. Collection of requirements through surveys of superiors and the study of Excel files.
2. The choice of development technology, which was little studied by the developer at that time, delayed the appearance of the first version.
3. An attempt to make the first version of the system immediately mega-universal.
The global cause of all these errors was that I was too carried away with my goals, forgetting about the goals of the customer. I wanted to make a good and universal system, while studying new technologies for me. And the customer just wanted to reduce the time to perform calculations and leave home on time.
What the ideal spherical developer should have done in a vacuum:
1. Start by examining the business domain by completely immersing the department for some time with the goal of studying all the processes from the inside, right through to the basic jusky of the ordinary employee of the department yourself.
2. Within a week, a maximum of two, write several macros in Visual Basic, which would ensure the use of the results of some calculations as source data for others, as well as digitize the most frequently used directories in Excel, which would give an acceleration of work by about a third.
3. Having a partially happy customer nearby, calmly develop a real system, already understanding all the juskeys and the main risks, which would also accelerate the development process by no less than a third.
At first glance, the example does not fit into the problem and symptoms described above. At second glance, the way it is. Since there was a presence of a developer very motivated to study the problems of the customer and attempts to solve them in the best possible way (apart from the initial error with macros, more precisely, with their absence). The problem is that everyone else who was around was completely not motivated to improve the overall situation in the company. The question is whether I really need more than anyone else I heard regularly. And at one point, patience snapped.
What are the conclusions from this whole story?
1. The user must know in person. And not only the manager and business analysts, but the whole team.
2. The whole team should participate to the maximum in the process of creating functional and interface requirements.
The presence of these conditions will give the team the opportunity to be creative, and a personal acquaintance with users and their tasks will allow them to best solve these problems. When the user is abstract and impersonal, no one puts his soul into the product for him.
But what to do when there is no access to the real user?
On the topic of meeting with users and studying their specific needs, I can name two more cases. Just recently, we were sitting in the customer’s office and had the opportunity to chat with live users of the future system. And the girl-designer of the interfaces repeated the phrase several times: “Oh, how cool it is all the same that you can talk with users like that! Usually you don’t know who it is and how exactly they will eventually use the product. ”
Actually, the fact was that while we were communicating with the customer’s management, they proposed to create a super-universal analytical system that would allow us to show diagrams and summary data for any conceivable cuts and would somewhat resemble a large Excel, in which users are now working with tables charts. It so happened that we flew to Moscow and got together to discuss the requirements that have already been finalized and to sign an agreement. There were 2 problems: on our part, the lack of a clear understanding of the timing, since some universal something is more difficult to evaluate, the requirements are more vague, and on the part of the team developing the user interface - the feeling that most users will not need such a universal interface and is incomprehensible.
From the very beginning, we were going to offer to invite end users and stand with them at the blackboard with stickers and markers, conduct story-mapping (again, I refer to AgileCamp from Scrumtrek). Although this did not work out, we nevertheless invited users and talked to each of them, trying to understand what his main juskeys and expectations of using the system are. The result of this was that the super-versatility was dismissed and received several clear juskeys that covered 80% of the most important functionality. All this will make it possible to release a working prototype much faster, which will already benefit the business.
A similar story happened recently with our other customer. He is a good programmer who, from some point on, became a technical director. Therefore, he set us, in fact, not business tasks, but proposed specific architectural solutions. He tried to get from us, again, a super-universal and super-modular system that does everything. We could not really get any concrete cases out of it and we were not presented with end users either.
Six months ago he was in Omsk and we spent half a day composing Lean canvas and doing Story-mapping. As a result, we chose a case for the first prototype and everything seemed to go almost perfectly the first few iterations. However, at some point, an unexpected demand suddenly arrived, about which there was not even a hint of story-mapping, to create some directories: organizations, geolocations, etc. The team did not ask why - and the customer did not consider it necessary to explain. And after another 2 weeks, it suddenly became clear that the customer was facing an urgent important event, for which he needed a product to prepare for. He wanted to put users in advance to fill the system with data in order to be in time, but since he had not warned about it in advance, the system was not ready for users to work precisely on those jusseys that they needed at the moment.
What are the conclusions from these two stories:
1. It is necessary not only to know your users in person, but also to get information from them about the most important options for using the system, which cover 80% of their needs and should be realized in the first place.
2. It is better to limit the influence of technical management on the part of the customer as much as possible; insist on communication with people from the business and end users for the best understanding of the goals of creating the product.
3. It is necessary to ask the customer questions regarding the timing of the scheduled demonstrations or other important events, since he may not think about it himself. It is important to understand that sometimes the date of the event, when the product will be used for display, must be preceded by a week or two for alpha testing by end users.
Immediately after the design institute, I worked in a stupidly bankrupt small subsequently outsourcing company, in which one of the first tasks with the manager and I joined forces together. The system consisted of two parts: recording a video stream from surveillance cameras with streaming in two modes - online and recording - and a web admin panel for configuring camera settings, storage systems for recorded video, and all kinds of event notifications.
The manager knew that we had one big technical risk - video recording and streaming. There were serious concerns that in a month the developer would not have time to study the formats of the main cameras and write something digestible to demonstrate to the customer the possibility of recording a video stream. Therefore, he hoped that I would quickly rivet the admin panel, which could be used to blur the eyes of the customer, he would be carried away by comments and wishes and for a while forget about the video, which would give the second developer time to maneuver.
However, all these considerations were only in the manager’s mind. The developers saw the deadline - 3 months - and were not particularly worried. We practically didn’t communicate with the customer personally; the manager was engaged in this. The information was already reached to us in the form of instructions, with which we argued and in some places did it in our own way, delaying the deadlines set by the manager. We would surely meet the total deadline (plus or minus, of course). But we did not have any working system after the promised month, because both I and the second developer pursued their goals, not very caring for the customer - for us he was just a skype and email address. Therefore, I chose to develop a new framework for me to kill two birds with one stone. The manager did not stop this matter, although he suspected that I would not have time to meet the deadline with the study.
As a result, the authority of the manager and the company as a whole in the eyes of the customer was greatly shaken, interruptions in communication began, and the first monetary tranche was postponed.
One could say that the problem is the lack of a proper development process. That would be a scrum and happiness would come. However, the point here is still not the process itself or its absence - we had iterations with the described scoping with any acceptance criteria - the fact is that we did not solve the customer problem together. I absolutely certainly didn’t have a headache about the profits lost by the customer due to the shift of the deadline.
Considering the previous experience with environmentalists, I would absolutely definitely get into and think in the direction in which I would not even like the manager, but the customer, since the manager was more interested in the issue of covering the loin with a frying pan than launching a prototype to test and possibly even commercial use with disabilities. But - he did not file properly, and I did not show enough curiosity. The new framework with its technical features at that time interested me much more. His choice, too, was unsuccessful in the end, the study took a prohibitively long time. For this task, you could choose one of the dynamic languages and a framework like Django or Rails.
What are the conclusions from this story?
1. The team should be aware of all the risks and problems of the customer’s business (why should he launch it and exactly at these times, what kind of functionality will suit him for the prototype).
2. The team should be aware of the motives of their own company (how important is the project for reputation, portfolio or financial well-being).
3. When discussing and choosing technical solutions, technical management should first of all be guided by business problems, and explain to developers that it is inhumane to practice new frameworks on customers. So that developers nevertheless do not lose interest in learning new things, you need to give some opportunities to apply new technologies, but on your internal projects or give time for open source development.
This will lead to the fact that the developers will no longer be able to frankly ignore both the customer and the manager, since they will feel to some extent in the same boat with both the one and the other, realizing how much the success of the project will affect them, since successful the project in the portfolio is a reason for pride, not to mention the possible improvement in the financial situation of both the company and the specific developer.
Two weeks before the bankruptcy of a small outsourcer, I went to work in a branch of a large outsourcing company.
I got there interesting. I came for an interview just out of curiosity, in order to check my skills against the needs of a highly respected company in the city. And I was completely fascinated by the interviewer. We talked very nicely with him about various technical issues, and I realized that he was very cool, you can learn a lot from him. He, as it turned out, also appreciated me high enough that the headhunters began to actively lure. The final decision was influenced by the fact that my interviewer would be the team lead of the development team I was to join.
I honestly warned the branch director and manager that I have my own small team, which I will deal with in parallel, received consent and began to join the team. The project team of 45 people, of which fewer than a third of developers, surprised me a little. In this case, there were significantly more testers, several distinguished analysts, each team has its own leader and over all - the architect, project manager and program manager.
The project turned out to be a long-liver. It existed for 30 years on Fortran, then in 2000-2001 it was rewritten, making it a web project in Java + Oracle. At the same time, the appearance of the interface was completely preserved. Not so much because users are used to it, but because not a single developer fully understood what the essence of the system was and what all these screens for data entry mean. During the existence of the project in the company, more than 100 developers have replaced it, how many testers and analysts I do not know. As a result, in the team that I got into, there was not a single person who would fully understand the system. Even the analysts, who cheerfully showered with obscure terms to me, could not answer most of the questions about the goals and needs of users.
All this led to the fact that the development was carried out by the method of applying patches. Documents on the system, created by analysts and testers, often did not correspond to the current state of the code, since not every developer had the patience to read them and execute everything that was written there. For some user stories, the customer and the development team had two different pictures of the same functionality.
It was on this project that I observed most of the symptoms voiced by me above. My desire to understand the business domain was puzzling. After all, it is much easier to perform a small task, without delving into the fact that supposedly it does not concern it. What bothered me was that the system, in terms of usability, was the worst example I had ever seen. The time to train the user to work with it was enormous. The user was forced to keep in mind a huge number of valid parameter values and their combinations, since the system did not give any hints and even the huge form validation often gave just the message “Error!”, Overloading the page with clearing all the entered data, after which the unfortunate user was forced to enter All over again.
At the same time, basically the people who worked on the project were technically very competent, versed in the huge number of subtleties of the used and related technologies. Nevertheless, in the eyes of many I saw longing. The company, which brought together almost the best developers of the city, very strangely disposed of these resources. There were projects where a small development team and literally 1-2 testers worked overtime in a constant mode, while we often wandered from corner to corner, not knowing what to do when the code was given for testing, and the next iteration had not yet begun. But program managers at their meetings did their best to keep their people away, not giving them to those who urgently needed it, because they understood that they might not be given back to them, even if necessary. So many developers sitting inside the company,
The result was the departure of several fairly proactive employees who eventually took up leadership positions in the dynamically developing companies of the city or left it. They were ready to implement their ideas within the previous company, but these initiatives were left without the attention of the leadership, because at a high level of management, the problems of end users and even internal problems of the development team are no longer visible.
For myself, I made the following conclusions, which in this case are highly controversial, since there are a huge number of people who feel completely comfortable in a large hierarchically built structure:
1. In such a structure, a mass of people who prefer not to take responsibility and value “stability” becomes critical. This leads to the fact that in those rare moments when it is required to quickly brainstorm a new project with checkers, no one is ready for this type of activity. Therefore, projects that come to such companies are as boring and long-playing as those that are already under development.
2. If projects of a different type nevertheless leak out, everything seems to be fun and interesting at first. Most often, the developers there are newly arrived employees or passionaries who have fled from other projects. However, the proximity of half-asleep teams from other projects that are constantly going to chat in the corridors or have tea time in the kitchen, or those who obviously go fishing during working hours, very quickly makes you wonder - why actually I have to work hard, when around a lot of people get paid almost for nothing which has a lot of free time. This reduces motivation pretty quickly. Further, only salary and promotion prospects begin to hold people. However, very many in the end still go to startups, small but fun teams, or freelance.
3. The percentage of happiness per capita of the programmer population in small teams that do not have several levels of the management hierarchy is much higher. Personally, I am impressed by such teams much more. Being among people with burning eyes is much nicer. Therefore, I would not recommend combining the mentioned types of teams and projects within one company.
4. The reaction rate to the wishes of the customer in small teams is higher, which increases the level of customer happiness. Not every customer is ready to take a chance and hire a small but proud outsourcer. However, there are those for our happiness.
Formula of love of happiness
For me and my partner, it consists of the following components:
• Developing a product that is primarily intended to help users solve some very important problem, and making a profit is a side effect - just such a useful service cannot fail to become popular. Ideally, the product should be so interesting that they even want to do it for free in their free time. Therefore, the ability to work on it for money is a real happiness for the team. Ideally, the product is your own.
• A small, but very high level skill team, in which there are simply no extra people. Each enthusiast and evangelist, in addition to the main work, is actively engaged in self-development, has an educational blog, contributes to an interesting open source project, or makes his own.
• The team delves into the customer’s business or the problems of end users so that they can speak the same language with them and view the product from the point of view of business value, adapting all processes and technical solutions to the needs of the business / users.
• The customer is so adequate that he trusts the team in choosing technical and process solutions, allowing them to decide how to meet the needs of the business within the specified budget.
• A large number of routine operations such as deploy and running diverse tests are so automated that the team has enough time to work on really interesting and complex things that require the application of the brain.
• The team has time to test hypotheses on
Nice collection in the style of "Thank you, cap!" Actually, for us this is still some kind of ideal, to which we are striving with all our might. I by no means pretend here to the ultimate truth. There are many successful companies in terms of profit that do not have any of the items mentioned. Or bits from one or two of them. But I want to emphasize that I'm not talking about maximizing profits, but about completely different things. This is a largely philosophical moment. Money alone is not really needed. A bag of money on a desert island is useless. A person needs a feeling of happiness, which is by no means given by money as such.
Actually, the purpose of my speech at conferences and this article is to discuss with my colleagues the aspect of the interaction between the business and the development team, the relevance of the problem of misunderstanding and mistrust in this interaction. Therefore, first of all, I am ready to ask the readers a question - is what I was talking about relevant for you? Is there a desire to discuss these topics in more detail?
The question is not idle. We are going to hold a conference based on slightly different principles than those conferences that we attended the last couple of years. In particular: dump.it in Yekaterinburg, codefest in Novosibirsk, devconf in Moscow, agiledays and agilecamp. The conference is scheduled for September 29th.
The idea is to break up the reports into sections not according to team specializations: developers, testers, designers, managers, and not according to the technologies used. I would like to unite people in sections according to the types of business tasks, having examined specific cases in the complex on each section. People working in the enterprise, at banks and other large companies are not interested in listening to those who have limited budget startups who need to quickly make a prototype to get a round of investment or to test the hypothesis and measure KPI. I want people to share their approaches to organizing development processes and choosing technical solutions based on the needs of the problem being solved.
Thanks to everyone who took the time to read. I would be glad to any tricky questions and advice on the topic.