ProjectManagement

《走出软件作坊》

2

《走出软件作坊》,说实话,我第一次看到这个书是在书店里,还以为又是那种骗钱糊弄人的炒作书籍。没看。等到时隔1年,偶然在豆瓣上看到这个书的书评竟然如此之好。再一句:“三五个人,十来条枪,如何成为开发正规军。”这句话一下子让我感到了共鸣。虽然我在一个有“十年历史”的软件公司,但这个公司着实没有在十年里迅速发展壮大到“正规军”,和大部分企业一样,买个CMM2,搞个ISO,然后弄一大堆“国家信息技术试点企业”之类的牌子,其实做的就是低劣软件作坊的工作和流程。来这个公司说实话,有点偶然,因为2009年的个人问题、工作问题等等一切不顺利,找工作非常没心情,自己的学历、技术完全不行的情况下,就随便找个地方“别饿死”了。但没想到我呆到现在。期间经历了公司那么多同事的离开,很是难过,但公司的政策跟大部分小公司一样:留住中层,底层开发人员有的是,尽管低工资就是。

读者热评中摘录书中有这么一句话:当你从这个大家嘴里的破公司离职的时候,心里默默的想,这个公司肯定不久就倒闭了,但隔了三五年之后再看,这个破公司还是那么半死不活的开着,业务没有大发展,但也没有惨淡到关门。这不就是描写我在的公司么?公司实行CMM2不可能,人员轮换太频繁,再说CMM2早已过时。大家就用最原始的方式在工作,不敏捷更不文档化,开发出来的东西客户评价很差,返工,修改是小事,几次出现客户因质量、延期等问题终止合同。人员频繁流动造成公司没有积累,没有稳定团队;电脑陈旧到7、8年的电脑还在做为开发人员的电脑,清一色17寸CRT显示器;公司三级管理,但执行效率相当差;管理制度存在严重问题,不是过于严格就是无法执行、连篇累牍;中层成员思想守旧、懒于更新知识;公司人员忙忙碌碌一年,累得半死,工作效率很低很低;营销人员外出没有脸面,做出的东西送给客户只能挨骂,回来再找开发,开发也一脸委屈;硬性要求纸面需求确定之后再做开发;……一时间都难以再罗列这些问题了,但这些几乎都在中小型IT公司或多或少出现过。

这本书几乎都涉及到了相关的问题,当下决定买回来看看。我知道这本书不可能是我在的公司的“银弹”,但是会给我启发,点醒我很多作为一个普通员工在这种企业到底能发挥怎样的作用,去实现自己的价值和理想。

我会找机会推荐给我的领导、老板看看,大家凑在一块不是这样半死不活的混着,而是要把这“三五个人,十来条枪”变成“正规军”在本来就很复杂的中国IT市场拼杀,客户满意,老板赚到钱,员工得到应有的收入并实现自己的价值,这才是我们要的。

但愿未来的日子能一切顺利。

ps: 本书在豆瓣的地址:http://book.douban.com/subject/3319935/

2/3的项目总结

2

项目概况:网上商城项目,类似知名的凡客诚品。但网上商城经营种类繁多。.net开发,数据库为SQLserver2000。开发时间大概60工作日,大陆货的项目。但是搞的很累很费劲。

总结:

1.项目对目前的团队基本是全新的项目,在没有任何人参与过完成商城开发的基础上,项目经理(或者架构师)应该对整个项目有至关重要的作用,业务流程必须明确、清晰,所用技术(框架)也应该是团队相对熟悉的。

2.客户的需求分析不明确的时候,尽量确定小型、频繁的迭代(Scrum是非常合适的),短周期的迭代、确定的小目标、可演示的Sprint成果可以帮助客户明确需求,更减少了到项目交期客户反复变更/增加需求造成的反反复复,磨磨蹭蹭。

3.产品经理或者营销人员,要针对项目预算,成本,跟客户良好的周旋,防止6万的项目做成10万的工作量,同样让客户满意,并知悉软件劳动同样“花多少钱买多少功能”。

4.文档是非常重要的东西,但要看情况,文档有时候反而会成为项目的羁绊,项目组成员会让文档“烦死”,就像小学时候恨写作文。单独的文档工程师可能没有必要,但项目中后期,项目经理或者开发的Team Leader需要注意整理文档,对内是项目各模块间的接口文档和测试用例,对外最重要的是“帮助文档”,客户可能不知道我们开发时候有意或无意的对需求进行的“灵活”处理。

5.如果你是客户,不要吹“牛逼”,虚心是重要的,当讲则讲,就算你是客户,也用不着当上帝摆谱,否则只会显示你的无知和空虚,三两鸭子二两嘴。(该条总结属于我唠叨,过过隐。)

6.软件是长出来的,不是开头就一份需求分析确定的,作为软件开发方,需要以服务的姿态对待客户的变更,在成本允许的情况下,尽量满足客户。谁都不是圣贤,最初的需求分析也就是项目过程中的一个Alpha版本而已。

先总结这些吧,毕竟项目没完全完成,2/3的总结更像突然的“头脑风暴”,仅仅作为临时笔记而已。

抓紧学习,努力前进。

ps:去他妈的光棍节。人都没事装什么寂寞,天天有妞泡的人到了光棍节才他妈的兴奋。

Go to Top