走出软件作坊

1. 如何保证软件稳定性?

     软件稳定性的问题, 会引发实施培训, 实施推动上线的困难, 客户使用效果不佳, 支持费用高, 支持难度大等问题, 最后实施部门不愿意实施, 销售部门不愿意销售, 支持部门直接找开发部. 所有的矛头都会指向开发部.

    一般的作法是招聘测试人员. 但在一些小公司, 因为成本问题, 老板是不愿意这样做的. 而且如果公司的流程和制度不配合测试人员, 问题也依然不会解决. 所以, 不管有没有测试人员, 可以从开发人员身上入手. 

     1. 专门划出一个辅助开发人员, 要求有耐心和细心. 由他来统一开发部对公司其他部门的接口, 来记录或者解决客户或者老板的疑问, 分担其他开发人员不必要的骚扰. 在熟悉产品以后, 再入手测试工作, 为了减少自己支持工作的压力, 只有专心测试反馈问题, 保证系统出越少问题, 同时负责输入BUG和需求的录入

     2. 新增公共代码开发员角色. 每个产品或项目的修改需求都必须先经过他的思考, 能成为公共代码的, 能做成封装函数的, 都由他来完成. 其他程序员只负责函数调用, 客户UI操作和辅助功能的开发. 也就是保证系统的主要功能由技能相对较高的公共代码开发员控制, 才不会引发系统稳定性的问题

          公共代码开发员必须具备的能力:

          a. 参加过多个主要项目的开发, 实施, 支持. 才能对客户需求有综合的把握. 也就是说要对客户的思维方式有一定的了解,能站在客户的角度来思考问题. 这一工作也可以由开发经理代替, 当开发经理接到客户需求以后, 由他     来分析, 分解, 分辨出公共开发代码员和其他程序员的工作.

          b. 需要有认真负责的工作态度

          c. 思维严谨, 考虑周详.

          d. 代码开发能力强. 能提交优美,可读性强, 性能和稳定性都高, 并且具备相当的灵活性和扩展性功能的代码.

2. 怎样应对客户多种个性化需求?

     单个部门或需求人大多数时候都是从自身考虑问题, 所以所提的需求也同样有很大的局限性. 如果全部接收并加到系统中, 对系统本身是一种破坏.所以, 解决的方法. 

     1. 从流程上可以让所有提需求的部门都经过客户的IT部门, 由他们来汇总过滤, 并经公司领导层审批之后再由软件公司进行开发. 并且是要走正式的流程, 而不是打个电话知会一下就行了. 而且同时要让客户明白对于不明智的需求开发也是需要支出的. 但这种做法, 可能还是不能让用户真正从我们的系统中获利, 提高工作效率. 

     2. 从业务上, 软件开发经理要能理解客户提出的非正常需求背后真正的意图. 了解到他们的难点和痛点. 根据业内行业标准或者软件开发思想来给出软件体系中专业的解决方案. 如果能成功, 会让客户觉得我们才是专业的. 在以后提需求以前也会来多征求我们的意见. 这样以后的工作也会更加顺畅

     3. 从系统和技术实现方面, 有时候可能用户的需求是很有创新的, 甚至对系统本身以后的发展也是很有利的. 但是技术实现上可能需要更多的付出, 这时可能就需要能很好的引导用户了. 在技术实现方式, 交付时间, 交付方式等关键点上取得平衡. 可能技术人员就不太擅长了

3. 开发经理要考虑的问题

     客户行业这个群体有多大? 大中小规模各有多少家? 是怎么分布的? 我们面对的最佳客户是什么规模什么信息化程度的? 我们的次佳客户是什么规模什么信息化程度的?

     我们的上层竞争对手, 本层竞争对手, 下层竞争对手目前的产品怎样? 他们各自的优点和缺点各是什么? 我们自己的优点和缺点是什么?

     客户行业的过去, 现在和未来的发展历史和趋势是什么? 他们面临哪些挑战和机遇?

     我们现在所做的典型客户, 他们的组织机构, 人员规模, 每个岗位每日业务流程, 每日每周每月每季度每年的关注报表数据, 考核指标有哪些?面对客户未来的挑战和机遇, 应该如何优化他们的岗位和职责分配?怎样优化他们的业务流程 ?

      这些工作相当于业务架构师. 而公共代码员相当于技术架构师. 要做到这些, 对行业的业务熟悉程度要求是相当高的, 甚至和客户内部的业务专家都不会相差很多. 

