想请问软体业的前辈 你们怎麽决定现阶段的开发已告一个段落，可出一个给客户的版本呢？ 这问题源自我们团队似乎还找不到一个好的流程 团队是这样子运作的 我是系统分析师 + presale 技术总监以 1.5 个月为一个开发周期，订好这段期间要开发哪几个功能 比方说 B、C 两个新的，附带上一个周期 A 功能里的 2 个小改善 大家若看过我之前的发文可知道，我们不是专案 所以在决定 B、C 功能到底具体来讲要达成什麽，需要蛮大的想像力 我尽量以 presale 时被多数客户提到的情境来设想功能细节 所以这个阶段我需要跟开发人员沟通、以及提供 prototype 请大家就这些部份列出计画，再估计时程 周会时再跟总监、专案经理与团队讲述这部份的情况 这时有些变数 总监偏重技术上的设计有没有合理 专案经理在意提供的功能够不够丰富 所以经常会议开完後 得回去再确认这样子设计好不好、或是某个功能有没有做进来 这样子的往返通常会花一两周，包含我跟开发人员的想、写、画、改 当整体要做什麽都确定後 再根据个人估的时间，看看 deadline 前可能完成哪几项，大家再开工 开发过程中会冒出一些影响到原有好功能的 bug 或是牵连到底层设计的状况需要 refactor 因此实际开发时间通常会比大家原本预估的还久 又因为我们系统有提供给公司内部使用 所以开发过程中也得岔出来处理公司内部更新的事 当老板问到现在开发情况如何？ 专案经理很希望给同事『尝鲜』新功能 所以他希望我们经常更新公司的系统，某功能部份完成的话就先上去 另位系统分析师觉得不妥，因为新功能还没被完整测过 但专案经理坚持应提供给公司同仁新功能 所以过去曾发生过一更新上去很快被老板按出 bug (冏rz) 我还私下被老板找说我们的测试流程是怎麽样呀 ^^;; 在我的坚持之下，专案经理找了支援部门的同事当 QA 才让新功能有把关者 但这又牵扯出後面的问题，就是 QA 一定会测出不少 bug 所以开发後期有很长的时间在 debug 此时离表定的 release 将近 专案经理会把过去周期没空做，而他觉得重要的再加进来 这边经常会出现的情况有 1. 到底要改成什麽样子？ 比方有些是专案经理觉得某功能不好用，要开发人员改 但对 coding 的人来讲，他很难知道要改成什麽样 专案经理本身没办法给什麽好建议 我们去找视觉设计部门的同事，她也有其它部门专案的东西要设计 所以她希望我们直接跟她讲要改成什麽样子 总监跟专案经理都没有好想法，但又觉得这个很重要 所以变成我负责想 这种『某某东西不好用』，主要跟 usability、互动设计有关 我也是待在这个团队後渐渐学到这是另个领域的东西 我会蒐集资料，提出几种改法跟可能遇到的问题 跟大家讨论(主要还是总监、专案经理、设计人员) 但经常发现讨论到最後也没结论 结果就不了了之....但时间已经花下去了 这个循环每隔一个周期就会冒出来一次 2. 功能开发出来後，专案经理发现哪边应该要再加什麽 or 改什麽才会更好 此时人力已经吃紧在 debug 了 我、资深开发人员齐建议专案经理，应以稳定系统为优先考量 至少要测过目前的系统，不要蹦出错误 or 让 flow 走不下去 我说，即使是一般的专案，客户中途想改需求也得填需求变更申请 否则时程会一直 delay 专案经理说，他觉得产品开发跟专案不一样 产品若功能不好的话，客户就不会想买 所以最好能尽量在这次 release 时提供给客户这个功能 那麽我们问说，时程可以延後吗？或是把这次要提供的东西变少？ 通常得到的答案都是『尽量赶』 所以究竟是完成 issue 才叫 ready？其实并没有答案 我也曾经问过，我们总是对 1.5 个月的开发周期开天窗 也许是要做的事根本 1.5 个月就做不完 那这样为什麽不把周期拉长呢？ 专案经理说，产品应该要经常 release，这样客户才觉得这产品是活的 虽说这个出发点是好的 但总觉得我们团队现有的流程离这个目标还很远 尤其发现有段时间的 release 都是 bug-fix 新功能反而不多，也不知道是不是哪个环节出了问题 呼..一口气写了这麽多 无非是希望藉诸位前辈的经验来帮我们团队看看问题出在哪 面对辛苦又无助的团队成员，很想帮大家做些什麽好改善状况 也希望自己可以有比较正确的软体产品开发观念 或是哪边可以有所改善精进 谢谢大家! ※ 编辑: statuette 来自: 59.104.88.225 (01/23 23:35)