当老板喜欢研发过程规范化,该怎么办

有一个过程改进的方式,就是通过反思会议.

只针对已经发生过的实际情况进行反思.

1.好的措施,也就是以后需要坚持的.
2.不好的地方,以后需要改进的.
3.值得尝试的方法

即便听上去不错的注意,如果没实际发生过相应的问题,
就不去考虑.

定期进行逐步积累,这方式的优点在于很好的适应性.

(这些想法主要来源于Alistair Cockburn<敏捷软件开发>)

我贴在这里，夏昕和晓钢应该不会有什么意见。

请君入瓮还不阴险啊 ?

认真的说 你老板的这个愿望 不是通过"过程规范"能实现的.   

其实你能做的很有限. 唯一能让你老板看到结果的就是 保存下大量的文档. 这对小项目的开发其实是弊大于利 甚至可能让公司彻底死掉.

有的事情需要认真 有的事情必需学会敷衍.

阴险没有看出来.文档也行会留下不少.
敷衍的后果谁都知道.

to jack：
做好软件的配置管理永远是一件大事情，你们如果真心希望走研发过程正规化的道路并且取得实效，就按照我说的先把配置管理的工作做好。先把版本服务器配好，然后按照上面这篇文档的指导把持续集成的环境建立起来。

关于配置管理，我再推荐一本书：
《软件配置管理模式》，这本书在 Amazon 上面被列为五星级。我也认为是很有帮助的一本书。这本书中介绍的方法完全可以与 XP、RUP 等流行的开发过程紧密结合起来。
http://www.cnforyou.com/query/bookdetail1.asp?viBookCode=12933

我们还是继续接在以前的这个主题后面讨论吧。jack 把沙盘推演的帖子重新发一下。
这确实是一个非常有代表性的问题，我相信是可以讨论清楚的。

根据前面的讨论.
剩下的似乎就是一个怎么做的问题了.

但是 怎么做呢?
由于老板极不会说话,和他说话的时候很多时候需要猜测他的真正含义.
今天又和他聊了聊,发现.让我提交文档的主要目的是为了"推演"!!!!
他想知道是一些规则实施之后是否有效,以及如何作些风险防范.和带来什么风险.他并不关心规则实施的过程.

因为他不懂,所以无论我说的如何好,他都不相信. 这个是他的原则. 他需要一个接近可以执行的方案,然后用各种问题去考验这个方案.看看这个方案是否足够健壮.能否到达他需要的目标.

这个就是"兵棋推演". 提出一套作战方案,先在假设的时间中,但是真实的环境中进行演练.最后能够胜出的.才能够去实施.
说实话,"推演"这步,从未想过要放到台面上来做.总觉得设计方案的时候,已经在考虑各种情况出现是如何解决得了.
这样的推演过程,实际上也就是一个"说服过程",常在很多帖子中怎么推广某某技术,某某方法.很多人都会提到要"说服老板",但是怎么"说服"从未看到过...........,或者从未明确的提到过.


推广新技术的时候,可以做一个新技术构成的Demo演示下,同时说明下新技术的各种优缺点.
推广新的技巧时候,实际演示给同事,给老板看,让他们看其成效.
推广新的方法时候,方案的推演,应该是最好的说服过程了.因为新的研发方法的实施需要过长的时间,过多的人力.而且不是马上见实效.嘴上说的再好,不如作些预演练.

这些研发过程中推广新技术,技巧,研发方法论的过程是如此的一致性.
研究理论->推演->实施
新技术推广,新技巧推广,这个过程我异常的明白该如何做.不知道为啥,愣就是没有搞明白新的研发方法的推广怎么就卡壳了. 原来"如何说服"早已经用了不知道多少次了.只是对象的不同而已. Mad

真是有点傻兮兮了. Wink

PS:想搞清楚一个问题,与其努力想,不如努力写.这个也是我续贴的主要目的之一.

这样的可能下场我也清楚,我很清楚这次是一个试验,但是他在做试验,我未尝也不是在做试验?对于这个我早有心理准备.
我前面也说了,我不太喜欢有很大的改变.特别是研发方法这种框架性的.如果说老板拿我做试验品,那么他差不多也就是逼我改变一些管理或者做事情的方法,这个未尝不是坏事.
的确技术出身的老板的确有很大问题,
一个对技术的干涉太多.
另外一个当老板也参与开发的时候,我当他是老板,还是普通的研发人员呢?
老板参与项目过程过多实际上是一种很麻烦的事情. 我很明白我已经遇到了.