4. 操作文档, 培训工作如何开展? 文案和培训人员如何培养?

     在软件系统功能稳定,实用的前提下, 怎样让用户更快更好的上手使用也是不容忽视的. 否则, 将无法体现软件的真正价值. 

     这部分工作应该有专门的文案人员来完成, 这个文案应该是属于开发部的.由他们来写帮助说明, 制作操作视频, 制作学习版数据库等工作. 但由于行业特殊性及软件思想等等的限制, 文案人员的不可能很快完成. 

     首先可以从辅助测试工作开始, 让文案人员来逐步熟知产品和业务流程. 然后从内部培训开始, 为开发部或其他部门人员进行培训, 让公司其他人员更加了解熟悉公司的产品, 同时, 因为他们作为开发部中非开发人员, 他们就能作为使用者来提出更多的产品易用性建议.

     第二步, 再开始和用户接触, 了解用户的思维方式和操作习惯后, 再结合系统本身的特点来向用户进行培训. 在培训过程中面对内部和客户多方的问题, 他们自身也会更加增进对产品和系统的了解, 甚至提出更高层次的系统需求, 来完善优化系统.这部分可以由培训专员来完成. 具体的手段有培训手册, 培训课程, 模拟练习环境, 模拟数据等

5. 一个软件研发团队应该有着怎样的配置和分工?

    不可缺少的几个方面:业务架构, 技术架构, 测试兼技术支持, 文案兼培训. 但这些工作不能由一个来完成, 每个项目一个人负责, 从头到尾这些工作由他他来完成. 

     1. 项目经理. 承担售前的工作. 需求调研, 输出需求说明书.业务开发组长也可以参与其中.  项目经理负责指定, 分解, 分配, 协调, 汇报项目, 质量控制, 项目需求变更控制.但国内的项目经理一般没有人事权和财务费用权. 而从现状来看, 他们也没有项目范围和项目需求控制权.

     2. 业务开发组长是技术开发出身, 了解开发人员的工作流程, 他的主要职责就是跟踪项目的开发进度和管理质量, 对项目的干扰因素要能及时预见发现并上报解决.所以, 要保证开发组长和开发人员在一起工作. 

     3. 公共代码开发人员. 对于企业管理软件的开发, 框架的开发和维护, 公共代码的开发, 高难度的问题跟踪, 高性能高扩展性高稳定性搞安全高并发的代码设计, 复杂代码重构. 他还负责新技术跟踪, 试验. 但这个新技术要上报给公司技术总监, 以防不符合公司目标. 对于有利的开发技术, 可以对研发人员进行培训讲解.如果大家认可, 则选择适当的机会引入产品中

     4. 测试人员. 兼顾服务部门技术支持人员, 兼顾产品打包, 产品安装测试, 产品发布, 版本分支管理, 源代码备份等工作.

     5. 文案. 美工. 负责产品帮助说明文档, 更新说明文档, 配置维护管理文档, 基础数据配置, 软件操作演示视频. 产品演示PPT等工作. 美工在协助开发人员的同时, 辅助文案.

     6. 开发人员. 

