技术合同

3 月，跳不动了？>>> 想要关注更多接单的技巧和接单分享。请关注公众号：开源众包 开发商角度的服务之星：一个接单者的自述。 接触开源中国很久，先发自内心的希望开源中国众包平台越做越好，因为平台在我曾经最困难的时期给我了很大希望，陪我渡过了最艰难的时光。我从创始团队开始一人到现在的五人，从最开始接几百单子到现在能承担几万、十几万的单子，从最开始的普通开发商进阶优质开发商，直到最后的服务之星，不敢说自己成功，因为自己离成功实在太远，但是可以说自己做人做事还是有几个分享的地方。 有几个经验点可以分享给即将要踏入众包平台的开发者。我总结出接单需要有几个需要注意的地方。其中有不对的地方望指正。 第一：特别是才开始做项目的不要“挑食”，不然最终你将一无所获，根据各位朋友的经验几百万、几千万的项目的都做过，认为项目太小看不上，这种心态是没有办法接单的，因为最开始我也有这种想法。 第二：根据自己所掌握的知识接单，不要什么单子都去投标，自己不熟悉的知识领域不要强行去挑战（想挑战也可以，但是需要提前去做好功课）。前期需要进行的技术可行性研究是很有必要的，不要做超出自己能力范围的事情，会这个技术和熟练这个技术是两码事，一定要认清楚了，事情没有绝对，客户允许，你的条件允许，也未尝不可。 第三：竞标方案，说实话，我的语文水平也不怎么好，也写不出什么好的方案。根据我写的竞标方案主要有几个需要注意的地方

现在到处讲副业，怎么样利用副业赚钱，这能理解，一方面年轻人生存压力大，多赚钱点总是没有坏处；另一方面，每年的裁员信息看的人心惊胆颤，大家都想为自己留一条后路。 新年伊始，想必很多小伙伴可能都想大展拳脚，新的一年好好干一番，很多人就想到了接私活，但是接私活到底赚不赚钱，这里有哪些坑，松哥和大家扯扯。 松哥刚毕业的时候做 Android 开发，在做 Android 期间基本上没有接过私活，因为 Android 有一个特点，就是应用看着很简单，在甲方眼里可能就是画几个页面，但是实际操作起来，要考虑各种各样的机型适配、屏幕适配、甚至系统适配（由于国内厂商做了各种定制带来的）等操作，也算是一件非常费力的事情。由于和甲方这种认知上的差异， Android 的活很难谈上价钱，所以就没接过。 直接接应用做虽然没有做过，但是 Android 有另外一个灰产，就是做“二次打包”的羊毛党，这个几乎不需要很高的技术手法，把别人发布的 App 拿来，拆包之后，加入自己的私货（大部分情况下可能是广告），然后再发布出去供用户下载，就能赚钱了。由于 Android 的开源，加上二次打包成本低，导致这一现象曾经非常猖獗，在 Google Play 排名前 100 位的应用中，有 60% 的应用出现了二次打包版本，而这 60% 的应用中，大部分都是游戏类应用，高 ARPU 游戏，单个安装激活价也比较高。

本打算15天完成第二轮复习的，结果项目太忙，拖成了25天。第二轮主要以小绿书为主，就是如下这本 怎么说呢，题目偏向于考ITTO的内容，情景题比较少。可以使用“管理圈”APP作为补充 1.敏感性分析的结果通常用龙卷风图来表示 2.在制定风险管理计划时，项目经理通过审查项目文件来识别风险 3.识别风险的输入项目管理计划中，有进度管理计划、成本管理计划、质量管理计划 4.对于大型采购，采购组织可以自行编制独立估算，或者邀请外部专业估算师做出成本估算，并将此作为标杆，用来与潜在卖方的应答做比较 5.优先排序是定性风险分析的关键词 6.卖方如果是按合同规定完成工作的，不管买方主观评价如何，合同状态都是完成 7.风险审计、技术绩效分析以及储备分析用来监督风险 8.相关方的风险承受力是风险管理计划的一部分内容 9.项目组合的范围与组织战略直接相关。所以在组织战略发生变化之后，项目组合范围也要发生变化 10.阶段审查又称为阶段关口，在项目阶段结束时进行 11.多阶段管理有利于管控项目 12.项目阶段划分需要考虑具体项目的具体需要 13.在项目执行阶段，就是做项目，不与运营发生直接关系 14.预测型生命周期和适应型生命周期的组合就是混合型项目生命周期 15.迭代型和增量型生命周期的组合是适应型生命周期 16.项目经理应该确保项目管理方法有利于实现商业文件的意图 17.直接服务于执行组织战略目标的项目

项目整体管理 框架 过程 依据 工具和技术 输出 制订项目章程 1、合同； 2、项目工作说明书(SOW); 3、项目论证信息； 4、事业环境因素； 5、组织过程资产 1、专家判断； 2、项目管理方法论； 3、项目管理信息系统(PMIS) 项目章程 制订初步范围说明书 1、项目章程； 2、项目工作说明书(SOW); 3、事业环境因素； 4、组织过程资产 1、专家判断； 2、项目管理方法论； 3、PMIS 项目范围说明书(初步) 制订项目管理计划 1、项目章程； 2、项目范围说明书(初步)； 3、来自其他计划过程的输出; 4、事业环境因素； 5、组织过程资产 1、专家判断； 2、项目管理方法论； 3、PMIS 项目管理计划 指导和管理项目执行 1、项目管理计划； 2、已批准的变更请求； 3、事业环境因素； 4、组织过程支持 1、专家判断； 2、项目管理方法论； 3、PMIS 1、可交付成果； 2、工作绩效信息； 3、变更请求； 4、项目管理计划(变更); 5、项目文件(更新) 监控和控制项目工作 1、项目管理计划； 2、工作绩效信息； 3、绩效报告； 4、事业环境因素； 5、组织过程资产 1、专家判断； 2、项目管理方法论； 3、PMIS； 4、挣值管理(EMV)方法 1、变更请求； 2、项目管理计划(更新); 3、项目文件(更新) 实施整体变更控制 1、项目管理计划； 2、变更请求；

今天接着上一次文章接着聊，开始之前了也聊聊上一篇文章的反馈情况，自从上一次对话方式的文章发布后，有非常多的正在前线的作战的销售伙伴们加我好友了，并通过邮件联系到我，表达了很多正在遇到的‘困境’，比如；我不懂技术，怎么能跟客户互动好？、我是个技术，但是我就是跟别人不来电，不知道怎么开场？ 文章收益人员：销售、售前、正在转型做销售的技术（售前） 其实有的人看性格，有的人看心情，也有的人看经验，但不得不说售前是一个急各种综合素质能力于一体的岗位，需要不断修炼自己，强行让自己走出舒适区的工种。 包括我坚持写这个的心态也是一样，希望分享一些工作经验给大家。 笔者联系方式：allen_junjun@hotmail.com 此次交流，侧重与业务线的交流和沟通，这里不会分享技术原理。文章已通过内部团队脱敏审核，请大家放心阅读：） 分享形式将会使用‘对话形式’，最大化的还原我作为偏业务线（架构师）临场与客户沟通时候的心理变化以及应对策略 本次交流重点简述  一次奇妙的沟通际遇  顾问式销售的三把‘武器’ 「此篇分享主要内容」 上篇分享概要 还记得上一篇我们是如何临场‘见招拆招’的情境否？化被动为主动的技巧其实并没有想象中的需要技术很强等等，只需深刻的理解我们客户业务场景，有一定的技术底蕴。将一个相对专业的技术术语解读为用户听得懂的语言，这才是一个尽责的‘售前’工程师最应该先理解的问题