C++博客-快乐的天空-随笔分类-项目管理

SCADA/EMS Developer

探路者 — Wed, 19 Mar 2014 03:12:00 GMT

MN to design, develop, test, and deliver software components.

These components are integrated and delivered as part of the EMS/SCADA software solutions.

Help develop visualization software for the Energy industry.

Software will incorporate geo-spatial features and presentation of real-time data.

Will be working with Qt/C++ and interfacing with Java, Oracle, and several other technologies on both Windows and Linux.

Experience with multithreading and multi-tier software is highly desired.

Software developed will have an emphasis on security, reliability, and performance.

Should be able to pick up new technologies quickly.

Will be requested to diagnose and troubleshoot complex software problems.

Will work both internally with other software development teams and will also work with customer project teams.

Excellent communications skills required.

Up to 15% domestic and international travel is required.

Minimum Requirements:

BS in Computer Science, Computer Engineering, or a related discipline.

3 years of experience with SCADA/EMS software programming.

3 years of C++ programming experience.

2 years of Qt programming experience.

1 year of experience with Oracle or similar RDBMS.

Excellent communication skills.

探路者 2014-03-19 11:12 发表评论

产品经理工具集

探路者 — Tue, 04 Dec 2012 13:22:00 GMT

在通用产品的工作，除了你需要一个敏锐的思路与设计思路外，将未来需要的产品的方向、设计、及需求等如何描述出来，及期间与团队共同面对产品的实现过程中，你如何将脑袋中的“货”，表达“给” 或是正确的传达“给”团队成员或是后期的使用者，成为你产品人的艰巨任务，不管是产品部门的管理者或是最小的产品专员及助理兄弟们，对以下的工具正确的选择与使用，或是说为了拼搏在产品一线上，你产品工具的十八般武艺，你必须得会技痒了。

原型设计工具》Axure RP Pro, UIDesigner

流程用例设计工具》Mindjet MindManager, MS Visio

数据库设计工具》PowerDesigner

业务解决设计工具》MS Word

项目统计与计划工具》MS Excel ,MS Project

产品培训与演示工具》 Microsoft Office PowerPoint 2007

探路者 2012-12-04 21:22 发表评论

不要一辈子靠技术生存

探路者 — Fri, 30 Nov 2012 03:59:00 GMT

我现在是自己做，但我此前有多年在从事软件开发工作，当回过头来想一想自己，觉得特别想对那些初学JAVA/DOT。NET技术的朋友说点心里话，希望你们能从我们的体会中，多少受点启发(也许我说的不好，你不赞同但看在我真心的份上别扔砖头啊).

一、在中国你千万不要因为学习技术就可以换来稳定的生活和高的薪水待遇，你千万更不要认为哪些从事市场开发，跑腿的人，没有前途。

　　不知道你是不是知道，咱们中国有相当大的一部分软件公司，他们的软件开发团队都小的可怜，甚至只有1-3个人，连一个项目小组都算不上，而这样的团队却要承担一个软件公司所有的软件开发任务，在软件上线和开发的关键阶段需要团队的成员没日没夜的加班，还需要为测试出的BUG和不能按时提交的软件模块功能而心怀忐忑，有的时候如果你不幸加入现场开发的团队你则需要背井离乡告别你的女友，进行封闭开发，你平时除了编码之外就是吃饭和睡觉（有钱的公司甚至请个保姆为你做饭，以让你节省出更多的时间来投入到工作中，让你一直在那种累了就休息，不累就立即工作的状态）

　　更可怕的是，会让你接触的人际关系非常单一，除了有限的技术人员之外你几乎见不到做其他行业工作和职位的人，你的朋友圈子小且单一，甚至破坏你原有的爱情（想象一下，你在外地做现场开发2个月以上，却从没跟女友见过一面的话，你的女友是不是会对你呲牙裂嘴）。

　　也许你拿到了所谓的白领的工资，但你却从此失去享受生活的自由，如果你想做技术人员尤其是开发人员，我想你很快就会理解，你多么想在一个地方长期待一段时间，认识一些朋友，多一些生活时间的愿望。

　　比之于我们的生活和人际关系及工作，那些从事售前和市场开发的朋友，却有比我们多的多的工作之外的时间，甚至他们工作的时间有的时候是和生活的时间是可以兼顾的，他们可以通过市场开发，认识各个行业的人士，可以认识各种各样的朋友，他们比我们坦率说更有发财和发展的机会，只要他们跟我们一样勤奋。（有一种勤奋的普通人，如果给他换个地方，他马上会成为一个勤奋且出众的人。）

二、在学习技术的时候千万不要认为如果做到技术最强，就可以成为100%受尊重的人。

