标签归档：项目

怎样提高开发速度

软件产品想在市场上获得竞争力，开发速度是克敌制胜的重要因素之一。基于此，在产品开发的过程中，速度是每个团队都会重点关注的指标之一，每个团队都在极力想办法提升产品开发的速度，以便在市场的赛道上奔跑中领先那么一半个身位。从我自己的角度来看，我会尝试关注以下 6 方面的工作，这可能会对团队提高开发速度带来一些帮助。

及时清理技术债务，技术债务对团队生产率的影响是非常大的。技术债务很容易产生，产生后往往又不是一个能够快速修正的工作，当技术债务积累过多时，常常会花费数月乃至数年来偿还。避免产生技术债务需要优先考虑代码质量，实际中很多团队为追求开发速度往往并不注重代码的质量，或许开始能够在赛道上领先，但在整个赛程中，随着积累的技术债务，开发速度会越来越慢，直到花费巨大的成本偿还这些债务，这个阶段往往也是模仿者/追随者弯道超车的好时机。一开始就保持时时清理技术债务从整体是会提高开发速度的，毕竟开发是伴随着整个产品的生命周期而时刻在进行的一项工作。

技术债务并不是那么容易清理，依赖于技能水平与经验，但总可以从最简单的开始。比如，当发现有重复性代码的时候，可能就产生了技术债务，对这些重复的代码进行重构，既避免了技术债务的生成，又提高了自己的技能。伴随着勤快处理问题和系统演进中的即时重构除了能够降低技术债务的累积，也是提高个人竞争力的一条道路。

提高客户参与度，开发人员往往不具备客户领域内的知识，碰到需要客户解答的领域内问题时，要么等待，要么猜测，这么一来一往之中，会拖延开发的速度。提高客户参与度，有能够随时回答开发人员问题的客户，无疑会提高开发速度。

让客户参与进来往往并不那么容易，在这方面往常中采取的措施是引入行业领域内的专家，或者把整个团队进驻到客户所在的场地，通过这种方式来提高客户参与度往往会增加一定的成本，但相比缺乏领域知识造成的开发效率低下和不专业性无疑是值得的。另外一种做法是用专人往复于客户与团队之间传递这些领域内的知识，效果取决于这个专人横向的认知广度和纵向认知的深度，在以前可能由项目经理承担这个角色，现在更多会设置产品经理岗位。

精力充沛的工作，疲倦会带来成本高昂的错误，同时疲倦也会让人难以全力以赴地工作，长时间的加班是极不可取的。短暂的透支一下精力是可能的，长期透支则代表应该寻找问题的根源了。试试在单位时间的使用上投入更多的关注，这样或许会更好一些。加班普遍的现象有一部分原因是实际上投入工作的时间并没有那么长，拉长的时间线在补充了实际工作时间的同时很容易让人精力不济。

减少对开发人员的干扰，尽量将非开发的工作交给其他能完成的人来完成，减少不必要的会议，在产品开发进行中时，跟产品开发无关的事交由另外的人处理，比如行政事务类的事由专门的人负责。另一方面的干扰来自自我，面对众多的干扰源，要求我们自律一些是重要的，这方面一方面需要团队的文化制度塑造个人，另一方面选择合适的人可能是更合适的。

尽量提供优质的资源，一台电脑在手，天下我有。很大程度上开发人员的主要资源需求就是设备，不要让开发人员抱怨电脑慢、内存不足…，给他们提供优质的资源。在这些资源上省钱是毫无意义的。这方面我们可以简单的算笔账，如果每天因为设备耗去每个开发人员半小时，算算一年损耗的时间和因损耗减少的产出。

尽量谨慎地增加开发人员，除非团队人员严重不足，而且有经验的丰富员工可随时拿来用，否则开发人员的增加并不会带来速度的提升，项目往往还会进一步延期。假如开发一个产品需要 10 人月，那么并不能增加到 20 个人就能半月完成，这应该是产品开发中的常识。

将这些方法应用于开发过程中，随着时间推进，开发速度应该会有显著提高，从而使团队具有「小步快跑，试错迭代」的能力。当然有一个清晰的要达成的目标是最根本的，这就好比打仗，当团队知道为什么战斗时，具备这种能力的团队，往往每次迭代都会交付一个好结果。