6. 项目中可能遇到的问题. 

     1. 需求调研工作如何开展和推进?

         研究此次项目组的用户人员构成, 能力, 职责, 上线时间, 用户计算机能力, 用户部门对上一套系统的抱怨和赞扬, 业务支撑部门的难点和痛点. 周边还有哪些系统在持续运行. 上一套系统的功能结构和操作流程. 这些工作做完以后, 才能确定接下来项目开展实施推进的策略和方法. 

         项目调研阶段的一个工作开展方法

               1. 了解用户方的部门组织结构和部门负责人 了解这个项目和各个部门的关系. 通过访谈或者拜访或者其他交际手段, 从基层人员了解细节信息.

               2. 确定一个和项目关系比较紧密, 最容易配合和工作突破的部门, 单独去拜访部门负责人. 在负责人层面如果能达成一致, 下面人员的配合工作会比较到位.

               3. 了解这个部门的核心工作, 重要指标, 工作流程, 工作方式, 从信息化的角度结合项目进行优化, 拿出确实高效的解决方案

               4. 第一个部门的工作要做细做优, 才能创造出好的口碑. 大老板和其他部门才能愿意配合

     2. 需求调研需要确认和完成的目标

          需要确认好项目的边界和目标和执行标准和责任人. 已经可以预期到的需要用户配合的工作, 以及相应的责任人和责任部门. 这些要与用户高层达成一致, 并有规范的输出文件.

     3. 系统环境的搭建和试用

          需要基础数据. 并且需要校验. 基础数据来源于原来的系统, 如果原来系统没有问题的话, 用户也不会考虑换一套系统. 所以校验基础数据是很有必要的. 这部分工作都需要用户的支持, 而且同一行业不同公司都有其独特的地方, 不要自以为是的认为这些数据没有问题.

          当用户嚷嚷需求的时候, 一定要以系统目标为约束. 这时, 之前约定的系统边界和目标就开始起作用了. 可以分阶段来完成用户的各种需求, 但一定要先有明确的时间点来完成系统上线才能实现.

          项目的需求修改, 尽量不要在用户现场. 作为甲方的用户, 相对于软件公司来讲具有绝对的优势. 让开发人员面对过多的用户压力, 可能导致用户满意度问题, 也可能出现系统目标偏离等问题. 现场应该有一个项目经理, 负责协调,控制,理顺, 执行流程, 规范, 目标, 时间, 保证执行到位. 一个培训专员, 分担培训工作, 帮助校验数据, 测试功能. 开发人员应该在公司分担开发测试工作, 而且开发人员还要完成其他公司需求的的开发, 站在他们的角度, 要兼容更多公司的客户要求, 所提交的代码会更高的稳定性和可扩展性. 

     4. 实施过程中, 用户业务部门的不想用, 对使用新系统比较抵制.

         首先要搞定老板. 老板看重的是管理. 管理软件除了实现电子信息化, 还有着自己的管理理念. 从其中抽象出管理模型KPI, 管理模型计算方式, 管理模型流程, 把这些确实可行实用的思想灌输给老板, 在老板下决心上线后, 下面的部门和人才能有压力.

     5. 实施过程中培训

          由培训专员制作培训课程, 培训教材, 培训考试试卷, 模拟练习学习软件, 视频教学软件. 使用的方式,可以有实地教师培训, 网络在线/视频培训, 事后考试考核, 并通报老板

     6. 实施过程中的问题处理

          充分利用网络软件和工具, 提高工作效率. 要让用户感觉问题处理是有时间限制的, 一个实施人员到现场的成本和时间都是有限的, 需要用户积极配合, 共同努力才能达成目标.

          自己的工作态度和行事风格, 决定用户对你的态度. 

7. 需要的工具

     1. BUG管理工具. 记录所有来自外部的需求和BUG.由支持人员和测试人员来录入, 这样对他们和开发人员的工作都有了量化. 所以BUG管理工具, 能把计划, 进度, 质量, 需求, BUG都管理起来, 而且能追溯,考核, 统计工作量和工作质量. 

     2. 需求描述工具. PPT+word+脑图+excel. excel用于描述报表需求.

     3. 软件包装. 

     4. 日常维护和问题解决工具. 网络教室管理软件, 网吧管理软件, 远程监控软件. 局域网内数据文件同步工具. IM工具