　　有一次一个人在面试项目经理的时候说了这么一段话：我只用最听话的人，按照我的要求做只要是听话就要，如果不听话不管他技术再好也不要。随后这个人得到了试用机会，如果没意外的话，他一定会是下一个项目经理的继任者。

　　朋友们你知道吗？不管你技术有多强，你也不可能自由的腾出时间象别人那样研究一下Linux源码，甚至写一个Linux样的杰作来表现你的才能。你需要做的就是按照要求写代码，写代码的含义就是都规定好，你按照规定写，你很快就会发现你昨天写的代码，跟今天写的代码有很多类似，等你写过一段时间的代码，你将领略：复制，拷贝，粘贴那样的技术对你来说是何等重要。（如果你没有做过1年以上的真正意义上的开发不要反驳我）。

　　如果你幸运的能够听到市场人员的谈话，或是领导们的谈话，你会隐约觉得他们都在把技术人员当作编码的机器来看，你的价值并没有你想象的那么重要。而在你所在的团队内部，你可能正在为一个技术问题的讨论再跟同事搞内耗，因为他不服你，你也不服他，你们都认为自己的对，其实你们两个都对，而争论的目的就是为了在关键场合证明一下自己比对方技术好，比对方强。（在一个项目开发中，没有人愿意长期听别人的，总想换个位置领导别人。）

三、你更不要认为，如果我技术够好，我就自己创业，自己有创业的资本，因为自己是搞技术的。

　　如果你那样认为，真的是大错特错了，你可以做个调查在非技术人群中，没有几个人知道C#与JAVA的，更谈不上来欣赏你的技术是好还是不好。一句话，技术仅仅是一个工具，善于运用这个工具为别人干活的人，却往往不太擅长用这个工具来为自己创业，因为这是两个概念，训练的技能也是完全不同的。

　　创业最开始的时候，你的人际关系，你处理人际关系的能力，你对社会潜规则的认识，还有你明白不明白别人的心，你会不会说让人喜欢的话，还有你对自己所提供的服务的策划和推销等等，也许有一万，一百万个值得我们重视的问题，但你会发现技术却很少有可能包含在这一万或一百万之内，如果你创业到了一个快成功的阶段，你会这样告诉自己：我干吗要亲自做技术，我聘一个人不就行了，这时候你才真正会理解技术的作用，和你以前做技术人员的作用。

[小结]

　　基于上面的讨论，我奉劝那些学习技术的朋友，千万不要拿科举考试样的心态去学习技术,对技术的学习几近的痴迷，想掌握所有所有的技术，以让自己成为技术领域的权威和专家，以在必要的时候或是心里不畅快的时候到网上对着菜鸟说自己是前辈。

　　技术仅仅是一个工具，是你在人生一个阶段生存的工具，你可以一辈子喜欢他，但最好不要一辈子靠它生存。

　　掌握技术的唯一目的就是拿它找工作（如果你不想把技术当作你第二生命的话），就是干活。所以你在学习的时候千万不要去做那些所谓的技术习题或是研究那些帽泡算法，最大数算法了，什么叫干活？

　　就是做一个东西让别人用，别人用了，可以提高他们的工作效率，想象吧，你做1万道技术习题有什么用？只会让人觉得酸腐，还是在学习的时候，多培养些自己务实的态度吧，比如研究一下当地市场目前有哪些软件公司用人，自己离他们的要求到底有多远，自己具体应该怎么做才可以达到他们的要求。等你分析完这些，你就会发现，找工作成功，技术的贡献率其实并没有你原来想象的那么高。

　　不管你是学习技术为了找工作还是创业，你都要对技术本身有个清醒的认识，在中国不会出现BILL GATES，因为，中国目前还不是十分的尊重技术人才，还仅仅的停留在把软件技术人才当作人才机器来用的尴尬境地。（如果你不理解，一种可能是你目前仅仅从事过技术工作，你的朋友圈子里技术类的朋友占了大多数，一种可能是你还没有工作，但喜欢读比尔。盖茨的传记）。

探路者 2012-11-30 11:59 发表评论

产品经理需要解决的问题

探路者 — Thu, 27 Sep 2012 15:48:00 GMT

你有没有对用户体验有理性的和感性的认识？

你有没有优化产品，提出产品改进方案的能力？

你能不能把握互联网的最新趋势？

你懂online marketing不？

你有技术背景不，能跟CTO顺利沟通，并且在不被其气场的打压下把他给说服不？

你懂市场营销不，能跟市场人员顺利沟通不？

流程图，ppt，这些都是必须的，你得不停演示。

你的外语好不好？每天早上来公司第一件事，是不是去读 techcrunch， readwriteweb，smashing magazine 这些博客？

你懂管理不？如果你有一只团队，能不能带领这个团队打造一个初创企业？

