分类： 项目管理

雷军的互联网七字决，一直铭记在心，＂专注、极致、口碑、快＂，很多大拿也一再强调创业初期，不能分散精力，必须集中精力把一件事情做好。同样知道，创业公司，必须快速试错，而所谓试错，一层意思是试到认为错了，马上掉头；另一层意思，是需要尝试不同的方向、方法。这里存在一个问题，试错与专注会否有冲突？

5个月以来，我们做了好几个项目：
– Pinterest小工具：EasyNip，最终发现是个非常小众的需求，放弃了
– Instagram客户端Padgram，这个我们投入最大，最近开始有所起色
– 图片浏览小工具PicQuotes，专注于Quotes（国内可以认为是名人名言）的浏览
– 微博方面，我们做了一些客户分析和娱乐小app

以＂试错＂之名，我们做了很多尝试，一度每个项目上只放了1~2个人，大家都很辛苦，但一些问题也随之而来：
– 兵力分散，没有集中，产品无法做到极致，现在的移动网，竞争如此激烈，没有做到极致的产品绝无机会！
– 8个人分散在几个产品，缺乏分享和交流，团队缺乏士气，没有文化氛围，大家对创业、对产品的理解停留在执行层面，进步缓慢
– 因为精力分散，对某个方向，没有经过详细分析就进入了，做到后来发现空间不大而进退两难，无端的消耗了宝贵的资源

这样做下去，只会更累，却不会有任何成果，每个方向看起来都大有可为，这是非常危险的诱惑（每个方向当然大有可为，不然别人何以成功？！）

做到极致 = 极致的体验 + 极致的用户支持 + 极致的市场推广
另外，就是要快！

我们需要收缩战线，全部的人只做一个项目，Padgram将是我们的今年的重心，唯一的重心。

在人手极其缺乏的条件下，去年我带过了两个项目，但毕竟team太年轻，内部效率还是挺低的。所以我最近想的最多的是，如何才能提升team的战斗力，如何才能更优雅的完成任务，可是要推广自己的想法真的是件任重道远的事情，过分强调结果，让我有点累

所思非我所应思，我所想的，已经超出了Developer leader的范畴，也许QA和整个Mobile的方向真的不是我要操太多心的，做好自己分内的事情看起来更合理

几天前跟道道讨论side project的问题，去年与willie参与的项目已经以失败告终了，那种分心在多个开发项目的感觉让我感觉好累，道道建议我去兼职讲课或者写书（或者翻译），听起来也完全是可以考虑的方向。刚刚回到博客，竟然发现自己的思考水平已经大大下滑，于是准备加强一下：

• 我们的Mobile产品线，以及开发过程中的一些体会
• Mobile开发技术，Windows Mobile、Symbian、Android，还是有很多值得写的
• 接下来要在组内力推的TDD实践
• 碰到的一些有趣的Mobile平台问题

嗯，接下来，show time…

自从上次跟东大微软俱乐部接触过以后，就没有更新blog，原因好复杂。
今天要总结的是质量管理中的管理者问题，用克劳士比的话说，就是管理者的认知和态度。书翻译得很烂，而且老外写书经常扯了好大一个圈，最后只为了向你说明一个其实很简单的问题，克劳士比用了好大一个篇幅，似乎只在告诉我，对于质量管理，领导者光说支持是不够的，必须有由上而下的行动。最高领导必须有自己的行动。因为质量免费，是非常有诱惑力的境界，光作出指导性的意见是完全不够的。管理者不希望下属说“我不知道怎么办”、“这个方法行不通”，他们希望自己的下属给出自己的意见，但不是每个下属都能做到管理者所想，管理者必须做出示范。比如装配电视机的时候，为什么有些工人总是把油漆弄损了呢？是不是他们故意要这样？NO！这一问题出现的实质，一是供货商有问题，二是装配间没有给工人足够的装配空间。这些问题，为什么从销售部门发现了问题，生产部门却迟迟没有纠正过来？从装配一线的直接主管，到各层次管理人员，为什么他们无动于衷？
这里的解决方案，就是高层主管要重视这样的问题，并且亲身做出示范，纠正这样的问题，做示范还不够，因为这样会造成事必躬亲的后果，最理想的解决方案，就是亲身示范后，高层主管要灌输一种主动发现问题的习惯，并对这种习惯进行制度化的激励。这样才能从根本上解决问题，并在体制上保证这样的问题在以后也能得到解决。
总而言之，管理者的实践，不仅仅要解决的当下的问题，更重要的是，通过这些实践，要能够防止类似问题发生，要能够促使员工去主动发现问题，未雨绸缪，把问题尽早发现，这样才能做到真正的质量免费。
对于这一点，Trend是做得非常好的，Trend的Change文化，就是促使大家不断去发现问题，去思考如何做才能更好、更省钱。以前在学校做项目，总是觉得甲方变得快，来了Trend，发现Trend变得更快，经常有计划周全的项目被cancel掉或被拿到其他site去做，产品的feature集随着项目进展，增加或者减少都是正常情况。这些情况如果在Dian团队，也许大家都会觉得很恐慌，但在Trend，大家都已经习惯，并随时思考着，如何才能做更快更好的change。
这是Trend生命力之所在，她的骨子里，她的文化里，已经植入了能够促使她主动更新、主动发现问题的元素。所以，我相信Trend会成为一个伟大的公司。

