Building the team (part2)

In part 1, I reviewed “the critical skills that team members should have in order to succeed at a jPOS-based project.” To recap briefly, Alejandro said those were (in loose order of importance): O-O Programming; Java; Open Systems Projects; Hibernate; and jPOS itself.  [I added general SQL knowledge to the list.]

Now, the fact of the matter is, in a real-life project not every team member is going to meet the hurdle of this ‘ideal’ profile.  But you can still construct a very effective team.  Here are some thoughts on a good team based on some recent experiences.

1. There’s no getting around the fact that you need at least one lead developer that possesses all those talents (from my original list).  In fact, I’d go one step further and state that this person needs to have some additional skills in the kitbag: first, they ought to know about Online Transaction Processing (‘OLTP’ – inherently different from and more challenging than batch coding) and (optimally) they should have previous experience with payment systems (a.k.a., ‘financial switches’).  The litmus test on that last item is: is this person familiar with the ISO8583 standard?  If so, that’s your leader.  This person needs to do (or, head up) the implementation of the project’s core OLTP aspects.
2. Now, you might have a second person (or group) that comes close talent-wise, but is a bit junior to the person described in item 1 above.  Perhaps they possess many of the original skill list items, but are less experienced in OLTP or are brand-new to the payment systems world.  These people can be very effective by helping on the batch aspects of the project.  Don’t underestimate your offline needs.  Yeah, it’s sexy and cool to work on the OLTP stuff, but you’re not going to rollout until you’ve successfully built extract (settlement) files, created reports for key user constituencies, and built access/status screens for operations.  Don’t leave these tasks until the end of the project.  Get this part of the team working in conjunction with the team members from point #1.  In our projects, we make OLTP implementation decisions every day that have some type of impact on batch processing.  In an ideal world, you’ve got these two efforts going side-by-side.  The side benefit is that Team #2 learns a bit more about OLTP and Payment Systems every day the joint efforts go on.
3. Unlike legacy payment systems, jPOS is SQL-based.  As you saw in my previous post, I feel very strongly that having generic SQL knowledge is invaluable in these projects (I tacked the skill onto the end of Alejandro’s critical skill list).   I mention ‘generic’ here.  What I mean by that adjective is that this person doesn’t need to be an administrator.  [You must have access to a DBA to do the project and maintain performance levels, but not as a full-time project member.  See more thoughts on DBAs here.  The DBA is your best friend on a jPOS project.]  Instead, what I mean is that you need a full-time project team member who is comfortable devising, implementing and performing SQL-based tasks (in the DB of choice, e.g., MS SQL Server, MySQL etc.).  This person can be invaluable resource.  They can set up specific test conditions, allow iterative testing of new or changed functionality, assist in priming and maintaining production databases, and – most importantly (in my book) – allow Teams 1 and 2 (from above) to focus on the coding implementation.  That defines a nice ‘point of intersection’ where the coders produce the incremental schema additions/changes (out of Hibernate) and it’s up to Person #3 here to implement the schema and populate it.
4. [Now, we go out a bit from the core technical circle of the project...]  Next, you need someone to write specifications.  This is a critically important role.  [And this isn't simply because I write the specs on our projects.]  Here’s why: when you get these specs from organizations like FDR, AMEX, Discover (etc.), you quickly see that they need to be all things to all people.  They’ve got every possible type of option and implementation ‘mode’ defined.  Most times, maybe 20% (or less) of that content will apply to you.  It’s not fair to leave it to the coders to weed through the other 80% to figure out what’s ‘in play.’  My goal in these jPOS projects is that I always that I produce and provide a spec that eliminates any need for the technical team members to refer to the original source spec.  If they’re having to look through doc from AMEX to figure out an unclear point regarding the implementation, then my spec isn’t good enough.   These specs should synthesize all aspects of the project and leave nothing to guessing.
5. You also want to have someone in charge of communicating to third-parties.  Especially on these big projects where you’re building interfaces to three or more external organizations (not uncommon if you’re putting in Debit/EBT, Credit and one or more Stored Value links), the communication alone can roll down the hill like a growing snowball.  It’s important that a team member be designated to handle that communication and protect the others from ad-hoc and random communication attempts. 
6. You also need one or more testers.  I’m referring here to testers that are engaged before you have the users take a whack at it.  Typically, projects like this run pretty tight on manpower basis, so you often don’t have the luxury of a separate test team.  I know we typically don’t, so the spec writers (the people who really know the expected results the best) and the Third-Party communication person (from my points #5 and #6 above) may need to pull double-duty here.
7. One last point is about telecommunications, which typically manifests itself when you’re setting up connections to the third-parties (e.g., an online interface to First Data).  Now, the good part of this point is that with the standardization of everything onto TCP/IP (thank god), a full-time comm expert on your team isn’t a prerequisite.  [NOTE: if someone suggests anything but TCP/IP for connectivity, push back like a madman.  I'm serious.]  Of course, there’s a bad part, too: telecommunications has become increasingly complex due to security concerns and the overwhelming digitization of (and connecting to) everything.  So, like the DBA, you need to have someone (or a group) in the enterprise that you can call at a moment’s notice to ask the inevitable question: Why can’t we connect?