Macro vs micro (slideshare)

11,818 views

Published on

With today's ever advancing technologies—better tools, frameworks, libraries— software/web development is becoming increasingly faster in many regards. Yet in large companies, the processes for designing, developing and deploying software/web products remains cumbersome. To a great extent, the processes have remained the same for nearly a decade, and are very slow. On the other hand, smaller companies (startups) are able to go from inception to deployment in very little time. They are able to iterate and experiment with new features sometimes on a daily basis. Can large companies learn from small company processes, and vice versa?


Kalani Kordus and Karl Adam will juxtapose their large company (yahoo!), large team experience with their small company (smudgeproof), small team adventure. Their current design/development process—a mashup of traditional and progressive techniques—is akin to musical improvisation, Dirty Jobs and UFC cage fighting.

Published in: Design
0 Comments
21 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
11,818
On SlideShare
0
From Embeds
0
Number of Embeds
227
Actions
Shares
0
Downloads
390
Comments
0
Likes
21
Embeds 0
No embeds

No notes for slide

Macro vs micro (slideshare)

  1. Kalani Kordus Karl Adam Designer & CCO Engineer & CTO @kalkor @thekarladamInteraction Eleven • Feb 9-12, 2011 • Boulder, CO
  2. DESIGNENGINEERINGQUALITY ASSURANCE
  3. DESIGN ENGINEERINGWe will use Yahoo! Messenger foriPhone and Symposium as case studiesto juxtapose a large company (Macro) QUALITY ASSURANCEsoftware development process with our(Micro) software development process.These projects were similar in scope.Yet, we were able to design and developSymposium at a much faster rate.
  4. DESIGNENGINEERINGQUALITY ASSURANCE The Builders
  5. DESIGNENGINEERINGQUALITY ASSURANCE Each builder reports to a manager who must approve at different stages of the process. They are similar to valves in a plumbing system; regulating the flow of things. Most of management are not builders anymore because their time is spent having formal meetings with other managers and executives.
  6. PRODUCT DESIGN RESEARCHMARKETING ENGINEERING INTERACTION DESIGN VISUAL DESIGN PROTOTYPING ENGINEERING QUALITY ASSURANCE PROJECT MANAGEMENT MARKETING PRODUCTQUALITY ASSURANCE Product Managers are invited to all meetings. Marketing attends all milestone meetings; both act as additional valves to the process. Roles tend to be very specialized in large companies. In contrast, small companies are forced to wear more hats out of necessity.
  7. PROCESS DESIGN ENGINEERINGPRD Alpha Beta /Triage /Triage IDEATE ARCHITECTURE IMPLEMENT SKETCH IMPLEMENT TEST WIREFRAME TEST ANALYZE MOCKUPS ANALYZE SPECIFICATIONS = MILESTONES
  8. PROCESS ENGINEERING Beta GM Deploy /Triage /TriagePLEMENT TEST TEST TEST FIX BUGSNALYZE BEERS! = MILESTONES
  9. REALITY DESIGN ENGINEERINGPRD Alpha Beta GM Deploy /Triage /Triage /Triage IDEATE ARCHITECTURE IMPLEMENT TEST TEST SKETCH IMPLEMENT TEST FIX BUGS WIREFRAME TEST ANALYZE MOCKUPS ANALYZE SPECIFICATIONS If something goes wrong, it requires going back through this rigid process to fix it. The farther an issue goes back in the process, the more valves it has to go through again. This process is very formal, and usually involves many meetings and stakeholder/management approvals to get the flow going again.
  10. vs TRAFFIC LIGHTS ROUNDABOUTShttp://www.ted.com/talks/gary_lauder_s_new_traffic_sign_take_turns.html
  11. CONVERTPRD Alpha Beta GM Deploy /Triage /Triage /Triage CONVERT CONVERT CONVERT CONVERTPRD Alpha Beta GM Deploy /Triage /Triage /Triage This process could be improved by converting most of the traffic lights to roundabouts; metaphorically speaking. Less meetings, formalities and CONVERT interruptions. This would improve the flow, and free up management to participate again as builders. Meetings would be minimal and informal because management would once again have a deeper understanding of Managers Builders how it all works on a technical level, resulting in a faster process. RECOMMENDATION
  12. PRODUCT This role is crucial in the macro. They decide what gets built in what order, and are in charge of the overall strategy. This role is CONVERT often over staffed and confused with project management. Having too many will surely slow down the process. Much like the starship enterprise, a product has the best chance of being nimble andProduct Management One Captain insightful if there is just one captain. Like a CEO to a startup. They should curate the right team with the right dynamic, keep the ship straight and get out of the way. Product managers tend to have backgrounds in business (MBA), but amazingly do not have much –if any– experience with product design. Marty Cagan’s Inspired (How to Create Products Customers Love) explains what to look for in candidates when filling this role. RECOMMENDATION
  13. PROCESSOur process is one huge roundabout. Design and Engineering are constantly influencing eachother throughout our process. From the earliest ideation sessions, to the last line of code.
  14. Concept to Creation, and everything in between. We flow like water. A constant continuum.
  15. We begin by riffing on potential features during our initial brain dump. Over a period of time, thewhiteboard sketches start to slowly gain more fidelity. Once there is a consensus on the corefunctions, the design moves toward full fidelity with pixel perfect mockups and animatedexamples of behavior.
  16. SOFTWARE ARCHITECTUREDuring this time the app logic is built. In the case of symposium, the server side backend as well.
  17. SIGGRAPH 2010 When the final mockups are agreed upon, the front end development begins. Values (shadows, margins, sizes, text size, etc) and sliced PNGs are extracted from the PSD files.
  18. INTERACTION ELEVEN For the IxDA11 app, I (designer) was able to tweak the existing code to position items, change color values and swap images to match the IxDA11 brand. By wearing another hat, I was able to free up time for Karl (engineer) to work on more complex engineering tasks.
  19. We often start our process in a linear fashion, but quickly find ourselves bouncing back and forthbetween roles. An idea can spark a series of code tests to validate if something is possible.
  20. While conducting a competitive analysis, a marketing idea might come to mind.
  21. Minor QA issues can circulate for days –even weeks– in a macro environment, because of theirrigid formal process. If we run in to a QA issue, it is usually investigated, discussed and resolvedwithin minutes.
  22. WEAR MORE HATS FEWER FORMALITIES BE LIKE WATEREncourage adaptability by wearing more hats. Get dirty. Learn what your teammates really doby shadowing them for a day or two, or week. Meet your engineer or designer halfway; get a littlemore familiar with their tools. Teach each other.Design and engineering should be involved from day one in the ideation process. It keepsengineering informed early on of what is expected of them later on, and it informs designers oftechnological possibilities. Yet, collaboration does not mean “Design by Democracy”. Rather,allow ideas to flow through the process –linear or not– and let your opinions regulate the rate.Better software can be made faster if we have fewer formalities. Fewer captains, fewermeetings, means more work force to actually build your product. Captains, stay out of the way.
  23. Links contact us:@thekarladam info@smudgeproof.net TED (traffic stops): http://www.ted.com/talks/ gary_lauder_s_new_traffic_sign_take_turns.html@kalkor Inspired (Book): http://www.amazon.com/Inspired-Create- Products-Customers-Love/dp/0981690408 Bruce Lee Interview: http://vimeo.com/3841165Gratitude feedback for this session: http://speakerrate.com/talks/5393-macro-vs-micro

×