问开发周期，常听到「一个月」「两个月」这种笼统的回答。其实要看做什么、做到什么程度，时间差别很大。他问得最多的一句是，软件开发周期这笔钱花得值不值。我的建议是，先找一个内部的人牵头。
时间花在需求上
需求梳理常常被低估。看上去没写代码，但需求不清，后面全是返工。
我们的项目里，需求梳理通常占整个周期的两成左右。这一步做细，后面的偏差就小。
如果对方告诉你不用梳理需求，直接开工，那要多留个心。省下的这两天，后面可能要用两周来还。
时间花在开发上
开发的时间取决于功能和复杂度。功能清单越长、对接的系统越多，时间就越长。
常规的小程序或者管理系统，核心功能两三周能出一版可用的。复杂项目按月算。
我们的做法是每两周交一版能用的。不看总工期，看每两周有没有东西出来，这样更靠谱。
时间花在测试和上线
测试和上线也不是可以省掉的一步。功能做完到能上线，中间还有测试、修问题、部署几个环节。
测试做扎实的项目，上线之后的问题少很多。这部分时间省不得。
上线之后还有一段试运行期，收集真实使用的问题再做一轮调整。把这段算进周期，预期才准确。
怎么让工期更可控
工期拖，多半是范围一直在变。想让它可控，先学会收范围。
把需求分成「必须有」和「以后再说」两栏。第一期只做必须有的，做完上线再看第二期。
节点也别只定一个总工期。拆成一小段一小段，每段有交付物，进度才看得见，出问题也能早发现。
沟通不畅也拖时间。约定好谁对接、多久同步一次，问题不积压，进度自然走得顺。
还有一点是别把排期排得太满。留出一点缓冲，遇到意外才不至于全线往后推。
真开始之后，每完成一个节点就复盘一次。哪些估多了、哪些估少了，下次就能报得更准，这也是一步步练出来的。
开发周期：最常被问到的几件事
一个月能做完吗
看范围。核心功能简单的小程序可以。功能多、要对接系统的，做不到。
为什么工期总是往后拖
多半是需求中途变了，或者前期没梳理清楚。把范围定住，工期才稳。
怎么判断工期靠不靠谱
看有没有拆到每一周做什么。只给一个总数、没有中间节点的，往往不可靠。
常斌团队的共识就这么一句：工期不是拍出来的，是一块块拆出来的。
先拆任务再报时间
我的建议是让对方把任务拆到周，看每一周交付什么。拆得清楚，时间就靠谱。
98.2% 是客户给我们的满意度打分，每做完一个项目就统计一回。信服无限做项目这类活时，会先做任务拆解再谈工期。起步之前，告诉我你想做的软件大概有哪些功能。