本文首发于我的微信公众账号「时间易逝」，欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

记那些年在 IT 项目中踩过的坑

发表评论

最近进行了几次 IT／互联网项目的交流讨论，主要针对项目实施过程中碰到的问题展开，以求寻找问题的解决方案得以让项目继续向前推进。项目实施中碰到问题是很自然的事情，本以为是一些随机性的现场功能性问题，但其实并不是，在我看来这些碰到的问题是一个 IT／互联网项目比较基础的问题，结合过去项目的一些经历，说说我的看法。

在这里 IT／互联网项目包括软件开发项目、软件+硬件的系统集成项目以及现在的互联网+智慧型项目，这类项目一般面向一个行业，项目规模比较大，涉及的内容比较多，需要投入的资源比较大，这也催生了很多专门吃某一行业的项目型企业。这类项目的甲方「客户」通常会采用招标、邀标、单一来源采购、内部议标等诸多途径来选择乙方「实施方」。

对实施方来说，在做这类项目的时候，重要的是能不能围绕时间、质量、成本这三个要素完成一个可交付的产品，一个可交付的产品并不是指一个非常好的产品「据最近的朋友反馈说朝这个方向在转变」。可交付有两重含义，其一是客户能够按照约定期限给你钱，其二是内部团队有能力按照约定给用户提供产品及服务。这需要在这三个互为矛盾的要素间寻找平衡，这属于项目管理范畴，可以通过阅读相关书籍和实践获得提高。从经营的角度来讲，只要完成可交付那么这就是一个成功的项目，从这点来讲一个项目最大的坑就是怎么完成可交付，这应该是项目团队所有人时时应该考虑的事情，团队所有的协作就为获得这个结果，为此团队成员需要设定一系列的目标并完成它们。

在完成可交付的路上碰到孤立的项目是幸运的，但现在往往这样的项目很少，不孤立意味着会与其他项目发生关系，发生关系就会产生成本，很多时候这就是一个坑，常见于跟其他系统或设备的对接，我们可能会碰到其他供应商不提供接口、提供接口要收费、提供不符合我们使用的接口等诸如此类的情况。

无论什么情况，在实施过程中才发现这样问题往往会付出更大的成本，首先是时间成本，项目肯定延期；其次是费用成本，无论是那方解决问题都需要投入费用；最糟糕的是第三种情况，就是付费人家也不提供接口。

对于付费能够解决的通常会给这部分做个接口费用的报价「客户如不想支付这部分成本，必然会主动协调各方」，对于付费也不能解决的可能需要审视自己提供给客户的产品和服务，这有可能就是碰到的又一个坑，你无形中攫取了别人的利益。如果别家厂商的盈利方式是靠这个的，你的产品或服务在有意或无意的情况下分走了人家的利益，这肯定是很糟糕的。

如果提供的产品和服务的核心价值在此，客户又认可，那么可以采用不友好的方式替换掉对方，替换不是单一的设备或系统，而是要接管系统和设备后承载的所有业务。合作则是我认为比较好的选择，这就要求关注自己提供产品和服务的核心价值，尝试找出能够结盟的利益分成点，放弃涉及别人利益的地方，改造自己的产品以共同完成客户的不同方向的诉求，同时努力提高自己产品的壁垒。并行也是一种选择，并行的背后依然涉及到竞争，同时会对客户的使用多少造成不变，在自己很弱小而且提供的产品和服务的核心价值的壁垒并不那么厚的时候，很有可能只是帮助其他厂商验证了一下你的产品和服务给用户带来的价值。

在做项目的过程中，账期也是一个坑，账期是你的成本，账期也可能是你的收益，虽然做项目的过程中很少有把账期作为收益来运作的，但在不得已的时候也是可以给你的供应商一个账期以延缓资金的压力。针对成本好好的细细思量，要不看着赚钱，其实一屁股债。保持足够的现金流，尽量根据回款周期阶段性的支出成本。有不少企业项目做的不少，回款收不进来，最后企业给拖死这也是有的。

