问：刚入行的程序员，如何才能装得像个老鸟的样子
答：很难！但如果你能在接到需求之后先琢磨点时间，再提出一两个问题，人家一定会高看你两眼……
对一个项目而言，新人通常会以为最难的“实现功能”，但实际上最让人头痛的，通常是“需求”！
为什么会：返工返工再返工，加班加班再加班？
飞哥是做过律师的……深知：精确的表达，是一种能力！而大多数人并不具备，(坏笑.jpg
请同学描述：源栈的红包政策
代码要不要注释，可以两说……
但没有文档是绝对不行的：
谁来写需求文档？
最常见的“作坊式”写法：一张UI图片，加点描述说明……
深刻的理解语言的局限性：
PS：判例法 vs 成文法
说实话，从业十多年来，我没看到过优秀的需求文档；但哪怕是稍稍过得去的测试文档，也让我耳目一新！
测试文档的写法：（示例：注册）
能不能把需求和测试两份文档合二为一呢？本质就是把描述和举例（但要求穷举）结合起来！
重要的事情说三遍，不是：猜！猜！猜！
business logic is illogical，你猜不出来的。
我碰到过最奇葩的一件事：直接改我的文案，因为他觉得……
沟通非常重要。事前不沟通，事后板子要打到你身上的，
更高的要求：你是专业（professional）人士，客户没想到的，你要能想到。
我们的作业，有意识的埋了一些坑（模糊需求），目的就是锻炼大家“挑毛病”的意识，但是如果发现了模糊需求，不用来问我，每种可能性都实现一遍！^_^
再次强调：不是需求模糊！
本质上，为什么需求变更老是被抱怨？因为之前改的那些都不算你的工作量（就和加班不给加班费一样……）
场景：为什么项目延期？
程序员：需求老是改……
产品经理：哪有？我就改了那么一点点……
需求发布/开发/验收三方像签订了合同一样，按约定履行各自的职责，并承担“违约”的责任。
飞哥的应对：自由飞·任务管理系统，使用工具，让一切有据可查。
责任的流转：
作为开发人员，还是只有放平心态。
然后，加强沟通！很多技术上的难点，可以通过业务流程调整平滑实现。
PS：因要求APP背景色根据手机壳颜色变化，产品经理被程序员暴打，^_^
人是万物之灵，其实最难管理。
而编程开发（包括产品/测试）的工作，因为其高度的创造性，极难量化，更增加了管理的难度。
#题外话#很多时候项目的真实情况是：
上班摸鱼，加班干活；
忙的忙死，闲的闲死！
不管不行，但管呢，新人有鸡血但没能力，老人有能力没激情……
还有人员流动的问题：一个项目核心团队交接个几次基本上就散架了！
总是能按时交付，是够一个项目团队吹一辈子的牛逼！
大多数项目上线，总是延期延期再延期，最后要么就崩了根本上不了线，要么就东拼西凑的硬着头皮先上线再说。
如果是外包项目，验收会上演示直接崩盘的事不要太多……
为什么？除了需求不明随时变更，团队水平参差不齐，还有一个很重要的原因：
软件开发是一个创造性工作，这项目很多东西都是以前从来没做过的。你不要以为增删改查写业务逻辑没啥技术含量，说不定哪里就整个幺蛾子出来，直接卡死你。
所以“江湖越老，胆子越小”，越是老人越倾向于老技术，只有新人才初生牛犊不怕虎，各种新技术可劲儿的往上堆！项目初期雄心勃勃，项目结束一地鸡毛……
只是经验之谈：把任务（功能/实现）尽可能的切细。
前提：老大懂技术，最好是大牛
好处：
弊端：老大要花大量的时间切分/分配任务（但我认为是可以接受的，老大不就做这事的吗？）
没有对比，就没有伤害。
程序员年轻的时候，可以适当的跳几次槽，开开眼界。
可以从以下几方面考察/评估项目环境：
无论是最古老的瀑布模型，还是最新潮的敏捷开发，关键点就四个字：井井有条。
注意：不要照搬教科书，敏捷（结对/站会/轻文档……）都已经走下神坛。最好的方式还是因地制宜。
虽然说装备党人菜工具多，但一个项目组，还是应该有一些必备的项目管理工具的，比如jira、禅道、PingCode等，这些工具的功能都有重叠，但总体来说可以划分成：
设计一套打地鼠积分升级通关的游戏规则（其他也行）
多快好省！前端后端，线上线下，名师精讲
更多了解 加：