8. 摘录及想到的

     1. 你的目标要和老板保持一致, 老板的目标就是赚钱, 所以在没有明确足够理由表明你的建议可以赚钱的情况下, 老板是不会轻易投入资源的. 老板不赚钱, 一切好想法都会被推翻. 不要抱怨老板给的资源太少, 只有在实现了老板的想法和目的的前提下, 才能更好的实现你自己的想法. 中国的软件公司大部分都是这样, 在这个大环境下自己是无法改变的. 只能选择去适应.

     2. 技术只是手段, 赚钱才是目的. 作为商业软件公司, 最大的目的就是追求利润最大化. 实现的手段就是最小的成本, 最少的人, 最少的时间, 最简单的方法达到老板的目的, 拿出合适质量和功能的产品, 包装好, 卖尽可能搞的价格.

     3. 数据录入界面的校验功能, 在系统初始化时, 是十分重要的, 而不只是为了日后工作时相对使用较少的数据录入工作. 一旦录入的技术数据异常, 后续可能导致的问题层出不穷, 会导致用户对系统失去信心而放弃这个系统. 

     4. 收集错误日志. 可以参考windows软件的大部分做法, 一旦发现程序异常, 要首先终止软件,避免录入异常的数据. 然后把软件错误页面自动保存成gif文件, 同时收集关键变量数据, 用户session数据等, 通过点击按钮发送给公司报告. 

     5. 销售的PPT, 都是展示给用户的, 可以拿来参考和做标杆

     6. 一个团队的好坏, 就在于团队的创建者和第一任运营者. 就好像我们老听到的一句话: 什么是企业文化? 企业文化就是老板的性格. 一个公司如此, 一个团队也是如此.

     7. 判别平衡和矛盾冲突, 也一般从人性和利益两方面考虑. 企业员工间的矛盾, 不外乎一口气, 一个位子, 一个面子或者一点小利. 其实最大的控制者还是老板, 所有人都是棋子而已. 平衡下属间的矛盾和团结, 就能很好的搞定团队.

     8. 管理者应该类似导演, 而不是教练. 我喜欢这个群体中能制造出明星, 也有踏实的群众演员, 也有幕后剧务. 我希望这场好戏能买个好价格, 也是路演和推广是必不可少的. 我需要拍一部好戏的资金, 所以要找老板去讲故事获得资源支持. 也许, 这就是商业和软件艺术和软件工程的结合.

     9. 每个能做某行业信息化的, 都不是看着有前途突然杀进来的. 行业只是, 是每个行业管理软件都深刻能体会的. 技术并不是首位关键, 倒是大批量定制, 大批量实施, 大批量服务是很大的挑战. 所以这需要先进的运营和管理方法. 这就是工程方法, 就是软件工程. 需要团队大批量作业, 而不是精英研究攻克.

     10. 有什么样的人, 就有什么样的产品, 就有什么样的客户. 物以类聚, 人以群分. 如果你总遇到让你很倒霉的客户, 那么就应该先检查一下你自己. 

     11. 架构师是游走在技术和业务之间, 既要兼容软件历史不能割裂, 又要面向未来发展. 架构师的工作是其他人工作的基础, 架构师需要有很好的技术信任和很好的人缘. 

     12. 很多人在抱怨需求总是变化. 其实, 不是客户需求在变, 而是你对客户的需求是不同思路去理解的. 如果心中有业务框架, 有过去,现在,未来, 就能识别出这个需求是稳定还是临时拍脑门想出来的. 跟上用户的思路, 就很容易能说服客户. 

     13. 表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当他们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。”对于问题的我们很难看到本质，不过，如果我们想解决问题，就必须试图先去了解问题

     14. 这个需求要不要放在系统中实现? 衡量的标准是这个需求是否是基于盈利模式和竞争力构建的. 如果不能确定可以参考竞争对手,行业标杆, 业内管理专家的想法. 实在不能确定可以先实现简单功能再从统计数据评估. 想当然的决定是不科学的

     15. 要了解客户真正的工作流程和操作习惯, 因为客户才是重复多次使用系统来完成工作的, 很多操作不是开发人员想当然的确定的.

     16. 多剖析行业标杆的产品. 学习他们的架构, 产品气质, 实施模式, 咨询模式, 服务模式, 销售模式, 市场模式. 总结出优点和缺点, 来优化自己的产品. 同时要多接收用户的反馈信息. 这样才能结合既要站得高有长远目标, 也要能有落地的现状.

     17. 新产品要与现在的产品能形成增强的产品整合竞争力, 新产品和老产品之间最好能形成整合互补的关系, 而不是代替关系, 更不能形成互相不关联的关系. 比如微软的windows, office, sqlserver, visualStudio, 四个产品有机结合, 互相增强, 就使得整体推进. 反观金山词霸, 毒霸, 影霸, 产品之间几乎没有交集. 而且在各个领域内都有强大的竞争对手, 无法形成自己的整合竞争力. 

     18. 产品规划, 我们尽量促使产品能成为消费类软件或者基础类软件. 产品都是有生命周期的, 软件的框架要尽量符合生命周期的要求, 不能以做一个百变金刚的框架为目标. 

     19. 做产品不能抱着科学家研究的思路来, 而更应该在资金, 时间, 人力, 竞争压力, 客户现状等的现实条件和框架下进行研发, 有阶段, 有目的, 有重点的研发. 不能什么流行做什么, 要从历史需求库中分析总结已有用户的需求, 来满足老客户需求, 拓展新客户.

     20. 产品定位方法: 对于什么目标市场的客户（一定要精确描述好你的目标市场，千万别用什么中小型企业之类的词语）而言，你的什么产品或服务（针对这类目标客户，你提供了相应的什么产品或服务，这个产品或服务一定要与你的目标客户匹配），提供了什么主要价值（要精确，千万不要说提高了管理水平。管理这个东西很模糊，就类似这个企业管理水平低，到底指的是什么），因为你的这个产品或服务提供了什么独到之处（一定要独到，否则人家为什么买你们，而不是买别人的）。

     21. 不要让某个环节某个人的工作成为瓶颈. 可以并发或者分摊. 先完成优先级较高的部分, 就可以继续下一环节的工作. 同时本环节继续优先级较低的部分. 

     22. 视图的应用. 开发人员为了性能或者可扩展性, 把表结构设计成多个表, 而业务上理解时不方便, 这时就可以使用视图, 而不需要关注内部表之间的关联关系

     23. 新产品, 新团队, 新技术这三个因素不要同时出现, 否则将会出现很大风险.

     24. 一个有潜力的员工, 不是要具有什么样的技能属性, 而是是否有责任, 有耐心, 有韧性, 细心, 踏实等等这些人格属性.

     25. 每天下班前一个小时来做今日总结和明日计划工作. 相比早上刚上班没有进入工作状态, 和晚上将近下班心不在焉, 要更高效.

     26. 读书, 笔记, 还需要回顾总结

     27. 只有有了明确分工, 才能专业. 否则面对繁杂的工作, 员工是相当不稳定的. 

