只怪自己 young 已不是 too young 了，但 simple 却是 too simple
这里以“流水账”的形式描述一个自己全程参与的技术产品的生死历程，不对，准确说是「产品失败难产的历程」
从2014-03-29立项开始
- 我们要基于还算新潮的AngularJS、做一个上层的组件库
- 我们探讨各种做法：参考传统组件做法、参考已有的angular ui库的做法。
- 大概经过一个月，决定摒弃传统组件做法（致使支持传统组件开发的同学感到不愉快、不再参与）。
- 使用更加angular化的组件做法，但我们又不能在一些细节规范上取得一致意见，最终仍不能合力做一个东西。
- 不能合力，就分开成两拨，做两个类似的东西。
- 但我们总是期望有些一致性：于是想建立统一的模块平台、使用一套开发工具。
- 大家又收起争论，各自发展自己组件库、同时又一同出谋划策开心地建立统一的组件模块平台与开发工具。
- 但问题又来了：模块平台的界面以及提供的功能又有了不同的意见，开发工具提供的功能也不能取得一致。。到7月底、这些工具与平台已经成型可使用，但仍然只是那几位同学在使用；别人不愿意用、因为没有提供需要的功能，而那几位同学不同意加这些功能以及想法上有冲突。。
- 8月、9月大家都忙于业务，这个技术产品基本处于缓慢开发甚至是停滞状态，因为达不成一致、大家对这个产品的热情消散了许多。这期间自己也一直思考这个东西以后到底该怎么进行、已有一些穷途末路的感觉。。
- 10月，出于无奈，我提出让这个技术产品「更加松散」，各自发展、什么都不约束。原本仓库只保留 wiki 、issue ，做共建的周会记录、放分享、内容链接、问题讨论等，不放具体代码、可以放链接到各个组的代码库里。
- 松散到这个程度，差不多就注定了悲剧的命运
- 11月，关于它的计划、会议全部停止了，结束了！
- 本来老大对这个技术项目抱有很大期望，自己又何尝不是，但最终也没产出满足期望的产品来！
美妙过程
结果是不好的，但过程是美妙的
热情似火
这个项目主要参与进来的是10个人，还有另外3-4同学一直在关注和少许实际支持。大家都非常积极，都是要卯足了劲、大干一场！所以，过程中大家的讨论非常多，各种各样的方案也非常多。
感悟与教训
沟通
- 个人问题
- 当别人提了不太认可的观点时，首先应该站在他人角度想想，不能立即反对或否定别人，可以再提出自己的观点。
- 说话用词，一定要照顾他人感受，虽然确实无意、但可能会不小心伤害别人，这就不可挽回了！
- 遇到问题，首先多从自己身上找原因
- 大家其实很难互相说服
- 如果是老大说服下属，那应该是比较容易的；如果在合作前大家都已对你这方面的专业性或权威性有所耳闻，那么别人可能会对你「盲目崇拜」同样容易被你说服。碰到争执时、要有个能够拍板的人。
- 沟通成本
- 首先明确，异地沟通很困难！
- 我们是杭州与成都的两个小团队在互相沟通、一起搞这个东西，碰到不同意见、真的很难以沟通解决；虽然确实有电话、远程视频等沟通工具可借用。。
认知不对等
- 对这个东西的了解程度不同，会直接导致产生不同的意见。
- 如果这个东西本身「很松散」、又没有前人已经淌出来的「成熟可靠、又让人信服」的经验，同样会导致产生许多不同意见。
- 这些不同意见很难有一个让各方都满意的答案，也很难有一个折中的答案。
风险评估
-
风险问题很折磨人：评估过多，会让你畏首畏尾、不敢动手；评估过少，会直接让你得不到好结果、不过你会经历一个精彩的过程。
-
技术风险，技术基础是什么？这个很可能会直接决定最终成败：
- 就像要搞一个「无线组件库」就会容易许多，因为这几年无线已经有很大发展、大量人员投入其中；而它所要求的技术基础基本都是「开发人员必备的基础知识 + 一些设备厂商的规范知识」，技术基础、实现方法优劣等方面已有大量积淀、大家几乎也不会存在重大争议。
- 如果有「新概念与新东西」作为你的技术基础，那将会产生很大挑战。首先，你要让大家接受这些作为基础的「新东西新概念」；让大家愿意去探索去实际试试，消除内心的抵触、努力适应新东西带来的一些可能初次会让人不太习惯的改变。这一步走好、你才有走好后续路子的基础！
感谢有这一段美妙的失败经历！感谢一起走过的每一个人！我依旧充满希望的走着，相信终有一天会有成功来眷顾。