这些年开发了不少mis系统，是时候做一个系统性的总结了，有2年左右时间专门做政府/教育/国企的定制开发，感觉这行业项目按时交付并达到预期效果的比例不足20%，而且60%的项目因为需求不明/研发不力/实施遇阻等原因造成交付遥遥无期，庆幸我参与的项目都是按期验收的，因为在我的概念中，技术团队对项目成败起更决定性的：1）研发经理更理解需求，深挖潜在需求，就会少走弯路，少做推到重来的工作；（需求不明）
2）如果框架应变性好，更能拥抱需求的变化，改动逻辑不会造成推倒从来；
3）数据模型建立的好，开发更简单，开发人员更轻松，不会打疲劳战，把项目做“皮”了；
4）程序少一些常识性错误，bug修改及时，就不会消磨客户耐心，更容易趁热打铁一把火的上线。（实施遇阻）
信息化定制项目和产品的区别：
1）做项目比较难，不熟悉行业和业务，就像一个超市收银软件，电脑城购买1000块/套，但是如果从0开始造，没有3-6个月都难以造出来；
2）做项目基本上被用户牵着走，多了解行业，多弄透需求相当重要，不然搞不好都是白搞；
3）做项目的设计理念应该是“产品化”策略，即：个性化需求=标准模块+个性化配置，来应变不同客户；
4）有价值的产品必须承载：当前行业最先进的管理模式和业务流程；必须对行业相当熟悉，所有同类项目做多了，就可以成型产品了。
经过多年的“种田”经验，总结信息化管理分四个层面的需求（下面的文字其实可以好好替换，这个行业做过的就更容易理解）：
1）第一层需求：软件是一个工作助手，帮助整理生产数据，实现文档电子化； 软件由很多业务功能模块堆积，思路都是：给一张标准表单让用户填写，实现“生产数据电子化”，由软件系统做集中的数据分析，统计展示。
2）第二层需求：软件是一个工作推手，负责开展及推进各项工作，实现办公流程化； 通过制定业务工作流程，根据流程来协同各角色开展工作，实现办公自动化。
3）第三层需求：软件是一个指导员，积累了每个岗位的工作经验和检视标准，帮助每个角色做对做好每项工作；通过高度的自我学习，积累历史数据分析，成型文档模版、业务操作规程、工作质量检视标准；
4）第四层需求：
“软件即工作”，这是我们持续追求的目标，包含两个层面含义：软件不仅是数据处理工具，也是“直接参与生产实体过程的工作者”，利用物联网技术自动地、无形地承担更多的数据采集工作；软件场景跟实际工作场景不再脱离，用软件不再是完成实际工作之外的额外工作量，实际工作进展情况也会及时的、无形的在软件系统中反应，软件上操作也直接反馈到实际工作场景中；利用物联网、人工智能、图像识别、大数据分析等技术打通这两个工作场景，实现“无形的软件，软件与实际工作合为一体”。
在管理上我更倾向全栈型程序员，这样效率和结果一定会更好，主要依据：1）讲环节分解成：需求，编码（前端、后端），测试，因为分工太细，造成“2个监工的，1个做事的”，沟通不畅，相互内耗太多，相互推卸责任，相互忽悠，反而效率低下，难以管理；
2）程序员直接对结果负责，为了后期维护和交付，就不会避重就轻，偷工减料式的心态，也会更加主动积极的应对；
3）以前说项目时间分布：需求:编码:测试比例为4:4:2，现在编码+测试时间加起来控制在40%以内，否则表示您的开发框架很糟糕。因为框架完成了很多编码和测试工作，程序员只关注业务的实现，这样就用更多时间去弄透需求，讨论思路，自我测试等工作；这样的程序员更有价值，更符合时代发展需要；
mis系统需求特点：更多的是单机版，内网运行，数据量大，业务逻辑复杂，运维部署须简单；他跟互联网应用有些差别，这也就让技术选型及技术实现有些制约， 方案只能从实际出发。写着写着忽然有想写长篇的感觉，“教学相长”，我也需要从归纳总结中提升自己，以后就很多方面做一些讨论和实际经验的分享吧，首先大致写一个目录，编写的主题跟工作内容有关系，当前主要做什么就整理那一块内容吧，相关源码到时候也上传到码云上吧：- 需求分析
- 数据建模设计
- 开发框架设计
- 通用模块设计
- 权限系统设置
- 后台服务模块设计
- 系统性能优化
- 系统升级维护
- 开发平台设计
- 项目管理管理
- 工作流设计
- 还在孵化中....
涉及到的一些技术和理论，我可能不是那么的“高大上的专家”，所有有不要再次阐述我做技术的理念，核心理念都是围绕着：实用至上，大道至简；简单细化一下：
1）视开发效率、程序性能为第一原则；
2）有点不像正道技术，太土气，太原生，但完全够用够快；
3）丢掉花拳绣腿，条条大路通罗马，我们只须最快的一条；
4）不追求大而全，只做“小精美”；
5）底层更智能一点，使用更傻瓜；
我总是给团队伙伴说要“自动自发，主动协作”，而我对于自己的事情有时候是很被动，不痛下决心就很难坚持，在这里也必须做一个承诺吧：每两周至少写一个主题；欢迎监督，敬请关注。