Lots of software development companies do not like outsourcing, while others hate the very idea of having a development office offshore. Truth to be told, they have fair reasons to claim that you can’t achieve much with outsourcing that has its pros and cons. Managing a development office remotely isn’t an easy task. Major difficulties include lack of communication, time zone differences, peculiarities of national mentalities, motivation of employees etc. There are lots of difficulties, but there are obvious advantages - considerable cost savings, increased productivity and decreased product development cycle. Using the right tools, services and processes, managing a nearshore team is a breeze.
No specs - no features
One of the most common mistakes project and product managers tend to make is insufficient documentation of features, requirement and processes. Online discussions are OK, but it is very important to have all processes and communications properly documented in the internal company wiki.
Confluence offers a pretty standard set of features typical of ordinary text editors. Yet, the power of confluence is a collaborative mode. It is possible to create spaces like Processes, Communications, Product Specifications. If you want to have a new product feature or improvement, make sure it has detailed specs. The more details, the better. Developers are creative people, and they can come up with some interesting features and solutions without specs. However, if you want to get exactly what you need, write up specs in a corporate Wiki, comment on specifications, invite other users to join discussions.
Atlassian Confluence is incredibly popular among software companies, including those based in the US and having development offices in the Eastern Europe. It offers a series of tools to create tables, diagrams, charts and other graphic objects.
No issues - no work
Every software development process is doomed to deal with bugs. It is inevitable. Bugs are to be located, documented and fixed. Atlassian Jira is among the most popular bug trackers with a convenient interface, project and issue grouping options, comments to issues, and an understood logic of issue life cycle. It does not matter what you want to to - fix a bug, assign a task or improve something - register a Jira issue and your initiatives will never be lost. Skype communications can only clarify issues. However, the rule of the thumb is - if there is no issue, the bug never existed.
An issue life cycle is easy to understand - issue is created, assigned to a team lead, team lead assigns a developer to deal with it, comments are published to discuss tech aspects, once the bug is fixed the issue is validated by the PM and then closed. In such a chain, it is hardly possible to lose some important info or the entire issue itself. Moreover, developers can log in to issues and estimate time they need to fix bugs. This helps in planning for PM and of course, budgeting.
Jira has lots of helpful extensions and additional services like GreenHopper or Kanban (part of Greenhopper) which are manifestation of Agile approach in software development, i.e. step by step iterations.
With Kanban managers and developers can drag issues from and to several categories that are perfectly and clearly visualized: to do, in development, done, to review, to validate and what not. So, you have 100 issues for a current sprint and it is difficult to get one whole picture of what’s done and what is to be completed. Kanban offers such a picture.
Jira pricing is quite flexible and can meet requirements of both small development companies and huge dev teams.
Looking forward is the only way for a software company to succeed. Yet, looking backwards might help analyze own mistakes and imperfections. When a sprint has ended (a sprint is a period of time for which a certain amount of tasks is planned), ask team leaders to think of what has been achieved and what failed. Ask them why. This is not about finding the ones to blame. This is about bettering internal processes. Often, PMs change specs on the go, which makes it difficult for developers to follow up. Sometimes, goals of the sprint are not achieved because dev leaders have inadequately evaluated timing, or planned features turned out to be bigger than expected. You are sure to get some interesting information after such retrospective meetings. Another way to share this info is to use the abovementioned Confluence.
With that being said, even the best designed processes can fail because of difference in mentalities. Eastern Europe differs from the US, Europe or Asia. Russia and Ukraine have given the world tons of talented programmers. Yet, sometimes, the US managers cannot understand Ukrainian or Russian devs, who, despite their talent, might ignore certain requirements. So, what should be taken into account?
Most important things to focus on when managing an offshore development office are: