La Fondation Linux clarifie l'utilisation du code Open Source

Edition du 12/08/2010 - par Jean Elyan avec IDG NS

Un programme rassemblant outils et formation est mis en place par la Fondation Linux en réponse à la montée en flèche du code Open Source dans les équipements mobiles et l'électronique grand public. Une initiative dont les entreprises devraient également tirer profit.

La Fondation Linux a décidé de venir en aide aux entreprises qui hésitent à utiliser du code Open Source dans leurs propres produits, du fait notamment des questions de propriété intellectuelle. L'organisation à but non lucratif a annoncé à l'occasion de LinuxCon (Boston, 10-12 août) un programme d'assistance pratiquement gratuit qui comprend une grille de contrôle, des programmes de formation et des outils logiciels pour surveiller l'utilisation qui est faite des logiciels Open Source.

Lire la suite...

L’Afrique : Nouvel eden pour la délocalisation informatique

Une étude réalisée par AT Kearney montre que 7 pays africains figurent parmi les 50 meilleures destinations mondiales pour la délocalisation des services informatiques, également appelée offshoring. Égypte, Tunisie, Maroc et Sénégal sont parmi les destinations privilégiées par les entreprises occidentales.

Voir la suite...

Outsourcing: Quelques vérifications avant de s’y mettre…

Partie 3/3:

Paperwork AKA Contracts, Specs, Documents, and Milestones

Paperwork is usually the least thrilling part of development, but usually also the most critical. Well-documented work is the only concrete thing everyone can rely on to get the job done right.

There are four main components at play here, all of them equally relevant:

• Most contractual considerations are taken care of by the lawyers, but it is important to be aware of these items.
  
  
  For example, make sure Non-Disclosure Agreements are in-place; define who has the final say in whether an asset delivered meets the requirements of the work; what happens when one side fails to meet their obligations; what are the terms of payment, and so on.

• The work specification, generally provided by the developer, is the blueprint, recipe, and wish-list for the assets to be provided. The depth and clarity of the Spec are the primary resources for the outsourcer; write a quick and sloppy Spec, and you'll almost certainly get the same result back.
  
  
  Descriptions, annotations, and examples will be a boon for the person on the other end implementing your Spec. Don't assume the outsourcer "knows" a certain model has a polygon budget of X, because it's to be implemented in Area Y. Quantify whenever possible.

• Documentation, in this case, primarily falls into the arena of asset tracking. Spec delivered? Check. First Pass asset delivered? Check. First Pass Feedback delivered to Outsourcer? Check. And so on. This document should be organic, and shared by developer and outsourcer, in order to provide total transparency. Any red flags are then obvious to both parties.

• Developers live and die by milestones, so it is important to set up a milestone delivery schedule that works well for both parties. The developer almost certainly is already working off of a pre-existing milestone schedule, so integrating the outsourcing into that schedule, and by extension, the development pipeline, is paramount.
  
  
  A code/asset drop from an outsourcer two days before a developer milestone is due just won't work. Provide ample, and realistic, time to integrate assets into the game, especially for the first for the first few deliverables from the outsourcer.

The devil is in the details. With all of the above, there are still a staggering number of minor items that will come up. Manage expectations, prepare documentation, foster good communications, and frequently revisit your assumptions. Nothing ever goes as planned, including the plans themselves.

Outsourcing: Quelques vérifications avant de s’y mettre…

Partie 2/3:

Communications: Geography and Work Considerations

These two topics are closely intertwined, and will largely define how the developer and outsource group work together on a day-to-day basis. As the outsource group is augmenting the developer, the best idea is to have the outsourcer deliver resources in a manner that benefits the developer's production pipeline. Beyond that, how the two teams collaborate will make a world of difference.

The following are items to be mindful of in this regard:

• Where will the actual outsource work be performed? Onsite is optimal, but rare, and often expensive even if it possible. Be aware that even if you are lucky enough to secure outsource workers on-site, unless the development team is on-board with the new group, problems can and will arise.
  
  Several times I've worked on projects in which we've moved heaven and earth to get them working at the developer, usually at great cost and inconvenience to all involved, only to later find the dev team largely ignoring them.
  
  Sometimes it's overt, like when the outsource team was forced to work in an unheated conference room in winter. Other times it's more subtle, like the dev team that kept "forgetting" on a daily basis to inform the outsourcers that dinner had arrived during a crunch when all hands were on deck 16+ hours day at the dev studio.
  
  If the team cannot work onsite, see if you can arrange to have the outsourcers on-site for a week or two. This will enable the outsourcers have a "boot camp", if you will, into the processes, pipelines, and personnel that the studio utilizes. At the very least, once everyone has had a chance to put names with faces, it helps communications by orders of magnitude to not see people in either group as just an email address or voice on a conference call.

• If offsite, what is the time zone difference? The farther apart developer and outsourcer are, the more difficult real-time communications become. On the flip side however, if the developer is literally half a world away, the resultant lag can be beneficial, as it provides a 12-hour buffer in which to review the assets; it provides a chance to review the deliverables with more breathing room.

• How will the two groups talk with each other? Does the developer have a point person to coordinate and disseminate the assets internally, as well as supply relevant information and feedback to the developer (best case), or will assets delivered to the already over-worked lead(s) (worst case)?
  
  One project I worked with had an inordinate number of outsourcers required, including on-site, individual contractors as well as over 10 different outsource groups, across all disciplines, working offsite. In the end, it required one dedicated person at the developer, plus several additional people on the publishing side to coordinate and arrange all of the paperwork to process.
  
  It was a herculean task, and one that could have been mitigated with better planning on both sides, as well as a clear understanding from both parties on approval process to greenlight the overall outsource plan.
  
  Furthermore, with so many outsource groups located in India, Russia, and China these days, determine that there is a sufficient quantity of speakers of the desired language (generally English) so that queries and information can be exchanged at a peer-to-peer level for mundane daily issues. Of course, this assumes both groups are comfortable with non-critical conversations occurring outside of the main communication chain.

• Aside from assets and documentation between teams, there needs to be regular conversations via conference call, IM, and if possible, video conferencing. It might seem like a hassle to have the whole team assembled for an hour to answer some questions from the outsourcer, but 30 minutes on the phone is better than exchanging and forwarding a day's worth of emails explaining the same issues. Make this meeting mandatory for all concerned.

• Once the developer and outsourcer have gotten familiar with working with each other, and one cycle of asset delivery has occurred, it is a good idea to sit down with both sides and figure out what worked, and what did not. Identifying and correcting problems or hiccups now is much better than waiting until the project is over to do a post-mortem.
  
  One developer had a fairly good system of tracking each asset in its various stages of completion, which was shared with the outsource team. However, the outsourcers regarded the early stages of work as being more a guidance than a requirement, so when they submitted assets which the outsource team considered to be fairly far along, the assets were rejected because the outsourcers had strayed off-target on the deliverable, as they made some key assumptions that were not in line with what the developer expected.
  
  The original intent of the tracking document was to allow the developer to course correct the outsourcers' work product course in more discrete chunks along the way, and theoretically prevent deliverable expectations to snowball wildly off target. A mid-sprint post-mortem revealed that the developer did not really emphasize the importance of the tracking document, and that the outsourcer failed to see its relevance or importance, and just regarded it as one more piece of paper.

• Don't let the tail wag the dog. Time and again, developers get exasperated with an outsourcer because they begin to think, after answering a blizzard of questions, that it would be quicker and easier if they just did the work themselves. It's a common trap, and oftentimes seems quicker, but it's really only a short-term solution.
  
  Granted, outsourcers may often require a fair amount on bandwidth from the dev team during ramp-up, but if you've done your homework, and have the right team and processes in place, chances are that in two weeks time you'll find that percentage of time you spent hand-holding outsourcers is greatly reduced.

Your first round of due diligence should involve looking at the portfolio of work as well as the state and composition of the outsource studio. This includes:

• Past titles they've worked on. Do these types of games closely match your game?

• Types of work they've done on these titles. Almost every outsource shop nowadays has a specialization, so merely getting an "art" outsource may not meet your particular needs. Don't get level artists if you need concept work.

• Quality of the work, and time it will take the outsource group to create it. Create a sample spec document that is representative of the work you need performed. Monitor how long it takes for them to finish the sample and the quality of work. This should provide a ballpark baseline of the quality/tempo of their output.