总而言之，文化之优劣就在于，我们要解决的不仅仅是当下的问题，而是植入一种能够促使组织主动发现并解决类似问题的元素。这一点回到Dian团队的规范化年，就不难理解我为什么会在上篇文章中表达了自己对团队现状的忧虑。过去刘老师事必躬亲太多，现在开始讲体质化，但体制化会不会限制大家的创造力和积极性？体制如何制定，是需要认真思考，需要实践出真知的，匆忙之间在一年之内搞标准化，也许能够解决当下的问题，但能保证启发式的解决未来的问题吗？我表示担忧。

经验是很重要的东西，在规范形成之前，我们都是凭经验做事情。我们都在经历着“尝试”→“经验”→“规范”的过程。在Dian团队时期，我所写的《组长必读》，就是一种经验的总结，很高兴团队有人觉得它还不够详细，还需要上升到“规范”。这真是一件很值得去做的事情。

同样，在质量管理领域（当然，这绝不仅限于质量管理领域，在过去的Dian团队，这种事情一再发生了很多次），在规范制定出来之前，很多事情的推动都依靠质量管理专业人员的已有经验、个人魅力和说服技巧。如果人们敬仰或者喜欢这位管理人员（比如我们敬爱的刘老师，^_^），这件事情就会执行下去，这件事情的结果显示了该做法的正确性，但并不一定能够保证管理人员能够维系这种良好态势，更无法使管理人员的管理理念和管理技巧得到继承和发扬。最终，非常努力而且勤恳的管理人员成功的工作，并不能为自己和自己的团队产生更多机会，从而使得管理人员深感挫折（多少次顿呼“我不在，团队就要跨了”的刘老师，就是这样的管理者）。

克劳士比的伟大之处，就在于把经验性的质量管理经验，上升到规范阶段，而且这个规范不是死的规则，而是一个可以不断循环改进的规范，这个规范不仅为质量管理人员指明了方向，而且给了大家自由发挥完善的空间，从而使得质量管理成为一个有趣的过程。

克劳士比的质量管理成熟度方格分为5个阶段：不确定期→觉醒期→启蒙期→智慧期→确定期，我想，在这里把各个时期的表现形式列出来，是没有意义的，等到哪天真正从事质量管理工作的时候，我会去参阅这本书的。

这里，我想针对Dian团队做一个案例分析。过去的Dian团队在很长时间内都是一个典型的处于“不确定期”的组织。表现形式如下：“…，那就是无法解决的问题到处都有。每一个问题都被视为是独特的，即使以前曾经碰到过类似问题。问题滋生问题，而缺少一套可以公开改正这些问题的方法，从而造成了更多问题，进而在管理层造成情绪问题。大家的问题如今变成对人而非对事，造成困难重重，个性变成解决问题的最主要因素。这种情形有时会造成不合理的开除和辞职，因为大家已经无法有系统地研究状况和解决问题”。“知道他们有问题但却不知道为什么；虽然他们知道这不是由于他们工作得不够卖力，可是大多数人对于需要如此巨大的人力物力才能维持运转这点，感到十分沮丧”。

