Quality Assurance and Testing
How to build an expert nearshore mobile app development team, part 3
Nowadays, quality assurance is essential for publishing high quality apps, and with a plethora of devices on the market, it isn’t an easy task. The possibilities and challenges of testing in mobile worlds are slightly different than those in desktop/server development. So, what are the best practices for this?
Ongoing mobile testing process
With the complexity of current software, the old model of testing the software at the end of the development cycle is long gone. Testing should be done throughout the development process – for every functionality added, there should be testing (both manual and automatic) to ensure that the functionality actually works. Automatic testing is also essential to ensure that further development of the project, and changes in the project environment, don’t damage any previous functionality.
Unit testing is a classical approach to automated testing. In this approach, each code functionality is tested individually in separate unit tests. This can ensure that each code unit works when it should, and behaves as planned in the case of errors. Unit testing works particularly well when testing business logic.
However, many mobile applications are written in the ‘thin client’ way, which means that most logic is on the server side, and the application’s only role is to download data from the server and present it to the user. This is often the preferred model, because one type of business logic can be implemented on the server and used on every platform (each mobile platform, web and desktop).
However it makes unit testing slightly less useful – unit testing is not the best tool for testing UI, and there’s not much business logic to be tested. Unit testing is still useful in testing the technical aspects of UI – proper initialization, handling of screen rotation, saving user data, maintaining the correctness of data downloaded from web services, etc. – but unit testing is not an effective tool for testing the entire application from the user’s perspective.
Of course, this changes when application is built in the ‘fat client’ way – in this model, the application has its own internal data model and business logic that is partially or fully independent of that which is on a server. In this case, unit testing is essential for making sure that each use case and each code flow behaves correctly in numerous possible scenarios.
UI automation testing
UI automation testing constitutes an answer to the problems inherent in unit testing. Instead of focusing on individually testing each part of the code, it tests the application as a whole (black-box testing). Contrary to its name, it doesn’t only test UI – it tests the entire application, but from a user perspective. Instead of testing which code is executed, it tests the results of user interaction. For example it tests that results of pressing the button are as expected. This allows the entire application to be tested – both UI events, internal code for web service communication, and server-side code that responds to data. At all times, it also tests to make sure that the application doesn’t crash or execute properly.
An additional advantage of UI automation is that it is much better suited to testing device-dependent problems, such as problems with layouts, specific custom behavior on some devices that needs to be handled differently, etc. Running the same tests on different devices ensures that the application will work correctly on a wide array of devices, and may find unexpected errors that can’t be detected with unit tests.
Testing mobile application on a Device Farm
Every respectable mobile application vendor has multiple devices by which to test applications – both manually and using automated tests. This is a good foundation during the development phase for finding the most common problems and correcting them as soon as they are found. However there are so many devices on the market that this is impossible to test on-site for even a noticeable fraction of them. Android has more than 11 000 device models at the time of writing, and that number is constantly growing. Samsung alone has more than 1000 device models that are sold worldwide (including local variations for selected markets). iOS and Windows Phone have a slightly smaller number of devices, but they still come in different variations and system versions. That variety makes it unrealistic to have real market coverage of testing, when testing is only undertaken on-site. Luckily there are providers that offer device farms – remote services that allow companies to run remote tests on a large number of device models in a short time. Device farms are inexpensive, because you only pay for the time used on devices, and tests typically proceed rapidly. It saves the vendor the cost of buying hundreds of devices for testing, and also makes it possible to test the same device with different OS versions.
Device farms allow for the undertaking of most tests – unit, UI automation, and others, on multiple devices. Those tests make it possible to see detailed results, which in turn enable developers to find problems even if they only arise on a small subset of devices.
Additionally, aside from automated testing, device farms also make it possible to take screenshots of every screen in the app, which then allows for manual (human) checking to spot potential UI problems.
Beta testing and automatic crash reporting
Even a perfectly tested app may still have potential problems – new devices and versions of mobile systems arise every day and some of them change important behaviors or hardware features. So before final release, it is wise to first release the application in beta test mode. The app may be available to everyone, but the reviews and scores from the beta test are removed when the full version is released. Using the framework for automatic crash reporting, every time an application crashes on the user’s device, developers get a detailed report including which devices it was on, what version of OS, and when the application crashed. Due to this, it is possible to fix all the potential problems that weren’t spotted before going public, and allows for the release of a “final” version that is bug-free.
Automated crash reporting is essential even after full release – this mechanism makes it possible to fully monitor the market and spot potential problems even before users report them. For example, if the new OS version makes the app crash, developers receive instant reports of such events and are able to quickly pinpoint the reason and fix it.
Quality Assurance and Testing summary
Testing is essential for the ongoing quality assurance process, and should be done throughout the development process, not just before releasing the application. Combining unit testing and UI automation testing allows for a sufficiently acceptable initial release, while beta testing each version and monitoring crash reports throughout allows developers to make sure the application works well throughout its lifecycle.
Agile Process & Team Setup
How to build an expert nearshore mobile app development team, part 2
The Agile process of development is the preferred way of developing mobile apps. With Agile, we use the so-called sprint – it’s a set period of time during which specific work has to be completed and made ready for review. The length of the sprint is fixed and chosen at the start of the project – for example 2 weeks. Then, at the beginning of each sprint, we set goals – what we want to implement and function – and, after the sprint, that part is ready. After the sprint we can evaluate the current state of our product, and can redefine priorities or even the design of the application. Each sprint is designed to have relatively small, but fully working functionality added or modified. Thus we make use of Agile methodology to maintain the flexibility to make changes after each sprint. There is freedom for the client to make changes during the development to react to the market, user opinions or changing business priorities. Changes can be made at the beginning of the sprint (planning phase), but not during the sprint itself (development phase).
The above description is true for all software development, but is particularly important in the mobile world. Current distribution platforms (App Store, Google Play, and Windows Marketplace) make it very easy to publish an early version of the product, and even easier to update it often without any effort from the end user. This, along with the agile development flow, allows clients to publish the app early, see user reviews and reactions, and iterate functionality with each sprint, publish new versions and get feedback from the real market. Feedback from real usage makes it possible to set priorities that benefit users the most, and to alter the original vision so as to make the most attractive product. Agile, along with the frequent publish model, makes it faster to iterate toward a polished, functional product.
Product owner in the Agile development model
The product owner represents requirements in terms of software development. The client should select a single person for this role, who will be the main contact responsible for providing a vision of the product from the client’s side, for cooperating with the team which will transform this vision into the product design process, and then for implementing this design. The product owner is not responsible for the technical details of implementation (unless the client so desires), but is responsible for understanding target audiences and desired functionalities, answering questions about projects, and the ongoing process of selecting the priorities for the next sprint. The product owner doesn’t need to have programming experience, but it’s good if he has some understanding of the market, knowledge of similar solutions and possibilities, as well as a basic level of technical knowledge. The product owner should have enough time to be available for communication with the development team throughout the process.
Scrum development team
The Scrum team is responsible for executing the product owner’s vision and requirements. This team creates the technical architecture for the application, implements it, and tests it. The Scrum team is in constant communication with the product owner during development. At the beginning of the sprint, the product owner is responsible for selecting the most important tasks to implement, and the team is responsible for estimating how many of those tasks they are able to do within the confines of this sprint. They consult on the details of requirements with the team owner throughout the sprint process, and the results of their work is tested, then submitted for review at the end of each sprint.
Depending on the cooperation model, the entire team (except the product owner) can be from the service provider, or composed from among both the client’s and service provider’s specialists.
Setting up the team can be done after defining the requirements and scope of the project, as well as defining the expected deadlines for project development. The typical composition of such a team is as follows:
-> Native development
Team leader/Scrum master – responsible for managing the team, tasks, and overseeing development
iOS/Android/Windows Phone developer(s) – at least one developer for each platform, responsible for the implementation of mobile apps
Server developer(s) – responsible for integrating existing data sources or creating new ones
Testers – responsible for testing the app, finding and reporting quality issues
-> Cross-platform development
Team leader/Scrum master – responsible for managing the team, tasks, and overseeing development
Front-End HTML/JS developer(s) – responsible for the implementation of the mobile app for all platforms
Server developer(s) – responsible for integrating existing data sources or creating new ones
Testers – responsible for testing the app, finding and reporting quality issues
The exact size of the team depends on the scope and complexity of the application, as well as deadlines, and should be determined after consultation with the service provider.
Setting the requirements and the final team are important when starting a project. After that, the next step is to set the testing strategy, which we will dive into in the next article.
Setting the Requirements for an Expert Nearshore Mobile App Development Team
How to build an expert nearshore mobile app development team, Part 1
The mobile app development market has exploded in recent years, but it still takes careful effort to create and manage a perfect team to accomplish your business goals. ‘Mobile development’ can encompass a wide range of products: from a 1.5” smartwatch screen, to smartphones, tablets, cars, up to 100” smart TVs. Whatever you want to develop your app for major smartphone platforms like iPhone and Android smartphones, or to use the mobile market to its fullest, it all starts with business requirements.
Client needs and requirements
The first part of the process is always to define the needs and goals of mobile development. Those requirements have a variety of details – some clients can define exactly what system they want and can create a detailed specification of their expectations. Other clients only have more general business goals. That’s ok – there are appropriate models of cooperation for each of these cases.
The process of creating and updating project requirements is often split between the client and service provider. If you have a detailed requirements and want to directly control your development team – use the team extension model and use the provider’s developers as your own team. If you have requirements, but want to make use of the experience of the service providers to improve and refine them – use a development outsource model to have the analysis, design and project development done by the service provider. If you only have business goals – use the project outsource/managed service model, in which the service provider will take over the entire process – starting with designing a business model and proposal for your project(s), refining it, implementing it, and continuously supporting and further expanding it over time.
Read more about cooperation models.
To start defining the project requirements, we need to answer a few questions. The first one is about platforms – does the client want to release the app for iOS, Android, Windows Phone? Depending on goals, you can pick all of the above, if you want to have almost 100% market coverage, or only some of them to save on expenses. Every platform is different, and each one requires a slightly different approach to designing certain features. This is specific to the mobile world – projects typically have exactly the same requirements, but the resulting apps are slightly different on each platform. They are customized to the UI standard of each platform, tailored to services offered by each platform owner, and designed to be familiar to the target audience of each system. Those differences lead to the biggest question in mobile projects: Native or cross-platform development?
Cross-platform development makes it possible to create apps for every platform in one go, so typically it’s less expensive and requires smaller teams. But this technology often creates problems relating to implementing features, performance, stability and quality. It works great for apps for which the primary requirement is to present the user with information; but features like GPS, camera, advanced use of maps, layered animations etc. can be problematic.
Native development allows the team to achieve everything that is possible on each platform, offer the highest quality and level of performance, as well as perfect customization for the UI and design patterns of each platform. Native means that each platform has its own team of developers (at least one per platform), so there are more developers and the cost is higher, but it yields the best results.
Your service provider should always help to decide between cross-platform and native, because this impacts both technical implementation and limitations, team setup, and the budget.
If you only need the app for one platform – for example you are making an application for internal use in your company, and you only use iOS – always choose native, because there won’t be any difference in cost, but the quality will be higher.
Mobile apps are rarely stand-alone. Usually the data in the application is downloaded from the Internet – by means of a mechanism called API or webservice.
The client may already have some system and database which can be integrated with mobile apps. Alternatively, the service provider can design a web-based CMS (Content Management System) that makes it possible to easily edit mobile app content in the web-browser.
Defining app logic and functionality
After setting the baseline requirements and deciding on the external webservice, it’s time to define the core of the application – features, UX and UI. Depending on the cooperation model, this can mostly be done by the client, or the client can just define the business goals and the overall idea, and the service provider can design the exact features, UX and UI.
These are the typical phases of app design:
1. Functional specification – defining what should be in the application – which features are essential and which are optional. ‘Target audiences and devices should be kept in mind throughout the process..
2. Interactive mockup/wireframe – this stage defines UX and the overall layout and screens of the application. At this stage, the UX designer focuses on designing screens, transitions, and placing UI elements like buttons, images and text etc. However this stage doesn’t include the final look – only the layout. Preparing this stage allows the client to click through the prototype, and see how the application presents data, whether it is sufficiently intuitive etc. Making changes at this stage is far less expensive than making them after the application has been finished. Therefore, iterating the design and gathering feedback from potential users is essential.
3. Graphics – when the mockup is accepted, the next stage is to design final graphics for the designed mockup. This defines the final look of the application.
Having functional specification, the mockup and graphics concludes the requirement-setting phase. The next step is to define the team required for the project and the process of development, including quality assurance and testing. We will describe all this in the following articles. So stay tuned!
Formalising IT Contract Details
Knowing the rules of how to play chess does not make you a world-class chess player.
Working on the Client’s initial request
There are many types of requests that the software Vendor receives from the Client. Some of them actually provide little context, whereas other ones are context-rich messages. Depending on the prospect’s input (materials, requirements, business knowledge, etc.), we are able to prepare our initial feedback.
Here is an example of a context-rich enquiry:
I am the VP Technology at …
We are looking for ways to expand our development capacity and I have been tasked with identifying near-shore and offshore opportunities to outsource development. I look forward to opening a line of communication to discuss this further.
I look forward to hearing from you to discuss the requirements and our potential business relationship in more detail.
On the other hand, a low-context enquiry example is as follows:
We are an established medium-sized Internet business, operating for x years in the y industry.
We wish to rewrite our website using the latest Z technologies to make it more stable and flexible, as well as to add new functionality.
We are looking to outsource this, in part, to a team of nearshore developers who can work with us using the SCRUM methodology. This would involve rewriting all layers of the application (the core solution to use as a starting point has already been created), using the following technologies:
.NET, C#, MVC, some AngularJS, Entity Framework, Identity 2.0, HTML5, CSS3, bootstrap.
Let me stop for a while and focus on the crucial word: Feedback.
Feedback can have several dimensions. Let us focus on just two of them for now.
First: Feedback as an immediate reaction to what has been submitted to the software Vendor. It is not about what is our answer to the Client’s initial request. It is about showing our potential partner that we take care and are ready to talk about the idea – that we are committed and supportive.
Second: Feedback as a relevant info based on the Client’s request, which includes all the necessary info /the so-called: material pack/.
Third: Hybrid – as a combination of First & Second.
I am not here to judge which of the presented types of feedback is better and more effective. I am trying to make you aware that both of them are important and, in most cases, Hybrid (the third one) should be a kind of habit when approaching the Client’s initial enquiry.
We all know that first impression is crucial (and it does not matter if it is fast or slow). But what is more important (based on my observation I have made over the past years when approaching Clients with the JCommerce team) – is what happens next: When all the dust of the first contact has settled, all that matters is the quality of feedback, the quality of communication during the initial phase, the understanding of the Client’s needs, and being responsive and supportive.
How can we influence the quality of initial feedback?
Let me present you some practical tips below when approaching the first contact with the Client:
1. Arrange a direct follow-up call (Lync, Skype, Google Hangouts, etc.) with your potential partner.
2. When sending your calendar invite, please include a high-level agenda (this is a good moment to specify what you expect and what is missing).
Examples of high-level agenda:
– Introduction round (who is who)
– Overview of the Client’s organisation (business history, services, etc.)
– The Client’s expectations and current needs
– The Vendor’s overview
– Discuss the Vendor’s technical capabilities and references
– Discuss software development approaches
– Discuss the Vendor’s Human Capital Capabilities
– Discuss the Business Model and the Ramp-Up Phase
– Plan the next steps (a direct meeting, a formal arrangement, etc.)
3. During the first video call with your prospect, listen carefully and make relevant notes (it is highly recommended to use Microsoft OneNote when using a Lync connection), as you will be able to send all of the notes and the agreed further plan of working together right after your call. One of great habits is to make notes in real time – and show them on the conference panel screen to your Partner – this definitely builds trust and keeps your communication at a very professional level!
4. Right after the initial call, send a note to all of the participants (include roles and plans for the next steps).
5. Based on the agreed steps forward – keep your promises (deadlines, materials you promised to send, etc.)
Formalising the collaboration – Contract & Procedures
If we are lucky 🙂 and we have managed to convince our potential Client to go ahead with us, the next big challenge is to formalise the collaboration – before we finally start to work on the software project together. And because this is not as simple as it may seem, let me share with you some practical insights into how we, at JCommerce, handle this process smoothly.
As reaching a formal agreement between the parties should not be a long and exhausting process, I would like to present here a high-level concept of a contract proposal that I think is clear and efficient when formalising the co-operation between two entities.
For the purpose of this paragraph, I have focused exclusively on a contract template for outsourcing, when the Client decides to build a dedicated software project team in the Team Extension Model. I have consciously omitted standard paragraphs in the contract template, such as: Parties, Confidentiality, IP, etc. My main goal is to outline and focus on things that matter the most to Clients approaching outsourcing Vendors, especially when forming an initial co-operation flow and setting up the procedures.
1. Defining the development approach (team extension, development outsourcing, project outsourcing, etc., as well as the methodology of working, e.g. SCRUM)
2. Explaining the pricing model (Time & Material, Fixed, Hybrid)
The Developer’s full name, experience level and rates (hourly, daily, weekly, etc.) – all in
Alert! It is very important to explain what the all-in rate of a developer includes:
– A company notebook (including necessary software licenses),
– A Lync-compatible headset,
– Usage of the Vendor’s office facilities, including meeting rooms and an Internet connection,
3. Defining the resource allocation (we all should define in advance the scale of utilisation of a developer engaged in the Client’s project)
4. A detailed explanation of the seniority level
Alert! It is extremely important to explain what we mean by, e.g. Senior .NET Developer, Professional .NET developer, etc.
5. Alternatives when replacing developers (defining the warming-up phase, shadow resources, etc.)
6. The period during which the rates are ‘frozen’.
Alert! Most of the companies forget about the fact that the rates are valid for a certain period only. It is good to define the from – to duration when a given development rate is valid and it does not change.
7. The issue of the exchange rate index.
Alert! Nowadays, a lot of vendor companies have issues with fluctuations of the exchange rate index. For that reason, when presenting the hourly rate to your Client, try to think on what basis you have calculated it, i.e. if you offer your British Client a rate of GBP 30 excl. VAT per development hour of your employee, then you should always refer to the value of your local currency index (in my case it is Polish Zloty), which keeps your business healthy. There are several solutions to help both parties weather the fluctuations of the exchange rate index. At JCommerce, we develop a very simple Excel formula that allows both parties to adjust the hourly rates (in a critical situation). I will be more than happy to share this solution with you in a separate, private email.
8. Additional costs of working on-site in the Client’s country
Alert! When the development is done in the Client’s country by an Employee of the Vendor, additional costs are involved, such as:
– Daily allowance.
It is also important to define the on-site rate level as well as who will bear the on-site costs of development.
9. Notice Period
Alert! At this point, most of the vendor companies forget to specify what happens when the Client is in need of swapping/adding a new developer to work for them. It is crucial to outline this period in the contract as well.
10. The Client’s Employee Regulations
Alert! It is so important to introduce the Client’s standards and expectations among the development team that the Client is provided with by the Vendor. It could be something like:
– A standardised email domain,
– A dedicated footer,
– Presenting the Vendor’s developers to a third party,
Apart from that, there are also internal policies on the part of the Client, which the Employees of the Vendor should respect. It is important to set them forth in the form of a separate appendix to the contract and let the Vendor’s team read it carefully.
11. Evaluation & Rewarding (bonus) system
Alert! Some of the companies looking for long-term partnerships in the software outsourcing field define some kind of a rewarding system in co-operation with the Vendor’s management team in order to better control and motivate the quality of performance and overall commitment on the part of each employee of the Vendor.
This is one of the solutions owing to which [we can really influence the overall quality of the co-operation.]
For that reason, when signing a contract with the Client, JCommerce and the Client usually define the current team structure and performance as well as its future state. The parameters that help us to reward and analyse the Vendor’s team are presented below:
– Work quality (software/coding/documentation)
– Reporting accuracy (timesheet submitted on time, cases logged correctly, etc.)
– Communication skills (proactivity, taking initiatives, the quality of English, etc.)
– Productivity (meeting deadlines, expectations)
– Absences & being punctual (sick days, sliding hours commitment, etc.
– Telework Policy
Alert! It is important to include telework policy in the contract (which, besides, is not respected in many kinds of project engagement). But this is a part of the efforts necessary to achieve an optimum balance between the business interests on the one hand and the individual interests of the employee on the other.
Some of the practical arrangements in this area include:
– The request for telework must be made at least 2 working days in advance via email sent to the Team Leader
– Telework is limited to, e.g. 1 day a week
– The employee should be available online (MS Lync, Skype, Google Hangouts, etc.)
In my next post, I will try to share and break down the teams (Client vs Vendor) and roles (Client vs Vendor) during the first few weeks of collaboration (the most important weeks!) with international teams across different cultures. I will try to show you the mechanism, tools and practice that may help the Vendor and the Client gain better control over what is happening in the delivery process. More to follow soon!
Made In Poland – a Synonym of Quality Not Only in Germany
Let me use the example of my last visit at our western neighbour’s.
On 17-18 October 2013, the Polish-German Chamber of Industry and Commerce (AHK) in cooperation with the Chamber of Commerce of Upper Bavaria (IHK) invited the Polish IT companies to a bilateral meeting with representatives of IT industry from Bavaria.
The aim of the meeting was to introduce opportunities of cooperation to Polish software companies, explore the potential of this market and establish contacts that may someday turn into a business partnership.
Each time whether it was during the tour around the Smart Mobile Labs (innovative mobile applications laboratory in Munich), an BMW plant or directly during conversation with companies such as REC Global, I realized how much we contributed, we Polish people, to the IT culture of the European market, in this particular case in Germany.
During the second day in the capital of Bavaria the brief presentations of Polish IT representatives, also JCommerce, took place. I had a “five-minute” exposé to present the range of services and expertise of JCommerce (I mentioned the expansion of nearshoring, development of our Microsoft, .NET, JAVA, and Business Intelligence departments, methodologies of design: Agile, Scrum, and partnership with companies such as QlikTech and Microsoft). Of course, I did not neglect to mention the important value, which is the result of the work of our local IT professionals, that is the Quality of software development! I was surprised, when the moderator of the conference said after my presentation: “Here in Germany, we are convinced of the high quality of Polish IT services. Here, You are well-known for that, and you do not have to prove anything to Europe … “
Finally I want to say few words. If we are witnessing the changing the generational stereotype of “Polish drunk and thief” to “Polish IT specialists and Polish software quality” it means that we have reached the point where we have a national treasure of which we are known and respected in the world and certainly at our neighbour’s (which has been shown even this year by CeBIT and the Polish role in the project).
Nearshoring IT cooperation with German Client
Find out what our Client said about us 🙂 Recommendation of implemented project.
We run project, which name was Fineo Framework. Fineo is an OpenSource Framework, that provides a cloud based generic security platform, offering security services at various levels such as data, communication & user level.
IT Business is Like a Champions League Tournamen
What does the above paragraph have to do with IT business?
Let me try to prove my hypothesis- Doing IT business is like participating a Champions League tournament… by providing a thesis in the example below:
Since the beginning of this year (January 2012) we have been focusing to prepare ourselves for participating in the biggest Mobile Conference in Europe called Apps World 2012.
As an IT Company we deciding to join the most influential event in Europe related to mobile industry, where top market leaders from all over the world included: developers, mobile marketers, mobile operators, device manufacturers, platform owners and industry professionals are meeting in one place, once per year: at Earls Court 2 in London!
I personally believe that there are a lot of common factors when a football club is preparing for the Champions League tournament and IT Company is preparing for attending the most crucial event in the IT industry.
If you ever watch a football team interview before the Champions League game, you can always hear the following words showing up in the statements:
Prestige, confrontation, positioning, knowledge & experience exchange, bitter defeat, mobilization, strategy, challenges, harnessing our own stereotypes, fight, and many more…
It means that we, people are not so far away from each other, no matter what the industry, social status or any other differentiating factor is.
While attending the Apps World 2012, we felt that we are there rather small (with services offering, scale of product influence), when comparing with brands like: Google, Apple, Facebook, Samsung, etc. but on other hand, we had chance to make live interaction with them, try to see what their good and weak sides are, how they are preparing their business model and long term strategy. But even if you stand in front of your competitor acting as Dawid meeting Goliath, and your chances to win anything seem very low, there is a glimmer of hope. Because all the pressure is put on your “enemy” you do not feel any prejudice and paradoxically you can win even more than you might have expected before.
We spent some very busy time during those 2 days of exhibiting at Earls Court 2 in London (See some selected pictures below). We met a lot of interesting people (hundreds of business cards exchanged), had some nice brainstorm discussions with business owners and also shared our knowledge and industry approach with workshop attenders on panel discussion: “In-House app building versus working with vendors, and pre-packaged solutions”. We gained a lot of fresh inspiration how to handle security (in the development process) and how to monetize the mobile applications. We also had a chance to review and focus on our core mobile and web based solutions. We were being asked about dedicated solutions, resources availability and technology focus.
We were surprised when, at the first day of exhibition, we saw two project leaders from our current Belgian Client (this year we developed together top sports applications such as: Tour de France, Olympic Games or Gouden11).
They decided to attend Apps World event to get an industry update and meet us there as a partner to share their experience with prospects visiting our stand (#65) and explain to them the near-shore cooperation model (focusing on team extension mode).
The idea of entitling my blog post: “Doing IT business is like participating a Champions League tournament…” has its beginnings in watching a Champions League game: Arsenal London – Olympiakos Pireus (on the Emirates Stadium in London). We have been invited by our Belgian Client to go out for a match on Wednesday evening (just after the 2nd day of exhibition), 3th of October and integrate with each other watching an incredible football performance LIVE!
Doing IT business is really similar to the Champions League tournament. If you focus on the top things, you head to get the top Clients, top projects and top IT knowledge. But it also goes in the same direction with the local league. If your ambition and carrie goal is to win only the local league, you will become what you deserve, like in the Ben Howard’s song “The Fear”.
And the last important conclusion:
If you would like to join the Champions League tournament and win the main award later on, please remember that your whole team needs to put their hearts in the desire to fight for IT; doing IT alone will be useless…
Is it Possible to Manage Partnership with External Vendor?
Be our business partner!
Procedures commonly used by IT companies create a situation in which the client, having agreed to system requirements, loses control over development for months. Consequently, the client’s expectations are not always met.
To eliminate this problem we implemented a methodology where the client provides regular insight into the work progress at every stage of developing the application. We build a working relationship, which is based on trust and partnership.
Both sides can gain additional value from cyclic meetings, during which we listen to as many comments as possible and solve the emerging problems together. Responding to changes faster enables us to save valuable time, which can be later devoted to testing the application. In turn, a larger number of tests results in a higher quality product.
Partnering with software development experts is an effective way to build the software capabilities required by our clients. We work with one idea in our mind – When you work with a team you trust, they become a valuable extension of your in-house team.
Successful outsourced software developed by JCommerce
At the end of November 2011 we started cooperation with one of the largest companies in the media industry. De Persgroep, a leading bi-national organization with more than 3000 employees in Belgium and the Netherlands. They concentrate their business on newspapers, magazines and new media, with a yearly turnover of almost 1 billion euros.
Our cooperation is based on relationship in nearshore software development area (focusing on JAVA & mobile development: Android, iPad, iPhone).
First of all, we had to know each other. To start effectively, we set up an initial project which delivers us information with whom we work and what collaboration possibilities we have. We started with development of an android application for one of the Persgroep’s sites.
Each step of cooperation brings us closer to success
I Initial project – It had fixed functional scope, objectives had been defined in details and reached by us by the beginning of December 2011. Before the beginning of the New Year 2012, the Client had contacted us for the project kick-off.
II Building dedicated development team- We collaborated in the process of recruitment and the composition of the team. At that time De Persgroep formalized the cooperation model with a contract agreement. We started to develop the solution at beginning of February 2012.
III Continuation of development. Current status of cooperation– WE ARE A TEAM.
Currently, we are working with two dedicated teams, simultaneously carrying out the existing sports projects (“Olympic Games in London 2012”, “Tour de France” and “Euro2012”) as well as “Gouden11” which is a fantasy league game.
We are JCommerce. We also have a booth at the event (Stand #65), so do not hesitate to talk with us about our services & solutions.
‘2 in 1’
Last month we were invited for 2 important meetings that took place in 2 different countries (Germany & Belgium) and we had only 1 day to handle it.
We decided to travel by car directly to Düsseldorf from our HQ location in Katowice on Wednesday (25th of July). We arrived smoothly in the early evening hours in the city center of Düsseldorf. Because our first meeting had been arranged for the next day (Thursday), we had some time on Wednesday night to go out and taste delicious Italian pizza (which we love). Later on, we went for a leisurely walk around Düsseldorf.
The very morning on Thursday I was woken up by my colleague who had just came back from his short run around the city. I was really impressed by his discipline to get up so early. We ate a pleasing breakfast, packed our stuff, and left our hotel room, heading for the first meeting.
For those who are about to visit Düsseldorf we suggest going round the city center when travelling by car – or trying to use the public transport, in other case you will get stuck in traffic (there are really big construction sites and road improvements).
Shortly after that we left to Gent – our second meeting destination.
After a few hours of travelling we finally arrived at our Client’s HQ in Gent. We went directly to a conference room where our Client had planned to discuss with us the evaluation of a-few-weeks close cooperation. This Client signed a cooperation contract regarding software development services in the Microsoft technologies at the end of June 2012. We are currently having 6 developers full time engaged in the development process – therefore the meeting was strictly connected to the way of managing the team, communication lines and reporting. Moreover, the project engagement forecast for this, and the next year was determined. After few hours of discussing the way we would like to continue the cooperation, we were invited for a dinner.
The Client took us with his car to the oldest restaurant located in the Gent city center. We have to admit that not only the place impressed us, but the food as well.
We had a great time as during the dinner we discussed not only business cases, but also topics related to our private life, like: hobbies, holiday plans, etc. We could feel like we had known each other for a longer time.
After a very pleasant evening we went for a short walk around the city center of Gent. We stayed overnight in Gent and in the morning hours on Friday, 27th of July we left to Poland. It was one intense but also very important trip where we combined business with pleasure. In the upcoming days we will provide you with a short description of our last trip to the UK (which won’t be less interesting).
Smart board helps to increase efficiency of the company
To increase productivity, efficiency and quality of the meetings, we decided to install a collaboration solution from SmartTech.
SmartTech is the market leader in digital whiteboards and the first choice of Microsoft. SmartTech company defines itself as an innovative and improving the way the world works and learns. Have a look at a short promote video:
The company has implemented SMART Board interactive whiteboard systems, SMART Meeting Pro software, SMART Bridgit conferencing software and SMART USB speakers.
Below you will find the details of what we installed at our conference room:
– NEC U310W Ultra Short Throw Projector
– SMARTboard X885 + Meeting Pro
Team members and customers can write notes over any application or web page then save them in PDF or PPT files. Moreover, they can mark up files in common applications like Microsoft Word, Excel, PowerPoint, Visio and OneNote as well as AutoCAD and Adobe Acrobat Pro. After that, they are able to save notes in the original documents. Marked-up pages, revised documents, diagrams, notes and comments can all be captured easily and e-mailed directly to all meeting participants.
This solution enables users to improve the communication and make an interactive meeting almost a real one. The conference room is equipped with five cameras which follow the participants’ voice so that the remote interlocutor can easily follow the conversation (image + voice).
Since we installed the Smart board we use it on a daily basis for our internal and remote project meetings. Presenting new ideas, analyzing problems and finding a creative solution became much easier and faster. In order to do that we design for example:
– architecture diagrams
– network diagrams
– database schemas
– UI wireframes
Our Customers told us that the interactive whiteboards helped them to break down any barriers to explore new ideas so that they felt more actively involved in the meetings. Satisfaction of Customers and better cooperation adding the understanding of their needs is what runs us.