新手笔记-持续改进实践：开发计划的改进

标题：网站开发新手笔记-持续改进实践：开发计划的改进

关键词：网站开发、开发计划，过程改进，过程实践

       7月12号：越来越懒了，夏天的太阳就是让人懒懒的不想动……

 

真相总是杂乱无章，支离破碎，漫无目的，乏味的……，真相永远不会有趣，因此我们需要艺术。（引自高盛公司《关于中国与世界的五大神话》）

 

过程改进，CMM，诸如此类的名词在无数地方被人谈论着。有个朋友告诉我，在他每一次面试项目经理的时候，无论是大公司，还是小公司，都要问他是否了解CMM，是否了解ISO？可见这些名词的热度有多高。与此情况类似的是，几年前XML开始热起来的时候，很多人言必称XML。可是真正XML这玩意对项目，对组织来说有什么意义？我想并不是所有人都回答的出来！

在我的理解中，其实这些东东并没有什么特别的地方。书本上也早就告诉过我们，CMM的核心之核心就是改进，什么组织改进呀，什么过程改进呀，其它的可以放到一边（除非你们的公司要去想办法通过这类的评估或认证）。XML更是什么都不是。所有理论与标准对你的技术与管理方面的实践都只具有指导作用，最终有用的还是要开发人员在组织内部，项目过程中切合实际的方法，策略，才能真正实现。

下面的笔记主要是比较了两份不同时期我为网站开发制定的工作计划。而制定工作计划的方案都是具体根据对网站开发工作的理解，对工作任务的切分，对人员能力的计算。并且最重要的是，可以体现过程改进在工作中的具体应用。

简要介绍需要定制工作计划的任务。两个月前，我接手的网站之后的第一个正式的任务是要完成频道A。制定频道A工作计划并完成之后，通过总结，得出了可以进行改进的方面。紧接着的第二个正式的任务是完成频道B。下面就以技术部门为频道A与频道B定义的开发计划为例，简要的说明网站的技术部进行的过程改进实践。

频道A开发之前总结的问题

开发频道A之前网站进行了一次规模很大的改版。改版过程花费的时间几乎是开发计划中定义的开发时间的三倍，进行改版的同时，网站开发部门还要处理网站的日常维护工作。由于工作量大，并且工作的组织比较混乱，几乎每一次交给网站部门的工作总是一拖再拖。这种情况下网站开发部门给其它部门的印象就是开发计划的制定与没制定没咋子区别！技术部门从各个方面了解情况之后，总结出问题可能在以下几个方面：

a)         任务划分的尺度不正确

改版是一个非常大的工作任务，而当时配备进行网页的开发人员只有与两人。在这种情况下，定义的开发计划时并没有将大的任务切分成小的任务，进行分步的提交确认。所以最后出现的情况是，在拖了一个月之后完成的所有页面开发之后，统一的内容测试与确认后又一次性的提出了超多的修改意见，再花了两个月的时间改，再提交，再改。计划的拖延可想而知。同样问题其实在软件开发的工作中也遇见过。对应的解决方案无非是根据可以参与开发的人数，正确的定义任务的细度。找出一个合适的切割任务的方案。

b)        需求文档不完善

网站内容生产部开发的需求文档是“创意十足”，可是开发文档形式的创意对开发部门来说就是一场灾难。没有统一的文档模式，没有统一的说明方法。并且绝大部分情况下内容生产部的同仁也并不清楚是否将需要表达的东东说清楚了。于是开发的过程中，反复在开发过程中找技术部门进行确认，浪费了双方大把的时间。

c)        开发过程不透明

开发人员按照自己的想法进行开发，与内容生成部门同仁进行沟通，但是领导们并没有一个渠道去随时了解各个过程的开发到什么程度？而是通过开会过程中的相互扯皮来了解工作进度。导致所有人对开发进度的信心不足。

d)        需求经常根据时间在进行变化

网站信息发布是一个非常灵活的事情，当你开发出页面进度无法得到保证时，需求的经常进行变化就可想而知了。在前一期的开发中，经常出现的现在就是完成一个阶段任务过程中，开发人员要不断的与内容生产部门的人员确认需求，确认完成之后，又出现需求变化，又要改，无法上线，过了一段时间改完之后，上一期的需求已经过时，又出现新的需求……，开发与网站内容两边都叫苦不迭。

 

 

频道A开发计划

总结上面提到的问题之后，技术部门针对上面各点分别做出了一些对策。比如制定需求文档模块；培训内容生产部的使用需求文档模板；过程交互强制采用MAIL的形式，并抄送给各个相关部门以统一工作进度；将任务合理的分成几个较小任务，等等。在这种普遍改进的背景下，频道A的开发计划出炉了。虽然没有解决所有的问题，不过应该说已经运用过程改进的方法改进了工作交互，改进了工作的流程。

²     频道A的开发计划

频道A的开发任务被分成四个小的任务：栏目A、栏目B、栏目C、栏目D。技术部门分别为这四个任务定制了开发计划（以其中一个开发计划为例）

“栏目A”工作计划：

                         i.              需求+设计；（涉及部门：内容生产部+技术开发部） A天 （需求讨论，形成设计文档。）

                       ii.              美工页面开发；（涉及部门：技术开发部美工组） B天 （根据设计形成美工开发的页面）

                      iii.              数据准备；（涉及部门：技术开发部数据组） C天  （准备提取数据的数据库语句，或存储过程，并采用加速程序生成静态的信息数据文件。II步与III步是技术两个不同的组同步进行开发的。开发计划中安排的时间也是重叠的。）

                     iv.              页面整合；（涉及部门：技术开发部页网开发组） D天 （将静态的信息数据文件与美工页面进行整合，形成最终页面）

                       v.              测试；（涉及部门：内容生产部+技术开发部） E天 （两个部门共同协商，完成测试与修改工作。）

 

