Customer interaction with an outsourcing company

Published on April 24, 2014

Customer interaction with an outsourcing company

Good day to all! Today I would like to talk about the ways the client interacts with an outsourcing company, and also to receive from you comments on how you interact with your clients / software developers. This article is written based on work experience and, for the most part, is intended for software customers. The goal is to find bottlenecks in the relationship between the customer and the company that offers software development services.

Client and outsourcing company

About the author.
Разрешите представиться: Я – Корхов Юрий и эта статья у меня на хабре первая. Закончил Белорусский Национальный Технический Университет (инженер по безопасности), Белорусский Государственный Университет (инвестиционный менеджер). Стаж работы — более 6 лет в IT на практически всех должностях: webmaster, верстальщик, web-дизайнер, программист, менеджер-проекта и по совместительству разработчик UI, руководитель отдела… В общей сложности, за это время, реализовано более 80 проектов: от маленьких сайтов, игр для мобильных телефонов до крупных интернет-порталов… Основной профиль — управление ходом разработки проектов в IT сфере. Работал как на стороне заказчика так и на стороне разработчика, как на Российский рынок так и на зарубежный.
Background to the creation of the post or Thanks to Wargaming.
Обойти историю создания данного поста было бы не хорошо, т.к. хабр я читаю уже очень давно, а вот написать статью руки никак не доходили, а здесь дело “случая” и вот статья готова.

Уже пару месяцев я отдыхаю от работы, потому что устал от аутсорсинга, решил найти смысл жизни и неторопливо подготовить к запуску свой проект, и в один прекрасный день раздался звонок. Рекрутер Wargaming (основатели “танчиков” и, по-моему мнению, одной из лучших фирм в Минске) позвонил мне с предложением пройти собеседование на вакансию Vendor Manager (здесь следует сказать, что работу я не искал, и, судя по их вакансии, я не очень подходил им). “Это же интересно!” — подумал я и решил выполнить тестовое задание, тем более, что оно было достаточно интересным для меня. Рекрутер сообщил, что у них созданы все условия для приятной, здоровой (фитнес, страховка и т.д) и высокооплачиваемой работы а также, что не маловажно, для выполнения тестового задания мне потребовалось бы около 3х часов. Я сомневаюсь, что у кого-то получилось бы сделать все тестовое задание в течение указанного срока, что касается меня – в общей сложности ушло около 6 часов.

К моему сожалению, feedback от компании был в телефонном разговоре и выражался сухой фразой “всё хорошо, всем понравилось” (дословно не помню, но суть такая) и без какой-то конкретики. Я сомневаюсь, что мне удалось указать все основные «узкие» места, а т.к. не хорошо пропадать труду, решил разместить ответы на тестовое задание (с небольшими изменениями, для удобства) на суд общественности и буду признателен аудитории habra за дополнения и здоровые комментарии к статье.


Interaction scheme The customer is a software developer from the first meeting to the end of the relationship.


When designing a scheme, I mean:
  1. A software developer is able to complete a project.
  2. Prior to this, the contract with the software developer was not signed and there were no projects.
  3. TK is ready.
  4. Terms of payment are governed by the contract.
  5. Project management systems and software development methodologies (XP, Scrum, Lean, Kanban, ScrumBut, etc.) are used.
  6. Filling the application content (if necessary) is done by the client.

image

It is beneficial for the vendor to avoid aspects of the contract between software development by the vendor and the customer (to simplify, generally remove from the contract).
  1. Responsibility for meeting deadlines lies with the developer and in case the deadline occurs at the last moment (i.e. the developer did not notify in advance that he does not have time before closing) penalties should be imposed (there is a large selection of options here).
    Reason: failure to meet deadlines is one of the biggest problems and mentioning this in the contract is not very interesting, because for the most part, the failure to meet the deadlines lies with the developer. Here it is necessary to take into account that it is difficult to accurately calculate, but to warn in advance that the developer does not have time to complete the development phase in a certain period of time - it is obligatory and this must be prescribed in the contract.
  2. Warranty conditions for fixing “bugs” due to the fault of the developer, which were not detected on time. The usual warranty period is 3 months.
    Reason: it often happens that some “bugs” were not fixed or appeared already in the process of work, therefore this item is often tried not to indicate or reduce the warranty time. My opinion is that fewer than 3 months are few.
  3. Rights to developed software, modules, blocks, etc. belong to the customer and cannot be used for subsequent resale.
    Reason: it is beneficial for the developer to have intellectual property rights or to be able to sell / use the best practices for other customers, which in turn can put the customer in an uncomfortable market situation.
  4. When developing a new module in a system that affects the operation of other modules or the entire system, the developer must ensure the functioning of the entire system.
    Reason: often the development of one module can harm the work of another module or the entire system, and further improvements can lie on the "shoulders" (financially) of the client. The developer must take into account the structure of the entire system and in case of “bugs” found by the client, edit for free.
  5. Technical documentation for the development should be prepared taking into account the requirements of the customer.
    Reason: it is beneficial for developers to fully tie themselves to the customer, and it often happens that documentation is not kept.
  6. In case of developing a website, the contractor must take into account SEO optimization for the site, namely: description of images, pages ...
    Reason: saving time on the “little things”, which, depending on the terms of the contract, can lead to financial losses for the customer (the software developer saves time / finance).
  7. System testing should be provided by the system designer.
    Acceptance by the customer of the finished module should not turn into system testing, i.e. the developer is obliged to undertake the elimination of the identified “bugs” by the client at his own expense. This is necessary in order to ensure quality testing of the product by the developer. By the time the developer says “done” and testing begins on the client side - “bugs” are fixed for free.
  8. The responsibility for placing the project on the customer side is assumed by the developer. At the same time, the customer is obliged to ensure compliance with the technical requirements for the site.
    Reason: placing a project on the customer side can sometimes cause certain difficulties, which can lead to cap-and-mortgage, so the responsibility for placing and setting up the server should be on the side of the software developer.
  9. If the software developer is forced to resort to the help of specialists outside his team, he is obliged to assume all the associated risks for leakage, data loss or any other damage that may be caused by an external employee through his action or inaction.
    Reason: it happens that the developer may get sick, quit, etc. any of the employees. In this case, the customer must be insured.
  10. Backup copies of the project should be provided on the side of the developer at least 1 time per day. Any problems with the loss of data on the project should be undertaken by the developer.
    Reason: here it is necessary to indicate who is responsible for the safety of the project in case of any failures.
  11. The developer should proceed from the popularity of the use of the technologies used by him when choosing.
    Reason: binding to proprietary technologies that will complicate life in the event of a customer’s transition to another developer.


