|
在日常生活中，我们可以看到很多很多项目，建广场、建大楼、修公路、修铁路都是项目，有大有小。我们这里说的软件项目是项目中的一种，有许多特殊特点：不可见性，(不够直接，不易感知进度，不易监控)、不确定性(范围不确定，目标模糊)、多样性(很难有通用方法和最佳实践可复制)、工作量问题(渐进的计划)、丰富多彩的开发方法(条条大路通罗马)。先说不可见性，软件项目不像修路修桥等项目在建设之前把未来建成的样子都已经设计好了，就像售楼处的沙盘，项目结束后的样子就是沙盘的样子。虽然现在软件项目也引入了demo的需求获取及确认的方法，但是还是无法完全展现项目完成后的样子，而且，即使所有展现页面都做出来了，在实际项目推进过程中，变动也会非常大。另外一个问题就是，如果所有页面及所有交互都通过demo做完，成本非常高。软件开发不像其他项目，建设一部分就能看见一部分，而大部分是软件开发完成，部署调测后，客户才能看到项目的情况，对于项目开发过程，他不容易看到，对项目进度感知不明确，也不易监控项目的进度及项目质量，感觉是个黑盒子。对于项目不确定性就是指的需求的不确定性，软件项目不像很多软硬件的产品，像手机、空调等，我能提供的功能就这些，客户的选择是要还是不要，不是定制化的，我要这样，我要那样。软件项目面临的情况不是成熟的解决方案或产品，而是无限的解决方案，客户提出需求，项目承建方就要想方设法去满足，而不是我们不能提供的答复。尤其是对于软件开发的页面展现，更是仁者见仁，智者见智，有挑颜色的，有挑样式的，还有提出要科技感、要动态活泼的，五花八门，要想满足各类用户的需求，还是很难的。另外就是同一个人，今天想法和过两天想法就不一样，在实际项目过程中，经常出现这样的情况：周一项目经理和客户经理沟通，确认了系统首页面风格及样式；周三，客户把项目经理叫去开会，会上说周一确认的系统界面风格不太合适，你把风格调整成互联网化、扁平化模式吧；下周一开周例会时，大家又看了看首页修改的情况，这时客户说现在的样子还不如以前的好看呢，再改回去吧。就同一个人思想也是经常变的，需求也会经常变。最麻烦的是隐含需求，很多客户认为系统默认会带有很多功能，但是往往乙方项目经理会按明确需求来进行交付，因为项目预算就这么多，如果完成很多隐含需求或超希望需求，项目就会超预算，甚至会失败。软件项目样式繁多，复用性相对较差，很难有通用方法和可复制的实践活动。不像建筑工程，可以用空心砖、预制板等标准件。软件一直在探索复用的问题，复用颗粒度大了肯定不行，小了，管理难度就很大，需要管理的复用组件成千上万，边界难以确定。软件运行的平台也多种多样，linux、unix、windows、android、IOS等等，系统框架从单一系统到二层架构，再到三层架构，从CS结构到BS结构，软件项目变化大，软件技术发展快，更新换代快，从软件开发诞生到现在，很多软件开发技术已经绝迹了。这也导致了软件复用的难度。接下来是工作量的问题，在软件工程领域工作量是很难精确评估的，由于是脑力劳动，与体力劳动不同，它很难量化，同一个人，精神状态好的时候，一天的产出能抵自己平时的几倍，所以在评估工作量的时候，很难准确评估出多少人天来，这需要看个人的工作状态，团队的配合程度。在软件行业还有“人月神话”的说法，这里的人月就是只工作量，比如一个软件工程评估工作量是100人月，但是这100人月不是100个人干1个月就能结束的，它涉及很多工作不能串行，不能压缩工期，就和水泥的凝固期一样，有些工作必须要持续多少时间，这样就有了“关键路径”的提法，就是不能压缩的工期。为了评估相对准确的工作量，也有很多方法，比如专家评估法、delphi法、基于代码行的，基于功能点的都有。最后是丰富多彩的开发方法，很多软件项目能用很多种方法实现，这就需要进行开发技术的选型，开发框架的选型。这一般是由系统架构师来组织执行的，由架构师们进行系统架构的确定，开发技术的选择。一般会在技术先进性、系统稳定性、系统性能、系统安全性、经济性等多方面考量，最后选择适合这个系统的开发框架、技术路线，有时还要考虑开发人员的技术储备情况，最终选定系统开发工具、技术演进路线等。软件项目具有一定的复杂性，就是最简单的项目，都有几个月时间的稳定期，是软件就有bug，再牛X的系统都有，像windows、android等都有漏洞、都有bug。所以软件系统的复杂性，决定了软件项目开发和实施的复杂性，以上主要是针对软件开发的，有些软件实施也很费劲，比如ERP系统，开始实施时遇到很大阻力，很多人员担心上了系统会影响自己的工作岗位，不愿配合实施工作，还有的实施工作需要测试环境，由于测试环境很难做到与正式环境一致，需要组织系统使用人员试用系统，必须在系统不用的时候进行系统实施迁移。当然，随着软件技术本身的提高，很多问题也都在解决，但是不要想一蹴而就，毕竟脑力劳动的成果本身就有不可测量性。
|
