[经验随笔]其实可以做的更好（一）

 上线了，使用了，虽然bug不断但是好评也偶尔能出现，就这样我的第一个产品在酝酿了一年多以后变成了成果。如今第二个产品已进入了测试阶段，似乎一起都变得顺利很多，轻松很多，可是总结前后两次的经验我想说其实还可以做的更好。

 

从需求调研说起：

两个项目的需求来源截然不同，一个是痛苦地维护了将近一年的苟延残喘的烂系统，一个是经多人手做了两版却仍然没有弄清楚用户究竟想要的是啥的系统。

 

对于第一个项目，当时的功能的局限性可以说早已烂熟于心，但究竟一个好的系统究竟能好到什么地步，能提供什么功能没有太多的经验，但总算征求多人意见，借鉴类似系统and充分发挥个人想象，整合成了一个完整的有XXX特色的系统形象，一经发布视乎前景还很诱人。

 

第二个项目在需求调研上是“值得庆幸的”，在经历了前两个版本系统的不知所云后，boss终于忍不住发话了：做成和***and***功能一样的东东就可以了。omg，很简单就把需求搞定了？错啦，不做不知道，看似明确的模糊概念有更多歧义更多猜测，这和需求的明确性要求恰恰相悖。多次整理->确认->整理....循环后，总算敲定。

 

需求文档的编写要尽量详细、精确、无歧义，覆盖所有需要的功能点。往往认为大家都公认的功能点如果不明确描述就是出问题最多的地方。还有，编写需求文档的时候能够联想到设计最好。

 

产品设计阶段：

易用性需要设计的一致性和概念上的完整性，因此产品的设计需要有绝对权威的负责人做一致性和完整性保证。

感谢项目经理闲哥在两个项目中给我的足够空间，信任和支持我的异想天开，容忍我对他和他兄弟们的吹毛求疵，整个过程进行的非常愉快和顺利。

 

事后证实，这一切还远不够，不是设计完了就可以顺利进行了，暴露的问题还很多：

1. 设计不够详尽，以致到后来很多功能点的实现在设计文档里无从查找。是的，我们不是在写书，但虽然设计文档达到100多页，但如果能达到200多页或许以后的工作更顺利。

2. 交流不力，本来设计文档已经是浓缩型的了，加上没有完全贯彻设计概念到相关的研发人员，很多歧义就这样产生了。这个问题我设计的那一块儿更加突出，一直以为经过反复的讨论后把设计文档交给实现人员他会按原先设想的去实现，或则不明白的地方会过来问个明白。事实证明我的乐观铸就了一个大错误，实现人员以他理解的认为正确的方式实现了，结果和“设计”的相差遥远。

 

项目管理阶段：

第一个项目里简直可以用焦头烂额来形容：

一方面作为项目管理者，我极力用公平公正的态度制定、评定项目的进度；另一方面作为系统核心部分的实现着，我却有代表着被监督者，尽量追赶个人进度以确保整体进度。承受着双重压力，失眠在那段时间成了家常便饭。

索性第二个项目完全不去做实现工作，只做项目管理，但效果是否并不比上个项目好，或许是太安逸了就产生了惰性。

 

做好项目管理以下几点很重要：

1. 制定合理的项目进度，这个需要有经验的人员和对实现者的工作效率足够了解才能制定合理的进度。目前公司的现状是老板限制了整个项目时间，我们只能在这个时间框框里玩耍，实在不行只好削足适履，将次要功能放到二期、三期，也算是一种折中吧。

2. 实时进度了解，这个很重要，比较好的经验是周例会，实现人员相互通报当期的进度和遇到的麻烦。

3. 项目进度推辞的决策: 最近才知道加入往往是最错误的选择，加人后的培训、沟通、交接浪费的时间往往只会使项目更退后，幸亏公司里人手紧缺没有犯这样才错误，呵呵

 

 

今天就到这里吧，睡觉。