P92 RDI Services

Complex development services

• Agile coaches assist the work of business analysts. Moreover, in several cases there are no dedicated business analysts, but rather development teams who take part in project preparation under the watch of an agile coach. This technique has several advantages. First, it helps us find the most suitable and manageable solution for the client. Second, by increasing the developers’ involvement, they become much more motivated to see the project work succeed. Third, it drastically reduces business-developer misunderstandings. Developers who are trained this way are more sensitive to the users’ needs and demands, and they can identify ideal solutions much more effectively.
  
  A typical problem occurs when a client tries to analyze a problem “indoors”, and when they present their needs or demands they get lost in details. Most unsuccessful IT projects end in failure because the default presumption is wrong. The clients, inside their own organisation, define a demand in their own way, and then their IT crew recreates it as they see it. The IT team fail to understand their colleagues on the business side and simply describe the task as they see it. Most of the time, the requirement specification is the product of internal conflicts and interests. Whoever best defends their own interests wins, but this is not necessarily what is best for the clients.
• Another typical way to solve the problem, is to ask/delegate a consultant company to specify the tasks. Typical consultant companies operate passively, tending to say what they think the client wants to hear, because their impulse is to please. This leads to a vicious circle, and the result is an inadequate solution.
• Another typical setback is that software development companies wish to apply their own existing system to solve other company’s problems. This is why they don’t seek to understand the problems, but rather to shape them to fit their own system so that they need not change their current product. In certain cases it can be a virtue. If we improve an existing system we want to find a solution with which we can reach the goal with little development. However, it is much more important to get to know the real demands and needs rather than those that would be most convenient. The key is perceptiveness, which motivated developers guarantee. They resist the urge to force the existing product on the client, seeking instead to offer a unique solution.
  The feature that makes P92 RDI unique is the combination of sensitivity, talent, knowledge and experience that we use to understand the process, customs and inner hierarchy of the client (ie, the real hierarchy, not the organizational one), and we can recognize the real (often unspoken) needs that can cause bottlenecks, problems, difficulties, time-loss, and other setbacks to the organization.
  We often see difficult situations more clearly from the outside, because we avoid getting lost in the types of details that distract insiders, such as internal power struggles, day-to-day problems and other motivations that may be personal in nature. Although we have created many solutions, we don’t build our own products, and therefore do not feel the urge to push our own products. Instead, we seek to solve problems. We work to complete the task, and therefore it is strongly in our interest to identify and resolve the real problems, whereas consultants and product sellers avoid taking responsibility, because if the introduction is unsuccessful it reflects badly on the developer, since a consultant can say that the developer failed to understand what they had described, which is why they like to talk in riddles, and the product sellers like to refer to chaotic processes.) We are not committed to software producers or a strong third party; our solutions are customized to the needs of the client. We are not acting here out of honour, but rather out of calculated self-interest. The fewer headaches we cause ourselves, the less overhead will be generated on the project that would need to be passed on to the client or absorbed in-house.
• The user interface is the most important part of our work because this is the part that the users will contact with. It needs to be perfect, easy to use and enjoyable. If the user likes the system, the inevitable mistakes and anomalies can be solved more easily. Our dedicated creative team, UX and UI designers provide easy-to-use surfaces with cutting-edge visuals. They understand the target audience’s habits and expectations, and they are intimately familiar with market trends. Based on all these they create user-friendly and ergonomic surfaces.
• Our developers use agile methods, which require an intimate relationship with the client. The customer can track the current status of the development in real time and also see where it is heading. From a technological point of view we use the most modern techniques that have been proven effective. We use and optimize the  technologies and developer tools not in our client’s projects, but in our own R&D projects. Thus we can provide the currently most time-proven solution.
• Testing and quality assurance have accentuated importance. It’s hard not to fall into clichés, because anyone can say that they do testing. At the same time we know that this is the phase that most companies are likely to skip when a deadline is close. Members of our developer teams are mostly SRE (System Reliability Engineers). In a team like this everyone does every type of work. But also, teams like this have roles as well, certain members have their preferred roles, but everyone has to be able to change their role in any circumstances. Therefore, during a project, for a while everybody does software design, developing or devops activities. We focus our resources to where they are needed most. There is no finger-pointing, as happens in classic set-ups, where software designers blame developers that they don’t do the work the way designers planned it, devops blame testers that they don’t do the testing well, etc. In our case everyone takes responsibility for every process, so they can’t point to each other.
  
  For them, the workflow cycle starts with software design and ends with successful testing. They were trained to gain a mentality which doesn’t let them skip testing. Its biggest benefit/advantage is that the fixing of accidental mistakes will be their task anyway, so it’s better to nip it in the bud. Developer teams take part in projects as independent entities. It means maximal flexibility from almost every aspect, except for one: from the point of view of quality there is no patience or compromise. If the test fails in important levels (of course smaller differences in visualization are not included), then the QA doesn’t let the process to continue. But this type of rigidity will pay off in the long run.

We can dedicate a whole team to each project, with all key players. At the same time we have extensive experience in working in situations and environments where we provide only certain members for a team, or where our team has to “host” members from outside.

We’ve worked with partners from almost all around the world, in widespread multicultural teams, so our colleagues can handle confidently any difficulties caused by intercultural differences.

Incidental communication difficulties are helped by our internal language training program and our coaches.

We provide a complex internal training program to our colleagues to ensure their permanent professional development, it includes:

• Regular organized online and personal courses
• Constantly growing inner library
• Attendance in professional events
• Attendance in R&D projects (self-financed, EU and mixed financed), where our colleagues can learn the newest technologies.