在不断的看书，敲代码，看视频，敲代码学习过程之后，终于接手了一个B/S的项目。项目小组一共五人，组长是个有经验的老手。项目仅仅进行了一小部分，就发现单单依靠从课本上学到死知识，是做不好项目的。
想要项目有个好的开始，不仅要有很好的技术基础支持，下面的几点也是必不可少的。
及其细致的需求分析：
有人会认为做需求太浪费时间，但是好的需求分析却是整个项目的重中之重，是所有后续工作的保障。如果消耗大量人力，物力做出的软件，不能满足客户的需要，卖不出去，那所有的投入都付之东流了。如果不能详细全面的理解用户需求的话，也很难得到用户的认可。
在考虑功能的同时也要考虑系统在面对客户各种非法，合法操作，与各种各样的突发情况，是否仍然能够经受住考验，因为你是很难要求所有的用户都像你一样是个用电脑的高手，也不能保证用户使用的环境也像开发的环境那么稳定。
一切都要文档化：
很多人在项目中并不喜欢写文档，原因很简单，文档里面的废话太多，大概有八成的文档是没用的。而在一个团队里面，文档是作为交流最重要的工具与途径，除非你永远独立进行软件开发，否则你就必须要写。不仅要写，而且从需求、设计、实现、编码、测试的一系列过程。我们需要的是“准确记录”。因为文档不是为你自己写的，也只是为你现在的团队写的。我相信没有哪一个维护人员希望看到维护的系统，只有代码和注释。
而且，文字的表达能力是有限的，你不可能用于现实生活中的软件完全能由一堆冰冷的文字全部提现出来。图形化的文档是最能体现出软件的特性的。像UML，就是我们很好的工具。
做好你的版本控制：
《程序员修炼之道》中有的一句话："即使你的团队只有你一个人，你的项目只需一周的时间；即使那是'用过就扔'的原型；即使你的工作并非源码；确保每样东西都处在源码控制之下--文档、电话号码表、给供应商的备忘录、makefile、构建与发布流程、烧制CD 的shell 脚本--每样东西。"
版本控制在空间上可以保证完成集中统一管理，解决一致性和冗余问题。避免了我们出现代码或文档的混乱。现在我们项目中使用是一款VisualSVN的软件，还不错，这里像大家推荐一下。
清晰的功能块划分：
项目在能满足用户需求的前提下，如果没有很好的用户体验，在竞争激励的IT界，也是很难站得住脚的。在项目的界面设计阶段，将功能更好的分类，可以使用户能够以最快速度找到所需要的功能。举一个最平常的例子：谷歌，凭借及其简洁的界面，赢得了众多用户。但是其功能之强大，这个就不用多说了。所有功能块的划分相当合理，每一个页面功能清晰，页面与页面之间耦合性都极小。
由于原来只是做过C/S 的项目，结果把很多的功能都揉进了一个界面，组长审核的时候，结果就是所有的界面重做，原因很简单，复杂的界面，用户是没有耐心去研究的。
最后愿我们的顺利的如期完成。