9. 软件报价的一个实例

     1. 研发费用:

          产品开发的过程包括, 客户调研, 客户调研报告编写, 功能设计, 功能设计说明书编写, 开发测试, 帮助文档, 培训课程, 培训演示版本编写. 另外, 产品开发完成后还必须由开发部对实施部门的培训专员和项目经理进行内向. 否则产品知识就无法产地给客户. 这个内部培训也是需要成本的.

          产品开发团队的成本: 开发总监1名, 架构师1名, 公共代码开发人员2名, 业务开发组长1名, 主要代码开发1名, 辅助开发1名. 每个子系统3名人员构成, 假设有4哥子系统, 就需要12名开发人员. 产品测试团队:4+1个公共代码测试=5名. 产品文档团队, 4名.

          所以开发过程中, 需要共计27名人员.客户调研14天, 产品开发周期60天, 产品测试10天, 文档周期10天, 产品内部培训周期10天, 共计94天. 也就是共计94*27=2538人天.

          按人家6k工资计算. 开发成本约: 6000*27*3=486000, 再加30%毛利, 共计486000+145000=631,800.  如果再提出销售费用和税金和管理费用, 纯利在15%以下, 也就是说年销售额1000w的话, 纯利也就150w. 可见利润并不高.

          要有售前人员和销售人员一起配合, 售前人员负责手机分析客户现状好问题, 并提出解决方案. 然后在和销售一起完成销售报价. 销售人员在理性价格和感性价格之间做好一个平衡. 

      2. 实施费用:

      实施阶段分为: 项目调研期, 项目数据准备期, 项目培训期, 项目上线运行期, 项目验收期.

      项目调研期，项目经理负责项目范围界定、制定项目计划、组织项目成员。培训专员收集项目详细资料，以利于项目经理界定项目范围和制定项目计划。项目数据准备期，培训专员负责培训基础数据准备负责人员需要准备什么数据，数据如何编码，什么样的数据算是合格数据，培训数据准备操作员如何进行数据准备操作录入，帮助校验录入的数据是否正确。项目经理负责客户设计数据准备过程中出现的特殊数据处理方案。项目培训期，由项目经理负责培训计划和培训协调组织，培训专员负责培训。项目上线运行期，项目经理负责推进项目保证项目平稳全面的上线，培训专员负责现场指导手把手深度培训。在项目验收期，会对前期所做的工作进行总结，指出不足，报告以后系统维护的重点和注意事项，对项目上线效果给与评估.

     报价要做细做明, 而且要是可计算的. 用户可以根据自己的情况进行DIY. 培训的费用是要单独计算的. 如果每一笔账都很实在, 客户是没有多少讨价还价的余地的.