上面说到项目管理可以通过阅读相关书籍和实践已获得提高，这些获得的提高对内更有用一些，对客户来说实际更多的时候关注好人就行了，这类项目中的干系人不是单一的，很多时候往往由于忽视了不同角色的干系人就掉坑里了，比如搞定了埋单的人但是忽视了使用的人，因为这样项目失败还是蛮多的，就算项目没有失败，很多时候也是影响回款的。怎么维护好不同人的关系这其实挺复杂的，我做的并不好。在以往的项目中一般会用给他们干干活、买一些水果，小礼品什么的这样的方式接近他们，然后跟他们聊聊天。

除了上面说的之外还有很多很多的坑，比如需求的坑、选型的坑、运营的坑、部署的坑、售后的坑、安全的坑等等，要避免跨过这些坑在我看来主要取决于是否能够依据项目所在的行业，针对项目清晰的界定风险边界，而要想能够清晰的界定风险边界，就需要对这个行业组成的生态有足够的熟悉，在奔向熟悉的过程中，我们是需要支付成本的，企业为碰到的坑埋单是成本之一，成本之二是自己得花足够的时间成本来尝试理解这个行业。

去当收银员，该当个怎样的收银员？

发表评论

最近认认真真的当了当收银员，并让团队的成员轮着去当收银员，有一定的效果，但跟我期望的尚有一些距离。那么如果去当收银员，该当个怎样的收银员呢？

这主要取决于自己是如何定位这件事，如果定位于收银本身，那可能每一次轮到自己时就会相当乏味的在那里坐上那么一天，几次之后心里难免产生「我特么的是来干xxx的，……」的想法。但如果你把收银这个场景的主体作为你的用户场景，然后再与你的本职工作联系起来，开始思考，应该会有截然不同的收获。

比如我是作为一个产品经理去做收银员，我可能会开始思考在这个场景下目前产品的使用情况是否跟期望的一致，往来的客户具有什么样的特征，什么时段客流量会多一些，什么产品好卖，内部的业务是如何开展的，内部是如何管理的，周边环境什么样，什么样的推广可能会有效……，一旦开始这样思考才有可能确立产品下一步的目标，才能持续性的改进当下的产品。

比如我是作为一个架构师去做收银员，我可能会开始思考所做的架构是否良好的支撑当下收银环节的业务模型，针对不同用户角色的功能架构是否跟实际相匹配，架构的逻辑结构十分合理，物理架构是否有改进地方，是否遗漏了重要的质量要求，是否遗漏了约束下的架构设计部分的内容……，一旦开始这样思考才有可能持续的演化整体的架构，从而让架构更贴合用户的使用，不论是外部用户还是内部团队的用户。

比如我是作为一个设计师去做收银员，我可能会开始思考当下我的设计是不是更有利于让使用者使用，自己用起来是不是很容易，当下他们使用情况怎么样，是不是能够很直接的找到想要的展现，他们的基本特征是什么，设计面向的是什么行业，具体的场景是什么样的……，一旦开始这样思考，相信设计就不光是色彩的运用与美的展现。

比如我是作为一个程序员去做收银员，那就可以真正的用一用自己开发的最终产出，看看在处理实际业务的时候是不是像自己想象中的那样出类拔萃，顺便也可以看看其他小伙伴完成部分是不是也是同样的出类拔萃，是使用良好，还是问题多多，设计的是不是合理，结合场景也可以思考很二的需求是不是真的很二，需求怎么对应到开发的实现……，当将场景业务、具体使用和技术实现互为对应与融合之后，回过头来在看看我的开发，我相信会更好，每一个技术实现毕竟都会对应到实际的应用领域。

当然这样做并不容易，但是我们可以一点一点做起，如果每个人将这些一点一滴的体验带到整个团队，并最终体现在产品中，想想产品会变得怎样。现实中还有很多类似「让你去当收银员」这样的阶段性任务，遇到这样任务的时候我们应该想一想该怎么定位接到的这些任务，相当程度上这个任务不是真的就是让你去当一个「收银员」，那不如直接找一个专职的来做更合适。