探路者 2012-09-27 23:48 发表评论

项目经理的"势能培养

探路者 — Fri, 01 Jun 2012 16:03:00 GMT

我很早之前就听说过，做为一个项目经理，至少要在公司工作两年以上，且年龄不小于三十岁。我当时还年轻，对这两点很不屑。而现在，我却很理解。在公司工作时间短，对人员不熟悉，将很难横向协调资源；年纪过轻则不够沉稳、练达，难以实现快速沟通。
作为IT企业，很多项目经理都是由基层做起的，技术好、经验丰富、熟悉行业知识。作为项目经理本人，也觉得自己对团队的领导能力勿庸置疑。并不会认为自己沟通上会有问题。在这里，我也不想讲什么大道理，只举例子、讲故事。

举一个例子

去财务报帐，出纳说票贴的不对，公司财务制度上要求餐费与交通费分开贴，退回来重贴。贴完让出纳整好单子，找老总签字，老总出去了，没办法，只好到明天。而到明天，老总回来，自己却要出差了。
好不容易等老总签了字，拿到财务室，出纳说，财务上没有钱，票先放这里，等两天吧。一拖好几天，票压一堆报不了，项目中各项开销还得支出，严重影响工作情绪。这里要说明一下，财务上没有现金是很正常的，当然也不是完全没有，还是要留一些费用应对日常开销的，至于给不给你，就看财务的心情了。
如果换一个场景。
发票拿到财务室，出纳一看不合格，直接开涮：“你怎么搞的呀，刚公布的财务制度都没看吗，整天忙啥哩？算了，算了，放这吧，反正老总不在，等会儿还是我整一下吧，指望你干这活也没指望。你该干啥干啥去吧，下一回再这样我就给你扔出去。”
过两天，财务电话过来：“你的钱还要不要呀？公司有回款了，要拿钱的赶紧啦。”然后项目经理直接到财务签字拿钱，发票老总已经签过字，整个流程出纳都帮做了。
一个空降的项目经理与一个老员工项目经理，在协调资源时，差别是很明显的。
为什么空降的项目经理不能很好的协调资源。因为他跟同事不熟悉，他的团队会很支持他，其它人员则不一定。人家只给你照章办事，或许不会影响你工作，但同样不会推动你的工作。
而老员工项目经理，与各部门人员都很熟悉，老总也很信任他。这样处理工作就比较顺利，例如前面说的，出纳帮助你贴票，然后替你拿到老总那里，老总出于对项目经理与出纳的信任，就直接把字签了。项目经理出差回来签字就能领钱，效率高多了。

再举一个例子

项目临近结束，各个功能都差不多要做完了，项目完成进度也被标到90%。而项目经理心里很清楚，后面的修修补补，测试、调整会占用大量时间。公司项目管理不够完善，很多隐性的东西都无法显现出来。而客户此时又提出了一些新的要求，急切要完成。
如果告诉老总说，现在还需增加三个月的工作时间，老总肯定不同意，因为既然都完成90%了，剩下的工作还不加把劲在两星期内搞定，竟然还要增加三个月，挨批是难免的。如果给客户说，实在没有精力做新功能，客户要挟说，不做就不验收。
项目经理谁也不敢得罪，心里明白问题关键，却不知道该如何说服别人。只有硬着头皮往下做。结果项目延期，质量下降，勉强验收了，还有一大堆问题。最主要是因为工作强度加大，加班加点，透支团队成员工作激情，项目最终结束后，大批成员离职。
而如果项目经理换种思路。首先向团队成员灌输“行百里者半九十”，越到后面，繁杂琐事越多，越不能放松冲刺。要尽可能保持成员的工作积极性。一方面，向公司说明情况，通过项目管理的知识来讲解问题的具体原因，尤其是项目收尾管理，并不是代码写完就是项目结束，还有很多事情要做。总之，摆事实讲道理，积极向公司申请资源，尤其是宽限项目时间（此时单独强调增加开发人手并不明智）。
再一方面，与客户方负责人沟通，甚至私人宴请以促进感情。尽可能把一些新功能放到项目运营维护中来实现，或是项目二期中实现。如果客户仍然坚持，则最好说服他降低质量要求，在验收时放自己一马。向其承诺，在运维中提升质量。
整个情况要向团队成员说明，争取成员的理解与支持。也要向公司说明情况，尽可能多申请些额外福利。
从这个例子中可以看出，项目经理所做的工作，都不是“高科技”的，非技术的却又是重要的。针对不同对象，例如团队成员、公司高层、客户方负责人等，分析利害与关注点，权衡利益，各个击破。
一个年轻的项目经理与一个老成的项目经理，在处理这些事情时，风格会大不相同。就像上个例子，客户方负责人一般也不会太年轻，三十来岁才会担当个负责人，如果项目经理太年轻，阅历浅薄，则不太容易与对方平等交流。即便他明白道理，也很难影响他人支持自己工作。

