阅读作业-刘昕

 

 

阅读作业
这次阅读作业我选择了对课程讲义进行通读。
在实际的阅读中说实话是抱着学习和长见识的态度来学的讲义。整体顺序是从概论之后每个博客一个个看下来的，并没有按照链接中给的顺序。
感想就不多说了，以下是我的疑惑和一点意见。
对于《讲义7开发阶段的日常管理》一节，我总在疑惑在实际的课程中我们是不是有时间进行每日架构一类的工作，纵然知道每日架构、碰头会议的重要性。但是在实际操作上总是会有这样那样的问题。就像讲义上调侃的一样，“在理论上理论和实践是一回事，在实践上理论和实践是两回事。”
理由就不赘述了，总之都是可以视为借口的各种说辞。不过在借口之外我在考虑有没有一种更为便捷的架构形式和碰头会议方法。
首先目前我们小组的情况是每日晚上10：30的网络会议，然后在每周一的课程后会进行碰头会议。至于每日的理论上需要上传到TFS上的东西目前面临着TFS上不去的问题，所以只能搁置再议。
我在构想着，每日能不能以一个日报的形式来汇总大家的工作情况，格式不用太复杂，注明每日做了什么，付出了多少时间，完成的百分比，一项项的列清楚。有哪个事情需要备注说明的再备注说明。而随后可以根据当前的工作再列一个次日的工作计划，和日报的格式类似。而第二天就不必从新做表而是填写前一天的计划即可。在暑期生活中我被要求用这种方式管理自己的工作生活。说实话除了第一次的新鲜感和不适应，每日日报的工作并未对我的工作和业余生活造成什么影响（占用约5-10min）这样的工作同时对周报、月报、季度报告也都会有一个比较好的帮助。对于PM来说也可以节省每日大量的记录统计工作。也方便结合组员提交的报表进行下一步工作的安排。

对于每日会议我抱着很多的疑问，简言之一日一议太频繁了。或许对于PM来说可以监控项目的整体走势并及时给予判断，但是我觉得如果采用日报形式进行工作汇报的话，那么我们就可以减少会议的频率，一个时间段负责一个方向的工作，对于极个别人的极个别问题由PM负责单独指导，减少会议在其他人工作中占用的时间，或许这样更适合我们学生的生活节奏。

在创新方面的一系列讲义中，我不禁会产生这样的思考。创新这东西是我们从小学乃至幼稚园时期就被老师、同伴所强调的。而创新从理论到实践也常常是我们所关注的重点，或许在创新中第一个吃螃蟹的会占到便宜，不过更多的时候我们的创新却是像书中的一样，只有“用屁股对着用户”的结果。更多的时候我们的理念超越了当前的客户的理解范围，就好比大哥大刚刚出现的年代如果有人拿着iphone5去推销，如果那个人不是乔布斯或者是什么著名的推销员，很难想象当时的人们会如何看待这一产品。是迎合大众的创新，还是在创新之后努力的运用营销手段推陈出新强势的给客户灌输新理念，我们在创新的时候要不要去考虑这样的问题呢？

所以当看到讲义上用“Advance Option”和“Option”之间的思考时，我觉得面对客户的话题这个对我们来说很难做到，但是也是很有启发的事情。
不过，我们在进行实际的软件开发的时候我们用不用随时随地的去寻找目标客户对我们的产品进行评价呢？让他们去关注整个项目的每一个会面向用户的环节并及时给予反馈，还是说将这样的反馈环节丢给测试人员和开发人员自己去摸索，最后再找客户进行修改。前者用户肯定没兴趣，人家就希望给了钱（或者不给钱）之后能获得好用的程序，而后者必定在后期修改维护时牵扯大段的代码，耗费大量的人力物力。
一步到位肯定是胡扯，那我们开发者应该如何去做才能尽量的和客户的心思达到一致，如何才能最快的缩短我们和客户之间的距离呢？这种最快的方法存不存在呢？

以上就是我的基本疑问了，其余的讲义对于我来说都是新鲜的内容，其中许许多多的不解需要我靠将来的学习生活工作实践来一步步弄明白了。