目前这个阶段去做「收银员」是期望大家从不同的角度来近距离的接触一下我们产品中的其中一种类型的用户，以便对于我们在做的产品隶属的行业有个直观的认识，毕竟团队所有成员并不太具备这个行业领域的知识，近距离接触用户的实际场景可能是一条获取行业领域知识的路径，这个阶段的长短取决于团队的通力合作，用户就在那里，而我们的产品还在路上。

持之以恒，方得始终

发表评论

最近生活工作中几个场景中的小事，让我思考做产品过程中坚持的重要性。在日常生活中，会碰到很多新上市后反响不错的产品，但由于各种原因，往往不能持之以恒，产品逐渐变味，最终逐渐失去市场。我想「坚持始终如一」「坚持持续运营」「坚持勿忘初心」可能是需要我们做产品中时刻思考与警惕的。

一个烧饼小摊

去年的时候小区西门口开了个烧饼小摊，刚开始的一阵子天天都排着一队人在等着买烧饼，凑趣排队买了一回，烧饼确实不错，份量充足，外焦里嫩，外加厚厚一层的芝麻，对烧饼这个品类来说是一款好产品。

那段时间每每有时间都会去买上几个，并推荐给周边邻里，排队的人越发的多了，有时候还不一定能买到。一阵时间过去后，份量开始少了，随之芝麻也开始少了，品相也不如以往，也就不再有排队的情况了，当然小摊还在。

另一个烧饼小摊

前段时间又有朋友推荐了一家打烧饼不错的小摊，第一次去排队从最后一炉中匀了两个，吃后确实不错，便宜好吃，同样也是一个好产品，第二天特意去早一点排队多买了几个，隔了几天当第三次去买的时候发现没有了，心中还想着怎么没了？这几天经过发现又在卖，排队的队伍不见了，上前买了几个，随口一问原来是这段时间不想干想休息休息，好在烧饼还是如以前一样，花一定的时间后可能还会恢复如初。

不为发烧而生的小米

烧饼小摊的事就说到这里，转回互联网，这几年互联网中的明星企业「小米」最近被众多大V唱衰，已然成为最近的话题之一。我对手机这个行业的了解仅限于周边亲朋好友的使用情况，印象比较深的是在 2014 年中国互联网大会上北大的刘德寰教授对手机行业以「春秋五霸」做了主题报告，当时刘教授在报告中有提到小米是四面出击、细分待定。一边听一边跟一起参会的同事闲聊了几句，站在外行的角度比较看好华为，基于两点，其一是核心部件华为自己就有研发且有专利，其二是跟运营商关系不错，现在看来还得加上华为不是以风投驱动的。

「为发烧而生」品牌定位下的小米火箭式的成长，买小米手机也是一件不容易的事，要排队抢，经常会在线上线下听到「抢到了没，又没抢到……」，日常中见到的小米手机也确实越来越多多，聊起来反馈也挺好。但从去年年底今年年初，周边用小米手机的逐渐减少，后续的产品好像也不「为发烧而生」了，在偶尔听到类似「系统怎么推广越来越多，广告是越来越多了」的抱怨声中，手机也逐渐换成了其它的品牌。

产品推出市场后，能够解决冷启动获得初始用户已实属不易，我们团队从开始组建到产品开发到尝试让用户使用已经过去两年了，还没能很好的解决冷启动的问题，当然也不存在排队等用的初始用户。一方面我们在坚持，另一方面我们也在根据为数不多的用户的反馈持续对产品进行改进。

无论这两个卖烧饼的小摊，还是小米，一方面是极其让人羡慕的，另一方面是值得思考与学习的。如果他们一直坚持提供始终如一的服务，一直坚持持续的运营，一直坚持勿忘初心，可能会是另一种景象，可是现实是没有如果的。

本文首发于我的微信公众账号「时间易逝」，用微信扫描下方二维码可订阅我的微信公众账号。

如何挑选办公管理系统

发表评论