讲一个故事

很多年前，我还年少的时候，喜欢下象棋，在学校里基本上我能下赢的，我总能下赢，我下不赢的，总也下不赢。不得其解，也慢慢懒得操练了。
后来有次学校搞业余活动，有个老师是省象棋协会的，组织了一节棋课。我去晚了，只听了半节。大致意思是讲，下棋要讲全局观，要有战略，例如中局五种策略，中局成杀、不成杀则优、不占优占先、不占先则多子、不多子则求和。还有什么炮破士、马破相、残局炮归家等等。却没有讲如何下棋，课堂上也没有摆个象棋，或是什么棋谱。
我并没有把这些当回事儿，之后也很少下棋。
又过多年，毕业后同学聚一起，闲来无事，与一个同学下了两盘。刚开始，他问我这两年有没有下棋，我说没有。他调侃我，“那你以前下不赢我，今天你也难赢了”。我也笑着认同，反正只是玩玩，何必认真。
可是一开局，他就傻眼了，一直处在下风，且每局必输。他很吃惊，我也很吃惊。之后我认真思考了这件事，觉得是那节棋课影响了我，人的思考能力、计算能力都差不多，而思维方式不同，结果也会有很大不同。他看到的是“棋”，我看到的是“局”。决定胜败的不是棋艺。
又过了几年，我已经不再年少，但还算年轻吧。有一次找一个朋友玩，正好他的一个朋友也在，吃完饭没事儿做，恰巧有副象棋，就与他的朋友下了几局。他们都比我年龄大，已经三十多岁了。不过我也没有放在眼里，自以为水平相当可以，三局我两胜，颇为自得。
等他走后，我朋友问我：“他水平怎么样呀？”我带着些“谦虚”，洋洋自得：“他水平挺可以的，我差点就输了，还好我三局两胜，略胜那么一点点。”
我朋友听完哈哈大笑：“你知道他是干吗的吗？他是卖保险的。卖保险的吗，任何人都可能是他的潜在客户，他自然不会去赢你，不光让你赢，还要让你赢得有面子，这才是高手。他原来是在象棋协会的，论象棋，那叫牛×死了。”
我听完之后，惭愧至极。我关注的是“棋局”，人家所关注的，则超脱棋局之外。眼界不一样，看到的也不一样，操控点也不一样，输赢已经不重要，重要的是输与赢，哪个更有利于自己，然后才是“如何去输”与“如何去赢”。棋局只是一个棋子。决定成败的不是棋艺。
我讲这个故事，是想说明，一个项目经理，对自己操作的项目要有全局观；而且，视角不能仅限于项目本身。明确自身定位，了解外部环境，才能最大成度影响到整个“局”中的各个元素，而这个影响力，就叫“势”。可以这么说，你明确的势力范围，可以只是你的团队，但你的影响力却不能仅限于团队本身。
做到这些，容易吗？当然不容易。如文章开头所说，“做为一个项目经理，至少要在公司工作两年以上，且年龄不小于三十岁。”这样，才有可能会做得好一些。

探路者 2012-06-02 00:03 发表评论

一个失败软件项目的思考

探路者 — Fri, 01 Jun 2012 16:02:00 GMT

一、对一个估计撑不了多久的项目的抱怨（原文）
项目概况
甲方：A公司
乙方：本人所在公司（称B公司）
项目：X项目是A公司外包到B公司的电子商务项目。
人物：A公司M先生，X项目组，主管、G、Q、P成员
项目状况
      X项目当前状况不太好，可以说后果比较严重。
      1. 几乎处于停滞状态。现在的需求获取方式可以称之为“挤牙膏”；在现有功能完成，而A公司联系人M先生，提出新需求之前，开发人员完全不知道下一步是什么。并不是需求调研没跟上，而是跟上了M先生无话可说（讲不出需求）。另一方面，项目当前实现功能跟合同写的又有很大落差，不可能截止。这个矛盾就导致了项目几乎停滞。
      2. 项目本身质量也堪忧。X项目组，组成非常简单，1个主管，1个高级程序员（下面简称G成员），1个北大毕业的程序员（少“青鸟”2字，简称Q成员），1个美工皆程序员（简称P成员），ZERO测试。X项目组的需求调研、项目管理，程序设计，技术攻坚外加运维全皆在那个可怜的G成员(就是那个高程)身上。
      3. 上个月美工皆程序员撤退了，这无疑又是给项目雪上加霜。
原因分析
      造成项目如此惨淡的原因，也是多种多样。
      1. A公司的M先生，是在X项目开始的时候才进入A公司的，而M先生原来是写过代码的。G成员心想M先生有程序员的前身，好沟通，还暗暗偷笑。可没料到的是，M先生原先是个半吊子程序员，只写过几个asp页面，而心里却甚是得意，大有编程不过如此之气势。就是这样的程序员前身，给项目带来数不尽的压力。顺便摘几句就可以管中窥豹：“这个简单了吧，只要数据库这样这样，然后读出来就行了”，“这个有这么难吗？不就是加2个页面的事”。如此等等就不列举了。但这其实还是能应付的，最大的问题是啥呢。之前讲了他是项目开始进的A公司，或者说是A公司专门挑的给给X项目组跟A公司牵线的。这是好事啊。可也是坏事，坏哪了？X项目作为一个电子商务外包，现在却要跟一个不熟悉业务，跟X项目组成员一样的现学现卖的M先生调研需求。如此，我想“项目停滞”恐怕也是能够想象的了。
      2. 项目组成员组成问题也很多。G成员身皆多职，但一个人的精力毕竟是有限的，如果这么多的工作要8个小时内完成，几乎是不可能的，就算完成恐怕也是偷工减料了。于是整个项目周期经常出现这样情形：G成员忙的焦头烂额，而其他2个人就聊聊QQ看看新闻。并不是G成员不舍得把工作交给别人，而是另2个成员，非设计好的功能不做，P成员毕业才不过半年也就请有可原，而Q成员，自“北大”毕业，工作也已经一年多了，这就有点说不过去了。Q成员的事，还是事实为依据：有这么个功能，1个主表1个从表，依据主表当前选中记录，显示并修改从表的内容，这功能，就这么简单一个功能，G成员估摸着熟悉需求加表设计加功能也就是2天时间的事，可Q成员愣是给整了一个星期，结果一发布出去，还一堆问题，挨M先生一堆说。这样的组成和水平，我想代码质量不能保证也是在所难免了，更别提还没有测试人员。
      3. 基于2的问题，很多看官肯定要说了，这样的情况，还不赶紧跟领导提意见换人嘛？提啊，G成员可没少提。G成员要求也不高，就提这样个要求：请领导给我们再加个美工或者程序员。如果加美工呢，让P成员转程序开发（这个是P成员自己提的，他一直不想做美工，而且人也机灵，转程序员也行），麻烦再把那个Q先生给换下去，你说拿着3000的工资，干着这个活，我也是为公司节省成本啊。如果加个程序员呢，质量要稍微高点的，另外就要把P成员的思想工作好好做做，让他当个全职美工。
      可领导说了，我们这个小公司小项目，这样哪行呢，这成本太高了，我看你们也不是很忙，先这样吧。 G成员听着郁闷，这人家QP成员的确不是很忙... G成员当时就差说：你不换他们那就把我换了吧。毕竟还是饭碗要紧，就吞回去了。得......这一来一切照旧。
      4. 这项目组里都讲到了就差个主管，主管我就不给取外号了，比较是主管，咱得尊重。主管呢，是领导派下来的，其实不负责管理，也不负责开发，人家是搞delphi的牛人，但对C#是一窍不通，可是这人偏偏啥都爱插一手。
就说，项目刚开始，G成员思量着上个ORM，就跟主管打个报告，列了几个ORM的优势。人家主管就是牛：第二天给回话，不要上什么ORM 了，你看这个sql多好。这不看还好，一看就吓倒。人家的sql全是写在 frm上的，直接调用一个公用方法连接到数据库。看样子跟他光用讲的不行。
于是G成员重新整理了一遍ORM的优缺点，又认认真真写了个demo，再交上去。这次主管2天没给信，以为有点效果。那天正吃完饭，主管就把G成员给喊过去了，这主管能啊，真是爱学习，电脑上整理一个vs2005：G啊，ORM这个问题，我不是很懂，但我问了几个朋友，他们说没啥必要，如果非要上呢，就用这个吧，你看看这是我朋友写给我的。G成员心里一颤，看来这事要完。一看代码果然是头凉到脚。这这这也是orm？这写个sql读个datatable，再给他赋值给一个对象，然后这对象再给页面控件赋值，就算OOORRM了？真是尼玛的有木有！！！！！！！！！！
看官跟你讲，这事还没完。ORM这事是没戏了，那咱就上个微软企业库，这总行吧。企业库刚搭建完那天，主管就来了，说，这么长时间了，让我看看成果。这事没的说，领导看下工作成果，合情合理。可偏又看出个事。 ExecuteScalar 这个方法，常写sql连数据库的人都知道，获取单值。主管就问了ExecuteScalar这个奇怪的方法是啥意思，G成员就给他解释：这个是从数据库获取单值的。看看主管迷糊，又加一句：就是获取第一行第一列的那个值。这不加估计迷糊迷糊也就过去了，可这话一出口，主管就笑了（得意的笑，我得意的笑….），这他在行啊。主管说：这个方法以后不要用了，这个跟ExecuteDataSet重复了，你就取DateSet第一行第一列就行了。G成员当时就怒了，XX的，这有完没完。经过几回合的较量，终究姜还是老的辣，告到领导那被批回来了。G成员这次算是彻底服了。于是以后有什么东西该藏藏，大气不出一个，他说他的，我干我的。可这又何苦呢？唉～～～一声哀叹尽千愁啊！
      5. 对美工P的出走也交待几句。这美工呢，毕业没多久，但人好学，所以进步也快。进项目之前就是讲好了，等他把C#掌握得能完全参与项目了，他就不干美工了，想写代码。这领导也是同意的，结果一直干干干，从去年干到今年，提也提过几次，也没听到什么时候能找美工来替他。而且人家乃是蛟龙，能被这小水潭给困住？就另觅明主去也。这一换工作，工资直接翻番。
二、一个估计撑不了多久的项目的发展历程（原文）
之前发了一个抱怨文，把X项目前前后后几个人全给抱怨了。后面也有很多看管给我回复，有表示哀悼的，表示同情的，也有提意见，送安慰的，甚至还有抢占广告位的。不管怎么，本人在此表示感谢。
抱怨完了，也该反思下项目的历程和带来的教训。此文就先简述下项目的历程：估计还是以抱怨为多。望各位谅解。
一个估计撑不了多久的项目的
发展历程
记得去年的仲夏时间，天气正是当热，三十五度算凉快的，三十七八很正常，还经常能串到40的高温，当然40度往上天气预报是不敢报的，但明白人都知道，一个铁皮碗放太阳底下晒个两分钟，鸡蛋往里一敲，一个五成熟的煎蛋就出炉了，让人不得不佩服太阳核聚变的威力。
X项目就是在这样水热火也热的环境下启动的。X项目启动之初，领导只说让G开个项目，实现这样一个功能，然后给客户看看。因为领导并没有说是正式项目，就权当是原型开发，G就给顺便整理个小三层，把页面先给画起来，数据读出来展示，然后就给客户看了。这个时候的还是直接跟A公司的老总直接联系的，M先生尚未上任。然后客户就开始提意见了，要这样，要那样的，G就照着做，但一直没有正式项目的说法，就权当是按范例这样的简单方式都给写了。G也跟领导提过，这个情况是不是应该正式立个项，领导说，再等等。就这样拖拖拉拉一个多月过去了，代码也七七八八写了不少。
有一天，领导带来个人，跟G说，你做的那个程序现在呢正式立项了，这位以后就是你们这个项目的主管，以后有什么问题就找他。G一听心里乐呵，这个把月没白搞。Q和P两位项目成员也就陆续的来报道了。既然正式立项了，那不能按之前那种烂法子做啊，G就寻思着把项目重新架构下，这么大个事当然得跟主管商量下，这一来二去的还算顺利（这中间有个关于使用ORM的事，见前文）。就在此时，A公司的M先生也上任了，并指定了跟X项目接头。M先生之前兴许看过原来的demo版本的程序，一听项目调整，1到2个星期不能有功能产出（项目调整这说法是领导提的，可能是怕客户有意见），就有点不乐意，催着X项目组赶赶工，这时间太久了。这话就由领导传到了X项目组，既然是领导发话，X项目组只有惟命是从，G就给大家开了个小会，打打气，加了一个星期班，连架构，带实现，把之前一个月的事，大家给翻了个新。
这之后的一个月，都是领导亲自去客户调研，然后需求以口头和少许说明的形式，转到G这边，G再根据自己的理解分解素材，设计程序和数据库，把素材转化成任务，分配到QP和G自己。我想很多看管可能都看过这样的图：
在这样的需求调研下，程序表现往往跟客户的需求不符。领导就把需求调研的任务干脆就直接交给G了。G兼着项目管理和设计开发，本不想再参与需求调研的事，可主管说他很忙，没有太多时间调研写需求文档，公司又没有配置专门的需求调研人员，也就只好应承了下来。也就从这个时候开始，G认识了M先生，才了解到需求为何会如此零散。M先生的事，就不过多描述了，毕竟文章还是以X项目发展为主。
简单描述下X项目的组成：此项目为电子商务网站，而网站数据几乎全依赖外部接口，这个也是由于网站业务所决定的。X项目总共前前后后开发了各式各样9个外部接口。平均的说是一个月要针对一个接口开发。Q和P2位成员的能力，上个文章也说了，此处不再赘述。P要为X项目画界面做图片，尤其是M先生要求网站兼容IE678 FF 和谷歌浏览器，这也够P先生忙一壶的了。而这Q就闲了，每天只等着G设计好了，告诉他功能怎么怎么做，如果这天G没空设计新功能给他，他就聊一天QQ，听一天音乐。
由此可见G要忙到什么程度。人不怕辛苦就怕比较，辛苦都是可以撑下来的，可要有个人在旁边这么一比较，这心理真是全然不同了。G是农村出来的娃，辛苦点不怕，只是你辛辛苦苦一天忙到晚，人家坐你旁边聊QQ，看新闻，这感觉很是不爽，最最关键是这闲的主还是得听你指挥的小弟，这真是要命。于是就出现了前文中要求加人或者换人这样的事情。无奈项目组加人不成功，G只能继续匍匐前行。
转眼就到了年底，根据初始合同需求确认书，半年过去了，却才做完了三分之一多些的功能项，G的心中有些不安。有一次G去A公司跟M先生进行需求调研，讲到了对项目目前状况的担忧，M先生不愧是过来人，信心满满的说，你放心好了，这个项目我肯定给他搞活了，不可能倒。大有一切尽在掌握中的气势。虽然M先生如是说，但G心中始终是放下不，就细细总结了这半年的得失，和来年的一些计划和改进方案，交到主管手里。
这个文档的主要内容这里摘一下：
1. 确定项目驱动因素，不能由M先生带领大家挤牙膏，必须要进行项目远景定义和功能集合的详细定义。
2. 项目风险总结，将近半年的各种问题进行一个简单汇总，并请求主管对项目组外的风险提出相应的处理方案。
3. 延迟发布周期为1周（原来是，M先生说个需求和修改意见，然后马上开动，做完就发布给M先生审查，几乎是一个星期要发布2到3次）,而且一周内已经定好在做的功能，不接受任何修改。
4. 提出项目缺陷管理。对项目问题进行统一管理，这中间引起的客户和开发时间问题，希望主管能够帮助协调。
5. 每日会议的召开。（原来只有1到2周有次项目总结会议），随时捕获风险。
6.望主管能够部分接收G手中的项目管理工作，减轻G的工作负担。
也主要摘下主管对这个文档的回应：
1. 明年会跟客户进行有效沟通。
2. 明年会跟领导报告，尽量解决。
3. 同意一周发布一次，但也要尽量满足客户要求。
4. 缺陷问题很重要，要管理，但还是要以客户发布时间为第一位。缺陷可以后期修改。
5. 每日会议，有这个必要吗？如果没啥必要就不要开了，大家都比较忙。
6. 明年再定，看明年能不能抽出时间来。
再主要写下年后的实际执行情况：
1. 不知道主管有没沟通，反正M先生照旧。
2. 好像汇报了，但没有相应反馈动作。
3. 被G强制压为一周一次发布。M先生起初不满，但不发布他也无奈，就算是默认了。
4. 几乎是直接就丢下了。原因：主管再次表示要以客户发布时间为第一位。而G照旧被压着这么多的活，再来一个缺陷管理完全是自讨苦吃，也就放弃了。
5. 这个倒是坚持了3个多月，效果还不错. 本来Q在表达方面就有些问题，就是话说不明白，每次都要被G追问很多遍才能说出点头绪来。而这导致了Q对G的一些不满和抵抗。于是美工P一走，就剩下G跟Q2个人，每日会议干脆停掉了。
6. 看到4就知道，这个没戏了。
回到去年年底，客户对项目总体上表示满意，G估摸着这里面有M先生很多功劳。而公司领导以业绩不好为由，让每人领了200块的过节费就匆匆回家团聚去了。当年后G从M先生那里了解到年前公司已经拿了X项目绝大部分款项时，已经离过年甚远，追悔莫及了。而这事也在X项目组3个成员的心里埋下了许多的怨愤。连G先生在内的成员也少不了在闲聊时间，发泄一些对公司的不满。这也一定程度上，导致了P的出走。有句话叫兵败如山倒，这P一走，Q也开始紧锣密鼓的找新单位，终于这个月公司也接到了Q的离职申请。本就人丁不旺的X项目组就剩下2个光杆司令：G和主管。其实Q的离职对项目影响并不大，而P的离职相对来说大的多，P这一走，美工就没了，而多功能的M先生重操就业兼职做美工，这是G也得佩服的事，说啥来啥，都能上。
项目晃晃悠悠的走到了今天，眼看着也要到头了。而G站在项目的边缘不知何去何从。
三、从G犯的错误来看X项目如何失败的（原文）
下面做个简单分析，从G犯的错误来看看X项目失败的原因。
1. G兼着项目管理和设计开发，本不想再参与需求调研的事，可主管说他很忙，没有太多时间调研写需求文档，公司又没有配置专门的需求调研人员，也就只好应承了下来。
G本身已经兼着太多的职位，导致工作不能做好了，还要去接下一个本可以不搭的事情。这就导致时间更不够用。时间不够用将辐射出更多的问题：
1) 因为很有多工作压着，为了能够按时完成，必然胡乱瞎搞，能省则省，最终的结果就是质量完全不到位。
2) 没有办法进行有效的总结回顾
3) 长此以往，必将导致心理失衡，产生厌烦心理，从快乐工作变成了赶鸭子上架。
4) 以上3点连在一起，必然出现恶心循环，最终要么人崩溃，要么项目崩溃。
目前想来，解决方法只能是，积极主动而又耐心的反复沟通，对主管和领导进行主动劝说，让公司安排个人来专门调研需求以及分担G的其他工作，让G能够专心与程序设计开发或者项目管理。上文回复中，有很多人提到了PM的重要性和存在的问题，而G身兼PM在内的多职，必然导致了项目问题，偏偏这么重要的问题，被领导主管和G在内的X项目组成员所忽略。
2. 人不怕辛苦就怕比较，辛苦都是可以撑下来的，可要有个人在旁边这么一比较，这心理真是全然不同了。G是农村出来的娃，辛苦点不怕，只是你辛辛苦苦一天忙到晚，人家坐你旁边聊QQ，看新闻，这感觉很是不爽，最最关键是这闲的主还是得听你指挥的小弟，这真是要命。
这个是心理因素，说明G这个人心理不够淡定。合理的解决方案之一兴许跟1中的一样，让人分担G的工作，使G专心与自己的所长。再者，就是人员合理流动，对于不能达到岗位需求的员工，要及时更换或补充，一方面不至于引起其他成员的不满，另一方面也是项目成功的必要条件。敏捷开发的中心思想就是以人为本，如果人心涣散，项目想成功都难。黎叔说了，人心散了，队伍不好带了，于是黎叔也被抓了。
3. Q在表达方面就有些问题，就是话说不明白，每次都要被G追问很多遍才能说出点头绪来。而这导致了Q对G的一些不满和抵抗。
这是对人的管理不善，带来的严重后果之一，G明显缺乏那种让人家为他或者为公司卖力的领导能力。此点在2中已经有表现。
4. 连G先生在内的成员也少不了在闲聊时间，发泄一些对公司的不满。
G在一定意义上是X项目的负责人，而他带头在成员面前表示对公司的不满，这必将给项目组成员带领极坏的影响。这个举动说明了G在管理这个岗位上的不成熟，没有从大的方向进行考虑问题，而只是一泄心中怨气。致使人心动摇。
5. M先生提出需求和修改，然后马上开动，做完就发布给M先生审查，几乎是一个星期要发布2到3次（此处的发布指，将程序发布到测试服务器，供客户试用和审查）
这个就是明显的没有做好项目管理，简直就是把项目交给客户来管。程序发布，还是比较消耗精力的，而发布后，客户发现的各种错误异常，会要求马上更正，就导致了有时候一天中多次发布的情况出现，就因为几个很小的错误，导致时间消耗在修改-发布-修改-发布上。
解决方法：
1) 按照较长的时间周期进行发布，但不宜过长，比如1周或者2周。并且跟客户协商好，当前发布版本的错误，推迟到下个版本修改。
2) 每周邀请客户代表到公司来参与项目进展会议。让客户每星期都能了解到项目在进展，放宽他的心。约定好，每个月发布一次测试版本，让客户测试体验，相关问题，放到后续版本中修复。
3) 对需求的获取和变更进行控制，比如要求客户形成书面文字，进行需求提交等。
6. G照旧被压着这么多的活，再来一个缺陷管理完全是自讨苦吃，也就放弃了。
G因为手里活来不及而放弃了缺陷管理，这是可悲的。缺陷管理可以说产品质量的保障之一，缺陷管理那长长的列表尖叫着提醒项目存在的问题。这是一个项目出现质量问题，最显眼的警报器。没有缺陷管理，几乎很难进行项目质量的监督。缺陷管理一开始的缺少和后来提出又放弃，很大程度上决定了项目的失败的必然，一个不注重质量的项目，谈何成功？即使功能全部完成，你敢放到公网上让黑客转悠2圈吗？
综上所述，凸显出G项目管理能力上的匮乏和心理的不成熟。这是项目走向失败一个很大的原因所在。在此希望各位看官，能更多的提出G的问题所在，也希望能提供相应的改正建议。在此感激不尽。

探路者 2012-06-02 00:02 发表评论