今天开始呢，我将给大家白话项目那些事。
今儿个先谈一个现象，那就是：不懂开发可以带项目——吗？
第一集：来了一位美女项目经理不懂开发可以带项目吗？肯定是可以，因为必定是有人这么干了，所以才产生了现象。
但是，现象不一定都是好现象。
如何实施软件项目，被纳入了管理学的范畴，管理学有一个特点，那就是和行业无关。
不管你是哪个行业的，从文化到医学，从餐饮到建筑，我这一套方法你都可以用。
学术派属于学术界，它并不属于IT界。
见过一些漂亮小姑娘，二十来岁，知名大学毕业，辗转干过文员、行政等工作，皆不如意，后来考了个项目管理证书，于是去机关单位带起了软件项目。
小姑娘问我：下一步该干什么了？我说：你是项目经理，你安排啊！小姑娘说：那我安排你列一下项目计划吧。
小姑娘就是理论派的代表，她们强调你不用懂开发细节，项目管理的本质是管理，把握好各个流程就可以。软件开发不就是分析、设计、编码、测试、交付这些流程吗？你只要控好流程，流程不缺失，效果就不差。
你是个司机，没有必要了解汽车的详细构造，这丝毫不耽误你成为一名优秀的司机。
当然了，你了解更好，不了解也没事，可以去问别人嘛！
刘邦不懂打仗，但是有萧何、韩信。刘备不懂打仗，但是有关羽、诸葛亮。你看，反而不懂的人成就了霸业。
所以，项目管理就是要充分调动大家的积极性，严把时间节点，严控项目质量，这才是关键。
说的很有道理，就像你刚从总经理办公室出来，感觉进门前的疑难问题都不是问题了，原来是自己格局小了。
第二集：成功学的副作用但是，你一旦行动起来，马上就发现不对了：
诶？不懂车的构造好像是不耽误我开车，但现在是TM让我去造车呀！控流程是没错，但是程序员干没干完我都没法判断，我怎么控？！
管理学大师头上闪着金光从天空45度角的方向出现了，说话带着回音……着回音……回音：
关于专业的问题，你可以去咨询专业的人，不懂开发你可以去问开发经理！不懂产品你可以去问产品经理！
不懂测试你可以去问测试主管！
不懂啥就问啥。就像你不懂管理，来问我一样，我必定会告诉你答案。
啾啾啾啾……大师说完就消失了。
小姑娘如同醍醐灌顶，顿开茅厕……茅塞，恍然大悟，虔诚地向着余光拜了很久，直至太阳落下了山，秋虫儿闹声喧。
她踌躇满志地走进办公室，面对众人，决定重整河山，结果又遇到了很多问题：
开发经理和程序员同穿一条裤子，他说开发质量只能等投产后才知道，请问是否合理？产品经理和开发经理就“列表接口是否返回数据详情”而争论不止，请问如何定夺？程序员在发射火箭接口直接return了“成功”，直到上线才被发现，请问责任在谁？……此时，小姑娘虔诚地点上香，口念咒语。不一会儿，金光闪现，管理学大师再次出现。
“大师！
”，小姑娘连忙喊道：“大师，列表接口能否返回数据详情呢？请大师指点迷津”。
大师很生气：“你不要问我具体的问题，你要记得时刻充满正能量，并把这份正能量传递给每一个人。只要做到这些，一切的问题就迎刃而解了”。
说罢，大师再次“啾啾啾啾”，消失了。留下小姑娘一个人撕着头发陷入了沉思之中。
第三集：老板的力量小姑娘很消沉，把员工抱团偷
各个部门立马紧张了起来，放下成见，各司其职，主动推进，相互妥协，很快项目勉强上线了。
第四集：问题出在哪儿（上）上线后，项目运行不是很稳定。
小姑娘经常接到反馈：上传功能出问题了！
作为项目的头儿，小姑娘对有什么功能绝对是了解的，但是为什么出问题，她却不知道。
她首先质问测试：你们怎么测的？这么严重的问题居然没有测出来！
测试吓了一跳，先是看了看上线的checklist，然后又自己亲自验证了一遍，然后很有底气地说：不是我们的问题的，上线那天是好的。
小姑娘碰了一头灰：那为什么现在不行了？！
测试说：那你问开发啊，是不是他们偷偷改什么东西了。
小姑娘找到开发：你们怎么开发的？这个功能出问题了！
开发的内心一点波澜都没有：联网了没有？浏览器开兼容模式了没有？上传格式对不对？
小姑娘验证过好多次了：一切操作都没有问题。
开发依然很淡定：虽然这个按钮是我写的，但我是调用的后端接口，他给啥我显示啥，你找后端去吧。
小姑娘找到后端开发人员，又把刚才的话重复了一遍。
后端先是一愣，呆在那里好久，表情凝重，然后豁然开朗：你这个不对吧，产品需求里没有这种场景的，我们不支持这种场景。
第五集：问题出在哪儿（下）小姑娘说：但是用户都是这么用的呀！后端说：那你找产品吧，让他们改规则。小姑娘找到产品，把问题又重复了一遍。产品说：客户给的需求就是这样的，评审的时候，你也在场。小姑娘说：但是现在有这种场景了，得加上！
产品说：那让开发加上吧。开发说：你得给个规则。产品说：规则就是加上这种场景。小姑娘说：要多长时间？开发说：有了需求才能评估。产品说：不用需求。开发说：你原型不加一个说明吗？小姑娘：是呀，得说明一下吧!产品说：你已经知道怎么做了，改了不就行。小姑娘说：是呀，赶紧改了吧。
开发和产品一起愤怒地看向小姑娘。
小姑娘一言不发：你们到底想怎样，有没有大局观？！
我要报告老板！
老板：赶紧修复，否则扣工资。
顷刻之间，问题就修复好了。
小姑娘内心暗想：你看，他们是可以做到的，就是故意刁难我。
总结不知各位掘友看到上面的故事作何感想。
反正我有一点是可以确定啊，就上面的情况，就算再来几十个项目，都是可以开发的，也可以上线，公司也可以运转多年，这也是多数中小企业的现状，并没有你预想的那样恐怖。
同时，还有几个观点我想说明一下：
1、为什么老板一出面就可以解决问题，小姑娘却不行？上面的故事中，因为小姑娘的专业性不强，协调不动各方，导致老板两次出面解决了问题。
但是，老板并没有针对问题进行剖析，而是我不管你们怎么样处理，我只要结果，不然大家都扣工资。
协调本是小姑娘的工作，是因为她做不好，导致大家工作不流畅，矛盾点在她身上，大家心里不平衡，各自坚持不妥协，想倒逼她改善方式。但是，老板直接放出狠话，各方出于求生欲，放下坚持，自主协调完成了工作。
从这里看出，一方面小姑娘的作用不大，因为有她没她效率都没有显著变化。另一方面，小姑娘的权利也不是很大，如果有老板那样的权利，就不用老板出面了。但是，如果处理一件小事就动用老板权利，那么这种权利慢慢地就会泛滥，让大家不再重视。
所以，还得是小姑娘能处理好工作，保证大家工作有序开展，这样才能对于公司的业务发展、同事工作的舒适度、老板作为原子弹出场的次数，以及小姑娘在团队中的威信等，都是有利的。
2、谁更贴近一线，谁更接近真理！小姑娘从管理学大师那里不断获取管理秘诀，应用于项目管理，认为这样是可以成功。
管理学或者成功学，都是一门学科。并非说这些学科无用，只是它只限于应用于某一个层面。
比如从提高人们的积极性上来说，成功学就很有效，只需要听3分钟演讲，咔咔咔，精神振奋，无腿青年都想去爬珠峰。从精神层面，可以使用成功学来催人奋进。
但是，到具体的操作层面，因为成功学大师他没有带过IT项目，但他又想发言，所以就开始忽悠了：“我告诉你，如何解决你的困惑。首先分析问题，然后解决问题，最后总结问题”。他说的有错吗？没有错，而且极其对，就像人要呼吸一样。有用吗？没有用。
真正能带好项目的人，肯定是亲身经历过项目的人，绝不是纸上谈兵的人。就跟盖房子一样，建造师、瓦匠、水电工、采购等各种岗位多少都接触过，了解起码的工作流程和标准。最好能了解各自对接的痛点，比如由于UI提供的设计稿没有考虑适配，导致上线后不同设备出现效果错位的现象，这是提高效率的地方，也是你起作用的地方。这在哪个行业都一样，只是在软件行业这个情况更加明显。
不是产研出身的同学，并非没有优势。只要愿意倾听，愿意思考，可能比业内人更容易从特殊角度获得灵感。条件是贴近一线，并不是非得从事一线。
从来都是解决问题才能促进发展，掩盖问题只会限制发展。而贴近一线，是发现和分析问题的基础。
3、都会遇到哪些问题，该怎么解决？我们先看小姑娘遇到了哪些问题。
“程序员干没干完我都没法判断”，这是进度的问题。“开发质量只能等投产后才知道”，这是质量的问题。“开发经理和产品经理因为接口返回格式引起争论”，这是产品设计与技术实现的问题。“新增一个场景，要不要写到原型说明上”，这是项目流程的问题。有人说，开发的事情由开发经理来干就行，你去压他，让他去控进度抓质量。
当然这是理想的情况，我们都愿意这样。但是，实际上尤其在中小企业有些角色本身就配置不全，就没有开发经理，只有几个后端和前端。有的虽然存在角色，但是无法胜任。你要等换了人再开展项目吗？不可能的。
另外，软件项目是一个需要多方精心设计和配合的工程，就算都按照标准出产物，你是5毫米的螺丝钉，我是5毫米的螺丝帽，最后可能也无法收获满意的结果，因为客户是3毫米的孔。所以，想靠自驱力，靠意识，靠玄学来完成项目，本身就很悬。
最后，最重要的就是责任了。
前面说了一个小例子：“有个程序员在发射火箭接口直接return了成功，直到上线才被发现”。这件事就相当于客户让你建一个发射场，你做了一个按钮，一按放出段语音：发射成功。但是火箭根本没动，这纯属糊弄。
那么，这是谁的责任？
是那个程序员糊弄事情的责任吗？他的领导是怎么跟他安排任务的，是说做个demo还是要真的发射，后续有没有跟进，测试是怎么测试的，相关人有没有做过抽查？
这是谁的责任？企业肯定不会把程序员推出来的，说是这个临时工的锅，你们都去谴责他吧。从企业和客户之间，这肯定是项目管理者的责任。降几个层面，到自己家里关上门，才谈产品、开发和测试怎么分锅。
所以，出于这个目的，项目管理者对于所有的事情就都要了解，而且要管理。