在十五年前工作的企业中，为了便于团队成员的办公与信息化管理，企业当时采购了一套办公自动化系统「OA」用于日常办公，整套系统由加密狗「类似 U 盾」与诸多的功能模块「工作台、消息、审批、计划、任务、CRM ……」的系统组成，就是拿到现在，这套系统也是不落伍的，当时和小伙伴们用了 4 年多时间，中间厂商断续的更新了那么几次，每次的更新对于厂商都是一次收钱的机会。

在使用的 4 年多时间中，面对这么多的功能模块，大部分功能浅尝即止，最常用的是消息模块，这个模块提供选择小伙伴，然后录入消息内容，偶尔也可以添加个小附件，发送后被选择的小伙伴们的电脑都能弹出消息「前提是用IE登录了这个系统」，这个功能多用于中午约饭及周五约下班后通宵游戏，偶尔也会用于会议通知或进行文件发送，至于其它的功能模块基本都是放在哪里，成了摆设。

后来离开这个企业后又断断续续的在几家企业历练，也会有相应的办公管理系统「那几年无纸化办公是比较被追随的」，其大部分功能同样也是摆设，政府、外企和极少的大企业会稍好一些，这么多年过去了，中间也碰到诸多企业采购办公管理系统，直至目前，大部分企业在挑选和应用办公管理系统时依然是这样，以系统功能的多寡来选择，辅以性价比和是否提供本地化服务，而厂商也乐忠于开发功能堆叠的系统来迎合这种选择，以方便卖个好价钱，这样造成企业买了系统却没达到期望中的效率提升、节省成本，没有为企业产生价值，纯粹为信息化而信息化。

那么功能多了好不好，功能多肯定是好的，这么多功能的产生就是因为市场中有这么多的需求，功能多是好的，买来却没有产生应有的价值，那么该怎么挑选办公管理系统？

从企业内部进行审视是挑选办公管理系统的关键。区分办公的各个场景，梳理出各个场景中的资源、流程、碰到的问题，确定各个场景实施办公管理系统的关键指标，将这些关键指标与需要采购的系统相匹配，获得适合企业当下的办公管理系统。

关键指标有很多，系统服务于人，人员匹配就是需要考虑的关键指标；在协作之间企业团队成员完成日常的工作，流程贯穿于其中，流程也是一个需要考虑的关键指标；企业内部的职能部门有其内部办公管理的诉求，往往每个职能部门办公管理的关注点是不同的，这又是一个需要考虑的关键指标。当然还有更多的关键指标，如果全部考虑进去进行全面的匹配，往往就会出现这些年碰到的情况，买回来后的大部分功能都会成为摆设。

贪多嚼不烂，要有所取舍，以当下为准，尽量少发散，现在日常干什么我们就信息化什么，在享受了信息化的红利后，会自然的发散深入，要用一个、上一个，上一个、用一个。日常中没有使用的你不能指望采购个系统回来就用了，要知道功能越多也需要越多的人来参与使用，没有这么多的人参与使用同样也只能是摆设。而且一起堆积在系统中也会产生干扰，提高整体使用的复杂度，可能唯一的收获就是花了钱买了这么多功能模块，心里上占了便宜。在选择办公管理系统时，选择少要比选择多更好，少即是多。

最近有家企业在采购办公自动化系统，寻找了几家国内知名办公自动化系统厂商进行内部招标，大概情况是这样的：各家进行自家系统的宣讲；功能、价格、服务，洋洋洒洒的几十项功能罗列，适应移动场景，基本涵盖办公管理系统的各个角落。如无意外最终会从这几家选择一家，他们忘记之前他们曾有一套系统，有很多功能都处于闲置状态，仅仅不符合移动时代就需要，就要重来一次，对于厂商是极其喜爱这样的客户的，那么对于客户自己呢？

企业办公管理系统隶属于企业管理数字化范畴内，数字化需要做到可存储、可搜索、可调用。在移动互联时代，数字化系统会在连接中融合，企业既应该从内部考虑企业管理数字化后能给企业带来什么红利，也应该从外部考虑企业管理数字化后能给用户带来什么超值的服务体验。不要再仅仅为功能埋单了，用迭代式采购办公管理系统或许是一个值得尝试的好方法。

本文首发于我的微信公众账号「时间易逝」，用微信扫描下方二维码可订阅我的微信公众账号。