{"id":97853,"date":"2020-10-22T14:42:44","date_gmt":"2020-10-22T12:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte"},"modified":"2020-11-18T00:58:50","modified_gmt":"2020-11-17T22:58:50","slug":"organizacziya-rabochego-proczessa-v-komande-na-it-proekte","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","title":{"rendered":"Organizing the workflow in a team for an IT project","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hello friends. Time and again, especially in outsourcing, I see the same picture. The lack of a clear workflow in teams on various projects.<\/p>\n<p>The main issue is that programmers don't understand how to communicate with clients and with each other. How to build a continuous process for developing a quality product. How to plan their workday and sprints.<\/p>\n<p>And all this ultimately leads to missed deadlines, overtime, constant arguments about who is at fault, and client dissatisfaction \u2014 where everything is heading. Quite often, this results in changing programmers, or even entire teams. Loss of clients, damage to reputation, and so on.<\/p>\n<p>At one point, I happened to be on such a project, plagued by all these issues. <br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nNo one wanted to take responsibility for the project (a large service marketplace), turnover was horrendous, and the client was simply furious. The CEO approached me and said that I had the necessary experience, so here are the reins. Take the project. If you mess it up, we\u2019ll close it and fire everyone. If it works out, great, then lead it and develop it as you see fit. In the end, I became the team lead for the project, and everything fell on my shoulders.<\/p>\n<p>The first thing I did was develop a workflow from scratch that aligned with my vision at the time and wrote a job description for the team. Implementing it was not easy. But within a month, everything settled down, the developers and the client adjusted, and things began to run smoothly and comfortably. To show the team that this was not merely a 'storm in a teacup', but a real solution, I took on the maximum workload, relieving the team of unpleasant routine tasks. <\/p>\n<p>It's been a year and a half now, and the project is progressing without overtime, without 'rat races,' and all sorts of stress. Some members of the old team didn't want to work this way and left, while others were very pleased with the introduction of transparent rules. In the end, everyone who is on the team is highly motivated and has a complete understanding of the large project, both front-end and back-end, including the codebase and all business logic. It's even come to the point where we are not just 'rowers' but are also inventing many business processes and new features that the business appreciates.<\/p>\n<p>Thanks to this approach on our side, the client decided to order another marketplace from our company, which is certainly encouraging.<\/p>\n<p>Since this works on my project, perhaps it can also help someone else. So, here\u2019s the process that helped us save the project:<\/p>\n<p>Team Work Process on the Project 'My Favorite Project'<\/p>\n<p>a) Internal team process (among developers)<\/p>\n<ul>\n<li>All tasks are created in the Jira system.<\/li>\n<li>Each task must be described as thoroughly as possible and should accomplish exactly one action.<\/li>\n<li>Any feature that is sufficiently complex is broken down into many smaller tasks.<\/li>\n<li>The team works on features as a single task. At first, we develop one feature together, submit it for testing, and then take on the next one.<\/li>\n<li>Each task is labeled according to whether it pertains to the back-end or front-end.<\/li>\n<li>There are types of tasks and bugs. It is important to specify them correctly.<\/li>\n<li>After a task is completed, it is moved to the code review status (at which point a pull request is created for a colleague).<\/li>\n<li>The person who completed the task immediately tracks their time for that task.<\/li>\n<li>After the code review, the pull request is approved, and then the person who performed the task merges it into the master branch and changes its status to ready for deployment on dev. <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/en\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\">server<\/a>.<\/li>\n<li>All tasks that are ready for deployment on the dev server are deployed by the team lead (his area of responsibility), sometimes by another team member if something is urgent. After deployment, all tasks marked as ready for deployment on dev are moved to the status \u2014 ready for testing on dev.<\/li>\n<li>All tasks are tested by the client.<\/li>\n<li>When the client has tested the task on dev, they change its status to ready for deployment on prod.<\/li>\n<li>For deployment on prod, we have a separate branch, where we merge master only before the deployment.<\/li>\n<li>If the client finds bugs during testing, they return the task for revision, marking it with the status 'returned for revision.' This way, we separate new tasks from those that did not pass testing.<\/li>\n<li>As a result, all tasks go through the following stages from creation to completion: To Do \u2192 In Development \u2192 Code Review \u2192 Ready to deploy to dev \u2192 QA on dev \u2192 (Return to dev) \u2192 Ready to deploy to prod \u2192 QA on prod \u2192 Done.<\/li>\n<li>Each developer tests their own code independently, including as a user of the site. Merging a branch into the main one is not allowed unless it is known for certain that the code works.<\/li>\n<li>Each task has priorities. Priorities are set either by the client or the team lead.<\/li>\n<li>Developers prioritize the tasks they perform.<\/li>\n<li>Developers can assign tasks to each other if different bugs are found in the system or if one task consists of work from multiple specialists.<\/li>\n<li>All tasks created by the client go to the team lead, who evaluates them and either asks the client to revise them or assigns them to a team member.<\/li>\n<li>All tasks that are ready for deployment to dev or prod also go to the team lead, who independently determines when and how to proceed with the deployment. After each deployment, the team lead (or a team member) must notify the client about it and also change the statuses for tasks to 'ready for testing' on dev\/prod.<\/li>\n<li>Every day at the same time (for us, this is at 12:00) we hold a meeting with all team members.<\/li>\n<li>Each person at the meeting reports, including the team lead, what they accomplished yesterday, what they plan to do today, and what challenges they are facing and why. This keeps the entire team informed about who is working on what and the current stage of the project. It allows us to predict and adjust our estimates and deadlines if necessary.<\/li>\n<li>At the meeting, the team lead also discusses any changes in the project and the current level of any bugs found that were not reported by the client. All bugs are analyzed and assigned to each team member for resolution.<\/li>\n<li>At the meeting, the team lead assigns tasks to each member, taking into account the current workload of the developers, their level of professional training, and the proximity of each task to what the developer is currently working on.<\/li>\n<li>At the meeting, the team leader develops a common strategy for architecture and business logic. After that, the entire team discusses it and decides whether to make adjustments or to adopt this strategy.<\/li>\n<li>Each developer writes code and builds algorithms independently within a unified architecture and business logic. Everyone can express their vision for implementation, but no one is forced to follow a specific approach. Every decision is justified. If there is a better solution but no time to implement it now, a task is created in JIRA for future refactoring of a specific part of the code.<\/li>\n<li>When a developer takes on a task, they move it to the development status. All communication regarding task clarification with the client falls on the shoulders of the developer. Technical questions can be directed to the team lead or colleagues.<\/li>\n<li>If the developer does not understand the essence of the task, and the client has not managed to explain it clearly, they proceed to the next task. The team lead then takes over the current task and discusses it with the client.<\/li>\n<li>Every day, the developer must write in the client chat about the tasks they worked on yesterday and which tasks they will work on today.<\/li>\n<li>The working process follows Scrum. Everything is divided into sprints. Each sprint lasts two weeks.<\/li>\n<li>The team lead creates, fills, and closes the sprints.<\/li>\n<li>If the project has strict deadlines, we try to estimate all tasks roughly. Then we assemble them into a sprint. If the client tries to add more tasks to the sprint, we set priorities and move some other tasks to the next sprint.<\/li>\n<\/ul>\n<p>\nb) The process of working with the client<\/p>\n<ul>\n<li>Each developer can and should communicate with the client.<\/li>\n<li>The client should not be allowed to impose their own rules. It is important to politely and amicably make the client understand that we are the experts in our field, and only we should shape the work processes and involve the client in them.<\/li>\n<li>Ideally, before starting the implementation of any functionality, one should create a flowchart of the entire logical process for the feature (workflow) and send it for approval to the client. This applies only to complex and non-obvious functionality, such as payment systems, notification systems, etc. This will allow for a more accurate understanding of what the client actually needs, maintain documentation for the feature, and protect oneself from the possibility that the client might later claim that we did not do what they requested.<\/li>\n<li>All diagrams\/flowcharts\/logics, etc., are saved in Confluence\/Jira, where we ask the client to confirm in the comments the correctness of the future implementation.<\/li>\n<li>We try not to overload the client with technical details. If we need to understand how the client wants it, we draw primitive algorithms in the form of flowcharts that the client can understand and amend by themselves.<\/li>\n<li>If the client finds a bug in the project, we ask them to detail it very specifically in Jira. Under what circumstances it occurred, when it happened, and what sequence of actions the client took during testing. We ask them to attach screenshots.<\/li>\n<li>We strive to deploy on the dev server every day, or at most every other day. This way, the client can start testing the functionality and the project doesn\u2019t stand still. This also serves as a marker for the client that the project is actively being developed, and nobody is feeding them fairy tales.<\/li>\n<li>It often happens that the client does not fully understand what they actually need, as they are starting a new business with processes that are not yet streamlined. Therefore, it is a common scenario for us to throw away entire chunks of code and rework the application's logic. This leads to the conclusion that not everything should be covered by tests. It makes sense to cover only critically important functionalities with tests, and even then with reservations.<\/li>\n<li>There are situations when the team realizes that we are not meeting deadlines. In such cases, we conduct a quick audit of the tasks and immediately inform the client about it. As a solution, we propose to launch important and critical functionalities on time, while postponing the rest for post-release.<\/li>\n<li>If a client begins to come up with different tasks from their imagination, starts fantasizing, and explaining with hand gestures, we ask them to provide us with a page mockup and a flow that fully describes the behavior of the entire mockup and its elements.<\/li>\n<li>Before taking on any task, we need to ensure that this feature was part of the terms of our agreement\/contract. If it's a new feature that goes beyond our initial agreements, we must estimate this feature ((approximate execution time + 30%) x 2) and inform the client that it will take us this amount of time, plus the deadline shifts by the time of the estimate multiplied by two. If we complete the task faster, great, everyone benefits from that. If not, we've covered ourselves.<\/li>\n<\/ul>\n<p>\nWhat we do not accept in the team:<\/p>\n<ul>\n<li>Unreliability, disorganization, forgetfulness<\/li>\n<li>\"Feeding false hopes.\" If you can't complete a task or don't know how, you must immediately notify the team leader instead of waiting until the last minute.<\/li>\n<li>Boasting and bragging from someone who has not yet proven their abilities and professionalism through actions. If they have proven themselves, then it's acceptable, within reason \ud83d\ude42<\/li>\n<li>Deception in any form. If a task is not completed, it shouldn't be changed to completed status, and you shouldn't message the client that it is ready. Computer broke, system crashed, dog chewed the laptop \u2014 all of this is unacceptable. If a real force majeure occurs, the team leader must be notified immediately.<\/li>\n<li>When a specialist is always offline and hard to reach during working hours.<\/li>\n<li>Toxicity in the team is not allowed! If someone disagrees with something, everyone should gather for a meeting to discuss and resolve it.<\/li>\n<\/ul>\n<p>And several other questions\/theses that I sometimes ask my client to clear up any misunderstandings:<\/p>\n<ol>\n<li>What are your quality criteria?<\/li>\n<li>How do you determine if there are issues in the project or not?<\/li>\n<li>By ignoring all our recommendations and advice for changing\/improving the system, all risks are solely yours.<\/li>\n<li>Any major changes to the project (for example, various extra flows) may lead to the potential emergence of bugs (which we will, of course, fix).<\/li>\n<li>It's impossible to understand the issue that has arisen in the project within a couple of minutes, let alone fix it right away.<\/li>\n<li>We operate on a specific product flow (Tasks in Jira \u2014 Development \u2014 Testing \u2014 Deployment). This means we cannot react to the entire influx of requests and complaints in the chat.<\/li>\n<li>Programmers are just programmers and not professional testers, and they cannot ensure the necessary quality of project testing.<\/li>\n<li>The responsibility for final testing and acceptance of tasks in production lies entirely with you.<\/li>\n<li>If we have already taken on a task, we cannot immediately switch to others until we finish the current one (otherwise, this leads to even more bugs and increased development time).<\/li>\n<li>The number of people on the team has decreased (due to vacations or illnesses), while the workload has increased, and we physically cannot respond to everything you want.<\/li>\n<li>Requesting you to deploy to production without tested tasks on development is solely your risk, not the developers'.<\/li>\n<li>When you set vague tasks, without a correct flow or design mockups, it demands much greater efforts and time from us, as we have to do additional work instead of you.<\/li>\n<li>Any tasks related to bugs, without detailed descriptions of their occurrence and screenshots, do not give us the ability to understand what went wrong and how to replicate this bug.<\/li>\n<li>The project requires constant refinements and improvements to enhance performance and security. Therefore, the team spends part of its time on these enhancements.<\/li>\n<li>Due to the fact that we sometimes have overtime hours (urgent fixes), we have to compensate for them on other days.<\/li>\n<\/ol>\n<p>\nAs a rule, the client immediately realizes that software development isn't that simple, and mere desire is clearly insufficient.<\/p>\n<p>In general, that's it. Behind the scenes, there were numerous negotiations and initial adjustments of all processes, but as a result, everything improved. I can say that this process has become a kind of 'silver bullet' for us. New people who joined the project were able to dive into work from day one, as all processes were documented, and the documentation and architecture in the form of diagrams provided an immediate understanding of what we are all doing here. <\/p>\n<p><i>P.S. I want to clarify that we do not have a project manager on our side. There is one on the client's side. Not a technical person at all. The project is European. All communication is in English only.<\/i><\/p>\n<p>Good luck to everyone on their projects. Don't burn out and try to improve your processes.<\/p>\n<p>The source is in my <noindex><a rel=\"nofollow\" href=\"https:\/\/cleverman.org\/post\/organizaciya-rabochego-processa-v-komande-na-it-proekte\">blog<\/a><\/noindex>.<br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/524460\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443. \u041e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u0435 \u0447\u0435\u0442\u043a\u043e\u0433\u043e \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0430\u0445 \u043d\u0430 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u0445. \u0421\u0430\u043c\u043e\u0435 \u0433\u043b\u0430\u0432\u043d\u043e\u0435 \u2014 \u044d\u0442\u043e \u0442\u043e, \u0447\u0442\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u044b \u043d\u0435 \u043f\u043e\u043d\u0438\u043c\u0430\u044e\u0442, \u043a\u0430\u043a \u043d\u0443\u0436\u043d\u043e \u043a\u043e\u043c\u043c\u0443\u043d\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u043e\u043c \u0438 \u0434\u0440\u0443\u0433 \u0441 \u0434\u0440\u0443\u0433\u043e\u043c. \u041a\u0430\u043a \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u043d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u044b\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430. \u041a\u0430\u043a \u0441\u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u0432\u043e\u0439 \u0440\u0430\u0431\u043e\u0447\u0438\u0439 \u0434\u0435\u043d\u044c \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97853","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u043d\u0430 IT-\u043f\u0440\u043e\u0435\u043a\u0442\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-10-22T12:42:44+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-11-17T22:58:50+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Organizing the workflow in a team on an IT project | ProHoster","description":"Hello friends. I consistently see the same picture, especially in outsourcing.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u043d\u0430 IT-\u043f\u0440\u043e\u0435\u043a\u0442\u0435 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-22T12:42:44+00:00","article:modified_time":"2020-11-17T22:58:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97853","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:11:34","updated":"2022-10-03 07:12:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/97853","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=97853"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/97853\/revisions"}],"predecessor-version":[{"id":172897,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/97853\/revisions\/172897"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=97853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=97853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=97853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}