10. 对于维护一个老系统的建议

     1. 重点把控数据输入的校验. 确保输入的数据没有异常

     2. 控制好代码规模, 做单一功能的函数, 不要做联动触发

     3. 将特殊处理业务和正常业务的功能代码分离

     4. 对于现有的功能, 把不常用的功能做一些隐藏或者淡化处理, 使得用户逐渐少用或者不用, 最终做到真正隐藏.

     5. 维护修改老代码要心平气和, 能静下心来才行

     6. 修改需求或者BUG, 按照模块来几种修改, 而不要调好改的先改. 按照模块几种修改,可以让自己通盘考虑这些需求和BUG.

     7. 对于难以理解和维护的代码逻辑, 形成文档, 便于自己和后来人的工作

11. 管理软件的3个层次

     1. 代替手工工作, 成为一个电子化功能工具. 也可以使用excel来代理. 胜在廉价

     2. 有可量化的管理模型. 从系统数据能分析总结出可供管理使用的量化指标. 这是大部分中层领导们愿意看到的

     3. 有高校的管理方法. 能进行更有效的管理生产, 更有效的管理销售, 更有效的管理服务. 

12. 管理软件的7个阶段

     1. 具备3个左右的实用亮点, 开发成本能控制在一定范围以内, 有漂亮的 包装和配套的销售方案, 帮助文档, 软件界面, 图标等等. 还要具有稳定的性能, 这时候功能相对简单, 但稳定性要有保障. 初期的系统架构将会对后期的可扩展性和性能有决定作用

     2. 客户签单量逐渐增加. 客户需求也有很多, 在原来版本的基础上进行扩展和定制开发

     3. 客户使用了一段时间了, 服务压力日益增加. 开始关注软件的可维护功能.

     4. 软件越来越复杂, 如何兼容,如何容错, 如何容易维护成了首要问题. 这时, 重点就是内部代码重构优化

     5. 性能问题. 使用3~4年的系统, 数据量巨大, 系统反应时间越来越长. 性能优化是重点

     6. 对以后的众多功能进行分析,整合,优化, 突出实用重点功能, 裁剪不常用的功能. 重构易用性成为重点

     7. 几乎在打补丁了, 不再投入大量人力去维护了. 开发团队逐步萎缩, 下一代产品在酝酿. 

13. 一个公司高层的日常工作内容

     1. 跟踪开发组长的进度报告,功能需求设计报告, 并给出调整建议和知道. 并解决需要协调的工作

     2. 处理下属员工之间的流程配合问题. 对于低效的流程进行优化调整,要给出解决问题的方案和流程, 而不是去解决具体的问题. 

     3. 定期回顾公司业务的开展情况和面临的困难以及未来的动态发展. 时时审视产品战略, 以适应公司发展变化. 根据产品发展战略的调整, 调整内部员工的职责和分工

     4. 定期与员工沟通交流. 了解他们的心理变化和职业发展规划, 并解决他们的疑惑和问题

     5. 了解行业发展动态及信息, 研究软件中的管理思想, 管理模型. 

     6. 偶尔到客户现场与用户面对面交流, 交流目前的困境和焦虑, 交流未来的发展看法, 体会客户的真实想法, 思考思路, 真实的应用水平.