一篇流水账
Opened this issue · 6 comments
从 1 月 9 号 开始，截止现在（4 月 8号），这三个月期间，关于小程序的是是非非，已经议论了太多，然而今天，依然还要拿它说事。
有些话，不吐不快，有些事，不做不休。整整一个季度，亲身参与到第一线，围绕着小程序，我们做了『摇出微笑』、『小头牌』、『晓想』、『打卡咯』、『九十分钟+』、『晓闻鸣』六款小程序。
其中第一款是和战略伙伴的合作性探索，我们期望通过它来收集一手资料，并借助早期较高的关注热度来物色一批可能存在合作空间的线下行业，那个时候媒体炒作，微信低调，普遍观望，甚至质疑，整体上叫好不叫座，这件事情最后非常遗憾地告一段落。
第二款是团队内部为进一步覆盖小程序 API，同时确认下这些 API 能否快速重现一个小 App。我们得出『半肯定』的答案。『半』源于微信的『限制』。即：在微信团队允许的场景下，小程序可以快速实现大多数 App 能做的功能。这件事情让我们有了个底。
第三款是团队赶在微信开闸时上线的小程序，精简地复用了微信的语音功能。微信发语音很方便，但不能转发，不能保存，不能传播。我们尝试性对其做了一次拓展，发现还是蛮有意思的，但它本身不具备商业化价值，或者说，我们还没想到它能有商业化价值。这件事情可以说达成一定的预期目标。
第四款是团队为满足自身需求而开发的一款定位为产品级的小程序。我们很用心地规划了它的生命周期，切切实实打磨着它应该有的功能，以便达到简单易用、有用的预期目标，目前还在迭代中。
像我们这样不足十个人的小团队，可能不需要正儿八经的考勤系统，但天天不打卡，又会显得太松散。所以我们想到用微信做扫码打卡，这样打开微信就能看到大伙的出勤情况，这是产品的初衷。
个性化三班制、签到用语、内置通讯录可直接拨打电话（譬如某个小伙伴没来，打个电话问下情况），设置必要的出勤标签（我们迟到、早退、请假不会扣工资，但有个标签可以潜移默化提醒他们，这样不怎么好）
作为职员只需扫码就可以了，不需要过多的操作。作为 Boss 和管理，可以灵活设置符合自身情况的上下班时段，配置一些亲切的签到用语，直观地掌握职员的出勤情况。
很多朋友问我：不是已经有钉钉了吗，为什么还要做『打卡咯』。每次我都不厌其烦地说，路线不同，钉钉做的是流程，我们做的是辅助性考勤，主要是自用的同时也开放出来给可能需要的朋友们去用，况且，钉钉一如既往的继承了阿里系的五花八门特点，且不说钉钉的打卡很鸡肋，单单要找到打卡入口，就是一件不简单的事。
后来微信升级了企业版微信 App，加入了部分考勤功能。朋友第一时间分享给我，坦白说那一刻，我很沮丧。这显然是微信和阿里的又一次拉锯。但我仔细体验了一遍后，觉得依然还是侧重工作流，依然存在差异化，可以说『打卡咯』更垂直，更精简。但心里还是有疙瘩的，毕竟宿主东家做了这样一件事，虽然现在不够完备，但他们想要做的话，真的是分分钟的事。如此一来，『打卡咯』可能存在的商业模式也就呜呼哀哉了。我把这个想法同步给参与其中的每一个小伙伴，却收到出乎意料的回应。他们说：这个是为了自用而生，就算未来用它的人不多，依然不影自用，它所不能承载的商业模式，交给后续的产品来实现呗。一开始我还语重心长地跟他们鼓吹我看到了多远多远，后来仔细想了一下，确实也是如此，他们说得没错，有些东西不需要去攀比，本来就没想过要攀比，说实在，有一班踏踏实实打磨产品，波澜不惊的小伙伴，我还是非常欣慰的。这件事情，现在我又不想砍掉了。
第五款是近期停止的半成品。是给一个客户打造的 Demo，之所以停掉，是在沟通的过程中，出现了我认为很严重的问题。我们愉快地开始却不愉快地结束，有点尴尬，但并不遗憾。
Demo 之所以是 Demo，就是要快速实现核心功能，而后上手亲测，而后持续迭代打磨。因为认知存在显著差异，我眼中的 Demo，在他看来是一个不能商用的半成品，而我眼中的成品，应该是 Demo 经过一定周期迭代后的完备版。
我以一周为迭代单位，他以一个月为梳理尺度，我希望能快速实现，他却总说不急不急，最重要的是我无法忍受他脑海中一日三变的各种想法，时而文案，时而逻辑，时而视觉。想要把这些细节具体化，他却要我去这里看，那里仿，更有甚者让我在电话那头拿起笔边听边记。那么多优秀协作工具，其实可以很快速地让思维具体化。拿笔画鸦是一种很落后的生产方式，自己说，而让别人拿笔画鸦，是一种不敢苟同的心理。领导开会现在都不兴这玩意了，况呼这是合作。
这太磨人了，我们这些年沉淀了一套完整的开发流程，版本迭代计划。在我看来，陪他这样兜兜转转折腾了一个多礼拜，已经耗尽了我所有的耐心和对他的信心。我可以用一个月的尺度来一点一滴地帮他把脑海里凌乱的想法具体化到原型、开发文档、UI、文案上面去，但无法忍受这种混乱的协作方式和对互联网应用程序开发流程的轻蔑态度：什么都有了，就差一个程序员，好吧～呵呵哒。
否定了一个行业的固有工作方式，等于堵住了踏入这个行业的大门。祝他心想事成，诸事顺利。这件事让我更加确定：合作始于互补，成行于等同的认知。
最后一款是近日把玩的个人版小程序，基本上二次实现了『晓想』的功能，只是这次让它看起来更接近微信。个人玩具，前后端代码是在 Github 上开源的，有兴趣的朋友可以去搜一搜 joephon，我用了 Redux，初学者可能会觉得比较混乱，但如果你意志坚定的话，尽管来问，我知无不言。
好啦，就此搁笔 ：D
一直想问一个问题，就是你们技术团队，为什么这么喜欢分享？你们是如何做到的？我遇到的很多技术团队，无论如何也调动不起来，希望能够多指点一下
- 个人品牌，粉丝效应是未来的趋势，不表达自己的想法，怎么去吸引志同道合的人？
- 本人记性不好，学习探索新技术后，不分享出来，一个是怕自己会忘记，二来可以对自己所学有所强化，因为别人会看，三来也能帮助后来者。
- 刚开始写的时候也会不熟练，只是想到有这么多好处，为何不写呢？
虽然写的不是很多，但觉得把自己花时间所找到、所学到、所解惑的东西记录起来，自我感觉还是挺不错的。
@joephon 请问，如何创造这样的氛围呢？氛围的建立是我一直想做但是无法做到的事情，甚至我做的事情反而起了反作用，有些技术人员变得讨厌分享。。。。有没有实践的心得分享一下
@chuxue2005
如果没有分享的意愿，或者总结的习惯，那么分享会是一件很痛苦的事。
首先分享得有听众，其次分享的人也会渴望成为别人分享的对象，如此一来才能互补互助，相互学习。
此外，文字的分享考验一定的表达功底，我们线下每周都会有一个固定的分享日。
也是渐渐培养出来的这种习惯。
最后，得有所沉淀才能有所分享。如果太过于形式的话，就会失去分享的意义。
主要还得看 平日里 小伙伴们 在工作中的交流方式。
你这边的情况我不大清楚，笼统地没法给出贴切的意见，不妨说说具体情况？