现在的Dian团队处于不确定期向觉醒期转型过程中，标准化年是个机会，但我很担心大家到底怎么理解标准化，千万别为了标准而标准，千万别因为标准而限制了自己的创造力和灵活性，毕竟，我们不是企业。

    犹豫了很久，最终还是把这个贴子公布出来，非常不成熟的想法，^_^    

    DA板卡项目结束这么久，产品还迟迟没有出来，不得不说，我们错过了时机。
    正所谓攘外必须安内，如果我是嘉铭老总，我首先会反思公司内部的问题：调试的问题、芯片采购的问题、产品化监管的问题。尤其是产品化监管的问题，DA板卡项目结题以来，一直没有一个专门的实权人物专门负责产品化，导致进度不紧不慢，芯片购买也几度出现问题。我们是不是没有把正确的人放在正确的位置上？我们的员工素质是否能够胜任高速、高精度板卡的要求？我们的生产线（比如：芯片购买、设备使用）是不是要做些调整？一个产品从它的研发到最后大规模产品化，需要走一段很长的路，在这条路上，需要的不仅仅是乙方研发人员的投入，更需要公司的技术人员、焊接工人、采购人员的通力配合，尤其是技术人员，要增强他们的素质，一定要有人懂设计原理，要有人看得懂代码，要保证一定的解决技术问题的能力，要清楚地理解现有技术的优点和缺点。并且，要在公司体制上体现产品研发、产品试制和产品化三者的联系和区别，要对产品的这三个阶段进行明确的定义，并且保证相应的人员配置，制定严格的时间点，安排专人进行监管，一个强大的公司，必须要有强大的体制作为保证，嘉铭公司以前没有遇到过迫切的产品化需求，在产品化的人员和注意力投入上还有欠缺，一人多职现象，很容易催生责任不明、时间投入不够、进度拖沓等问题。
    其次，我会反思整个产品战略。DA板卡结题后，为什么不能马上产品化？是不是与上层软件没有做出来有关？上层软件做完以后，为什么要等灰度图像项目做完以后才把产品化提上很高的优先级？既然当初的定位就是控制灯泵浦，那6月份上层软件做出来以后，就应该可以产品化了。再把时间提前一点，2004年12月份做完中间层以后，到2005年12月份DA板卡结题这段时间内，我们做了什么呢？为什么没有考虑利用这段时间完成上层软件呢？所以，以后做每个项目，都要好好的整理产品战略，到底这个项目要放在哪个点？如何最大程度上节约时间？如何避免做完软件等硬件，做完硬件又等软件的情况。以前我们津津乐道的是我们将一个项目分成若干个小项目完成，这样的确有利于项目的监管，但这样必然会出现各个项目之间的接口、时序、磨合的问题；昨天张总说一次性签一个2年的项目，将软件和硬件全部来一次重构，这很可能造成项目监管不力、进度把握不足，过长的开发周期，也可能导致设计方案的过时、无法跟随市场变化等现象，影响项目的质量。这就又走向了另一个极端。我觉得，将一个大系统划分成几个子项目是正确的选择，但必须有一个统筹的安排，必须控制好时序，什么时候可以出产品，这个产品将具备哪些特性等问题应该好好考虑。这种规划，至少要考虑到2年以后的事情。Dian团队已经积累了很多经验和教训，在振镜控制系统开发领域已经入门了，应该及时的利用好Dian团队老队员，协同嘉铭有经验的研发、市场人员（尤其是市场人员），把双方近几年的产品开发时序做一个规划。这样就既可以保证单个项目成功，又可以保证项目平滑衔接，及时产品化。
    最后，如果我是嘉铭老总，我会大力支持上层软件重构计划，但更会把注意力放在高速灰度图像打标、飞行打标、彩色打标等技术上，因为这些技术是重要而且紧急的事情，而上层软件重构是重要，但不太紧急的事情。这些技术的实现，将有利于上层软件重构，因为这些技术可能引入的新特性、新设计要求可以减少上层软件重构的风险和难度。当然，目前最重要最紧急的事情，就是DA板卡的产品化。

    还有一些不成熟的建议：作为嘉铭老总，我会转变“做出来的东西就一定要马上产品化”的短视思维，支持Dian团队做一些前瞻性、预研性的技术探索。研发的最终目标是产品化，但产品化不能成为唯一结果，研发必然带有一定的风险性。Dian团队已经积累了很多振镜控制系统开发领域的经验和教训，对于这个行业，也逐渐有了自己的认识，他们有能力做好很多事情。