Geekly Articles each Day
📜 ⬆️ ⬇️

freelance - you're doing it wrong!

Good day, dear habrozhiteli, my name is Yura, and today I will tell you about the problems of high-tech offspring of remote work - freelancing, namely the development of mobile, desktop and web applications, layout and design. I have been working in this field quite recently, literally since 2008, and I have gained quite a lot of good and bad experience. The purpose of this publication is to show the difference between ordinary employees and freelancers, as well as to show the main organizational problems that arise when developing and designing software. I hope that this post will help clarify some production issues that might not be completely obvious to the developers and their management.

The judgments in this article are subjective - a solid concentrated “gag”.
They are based on my personal experience and the experience of people with whom I communicate.

Next mnogabukf


I apologize in advance for the confusion and oversimplified nature of the story in the article.
I understand perfectly that there are a lot of people for whom false-scientific formalities and officialism are too important, so you can simply not read.

The main causes of conflict and organizational problems are


  1. Compensatory processes of psychological problems


    • I want to be the most important and / or the most intelligent ...

      The position of an adventurer player requires quick satisfaction of their desires and needs.
      ')

    • I want to obey ...

      The position of the martyr's victim requires suffering, not any real gain.

    ... and not to develop high-quality, competitive and reliable products


    Of course, when both groups of people find each other - they work for some time, and even are able to produce products. That is why sane startups about which it was possible to tell grandchildren were not released on the territory of the CIS, and most people migrate - it is often customary to solve problems there intensively, rather than ignore them, or waste staff, and the very concept of a problem is by definition completely different. However, here it is customary for us to call every young small business in runet now, so comrades have lived, comrades ... In principle, there are exceptions, but you can count on your fingers: Yandex, VKontakte, Odnoklassniki and Mail.ru something death convulsions twitched, but something to do the beginning of the last 5 years. These are all offices for which an intensive solution of most problems is characteristic, and it is difficult to compensate there, because of this, quite stupid situations also arise.

    Unfortunately, we live in a sick post-Soviet society with rather primitive book problems which are also made to make a lot of money. These problems are handed down from generation to generation, and this is strongly encouraged by the environment and is often taken as the norm.

      <rage>
    As an example, I can cite group "help" in the framework of the average "training" or psychocult, as it is commonly called in the States and Europe. Instead of solving the problems of a specific group of individuals, they are told that they do not have these problems, they cease to be compensated, and as a result, they work with double enthusiasm, they don’t talk about the real exhaust in the early stages. When monkeys under cocaine eyes narrow a little - they ask for more. In general, this dependence on primitive illusions, which only slow down, but do not stop the compensatory processes. The volcano will still rage, and even how angry ...

    There are exceptions to this rule, but usually no one conducts an audit of psychological training and the work of a psychologist within the office. Trainings, most often, are the requirements of some foreign bosses.
      </ rage>

    1.1 Communication problems


    Most often communication problems arise due to
    • Inadequate self-esteem and inadequate perceptions about people
    • Separation on "friend or foe"
    • Discrepancies of roles in the team
    • Lack of resources - time or money

    The first three points - most often, compensatory processes that lead to communication barriers with subsequent conflicts. Lack of resources most often leads to isolating and ignoring existing problems without any desire of management to participate in the product development process.

    For a freelancer, it is especially important to deal with communication problems already at the stage of developing requirements, or immediately upon first meeting. The peculiarities of the market are such that more than half of the teams are built absolutely spontaneously and inadequate behavior on the part of the management is absolutely common, and the minimal discrepancy between the levels of trust or expectations leads to rather large conflicts. In any case, the issue of identification and resolution of communication problems is worthy of a separate article.

    In the case of remote work, the most important factor is equality and distribution of roles. For management, it is important to be equally attentive to both remote and local employees — to make resources, the results of their work and plans public and available for general discussion, to try to transfer local employees to the remote location and back to prevent social inhibition .

    Often you come to the team and do not understand what people eat their bread - the database model is not normalized, the noodles from the “undocked poltergeist” flavored with a pair of “divine objects” with the “singletonization” of everything, the person who is very fanatical about his creation and not able to withstand any criticism. Very much he wants to lead, and those who are above did not even check his competence. Therefore, I just stopped working with PHP projects - the percentage of amateurs is too large.

    Team roles can change as projects are implemented and this can be used as an additional means of motivating and strengthening cooperation.

    Next, I consider a couple of basic cognitive distortions with which I have to face constantly.

    I almost always put an end to people who insist on "the first personal meeting."
    Because of their dilettantism, they were thrown many times, but this does not mean at all that such a contingent is ready to learn from its own mistakes. The first personal meeting means that they need to create a positive impression, with which they will then compensate for any subsequent irritations due to the delay in terms, the lack of a visible result, etc. They do not want to be part of the process, delve into its components and make efforts to get the product that they really need. It is easier for them to create and believe in the illusion that “this smart guy will solve all my problems for money,” and you yourself perfectly understand what will happen next ...

    Also, I put an end to projects with phrases like “it's all very simple, for a professional this is 2 hours of work” with penny budgets. Usually, dilettantes write this way, who believe in supermen and justify their poverty. Of course, they may have some kind of technical support behind their shoulders, and they themselves may be able to do something, but if they are so smart, let them do it themselves. No matter how hard you try, in any case you will not reach the abstract superman in a vacuum, you will not justify your hopes, and this will be a good excuse that you are paid a penny. A similar opinion is formed when one amateur meets another, and they very superficially argue the deadlines for the implementation of any tasks. Again, these deadlines break down, not the fact that the task will be solved at all ... but the porridge about simplicity and 2 hours of work in the brain remains for quite a long time.

    People are not inclined to test in practice the skills of a freelancer about which “someone said well”, or who left a good impression of a person who is capable of “doing everything for money”, and there really aren’t such people. It is necessary to remember the needs of development and try to understand what kind of experience a specific artist needs, and why is he here? .. Make a sample project, cut down money, and run further? .. But who needs such products? They are needed by greedy people who, to the best of their underdevelopment, believe in the illusion of quick profits from the publication of a product of any quality, and then what? .. And then the ads in the style “complete that ... complete this ... for 1000 rubles. without documentation and tests. Such projects are performed by people who are stuck on a single tool and are not able to develop further as a developer. However, often they are not able to develop as a person.

    If people cannot communicate normally online, they will not be able to do it live, either.

    If you are unable to resolve the communication problem, the freelancer simply “crashes.”
    But the employees are more complicated: too many people are mentally tied with a back seat to their chair.
    Accordingly, freelancers who develop their skills and do not “get stuck” on any specializations, very quickly learn from the organizational mistakes of their leadership. But for a long time in one place they do not linger.

    A mature person is able to look at himself from the outside, try to evaluate the decisions made and their consequences, realize his own stupidity and draw some experience for himself. And the rest you need to a psychologist.

    Although psychology is now not particularly developed - large charlatan clinics are opened, which work according to the same method, which mysteriously solves all problems for money, and where there is esoteric, and where psychology still needs to be sorted out. Therapy in some particularly neglected cases may last about five years. One pill from all diseases can not be cured.

  2. Lack of quality control


    • No requirements

      It is clear that any customer will start with the desire to solve some problem by developing a specific product for this. Strange, but often they begin not with the formulation and formulation of a specific task, and the problems that they want to solve, but with the vision of the solution itself from the point of view of the customer. Unfortunately, it is not he who assembles "auto", and it is not for him to think which "forms", "metals", "details" and "joints" will suit his tasks better. He did not go to the car factory and did not tell the local workers what his real car should be. He can say that he likes it, but this does not mean that this is exactly what he will receive in the end - others will ride his car, and they will not need "seals and rainbow ponies." Of course, you can say “the customer is always right,” but why produce products that are then embarrassing to show?

      It is clear that 80+ TK pages according to GOST for automated systems will not be written by anyone at the start, but the requirements for the project may change in the process of researching the sales market and the target audience. So, the development of requirements is a separate development process that requires direct communication with the customer and / or management, it cannot be done only by managers, any point of view not only of the designer or programmer, and even your relatives, can be useful, the more views on the product and the tasks that it solves, the more accurate the requirements. Feedback from the target audience is more relevant than the initial requirements, which leads to their subsequent evolution. Usually it takes 2-3 cycles of the development of requirements before they are finalized.

      The form of requirements can be any - you can keep user stories, or you can simply record thoughts on a tape recorder or make videos, keep journals on which you will then rewrite or make user stories. In any case, you should not be strongly attached to the papers, you need to formalize the intentions of the target audience, and not the methods of their implementation.

      This is how the requirements are usually developed.


      Why would anyone draw seven red lines?
      What task are trying to solve this way?
      For which target audience is this functionality intended?

      Such issues are resolved when developing requirements, and not by the customer independently.
      Problems begin when the customer thinks he is the main boss who is able to formulate the tasks correctly.

    • No accounting for staff development

      For management, you always need to keep a “hand on the pulse”, and the most difficult thing with the introduction of personnel management tools, not only freelancers, but also simple office and remote workers, is understandable, no one in IDE’s will reach more than 6 hours a day, but even if it stretches out - surely in vain. But even these 6 hours are already talking about something. You can safely run some Harvest or RescueTime on your computer - the results are quite interesting. Leave off all, and leadership - more than anyone. The numbers are motivating.

    • No tests

      For me personally, the sad part is the lack of acceptance testing, for projects of 1-2 bodies - this can save a lot of time. You click your hands - you do not respect yourself. Acceptance tests are also a good indicator of job promotion for managers. If acceptance tests are must have and it is rather difficult to do without them, then functional (modular), integration and load ones often have to be abandoned before the first release.

      The lack of tests is
      • saving time and resources now (about 20%), but high costs in the future, of course with an exponential dependence
      • cross on product support and BusFactor = 1
      • the inability of management to think about the prospects of the product, and to give guarantees to customers.
        Rather, on the contrary, this kind of leadership tends to delegate responsibility to third-party vendors, create vendor lockin and rather intricate dependencies with a bunch of side effects. Although in fact, the more ready-made uncontrolled structures are used to maintain the product's performance, the greater the risk of failure of its components.

    • No repository

      If you come to work, it doesn’t matter whether you are a regular employee or a freelancer, get ready for a large granite fragment, from which you will need to make candy. Well, or not to sculpt, and give customers gag, perhaps even with a traumatic outcome. If management is interested only in profit, this is usually the case. In order to cut the granite, you need at least acceptance and functional (modular tests) with a source repository. Most often it is necessary to rewrite both tests and code in parallel with the development of requirements. Naturally, without a detailed history of all changes, even to one person, this can be quite difficult.

    • No audit of existing solutions

      It is necessary to understand how many people - so many views on the problem, and this is good. An audit of an existing solution within an office can bring many new fruitful ideas and solve a fairly large number of problems. The more a person “goes through” the code - the cleaner it is, and at least there will be no spaghetti code, bloatware and pattern-hell.

    • No refactoring

      Nobody writes perfect code with perfect architecture the first time. If this happens, then most likely the person has already solved the problem earlier and faced some of its aspects, but in this case he will come up with the idea “how it was possible to do better” and not allow him to do it - kill the trust and potential of the project . On the other hand, without an audit on the part of such decisions end with the code "Public Morozov" which, except for its author, no one can really figure it out.

      Software development is a recurrent process. In general, according to GOST, for automated systems there are only 2 iterations: draft and technical design, then the design documentation is developed. Although in practice you usually need 4-5 before the product can be safely used and maintained. For refactoring, you must have tests and a repository.

    • No audit of resources and corresponding cost / revenue optimization

      People do not know how to make a profit from a product, assess risks, and spend everything wisely. It makes no sense to purchase 100 servers with 64GB of memory each and with used 500GB screws in RAID-10, when the project has only three dozen clients. It makes no sense to save on the organization of processes, but any decisions made without discussion and audit from the outside imply some risks, you need to take these risks into account, otherwise the money will go "to the wind."

      It makes no sense to store all the honey in one pot - get money in dollars at the European Bank, distill them into rubles, and then again into dollars in order to pay for the next service.

      There are no things to buy and get right now.
      In any consumable resource or service, a stock is needed, or the possibility of compensating for its absence at the time of delivery. It is necessary to conduct a comprehensive risk assessment, with the construction of the dependency graph of all resources.

  3. Lack of developed development methodology


    I recently wrote why SCRUM is not very suitable for the post-Soviet space. And the reason for this is just the same psychological problems and compensatory processes. People replace the process of analysis with discussions, and assumptions are taken for facts. These are also different cases of cognitive distortion in decision making.
    It turns out "Meeting for the meeting", "Code for the code."

    You need to understand that methodologies need to be adapted to a specific team and selected for a specific project.
    The methodologies were not invented by managers, the methodologists invented by marketers - this is another “beautiful candy” for the leadership of those unable to lead, and who need guarantees from the side that this “candy” will solve all their problems. Thus, a rather large number of abbreviations were developed from three to four letters, on the standardization and issuance of certificates of which people earn millions.

    Stop yelling “Agile here”, Agile is four fun rules that everyone wants to strive to improve the quality of software and the happiness of developers ... Agile methodologies are a set of abstract methods that can be used to achieve Agile goals. But this does not mean that they will work for your team.

    You need to start with something small — take a V-model and adapt it to Lean with Kanban 's.
    Instead of building highly recurrent processes, perform only 2-3 tasks at the same time on the principle of "divide and conquer", and then, when you finish 2-3 projects, you can play with all sorts of SCRUMs. From the documentation, there are enough user stories, descriptions of the database model, descriptions of services in the SOA , tests, and the API schema in the Swagger 'e or JSON-WSP comunity.

  4. Organizational anti-patterns


    • Analytical paralysis - the development of abstract specifications is put above the development of even the most raw implementation of the product. Developing requirements and implementation are recurrent processes, and trying to “swallow an elephant without chewing” is rather stupid.

    • Cost Migration - the transfer of a cost optimization task to a potentially vulnerable partner or division that may not be interested. In general, any contractor will be interested more in remuneration than in ensuring that a product will be developed and completed on time.

    • The cash cow - money should bring money, it is not necessary to “eat away” everything, spend profit from projects for the implementation of more ambitious ones. There is nothing eternal.

    • Continuous obsolescence - porting poorly structured legacy code due to changing conditions or requirements for a project ends with terrible costs and deadlines. This is probably the most typical antipattern for existing crutch projects in which “why rewrite, and we ate our bread for nothing?”.

    • Creeping improvements - introducing new functionality without reworking an existing one leads to more side effects and “detonators” in the code.

    • Development by committee - design without centralized and competent leadership. This is found in 80% of projects in the CIS and in Europe. A lot of people gather and “poke a finger that is popular, move there”, do not measure or analyze anything, make decisions in the style of “if it was used in a large project and it works there, it means it will work for us too”. The result is "a lot, but bad" and bloatware .

    • I told you this - ignoring the opinion of an expert by the management. Such a situation arises when subordinates are more competent than the management, and instead of changing roles, a conflict situation arises - only the decisions that they make independently are important for the management. This is done in order to compensate for the internal stress that arises due to feelings of inferiority.

    • Escalation of devotion - continued support of outdated solutions, even if proved their inability to current tasks and showing the existing erroneous solutions. No matter how far you go the wrong way, it is important to turn around and move in the right direction right now.

    • Numbers management - the introduction of an excess of surface metrics, the appropriateness of which is a big question. They love leaders and managers to imitate activities and justify their usefulness.

    • Vendor lock-in - the absence of adapters for various vendor solutions, a very strong connection with their functionality. As they say, “no one has yet been fired for purchasing IBM software.” This is especially true for solutions based on Oracle and Microsoft - then it is quite difficult to switch to OpenSource.

    • — , . , - , . 2-3 . .

    • — - , . BusFactor == 1. , « », .



  5. . , , , . proactor' reactor', CQRS-ES. , .

    , , . , , , . , CQRS-ES , SOA , .

    , , . , , …

    ,
    • — / MustHave, « » 640
    • — Composer / pip / Bundler / Gradle / npm / bower… .
    • — , .
    • — . — Zabbix/Nagios Kibana logstash/fluentd ElasticSearch. .
    • — . , — , .


