写在端午节的工作总结--留给大家的思考
写在端午节的工作总结-留给大家的一个思考

5-19，接受任务，设计一个新的F所数据发布系统，目的是为了推广XX项目的开发架构，让P和D他们熟悉使用；
5-20，设计出页面风格，并得到确认；
5-21，试图在原FCOA解决方案中加入XX的软件架构，最后失败，于是创建单独的发布程序Web项目FcoaDataExp项目；同时，指导D在192.168.1.XX 安装Oracle.
5-22，在192.168.1.XX 上创建Fcoa的VSS目录，并帮助P和D设置客户端VSS；指导P安装Oracle。
5-23(星期五)，因为Fcoa的VSS设置有问题，最后单独创建发布程序的解决方案，并在服务器上和客户端设置成功VSS。创建发布程序页面DataExp.aspx，已经基本确定页面的运行时效果，做好了数据邦定的样例代码。和S，P，D讨论任务分工，最后确认D负责完善Web页面的设计（两个页面），P负责业务层代码的编写，我负责后台文件和数据发布服务程序的编写。
5-26（星期一），XX来了程序修改的需求，我和P修改XX程序；D开始做Web页面；
5-27，继续修改XX程序；D继续作web页面；
5-28，开始做发布程序后台服务，P开始写业务层代码，D继续做Web页面；
5-29（星期四），页面功能基本完成，可以调用业务层代码完成发布状态的设置，文件和数据后台发布服务还在继续设计中；M下午查看工作进度，提出了一些修改意见，并询问完成时间。出于对前期工作状态的考虑，我一时无法给出针对新的修改意见完成工作的最后日期。开发小组所有人召开会议，商讨完成任务的最后时间，最后商定最迟在6-3日完成。
本次会议对开发方式讨论的要点：
1，P和S一致表示希望推翻现有的系统架构，由P在业务层完成所有的查询，直接给Web页面生成所需的数据集；D在此基础上完善用户界面设计；
2，S表示一开始就应该采用用户控件方式，这样可以避免Web界面只能由D一人使用的现状；
3，我考虑到本次项目是为了熟悉XX项目的开发架构，如果赞同1号方案，那么本次开发方式又回到了最原始的方式，而且可能在他们两人之间产生更多的沟通交流的时间成本，因此不同意1号方案，支持2号方案。
5-30（星期五），实施2号方案，让P创建一个新的页面index.aspx,将原来的DataExp.aspx拆分成一个主页面和四个用户控件。P决定作公告政策法规类的用户控件和下载中心的用户控件，D作剩余的YY企业和项目公示用户控件，难度稍大。在用户控件中，发现分页控件无法正常翻页，网格控件在各个标签之间切换数据显示异常。我让他们继续做下面的工作，同时我即刻修改分页控件和网格控件。同一天，我的数据和文件发布服务编写成功。
6-2（星期一），我和P工作进展顺利，我完成控件的修改，P的两个控件设计完成，D未完成用户控件的设计。当天，我采用Ajax方式，修改了P的发布进度条页面。
6-3，我检查P和D的工作，指出较多的问题，并帮助他们完成修改。
6-4（星期三），催促他们两人的工作，但D仍然没有完成工作，可能跟工作量稍大有关。同时让P协助D。我完成《XX项目系统架构分析》最后一版的编写。
6-5，D工作未完成，我检查出P的程序一些问题让P修改。由于总体工作未完成，所以当天仍未向S提交测试版本。当天下午，我在测试数据发布后台服务中，发现服务程序发布进度停顿，一时未找到原因。在排除了原有程序编码问题之后，于当天晚上12点前测试确认是数据库未创建合适的索引。
6-6（星期五），在服务器上修改Oracle数据库设置，测试发布程序通过。P当天已经休假回家。我协助D修改剩余的问题，同时我又修改了P程序的几个问题。在当天下午2点半左右发布最终侧测试版程序，准备告知S，并准备此时向M请假回家过节。随后，看到S提出了一些BUG，M召集S，我，D开会讨论工作问题，分析为何进度如此之慢，为何说话不算数，未能按期完成任务。
我的总结：
1，XX项目的开发框架式基于SqlServer上的，本次移植到Oracle系统上来，难免会发生一些问题，必须修改原有的开发框架；
2，本次工作在我看来是一次改进XX项目系统开发框架，推广和培训公司同事熟悉此开发框架的机会，框架的完善和同事的熟练掌握是本次开发工作的最主要目的，而不是作为一项紧迫的工作任务必须在某个时间之前完成。
3，开发小组内部有些同事工作经验不足，基础较差，而且缺乏主动学习和积极思考的能力，对XX项目开发框架的学习和掌握过程缓慢，因而实际工作起来进展缓慢。
4，我的失误是在于没有认识到本次开发工作是M给我的带领一个开发小组进行团队开发的任务，没有强行拍板，下死命令，完不成任务必须加班，没有认识到任务的紧迫性。

题外总结：
从一开始接受工作任务，到最后提交测试版本，一个功能，3个用户页面，如此简单的工作，花了15个工作日，前后19天时间，超期完工3天。这合理吗？诈一看来，谁都觉得不合理，但是问题还是发生了，在客户面前，这是不容辩解的，在软件开发团队内的你，觉得合理吗？
黑格尔说过：存在即是合理！
说它不合理，那是唯心主义和唯物主义的辩论，已经超出了本篇文章的讨论范围，在此我不再讨论，留给大家去思考吧！





------解决方案--------------------
up

------解决方案--------------------
一看就知道楼主是那种非常热爱工作的人!
------解决方案--------------------
up
------解决方案--------------------
扯皮啊
从你的日志上看
5-23：你们就已经开始动工去做了
6-4 ：你的《XX项目系统架构分析》才出来。

那么在这段时间你，P、D和你的工作标准是啥？实际多人合作项目，第一步就是确定标准。

------解决方案--------------------
5-19，接受任务，设计一个新的F所数据发布系统，目的是为了推广XX项目的开发架构，让P和D他们熟悉使用； 
5-20，设计出页面风格，并得到确认； 
5-21，试图在原FCOA解决方案中加入XX的软件架构，最后失败，于是创建单独的发布程序Web项目FcoaDataExp项目；同时，指导D在192.168.1.XX 安装Oracle. 
5-22，在192.168.1.XX 上创建Fcoa的VSS目录，并帮助P和D设置客户端VSS；指导P安装Oracle。 
5-23(星期五)，因为Fcoa的VSS设置有问题，最后单独创建发布程序的解决方案，并在服务器上和客户端设置成功VSS。创建发布程序页面DataExp.aspx，已经基本确定页面的运行时效果，做好了数据邦定的样例代码。和S，P，D讨论任务分工，最后确认D负责完善Web页面的设计（两个页面），P负责业务层代码的编写，我负责后台文件和数据发布服务程序的编写。 
----
1. 这几天的工作中的来说就是设计和准备工作， 对于一个3周的工作来说，花费1/3的时间准备太多了. 应该考虑在第一天并行设计和准备工作. 第二天就应该开始进行关键部分的编码和框架确定. 

2.开发阶段还进行方案的修改,说明设计部分的准备工作不够细致.考虑问题有遗漏.

3.在开发过程中发现进度延迟的应该及时处理,或者安排加班 或者加人,或者修改计划.不要等到最后在找责任,也不要将延期的责任归咎于某人.延期的责任不管什么原因,PM都应该为此负责.

个人意见,仅供参考.
------解决方案--------------------
太悲惨了
------解决方案--------------------
UP
------解决方案--------------------