Known methods of overstating the cost of outsourcing work relative to reality. I suppose there are more.
  • A superficial assessment of the cost of developing a project as a whole, without dividing into stages, which can lead to a 2–3-fold excess of the project cost.
  • Failure to provide reports on the work done within the period specified by the contract or not able to control the development process by the client
  • The wrong choice of technology when implementing the technical part can significantly increase the cost of development.
  • The lack of the necessary specialists in the development team, which increases the time and cost of development.
  • A fixed setting of the cost of developing a project or module and a further increase in the cost for each trifle, which both sides understood differently.
  • Fixed installation of the cost of project development - a higher risk forces us to lay in the cost of the project.
  • While developing the design, prototyping is not used, and the design is being developed on the basis of textual specifications, which ultimately leads to a large number of improvements / corrections and, accordingly, an increase in the cost of the project.
  • Adding / complicating the functionality. You can make it easier - make it harder.
  • “Prettiness” is where they are not needed (you can say about the admin. Part of the site, if you can use css frameworks for quick customization of the admin. Parts - they begin to develop from scratch).


The relationship pattern 'customer - software development vendor', which, in my opinion, is closest to practical use.
Many outsourcing companies prefer not to provide access to their project management systems without providing detailed information; I personally think that access should be provided at the request of the customer. The client is responsible for the implementation of the project and to see the development progress in real time - it is important!
Also, I think that developing software taking into account the calculation of the total cost of the project is a waste of money and a nerve, such development usually leads to conflict situations.
The main points in the interaction of the software developer and the client, which I consider optimal:
  1. Payment for work based on the hourly pay for the work of employees or the average cost of the work of a specialist of the entire development team. Assessment of the development stages is necessary. Why I consider this form of pricing optimal:
    • It does not require a very scrupulous approach in evaluating a project, which is almost impossible to make 100% accurate. If the assessment is made incorrectly and the software developer begins to understand this, then “infringement” of the functionality occurs wherever possible, which will ultimately affect usability.
    • Improves understanding between the software developer and the client, as the main task is reduced to the principle - “do it quickly and efficiently”, and not “invest in a tight budget and how it will work so well”.
    • The client, based on daily reports on hours spent, can see what time employees spend on different blocks during development, which gives an understanding of the speed and quality of work of software developer employees.
    • The interaction between the customer and the project manager is as direct as possible, i.e. when using skype, phones, etc.
  2. Only 2-week reports and plans should be sent without fail by mail (for control).
  3. A client provides a prototype application or is developed by a software development team, if necessary:
    • Simplifies understanding of the main functionality of the project.
    • Increases the overall speed of project development.
    • Clear requirements for the functionality of both the customer and the developer.
    • A clear understanding of where the project will move.
  4. A project management system for monitoring the progress of the project and the ability to monitor the process, development time spent on each task separately. Unfortunately, access is rarely provided by developers.
  5. It is desirable that the whole project was done by one team, i.e. It should not be such that one stage is done by one company, another - another, etc.
  6. Control points (“run”) every 2 weeks is the best time to control the project.
  7. In development, preference is given to well-known frameworks, also for easier adaptation in case of any situation when it is necessary to transfer the project to other developers.
  8. Quality testing on the developer's side is a direct responsibility. When transferring to the client the project or any part of it, everything should be checked thoroughly.
  9. To support different browsers is a direct task of the developer


relationship pattern

Conclusion : the main thing is to adhere to partnership / mutually beneficial and trusting relationships with the understanding that developers are the same people and complicating their life complicates life for yourself! Everyone should be responsible for their part of the work, the client for providing clear technical requirements and respond promptly to emerging issues, not forgetting to pay for the work, and the developer for quality, time, speed. The ideal, of course, has not been achieved, but we are on the right track.