This chapter is from the book
This chapter is from the book
This chapter is from the book
Generating Clarity
A marketect has among his or her primary objectives and responsibilities the generation of a sufficiently precise understanding of what the development team is charged with building so that the team can actually build it. The specific approach for achieving this varies and is heavily influenced by the structures, processes, and outcomes the total development organization has chosen in building the system.
There are a variety of source processes and materials to select from. Marketects can choose simple paper-and-pencil prototypes or more formally defined marketing requirements documents (MRDs). In response, development organizations can create models using UML, entity-relationship models, dataflow diagrams, and so forth. Communication between the teams can take place in regular meetings that formally review progress or in daily meetings that track incremental improvements.
Chief among the variables that determine appropriate structures, processes, and outcomes are the size of the team and the number of external interactions it must support. (See [Hohmann 96] for an in-depth description of these variables). Larger projects require a level of formality and detail that would suffocate smaller ones. Other variables, including team culture, are vitally important.
The marketect has similar objectives and responsibilities but for a very different audience. He must make certain the prospective client is clear on how the system will impact its environment. If the system can be extended, such as in a browser with a plug-in architecture, the API must be made available to the appropriate developers. Data sheets outline the broad requirements, while detailed deployment requirements enable customers to prepare for the introduction of the system within their idiosyncratic IT environment. Performance and scalability whitepapers are common for any software that has a server component.
Managing Cultural Differences in Software Development
In the course of my career I've managed several groups of technical and marketing personnel, including those from Russia, Germany, India, Israel, China, Japan, Korea, Poland, Canada, and Mexico. At times I've had to manage a worldwide team focused on the same deliverable.
There are, of course, several challenges in managing a worldwide development organization, and many of them are logistical. For example, it is nearly impossible to schedule a simple meeting without inconveniencing some members of the team—08:00 U.S. PST is 16:00 in Israel. Some development teams have it even harder—12-hour time differences are common in Silicon Valley. Other examples exist in creating or adopting international standards for naming conventions, coding standards, source code management systems, and so forth. Most of these logistical challenges are relatively easy to overcome given a sufficiently motivated workforce.
A bigger challenge, and one that I've found exhibits no ethnically based pattern, is the relationship that a given group of developers have to their software process. These relationships actually form a culture although not the kind we commonly associate with the word. My own bias is heavily weighted toward processes and practices promoted by the Agile Alliance (http://www.agilealliance.org). However, at times I need to subordinate my own preferences to accommodate the dominant culture of the team I'm managing. Thus, while I firmly believe that in most cases iterative/incremental development practices are most effective, sometimes waterfall models are more appropriate, not because they inherently produce a better result but because the culture of the team wants them. Marketects and tarchitects both must pay close attention to these potential cultural differences and choose approaches and processes that work for a given culture.
The marketect is critically dependent on the flow of appropriate information from the tarchitect. An unfortunate, but all too common, situation occurs when last-minute changes must be made to customer-facing documentation and sales collateral because the tarchitect realizes that they contain some grave error resulting from a misunderstanding by the marketect. Even more common is when the tarchitect sheepishly informs the marketect that some key feature won't make the release. Printed material must be created weeks and sometimes even months in advance of a product launch, salespeople must be educated on the product, existing customers must prepare for the upgrade, and so forth. The marketect is partially responsible for making certain all of these happen on time and accurately.