上面定义的开发时间都是在以前的开发经验上定义的（由于我以前制定的都是软件工作计划，网站的开发计划还是第一次制定。所以上面的开发计划有纯软件开发的影子。）

²     完成频道A后遇见的问题

第一期结束时，我们完成的任务的情况大概是这样：

²        栏目A：定义时间是三个星期，最后是晚了二到三天完成；

²        栏目B：定义时间是三个星期，最后是晚了二到三天完成；

²        栏目C：定义时间是三个星期，由于前面的栏目开发时间过长，最后是晚了五个工作日完成；

²        栏目D：定义时间是一个星期，由于前面的栏目开发时间过长，最后晚了七个工作日完成。

 

虽然晚了很多时间完成，但是相对以前的开发过程已经有了一定的改进。由于初步体现出了过程改进带来的好处，所以我们并不沮丧。并且我们在开发过程中又总结了很多的经验与教训，可以将这些经验带入下一期的开发过程中，以实现持续的过程改进。

总结出的经验教训主要有：

Ø         没有抓住网站开发特点，将确认与修改过程制度化

通过几个小任务的开发过程，技术部门已经总结出一个规律。虽然内容生产部门各个同仁的适应技术部门定制文档，流程的能力并不相同，但是平均下来，每一个小的任务都需要二到三次的确认，修改过程才可以达到上线的程度。总结出这个规律之后，可以在开发计划中加入确认的流程，以定义出更符合本公司网站开发实际的制度化的开发流程。

Ø         内容生产部门同仁的责任不明确

频道A的开发计划中，只在I，IV中涉及了内容生成部门。实际情况是内容生产部门的同仁在每一个步骤中都要发挥主导作用。但是就算是在这两步工作计划中，定义的完成任务的责任人都还是技术部门的同仁，更别说其它的工作的步骤。这种情况的后果就是开发时责任不明确技术部门非常的被动。很多的东东等内容生产部门的同仁的拍板，但是内容生产部门的同仁由于没有明确的责任，对技术部门的问题并不能保证及时响应。总体来说这个问题涉及到管理上的问题，需要技术部门与内容生产部门进行管理上协商。工作计划的执行过程由于有一部分的参与者的责任不明确，最后完成时发生延误的现象也就不奇怪了。

Ø         任务完成的时间没有明确与上线时间结合

测试这个词在不同的地方有不同的含义。并且网站上线的时间点是所有的人最为关心的时间点。上面已经提到过网站栏目有很强的时效性，也就意味着很多情况下，根据时间的进行微小的调整不可避免。所以网站的测试与软件的测试不同，需要进行微小的调整的流程分离出，移到网站日常维护的流程中，安排其它的人进行处理。测试完成的时间应该是晚于上线时间，所以对应需要进行开发计划的修改。

经过总结与讨论，技术部门进行了第二次过程改进，修改了开发计划。并配置完善了很多的过程中需要加入的文档。进入了频道B的开发过程。

频道B的开发计划

1.      频道B的开发计划

频道B的开发任务被分成五个小的任务：栏目I、栏目II、栏目III、栏目IV、栏目V。技术部门分别为这五个任务定制了开发计划（同样以其中一个开发计划为例）

开发“栏目IV”：

                         i.              需求+设计；（涉及部门：内容生产部+技术开发部） A天

                       ii.              数据准备；（涉及部门：技术开发部数据组） B天

                      iii.              美工页面开发；（涉及部门：技术开发部美工组） C天

                     iv.              美工页面确认；（涉及部门：内容生产部）D天

                       v.              页面整合；（涉及部门：技术开发部页网开发组） E天

                     vi.              第一次综合确认；（涉及部门：内容生产部） F天

                    vii.              修改问题；（涉及部门：技术开发部页网开发组） G天

                  viii.              第二次综合确认；（涉及部门：内容生产部） H天

                     ix.              修改问题，上线；（涉及部门：技术开发部页网开发组） I天

 

可以看出，频道B开发计划是带上很强烈的网站开发过程烙印开的开发计划。主要加强的部分是对应频道A开发中总结的问题进行处理的。

Ø         对应内容生产部门三次明确的确认过程，并写清所承担的责任。

以上的步骤IV，VI，VIII步都是为内容生产部门定义的明确的计划任务。并且技术部门为其定义了确认文档的格式，以统一流程。

Ø         写明上线的时间点，并且规定上线时间是栏目开发的最后时间点，其它的修改将转移到日常维护的流程中

将开发与日常维护分离，使得开发的成果在合理的时间上线，满足各个部门的需要。

 

相对频道A的开发计划，此份开发计划执行起来比较明确，可操作性比较强。

并没有结束的改进过程

改进过程永远不会结束。也许在频道B的开发过程结束之后，技术部门与业务部门的磨合程序更高了之后，我们在可以找出更好的开发计划的制定方法。

 

差点忘了写我为什么用最上面的一段话作为这篇笔记的开头了。一开始其实我只想将“真相总是杂乱无章，支离破碎，漫无目的，乏味的……，真相永远不会有趣，”引进来，是因为我觉得只有理解这些才能理解持续改进的想法。事情总也做不好，不是谁的错，不是谁笨，而是过程不合适，而是真相本身就是杂乱无章，支离破碎，漫无目的，乏味的……，所以我们需要的只是改进一点，再改进一点，最后找到最合适自己的方式。就从现在开始吧JJJJ