入职dy的一年后（大约是2016年冬天），我被李科邀请办了一个扯淡闲聊的分享会，主题是 程序员想对策划说得那些事。今天整理了笔记，突然发现自己保存了讲稿，就发上来纪念下。
---------------------------------------------------- 我是分割线 ----------------------------------------------------
大家好，我是web一组的 .net 程序员黎进，今天有幸参加策划的分享会，站在程序的角度上，跟大家分享一下，我个人在入职以来，对策划的看法、以及自己的一些想法...o
为了不耽误大家时间，我只花半小时的时间，剩下的时间给大家指正批评。
今天想从4个方面来讲。
一、所谓的策划案到底有几种
与我一起合作过的策划有约9位，我从策划那里接收的文档，大大小小有百来个，有表格，有文档，有图片，其中不包括PM单。
参与开发过3个系统，维护过2个系统，每个系统的策划案风格都不一样，我至今不能总结出我见过的策划案分几种。
我一直认为的策划案，像一个人的一寸照，你大概一眼就将这个人的全貌了然于心，是美是丑，是英俊是拙劣，是西施出浴还是东施效颦。好的策划案，不管给任何一位策划浏览一遍就能大概知道某系统主要提供什么功能，有哪些大模块和小模块，给程序看，他们就知道该系统的数据库应该有几个表，有哪些外键。
当然，不是每一份策划案都是完美无缺的，大家都觉得自己出的方案是最好的。我这里提供了2分策划案，给大家分享下。
【此处献上策划案】
在程序眼里，拿到新系统或新需求的策划案后，能让我们知道我们大概要做成什么样子，有什么功能细节，其中是否有其他业务系统的接口交互。系统完成或维护期间，每个系统功能细节或设定有迹可循而非草草带过或者根本无处出或标记。像网站部的更新换代速度，一个程序或一个策划，至少会参与到3~5个项目中，并不是每个程序员都会在写代码时将注释写的很清楚，比如标记某处代码修改，是XXX的要求，某某某接口是由谁提供，等等，也不会有很多程序，记得系统的设定或规则细节，需要有个参考的。
这个时候，就体现了策划案的好处和便捷。
另外透露下，其实很多程序员都不喜欢看策划案中密密麻麻的描述，反而口头表述会比较清楚。但是口头传达后的这些东西，得有文档作为依据作为标准。
二、“你做这个要花多长时间？”
这个是很多策划都很喜欢问的问题，也是很多程序员很难回答且很不想回答的问题。
站在策划的角度，一个需求从产生，到程序员这里，应该经历了很多环节，例如需求提出，讨论，评审，出策划案，发单。但通常策划在描述了需求和问题后，会立即想知道完成该需求需要多长时间，随即问出如上问题。
但是，站在程序的角度，程序没有参与讨论，也没有参与策划案编写，仅凭一眼扫过的pm单，或几分钟的口头描述，怎么可能立马下定论呢。我就上过这个当。如果需求方在轻描淡写跟各位讲述了新需求后，马上询问完成时间，我想各位也会很厌恶的。
这里要把这个话题上升一下。我想现场做个调查，各位在吩咐程序完成某项功能时，他能按照他所说的时间点按时按质完成的，有多少？
在我看来，某个产品或功能从无到有，程序只是生产这个环节，时间上应该只占50%左右，而其他的时间还包括所谓需求调研、方案制作、功能完成后评审，直到上线使用，这些环节的时间，程序员是无法预估的，他能预估的时间，是他完成这项工作且保证无错的情况下所花的时间。
而且，更为重要的一点是，在某个系统的开发维护过程中，程序员应全听策划的安排，某个系统当前开发版本中，应该完成什么功能，预计什么时候上线使用，全都是策划来决定的，程序提供的时间，仅能当作开发计划的参考和规划时间。当然，程序在规定的时间内没有完成任务，沟通无效，不是可以上报给项目经理的嘛。
所以，作为程序员，我们更希望的你问我们 “你希望我给你多长时间来完成这个东西”。
三、为何内部项目总是被吐槽
在很多时候我都纳闷，为何系统做完了，功能也有了，为什么上线使用后，会有这么多人不满意，存在这么多槽点，我大概总结了一下3点：
1）将就 ；2）无趣且麻木；3）需求方的意见太过于重要
1、不管是在开发时，还是测试时，对于我接触过的内部系统，如若开发过程中某些功能短时间内存在技术挑战，程序会说服策划选择另一种方式做，货牺牲此功能委曲求全。内在原因是程序不愿意或没有办法快速的完成，直接原因是策划容易被说服，被洗脑，从而选择妥协。作为程序的我当然首先检讨自己能力不足，并努力改进，但同时也相对策划说，程序在选择和你坦白时，他其实是想问你有没有其他的备选方案，就像女朋友问你今天吃什么，你总不能说随便吧。
2、每天面对这么多内部系统，需求方和使用方的范围，总不会超出大多益，所以一眼望去所有的内部系统，风格都相差无几，网站部内的同事都能自报家门，说我维护的是哪个哪个系统，我做了什么什么功能，但对于其他部门同事而言，或许他们只把我们所有的产品统称为：“OA办公系统”。
说来惭愧，我曾经面试过某公司的策划，但无奈知识面比较窄没被录用。但我在等待面试时，遇到过他们公司的一些策划，经常来回走动询问工作进展，或者抱有一堆调研资料和分析结果图表，有的在会议室里跟程序员热火的讨论着他们将要完成的某功能，在某个相似的系统里有，分析他们的优劣和值得借鉴的地方。
这种氛围在网站部中，貌似是不常见的。
3、内部系统内部系统，说白了就是公司内部提出使用需求的系统，需求方就是公司本身。有些需求，策划在了解情况后马上反馈给程序去改动完成，然后发版使用。有些小的需求看起来没什么，但很容易对后期产生影响，积少成多，越来越多随意的改动后，导致系统越来越难维护，不得不走上重构的套路。当然，我们不能阻止别人随意提需求，也有的需求提出方提出的需求优先级很高，但还是希望策划们垛位系统考虑，多为自己考虑。
以上提出的几个点，只是很多很多原因中，我觉得比较突出的几点。
做一个系统做一个产品，就像抚养一个小孩，从啪啪啪到孩子出生，从会叫爸爸到长大成人，除非这小孩一开始就被打掉了， 不然程序和策划要陪伴他很长时间的。小孩成绩如何，是不是经常生病，是否能考上名牌大学，出来工作后是否经常收到领导的表扬，很大程度取决于父母的培养和教育。所以，希望大家在造小孩时，不要将就，要多教给他一些新的东西，多见识一些新事物，同时将别人的意见作为参考，以自己的思维来主导这个产品的走向和发展道路。
四、我想对你说
1、一个好的产品，并不是程序主导的，而是策划主导的，程序员只是你们实现伟大野心的垫脚石，但肯定有的结实，有的松松垮垮。
2、程序员都很愿意为策划解释某功能是否实现的，但都十分不愿意跟你解释为什么会出Bug。
3、口头表述的需求，其中种种细节，是否都有记录在案。
4、程序永远都是听策划的，再有毛病的程序员，都不会违背策划的意愿自己生产产品。
5、做系统一定要分阶段，每个阶段不能长，完成阶段性工作后，希望能跟需求方展示和沟通，避免套路越走越远
6、需求方的意见要听，但可以坚决不改
以上内容仅代表个人，不代表其他程序员的想法。如有雷同纯属巧合。也很感谢我叫来跟大家分享自己的看法，同时也给了自己一个回首总结的机会，不仅由衷感叹：活着真好。
最后希望今天分享的内容，能对大家有帮助，我的心愿是，世界和平，谢谢大家~