项目规划
笔者本身是一个程序猿，只不过有时候随波逐流担了些项目经理的活，因此本文肯定还是会有很多的技术相关点，不过总的来说应该还是通俗易懂。笔者
沟通是软件开发中最大的困难之一
参考资料：
需求分析
需求协作
User Story
笔者觉得，用户需求与用户故事是有区别的。假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。那么用户需求是什么，就是能够购买饮料这个动作。而用户故事呢，则是一个过程。譬如用户购买饮料可能对应着多个过程：
- 用户购买饮料成功：
- 用户投入一些钱。
- 售货机显示用户已经投了多少钱。
- 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。
- 用户按了某个亮了的按钮。
- 售货机卖出一罐饮料给他。
- 售货机找零钱给他。
- 用户购买饮料失败 - 用户投入一些钱。- 售货机显示用户已经投了多少钱。- 售货机发现用户投入的钱缺少，并提醒用户。- 用户继续投钱则进入正常购买。- 用户不继续投钱则退钱。从产品经理的角度来说，一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面有下划线的那些文字，就属于不应该出现在用户故事中的系统内部动作: 1. 用户投入一些钱。2. 售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。3. 售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料，对于钱足够买的那些饮料，对应的按钮的灯就会亮起来。4. 用户按下一个亮起来的按钮。5. 售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减 1。6. 售货机找零钱给用户。不管是口头描述的，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别的，千万不要提及任何有关数据库，记录，字段之类的对客户一点意义都没有的东西。但是，笔者是从项目规划的角度来说的，那么就应当把包括数据库以及开发中的注意点也包含在一个 User Story 中。
User Story Mapping(用户故事地图)
产品原型与流程图
灵活的设计稿
接口文档
技术架构:选型与预研
在技术选型上两种人是比较危险的，也是两个极端，其一是典型的保守主义者，死守着自己已掌握的技术，畏葸不前，不管整个技术变革的浩荡大潮，宁可用已经被淘汰掉的东西。其二是典型的激进主义者，唯新是从。笔者也是个典型，三年前第一次创业时候就尝试着完全用 Cordova 开发一个社交软件，自然死的连渣都不剩下。技术选型时，笔者自己考虑的原则为：
- 降低新技术的比重通过这样一整套新架构决策流程，我们能够确保自身使用的是最便捷且最具知名度的解决方案——除非没有选项能够供我们挑选。我们会尽可能避免进行全盘技术更换，单单是有趣或者令人激动是不足以使其进军生产环境的。
- 减少以自我为中心的态度与代码审查一样，架构审查流程同样具备协作属性，这亦有助于将技术设计建议由单一工程师或者团队转移至规模更大的协作团队的整体观点，从而打造出与个人兴趣无关、而真正切合买家与卖家需求的解决方案。
- 增加审视角度通过鼓励全公司所有工程师参与到架构审查中来，我们得以激发更多程序员的积极心态，特别是那些不会直接接触到新型技术的同事。通过这种方式，新项目开发团队往往能够跳出固有思路，得到来自全新角度的解读与启示。
- 提升认知水平与日常代码审查类似，架构审查也能够确保 Etsy 公司的每一位工程师了解技术堆栈中不同组件的工作方式以及决策制定理由。
技术负债
技术风险
技术风险对于使用的开源 特别是二次开发中有点类似于抽象漏洞定理。
正确使用开源项目
开源的意义毋庸置疑，但是不可否认，像笔者这样的"不负责任"的开源贡献者不在少数。
技术预研与可复用性
功能的模块化与界面的组件化，笔者在自己的
开发管理
Workflow
任务分配
进度估算
笔者看很多程序猿在估算自己的进度时候
需求变更与迭代开发
不可能有不中途改需求的产品经理，特别是在初创企业中。
从之前的敏捷开发到现在的精益开发，都秉承着一个核心概念就是快速响应、最小化测试。
进度追踪与反馈调整:随便扯扯
笔者在自己经历的大大小小十来个项目中，无一例外的没有把周报制度推行下去。我觉得对于周报制度给我的感觉就是道理大家都懂，但是尼玛推行起来就各种烦躁。形式不重要，重要的是讲清楚事情。
- 本周做了什么：做了什么不重要，而是要汇报做了事情的结果
- 下周要做什么：同样要汇报预期结果，比如跟谁讨论什么什么事情，为什么要讨论，讨论之后要达到什么结果
- 遇到了什么问题: 遇到了什么问题，怎么解决，需要谁的配合，是否需要上级的支援可以考虑金字塔思维方式，先汇报结果(项目的进展，项目的情况，项目的结论)，再汇报论点，再汇报论据。