这个蛮抱歉的,因为我很少参与这边的讨论.所以给你带来了麻烦了.
现在可以把另外一个贴删除了,内容我已经全部转过来了.

预防风险? 预防什么风险呢?
研发这块的主要风险主要也就是"文档和源代码丢失泄漏"和"关键开发人员流失"2项为主.
综合最近发生的一些事情,BOSS明显的能够看到的风险就是人员变动带来的风险.
前面提到过,目前的公司是1研发+1市场合作的方式来开发项目的.

如果研发人员突然失踪,那么保证项目"按原定下的速度"继续开发为第一要点.这个就是BOSS明确表示的一点.
同时如何保证"每个项目开发速度的合理性"这个也是BOSS明确表示的一点.

一般来说,开发人员流失,必然会影响项目进度,在短期项目中,这样的影响是非常的明显的.
如果小A负责开发B项目,时间是一个月.小A于项目开始了2周后离开. 如何保证B项目于2周后正式完结.
由于项目周期很短,同时其他开发人员如果正有事做的时候,无论怎么调遣,那么不是B项目延时,就是其他的项目延时.

风险防范方法:
1.在项目相近的情况下,开发相同的底层模块.给每一个研发人员使用.
2.从开始就添加人员到B项目中.2人以上共同开发.
3.公司内部研发人员之间互相做有关手上项目设计的培训课程.相互熟悉和相互学习.
4.从制度上规定,不做完手中项目,不可离职.
5.保有充足的研发人员.
.
.
.

符合以上的要求之后,实际上还必须有机动人员能够去调整.而且第四条只能防范恶意离职的情况,防范不了生病啊,受伤这些非主观因素带来的使得研发人员无法正常工作的风险.
在座的各位,应该还有不少的方法来防范研发人员流失带来的问题.
不过对于小型项目,防范的同时,还要保证不延时.这个.....

回到推演这个步骤,我需要列出全部的风险,风险产生的原因,风险发生后的后果,和如何去解决. 不然难过推演这关.
不过疑问来了,我一个研发管理的人,怎么搞着搞着在解决风险问题了?糊涂了? 项目经理的职责到底是啥?

(如果资源不足带来各种问题,告诉上头,需要什么资源,要多少,什么时候要,和为什么要?)

这里如果我没有搞错的,大概是一个小型公司的毛病,人员职责不明确.如果我有搞错,请各位告诉我.


保证"每个项目开发速度的合理性"这点,首先我想到的是各种各样的官样文章:shock:

"为了保证A项目的顺利进行,我们采用了XX新技术,投入的多少多少人力,在遇到怎么样的困难之后,设法解决了XYZ的困难,不分昼夜的加班加点,终于在预定的时间内完成了A项目的开发."

如果把项目开发和产品推出之后bug的修改这两个割裂开来看的话,项目开赛速度的确很稳定的.但是不同的客户,不同的做事态度,不同的测试态度,不同的使用心态,最后的产品反馈的bug数量,甚至有无需求的改变都是完全不同的.

研发这块当然无法约束客户的所作所为,唯一能够要求的就是市场这边加强对客户的亲密度,以期在客户试用产品的时间内发现够多的Bug,以及在项目开始时完全确定其需求.

难道要定下这样的规定,如果客户测试出的bug数目少于本公司的项目bug平均数,不得正式开始使用本公司产品!!!.

客户测试出来的Bug数目多少问题不大,测试出来不合他们的初始需求,或者漏掉需求才是问题最大的,而且一般情况下,一个项目外面测试的时候,已经在准备第二个项目了.如果客户测试不及时,那么就会出现第二项目进行中的时候,发现第一个项目需求不对的情况.这个时候是不理继续第二个项目,还是回头猛改一通?

当然会出现这样的情况的主要原因之一,除了客户之外,就是项目周期短所致的. 这种情况出现的不少,市场那边我也教育过不少回(虽然不是同一个部门的,但是对我这边影响实在巨大,不得不教育!).
这些大概也是各位所没有遇到的情况之一了.