How does all this usually happen?


Consider the cycle of developers in nature, the main causes of migration of flora and fauna, as well as the most common tools and tasks for each of the stages.

The concentration of "gag" very "rolls over", you can just read the item "3" from this list and go to its end, if you broke it.

one Basic knowledge of a technical university not supported by real practice

(), () () () (), , , . « », , Vendor Lockin , — , , , . « », « , , », .

, ATMEGA8 ( TQFP , DIP ), ', 0805 SMD . Arduino — POP-, , . 1-2 Cortex-m0 , Cortex-m3 Cortex-A5 A9 ARMv7 ARMv9 . OpenSource 15-16 . ArchLinux Ubuntu/Mint ( Arduino). « », 3 4 , - - .

CMS, , . « LAMP ».

, , …
« », « /MS». . , — , - . , SomeRandomName — , «golden hammer», .

, , , - .
, , , .

, , - , . , - . , , , , , - , . — - , 300 , , - /.



java :(
- 3 , .

, , - . / , .

, , .

2 ,

, , . , , . , « » .

:

* , , , — , , . - .

, « » «» — . — .

— « » « ». . , — , . , .

, - .

:

PHP / Python / Ruby , , RESTful , , push- . JVM, jRuby Project Graal. Jyton'a , . Groovy , J2EE - .

, Qt .net .
Java Air , JavaFX2.

, , , J2SE, J2EE, Java Android, , Objective-C / Swift . , , .

, , . - — « », , « ». , . , , . .

, .
.

3 « »

For such projects, first of all, the result is important, even the worst and poor quality, simply because it can be sold. They do not have a normal competent leadership, antipatterns very often. People who "work for food" most often get here - they are former students, or just lovers of disrupting abstract, unreasonable terms. History is silent about competence or even the simplest discipline and responsibility, so you need to hope for the best.

People who work “for food” are not able to see the prospect, their main task is to get any income, and not to prevent the customers / management headache and as a result of their own. Their development quickly stops, they become rigid, and often produce no quality products.

This includes people who did not have an example of how “good” is done, or people who “wanted well, but it turned out as always.” They can work long and hard, and consistently receive their salary, as Vitya said, “the main thing is stability!” Well, and leave the quality for later.

The team is spontaneous, with a bunch of conflicts and communication barriers, completely unformed. Due to the lack of audit and quality control, the budget expands 3-5 times, and all deadlines are delayed. The project requirements are minimal, and therefore there is no documentation, no tests, simply because no one cares if anyone understands something and that it works for a long time.

In an unformed team, a defensive reaction will be the rejection of any innovations, followed by complete isolation. Naturally, no one will say directly about this and they will pay the money, but everyone will be looking for a moment to “bake the white crow”. At best, everything ends with the “children in the sandbox” scenario: “here it is bad, let's not play with it”, without any discussion and adoption of subsequent decisions. The truth is usually these people are already under 30 tnik ... If you do not quickly deal with the attitude, and do not take appropriate decisions, a "mushroom garden in the chimney" arises.

Such projects are characterized by a static rate per hour, regardless of the competence of the developer or his skills and role in the project, managers or team leaders can get 1.5-2 times more, simply because they are “higher”, and not because they have more experience . At the same time, their contribution to the project is rather doubtful.

Here people experience time.
Experience is not measured by time, it is measured by the ability to adapt to the conditions of development of a particular product and its team, to solve problems in the best way, and for this purpose: analyze, research, implement, measure, optimize product components, positioning and monetization. Accordingly, it is important for management to maintain the cyclical nature of these processes.

It is possible for 5-6 years to ditch saytik on CMS'kah and enjoy life, to imagine himself a great man, and amateur customers then later easier to rinse the brains and develop leaky products. Well, yes, it makes money for food, and nobody needs anything else.

Here, because of their dilettantism and inability to see the development prospects, the leaders cannot guarantee the efficiency and availability of their products. They tend to delegate any responsibility to employees and third-party services, they believe that in this way they can be confident in the performance of the product, usually nobody thinks about quality. They believe that if we use an outsider here for a couple (maybe tens) of thousands of U. Dmurdskikh Ye. We will reduce the risks ... If we hire some cool manager who participated in managing the teams with cool products - he will be able to organize everything for us ... In fact, these are very big prejudices that only increase the risk of a complete failure of the project already at the design stage and the initial stage of implementation. There is a theory of resiliency - the more structural elements with a certain probability of failure, the greater the probability of failure of the entire system, this also applies to the number of managers in projects.

One of my most favorite particular cases of such projects are “quasi-marts with false-scissors”.
As one young lady with Luxoft said, in one mediocre presentation three years ago, “who does not have a startup, that one is a sucker” (literally). Wow, how I wanted to punch on ... really I wasn’t there then: (Given the primitiveness, and sometimes the complete absence of luxoft corporate culture at the time, such behavior of their employees didn’t surprise me. They now started working with the community, and the development of corporate culture - they understood that this is not only “training cats", but also attracts customers. There was even a couple of articles of resentment by their leadership in Habré - again, people simply did not have the motivation and opportunity for personal and professional development. In any context tea, I am pleased that there was a rotation, and they decided most of its institutional problems, though "initiation rituals" with some compensatory processes have not gone away.

The concept of a startup has become a part of pop culture, and more and more dilettantes are applying it to any small and medium-sized business in any way connected with IT. Again, you need to understand that start-ups are primarily tools for researching and creating new markets, and only then small and medium-sized businesses. Their advantage is that they can very quickly recoup the five-year investment in case of success, and in case of failure - partially compensate them. If you cannot provide investors with exhaust at least 10 times the initial investment in five years, then you have very serious problems.

Standard issues that are not solved in the "quasistartap"

If these issues are not resolved, then the project is just waiting for a vague perspective.
Although not the fact that in general there is someone who is able to imagine what will happen in a couple of years, or even in a month.

Again, people can wander around the “shops” of under-sites on CMS and Bitrixes for a long time, and this is a good experience.
Worst of all, if they stay there for a long time. Changing perspectives greatly contributes to personal and professional development, but changing jobs too often is very bad — you need to at least complete something. We need to lash when a “problem” in the English meaning of the word arises is something insurmountable, a conflict that cannot be resolved, and everything else is an obstacle to the realization of a product.

It is very fun with the foundry manager, who stands in the way of communication with the customer and the subsequent development of requirements under the pretext "I will translate everything into an understandable language." Naturally, their contribution to the development of the project itself is very doubtful. Usually such individuals do not have any competence in terms of quality control and long-term support, cannot ask the right questions, and are a “spoiled telephone”. It turns out and the development of requirements is delayed, and an abstract product is being developed, which may have nothing to do with what the customer wants. Instead of formulating specific tasks and usage scenarios, they operate with “Wishlist” and “Pink Ponies”, because the wallet is thick and someone’s drool drips. Here they produce “irreplaceable” and wake up at 3 o'clock in the morning because something “has fallen off”. Developing skills is difficult and sometimes impossible.

If the customer / management in the “meat processing shop” plays “the most important and the most intelligent”, then there can be no talk of any development - these are people who avoid problems, they do not solve them, do not get experience, and therefore do not develop . This is very well seen during the release of emotional tension - the repressed consciousness itself splashes out the most ingrained images in the subconscious, and people, without even realizing it, project what they think about themselves inside others (a primitive projection is a tough cat, I have it very angry and unhappy with what is happening "). The task of development they replaced the task of obtaining material benefits. Not only that, the brains will be cut "as it is necessary to live," but also any delay in payments will explain your some "failure". If they are so clever, let them do it themselves in order to scratch the tongue - a lot of brain is not needed. Trying to explain something is useless, since they will either deny any suggestions or criticisms to their side, or they will simply hate themselves in the subconscious, and this hatred will be successfully projected onto you. Usually I simply ignore such and suspend any cooperation despite any agreements - my nerves are more expensive. Yes, "I am bad" because I am not trying to part with customers "in an amicable way", but in this case it is unreal. To be good for everyone will not work, this is obviously a very defective position. If you have a solution to this problem - write in a personal. Psychologists are advised to just send , and I devalue - this is a subconscious blocking and suppression of feelings of anger, which I compensate by writing this article.

Between the change of projects, most often people are looking for new methods of solving problems at their previous place of work, and also return to learning and researching existing approaches and tools. True, the probability that they will again fall into the same fun place is too high. This will continue until they begin to analyze the behavior of staff, existing organizational problems and the decisions that their management makes. If they succeed, after the “enlightenment” they often get into normal projects, but this is a matter of luck.

four Small startup or outsource

I have already managed to talk about “quasi-start-ups” above, this is the case of “meat-packing plant”.
And startups get people who have experience in good, and not so, projects. These should be those who are able to realize everything in the shortest possible time and receive the first feedback from the target audience for better positioning and realization of the product. Otherwise, the tasks of a startup are stretched for immeasurable terms along with the budget, and the investments are simply eaten away. It requires a very large experience in developing applications. Without an audit, any startup simply eats away money, and there are now, unfortunately, the majority. But to live and develop is quite possible. After a full-fledged startup, people almost never go to the "meat processing plant." Unfortunately, professional development at this stage often stops completely, people get used to tools and approaches, and are very, very hostile to everything new — they become rigid fanatics of their decisions, with appropriate antipatterns.

In the case of outsourcing, everything is more fun - it combines both “bad” and “good” projects. However, in the conditions of intensification of development processes, staff rotation most often just happens and a lot of problems can get away with poor management. Outsourcing is the case when you don’t have to think about organization yourself - a lot of people are already doing this for you, and in principle they do it very well, and if it’s bad, they are quickly disposed of. In a good outsourcing, you can learn a lot, and outsourcing partly simplifies the life of a developer. But this leads to a slowdown in professional development, and sometimes to complete suspension: they feed well, there is a bubblegum, problems are solved — life is successful. Unfortunately, up to 30 people in such conditions become very rigid, and almost do not adapt to the new needs and objectives of the market. This is very noticeable in the case of employees of large offices, like Google or Facebook.

The main thing here is not to get stuck.

five Becomes a cat trainer

Teaching other people and sharing experience is an integral part of professional and personal development. If you have to audit other products or recruitment, this usually comes with feedback and a learning process — you need to explain to people what they are doing wrong, and how this should be done so that there is a basis for further development. When they say to me at the interview, “you don’t approach us,” I usually answer “why did you think that you were suitable for me?” You cannot say directly that you are not satisfied, it means that you yourself do not know what you need, and the lack of selection criteria is a sign of disorder in the organizational apparatus - solve your problems, then we will talk, ”and then a defensive reaction follows - people switch on the individual due to the inability to realize their mistakes. When I produce staff recruitment, I describe all the disadvantages and advantages of the methods that the applicant used to solve problems earlier, explain where he was wrong, suggest alternatives, explain existing different approaches and how they are suitable or not suitable for solving project problems, and all remain satisfied.

Project managers in our time are most often for two reasons.
Naturally, such leaders can only “hold tightly to the chair,” and their interests do not include the development of high-quality products.

Exceptions to this rule successfully manage their projects, and may even introduce horizontal organization of authority. As my personal practice shows, freelancers who have seen everyone become excellent leaders: they build teams and ensure that the development process is cyclical. Although it usually comes to this very rarely and if we are talking about a developed person who is able to learn from his mistakes and the mistakes of others, many more cones need to be filled, the main thing is that this does not have a strong effect on the final products.

Different personality types require different attitudes, and their motivational processes are very different. Some of them are very difficult to interact with others, and some compensate for their internal stress by procrastination. A good article about procrastination can be read here . When building teams, it is very important to pay attention to the tasks and peculiarities of motivation of each specific individual - not all are compatible with each other.

If the leader with his position “fails”, then the knowledge accumulation stage is waiting for him again, from which he probably will not return to the managerial position, since the learning processes are replaced by compensatory ones - many who compensate for the “loss of the chair” by the “glass”.

6 Opens his small projects

When a developer goes through all the previous stages of development, and begins to teach others organizational and architectural tricks, “Zen” is comprehended. If he has enough experience, he can start successful OpenSource projects, and even have passive income with their support. This happens extremely rarely, and this is the way of a person who “stuffed cones” or watched how others “stuffed” them. But this is the only way to create competitive products. So, before working with someone, it is better to ask about the solved problems in the industry, and not about the number of products implemented on some framework, or using some kind of library.

Well, this is about ideal options, there are very few of them ...

And usually someone spends a lot of money with burning eyes without any experience in organizing the development, auditing and quality control of products. , , - 90% .

Again, being a developer, and understanding process organization are two different things. But it is impossible, for example, to be a developer and go to managers or managers, or, on the contrary, to be a good manager / manager and go to developers - as a result, there are non-managers, underdevelopment. There is no understanding of the complete and clear picture of the production processes, the advantages of each specific approach and architecture, there is no understanding of the personal characteristics of the employees and how compatible they are with each other. Therefore, at a sufficiently high level of professional development, developers are managers themselves, and managers, in the literal sense of the word, need projects with poor organization, where people themselves do not fully understand how the product will be realized and what its long-term outlook is.In projects with horizontal organization of authority, very often good developers switch roles with managers.

one

, . , — , . CTO «». - , .

, , . , .

Agile « » « » .
« ». " Scrum ", and I will say that it works only in the case of healthy teams in which BusFactor is at least 20% of the staff - crushed by the bus, and no one noticed. But the metrics are usually used very simplified and" fake ", which have nothing to do to the development and design processes.

And what is the difference between freelancing and full-fledged remote work?


— « », . , , . (). «» , , … - — « », , , , ?

Remote employees are usually easier to motivate than freelancers — they have links to the real world and living people. They know that somewhere they have a chair and a table, perhaps very dusty ... which they can see a couple of times a week, or they may not. In many ways, this is a kind of privilege for them, which freelancers do not have. It’s not typical for them to recycle, but it’s not a fact that they will delay the time. The team treats them as equals if they see the work done and its value for the project, and it is important for the management to ensure this publicity. In the case of freelancers, they usually don't care, the threshold for joining the team and overcoming communication barriers is much higher. Yes, and they need to communicate at times more in order to feel part of the team, and this is one of the components of their motivation, and the management also needs to think about it.



?


.

2008', : div' / span', CSS , - . HTML5 DOCTYPE, - XHTML, 7 . — , . 'a, . : « 5 div' / span' — HTML5».

, , , .

— html5 / css3, , ().

— , -, , , . UX : , , . , , - 2-3 3-4 , . -.



?


.

95% « » .

, — , «» « ». , « , », , . — , , , , .

— , . …

« »?


The situation is better, but people are much healthier, and it is accepted in society to analyze and solve their personal psychological problems. The need for compensation is much less common, it is customary to “leave home” - everyone does their job, and they don’t waste time on what. True and in family terms, work too strongly affects the well-being - they “come off” primarily on the family. So the issues of family relations of employees are very important for foreign management, and often there are offices with their psychologists, most often this is a family psychoanalyst with interspersions of some kind of Freudianism and “pop” Gestalt psychology . -, , „ “, , (true story)…

, , , . , .

, . MIT Case Studies — . — CRUD' . Case Studies , , . Access'…

, , . … „, “, 300 10 , , „ --“.

, MIT — „“, , , . 7 „ “…

Conclusion


, , , . „ “ , , , . , , . , — , - -.

over 100500 , — ?
- „ “, — „The USSR way“, „ , “. , — „ “, . — „“, - . , , 70 , .

, , !

„ “, , , , , , . .

, . , , „ “. , — , . , - . , „ “ - . .


— , .

, -, -.

.
— . -.

, , . .
.

.

Thanks for attention.

PS — , - . , - „“.

Source: https://habr.com/ru/post/246631/

More articles:


All Articles