How To Create a Web AppWritten by Matt Rogers / October 4, 2007 / 27 comments这是关于指导如何创业系列的第二篇了。虽然阅读起来似乎都是老一套的东西，没什么了不起的新发现。但是在重新阅读的过程中却发现，自己总是在执行中遇到各种纷繁干扰的时候，有时候会偏离了应该的步骤和流程以及方法，失了节奏，失了方寸，可见执行这件事情，还真不是说说这么简单的。所以再次依据这样整理清晰的指导，记录下来作为未来可能凌乱时候的参考。
本章的关键在于：
- mockup的创建
- 产品设计规范的撰写
似乎恰恰是国内的团队比较忽视的部分，或者是喜欢随行所欲成分比较多的部分。事实上，正是产品经理或者核心设计者不能转嫁给开发人员的部分。尤其是小团队的时候，很多时候甚至是ceo亲自把关这些设计才行，但是他们往往大而化之并没有真正起到应有的作用。这件事情，开始怎么重视都不过分，否则将是一系列人的重复劳动和士气大伤。
但是，如果有合适的小团队，规范之类的灵活，可能是个优势，但无论如何，好的追踪工具还是不可少的。回头结合docbook细看一下。
This is the second post in our series on how to run a startup and develop a product. In part one, How To Bootstrap Your Startup, we outlined the process of bootstrapping your company into existence. In this post, we show you how to go from idea to specified product. By the end of it, you’ll know how to build a mock-up of your business idea and write the most important document you’ll write for the company: your functional specification.
For a simple system the process outlined in this post should take you a month. For a complex build, there will be a lot more research and your mock-up and functional specification will be big - so budget 3 months of full-time work.
A Word on Strategy
Every good business begins with a solid understanding of the proposition and business plan - in short, your strategy. It's worth reading Guy Kawasaki’s 10/20/30 Rule of Powerpoint
; it’ll provide you with an idea of what should be included in your business plan and strategy. Your actual business plan should be in a lot more detail than Guy describes in his post – his rules relate only to how the results of your work should be presented, not how the content should be derived.
From Strategy to Development
Whether you are out-sourcing or developing in-house there are two ways to build a system:
- Give your developers a rough idea of what to build and keep iterating the design as they build it;
- Give your developers detailed documentation of what to build.
When out-sourcing, the second option is always cheaper, faster and lower risk. Not only that, but the end product will be better architected, more coherent and easier to maintain. Given this, it might surprise you to learn that the vast majority of out-sourced developments do option 1. Don’t do it - option 2 is more work at the start but entirely worth it. The basic premise of option 2 is simple: instead of relying on your developers to think through your business properly, you take responsibility yourself. You’ll do this in two ways - firstly by creating a mock-up and then by documenting that mock-up in a functional specification.
应该是你自己而不是依赖你的开发人员来设计详细的应用特性。
步骤：1：mockup、2详细的功能说明
Your mock-up
The first thing you need to do is get yourself tooled up is to create your mock-up. This requires a visual web-editor (assuming you’re building a web-application). Personally I use Visual Web-Developer from Microsoft - it’s free and powerful. However, it is also very complicated to use, as it’s a full web-development environment. If you don’t know how to code in C# then it is probably easier and faster to use Dreamweaver, Frontpage or the freeware KompoZer.
A mock-up is a run through of your site and the learning process you’ll go through as you create it will be exceptionally revealing. It sounds simple, but when you start to put pen to paper you’ll very quickly find that it isn’t. Your mock-up is the first stage of building a real understanding of what your system has to do. The mock-up should contain no functionality and doesn’t need the final graphic design. Its objective is to help your developers understand what information the system should capture, when it should be displayed and what it should do when the user "does stuff" on your site.
关于是不是把美工设计尽量考虑进去可能是一个见仁见智的作法。不少人除了那mockup进行开发，更重要的可能是拿它跟投资人、合作伙伴等商谈用的。这个时候，可能mockup的美观或者一个过得去的模版之类就是很重要的事情了。
To give you an idea of how it should look and feel, I’ve created a small mock-up of an email service for you to peruse. Granted it is a mock-up for a terrible email service, but it should serve the purpose of detailing what a mock-up should be. When you’re building the mock-up, remember to include an admin interface – believe it or not, it is easy to forget to include this. Make sure you think through how you will administer the system, handle customer queries, examine user accounts, run reports on user numbers and website traffic, etc.
这一点尤其应该引起广大的2.0们的注意。至少在最开始2.0风生水起的时候，太多的创业者声称自己不需要后台管理，不要监控，只要民主的2.0，可是事实上，最后大家还是都回去了。关于这一点，社会改良者们可能早已经实践过了，没有绝对的自由社区。这样的社会学的前车之鉴值得2.0们好好思考和体会
Only when you’ve completed your mock-up and been through several iterations with any other business partners, are you ready to move onto the next stage - documenting it in a functional specification
相比较而言，国内的团队习惯开始走的很快。这里的说法是，只有反复讨论过mockup之后才开始写详细的设计规范书。而国内团队更加倾向于，mockup甚至还没有全部出来，就已经开始编码。尤其是根本听不得什么对于最开始自己充满热情设计出来的东西的任何反对或者质疑？没有讨论的胸怀。但是，匆匆上马之后，面对惨淡经营，才慢慢开始学会听人家的说法和建议，可是往往内外伤都已经不少了。痛惜，前车之鉴也！
面对若干次这样的事情，总免不了生出秦灭六国，又被人所灭的悲叹。但是为什么历史总会重演？每次担任首任的那一位，难道总是要这样的强硬态度才能足以领导么？这里有着人性的天然弱点难以逾越么？还是勇于创业者往往多独揽大包的个性？
The Functional Specification
This document is the most important document that you’ll write for your business. It will tell the developer exactly what your system should do. It will contain every page you’ve created in your mock-up; and for each screenshot it’ll explain what’s happening on the screen, what the user can do from there and what the system should be doing in the background. The document is called a "functional" specification because it should describe "what" your system does, rather than "how" it should be done.
不知道有多少人会认同这里所说的产品功能说明是最为重要的一份文档。国内的团队可能习惯于把用于融资的那份商业计划书视为最重要的一份。虽然那里也会包含产品、技术方面的东西，但是实在是一个很high-level的说明和描述，最多加一个moadmap，完全不能用来和这里的细致程度相比。
The first thing you need to do is get tooled up. Write the document in Word (or an equivalent). You’ll need to include a lot of screenshots - for this I’ve always found the Firefox plug-in Pearl Crescent Page Saver invaluable, because it lets you take screenshots of a whole webpage (not just the part which is displayed). Secondly you need some software to create flow charts in. I used WizFlow before we bought Visio from Microsoft. Wizflow is easy to use and does most of the stuff you’ll need.
工欲善其事，必先利其器。个人体会，mindmanager或者freemind可能比visio更加方便。除非你需要更加专业的面向技术层面的结合，比如生成数据库设计之类等等。可事实上，如果需要完成这些，另有更加专业的工具更加方便。不知道是不是我用visio不够专业，总之，感觉viso在这里有点鸡肋。如果我片面了，希望方家指点。
When you set out to write your functional spec, you need to follow a clear structure so that your developers understand what you are saying. The structure which I always use is:
- Confidentiality notice – make it clear that this document is your property and you are serious about controlling your IP（有言在先，很重要）
- Introduction – you should describe your company, the structure of the document and a one paragraph overview of your system（公司、文档结构、关于系统的一段简短描述）
- User scenarios – Include at least 5 clearly written accounts of what a user might do on your system. These serve to ensure that everyone who ends up on the development team knows what the system is for. Write them as a chronological story.（用户场景：包含至少5个清晰的应用场景的描述。按照时间顺序，讲故事的方式给出。非常好的建议。不少团队这里的工作也不算到位。他们会有基本的想法和描述，但是没有清晰说明、没有时间衔接、没有足够数量的验证。）
- Overview of the system –five page description of what you system should do; keep it very high-level and include a system overview diagram (see below).（5页纸的很高层次的概要性描述。最关键的是，应该包含系统的结构图。）
- End-user functionality – a section for each system module (see below) in the system overview. Each section should include several sub-sections for each possible action within that module.（用户功能说明，包含每部分的模块拆解）
- Administrator functionality –section for each admin module and sub-sections for each possible action.（管理功能说明，同样包含子模块的拆解）
- Non-functional requirements – design integration, SEO, availability and uptime requirements, scalability requirements and load calculation, data validators, security and back-up and the development platform (if you have one).（非功能性要求：设计的整合、SEO、可用性、可扩展性、负载计算、数据校验、安全和备份、开发平台选择等等。事实上，这部分是设计中非常重要的一部分。太多的团队在这部分语焉不详，而后手忙脚乱，包括自己的团队在这里也是没有做足功课。这里实际上要很好的经验支撑才能完成的。不知道国外的团队上，怎么保证这部分的有效性。抑或者，就是一个机制？毕竟这里的要求可能会对底层的架构带来根本性的改变。而开始就预估一个合适的架构支撑规模，多少是比较困难的。）
Clearly in a blog post I cannot cover each of these in detail, but one element which is particularly important is your system overview diagram. Whilst the developers might not build the system in this way, it is useful for you to mentally split your system up into modules. I’ve done a simple example using the email system used in the mock-up:
In the above simple example, the four boxes are the four major sections within the "End-user functionality" section of the functional specification. Within each section you should cover, with precision, what all of the possible actions are and what the system should do in each case. From this it is easy to build out your document structure. So for "user access" we’d need a sub-section on "Create account", "Log in", "Forgot password", etc.
Start by building out the document structure. Only when that is complete should you start filling out all the details. This way, you’ll slowly build up your document without feeling overwhelmed by it. When you are writing one section, you’ll get ideas for other sections – when this happens go to the relevant section and add the thought in square brackets so that you know what to cover when you get to it. Trust me on this: only one person can author a functional specification. More than one person can review it, but only one person can author.
这里显然都是充满了经验过后才有的操作性很强的建议。
通过一个小小的标示，不断地完善过程得到一个合适的追踪；
通过提纲挈领在先，避免让自己陷入一种难以完成的绝望中从而放弃这一重要工作；
通过合作中得来的教训告诉大家：唯一的一个人来负责撰写！但是应该多人、多轮讨论和完善。这一点对于国内团队的氛围，可能会是一个至关重要的拐点。也许很多成败的关键在于这种协作的方式和流程。
A Word on AJAX
You seemingly can’t launch a new web site these days without using a few dollops of AJAX here and there. However, you can’t incorporate AJAX into your mock-up, as there’s no functionality. Where there is a functional requirement for AJAX, you’ll need to use a new page in your mock-up (the complete opposite of what AJAX gives you). Therefore you need to explicitly include your AJAX requirements in your functional spec. Personally I insert my AJAX requirements in a box, so they are clear to the developers.
用特殊的标记给出Ajax的要求，换句话说，更加重要的是这里的思路。给不同的，难于在mockup上展示的内容以不同的标记，形成自己的规范和习惯，减少沟通的成本和维护的成本。这才是核心。
Container Documents
In parallel to writing your functional spec, start the following container documents:（需要并行考虑的一揽子文档。）
- Future ideas for the development of the system;（系统的未来功能扩展。其实把它写出来，然后分期实现也是常见的做法）
- Legal points you want to make sure that are included in the terms and conditions;（相关法律条款。可能考虑的人很少。很多都是到最后匆匆加上一些用户条款之类。甚至可能没有好好考虑关于内容上纠纷的处理。）
- Any design thoughts (include here screenshots of website designs you like);（任何设计上的思路。自己的经验来看，至少应该考虑不同应用场景之下的一些系统导语和指引之类。应该属于UI和UE一类，事实上，这部分的重要性不用再强调了，大家忽视的程度也不用再重复了。白鸦好像有一篇文章专门说这个事情。一个小姑娘做整理工作和初稿之类可能还行，但是，整体基调和氛围的把握，恐怕不是一个小姑娘能够把握的。包含一些你喜欢的站点的截图也是很重要的。因为，别人可能会改版，自己可能会遗忘。以前总认为自己整理资料还比较靠谱，事实上，还是有很多需要改进的空间。）
- Patent ideas;（专利的考虑。尤其是有些特殊的想法和应用模式的时候。算法似乎在国内的环境下容易一点，但是其他，国内环境就实在有点让人摇头了。大家有什么好的建议在这里么？）
- Marketing ideas.（市场方面想法。这一点非常重要。毕竟很多市场的点子可能就出现在你设计系统的时候。往往后续设计细节多起来的时候，会慢慢遗忘掉。而且，如果建立这么一个沟通和共享的平台和文档结构，便于团队之间的沟通。往往它山之石可以攻玉。）
As you are working through your functional spec, you’ll come up with lots of ideas in all of these categories (and possible more). Make sure you’ve got simple lists you can just drop them into – get them out of your head and into the computer as fast as you can, so you maintain a clear mental space free from idea clutter.
相信任何有真实经验的人都会非常赞同这里的说法。设计的过程中会有大量的新的点子和想法不断冒出来。如何有效地记录和整理他们就是一个非常重要的问题了。不知道大家都是用什么工具解决这个问题？有的思路之间需要相互妥协，因为冲突；有的思路相互补充，因为相关；有的思路需要暂且放弃，因为整体的考虑；有的思路需要延后细化，因为周期的控制；有的思路需要讨论，因为太粗；。。。这么多的思路和未来可能真正实施的模块之间有不同的关系，如何管理和追踪呢？希望方家指教合适的工具。目前自己完全是靠脑子和简单的工作日志管理，实在还是比较落后。
Conclusion
Creating a quality functional specification is a time-consuming - but essential - job. Take your time and do a quality job. Don’t be surprised if the document ends up being hundreds of pages long. But it vastly increases your chance of delivery.
In the next post I’ll be looking at how to build a long-list of developers, run an RFI to create a developer short-list, run an RFQ to select a vendor and a spare, and then what to look out for in the development contract.
最后整理一下这里提到的工具：
- mockup的制作工具。国内的不少人缺少这个技能，难以驾驭即使是DreamWaver这样的工具或者是效率太低，又没有什么不用编码的，快捷简单的页面制作工具提供呢？
- 流程图的工具
- 截图的工具：Firefox plug-in Pearl Crescent Page Saver
- mockup展示工具：mock-up of an email service ？（我理解对了么？需要研究一下）
我想，还应该有的工具：
- 文档管理工具：比如docbook之类。（是不是最适用，我自己也还需要再验证比较，希望方家有更多好的推荐）
- 项目前期的管理工具。主要是各种思路和未来设计模块之间的关系和演变的追踪。寻找中，希望方家推荐。
- 多人协作的工具？如果是参考这里唯一作者的原则，似乎也不必要了。
标签： Anlysis, Operation, StartUp, Strategy