• The financial state of the outsource organization. Are they agreeing to all terms and conditions because they are on monetary life-support, or because they are just acquiesce to everything because they are so darn accommodating? The last thing you need is to discover the outsourcer closed its doors midway through their task, leaving you high and dry, and in a worse predicament than before.

• The personnel the outsourcer will task to work on your project. It may be great if the company provided stellar assets for a AAA title that sold 5 million units, but if you're getting a different team within the company which had nothing to do with said smash hit, it doesn't help your needs. Make sure any contract you have with this team (see below) identifies by name key personnel who will be involved for the duration of the project.

• Related to the personnel point, above, be aware that many outsource groups utilize subcontractors as well.

• Reputation and word of mouth. Have you worked with this group before or know anyone else who has? Odds are, in this small industry, you can ascertain whether or nor not this outsource group will mesh well with your team, just from experiences you or others have had with them.

• Make sure you sit down with the development team and ascertain what exactly they need. Poll the leads and let them tell you what will work best for them, and make sure they have had the opportunity to vet and approve the outsourcers. Make sure the developer owns the decision to use a particular team. A shotgun marriage just won't work.

• Once you have a decent grasp of all of these points, create an outsource plan that delineates all of the above. Identify all of the pertinent stakeholders, ascertain their needs and areas of interest, and what they require for these needs to be met.
  
  This includes not just the developer and production team, but also those persons who will also be involved, such as Legal and Finance. Clearly show the total cost, payment terms, work product, and schedule for completion. Set concrete time limits for submission of assets, feedback on the assets from the dev team, the named person responsible for supplying feedback and approval, and approval times.
  
  As an example, one developer required that the art lead provide all feedback on assets. Unfortunately, there were no limits on how long the art lead had to provide feedback, and as a result it required constant prodding by several people to get the necessary feedback from the lead. In turn, this wasted precious time on basic housekeeping task that should have been a no-brainer.

• The most important item to remember harks back to 1975, when Frederick Brooks wrote The Mythical Man-Month. In essence, the book shows that adding people to complete a task does not always realize efficiencies of time, as tasks often have to happen in sequence, not in parallel.
  
  The frequently used example to demonstrate this theory is that if it takes one woman nine months to have a baby, then it should take nine women one month to have the same baby. Clearly, this is absurd. In practical terms, it just means that adding more people to complete a task, if the production pipeline calls for one person, usually a discipline lead, as the gatekeeper to moving the process forward, will fail. The lead becomes overwhelmed, no matter how many people are aiding in the work output.

Outsourcing: Quelques vérifications avant de s’y mettre…

Partie 1/3 :

[Working with outsourcers is a vital part of much game development these days, but it's easy to get off track, and this article from a former development director for 2K Games delves into methods to increase reliability and foster communication.]

In game development, whenever a title encounters a problem that will impact the game negatively, the oft-heard, knee-jerk response/solution is "can we outsource?" Outsourcing resources, whether it is personnel or assets, can provide a relatively painless answer that keeps your title on track.

Almost every developer these days employs outsourcers to one degree or another. But outsourcing is not a silver bullet solution in every instance. There are many factors to consider when examining the outsourcers for your project, and whether bringing in external contractors to augment your team is the best way to bring a successful result to your game. This article will discuss best practices for bringing in an outside group to aid the development during full production.

Before getting started, it is extremely important to get off on the right foot and make the sure the development team has total buy-in with regard to the need for the outsource team's involvement.

Some teams welcome outsourcing, some outright will say no, and some will say yes and then proceed to passive-aggressively foot-drag and sabotage all work being done by the outsourcing team.

Often, it is the publisher that will first suggest employing outsourcers, and many developers regard advice from publishers on development matters with an eye-roll.

Therefore it is incumbent on both sides of the publisher/developer table to come to an agreement that employing an outsource group is the best solution to the issue at hand, and then communicate this up and down the chain within the respective organizations.

In this case, you have to lead the horse to water AND make it drink -- if it is the best, most efficient way to solve a problem.

Due Diligence

Performing adequate due diligence is an obvious, yet frequently ignored, critical first step. In the rush to provide a solution, developers will grab any available group with bodies and availability and throw them at the problem.

While this may make the people upstairs happy because you are "doing something", it is fraught with danger. A more thorough process that allows you to kick the tires of your potential outsourcers will save you time and headaches in the long run, guaranteed.