高端企业网站建设注意问题,青海城乡住房建设厅网站,自媒体短视频制作教程,哪个网站专门做二手电脑手机的创建人#xff1a;X公司程序员 yunshichen 这篇是我读《微软研发致胜策略》后整理的笔记。身为一个软件开发部门的主管#xff0c;你的职责是什么#xff1f;单单完成项目是不足够的#xff0c;如果你的目标是这样#xff0c;那么你会做错很多事。我认为准确的表述应该是…创建人X公司程序员 yunshichen 这篇是我读《微软研发致胜策略》后整理的笔记。身为一个软件开发部门的主管你的职责是什么单单完成项目是不足够的如果你的目标是这样那么你会做错很多事。我认为准确的表述应该是 带领程序员按进度完成项目并且让他们能通过项目中在技术工资团队归属感等方面成长。 本文作者用轻松愉快的笔调讨论了作为一个主管应该怎样管理项目并且列出了他在微软的一些做法。或者他可能没意识到他提出的解决方法其实都是针对一个问题 你究竟想要做什么 小到编程买菜与人交流大到管理人生无非都是弄清楚你自己究竟想要做什么。弄清楚之后通常你就能找到相应的处理方法。 读完之后我没有单纯的记下要点我把作者的观点归纳之后重写成如下形式。希望能给喜欢读书的同行一点思考的火花。当然了最好建议你还是去读读这本书然后写下你自己的见解。当你我他都有了自己的理论或者中国软件业的春天就不远了。 项目的讨论精确的项目目标 作为主管值得你好好花时间去设定你的项目目标。目标定下来之后你就会清楚哪些工作该做那些工作不该做。例如你是基础函数库的主管如果你确定了“只有所有模块都使用的函数才是要开发的函数”的原则那么某个模块要求你开发的工作就不是你的目标了。 每天花1015分钟想想目标并且想些解决的小窍门。例如作者某天是这样想的Diego负责该函数的开发有可能需要一本技术手册。 于是他马上去买了一本。 就这样明确项目目标提前把影响程序员专心工作的障碍包括不必要的会议email电话等一一去除。主管才能把项目做好。开会与报告 有些会是不得不开的。例如 1 当某个人必须把信息传送给很多人时。 2 信息需要双向或多向交流人们必须立即反问才能了解信息。 3 必须亲眼目睹或亲身经历信息才能传达给接受者如产品示例。 4 有些事情须通过讨论才能进行。 但开会中断许多人的工作。所以在开会之前你必须动脑筋想想你开会的目的是什么有没有更好的方法达到同样目的。 会议时间应选择工作效率比较低的时段并且不会打扰程序员顺序连续工作时间的时段为宜例如早上刚开始上班下午刚开始上班快下班时。特别的如果可以选择的话在星期一早上或星期五下午开会。这是最没效率的两个时段。 如果会议确实召开了。一定要达到目的。即使是假设性的有条件的结论。例如如果其他小组的工作依赖于Diego的工作成果那么你可以问Diego“两个星期能完成你的工作吧”如果他同意了那么以此假定作为基础和其他小组讨论工作例如进度安排等。 作为主管避免在会后让与会者递交一份长长的发言报告。这是双重浪费时间。如果你觉得他们的发言值得记那么你自己记下来。再次强调写无用的报告浪费开发人员时间。如果你确实要报告最好单独进行并且尽量短。进度 微软曾有过惨痛的教训以进度作为项目完成的指导。任何进度落后都是不允许的bug的不断增加不算严重问题但只要工作没在排定的时间内完成就是罪孽深重的。进度取代了项目目标和软件质量变成了首要任务每一个人都在疯狂的赶进度。 以Mac Excel项目为例每周的进度检讨加上报告是微软用来控制进度的主要手段。除了这些开发人员害得每周和测试文件人员共同检讨原因和落后状况。可想而知只要进度落后文件小组和测试人员只好暂时没事做所有目光和谈话都集中在你的程序进度落后上了。 每周经理们会用更新的项目进度报告来更新项目总进度表然后分发给组员。于是你一眼就会看到本周落后了多少整个项目因此落后了多少。心痛之余你翻到后页看看还有多少未完成的工作上周是几百项现在还是几百项拼命做事结果似乎毫无进展。就像一个笑话如果你每次咬一小口多久才能啃完一只大象这张进度表就是一只大象我们一辈子也无法吃完。 实在是太过分强调进度了。以至于无论我们做了多少了不起的事情都没有半点成就感。我们被落后的威胁淹没了再怎么努力也看不到成功的彼岸。这不是工作本身的问题实在是那种绝望无力的感觉所致。 更荒唐的是进度表是基于如下原则设定的 1 为期两年的项目所有该做的事情都在进度表中没有任何遗漏。 2 每人每周实际工作时间40小时。 3 对于每件工作的时间估计完全准确。 4 所有程序第一次出来就是完美状态没有bug不需修改。 这真是天方夜谈。 教训不要利用进程表来驱使项目前进这实在太伤害小组士气了。 在这里作者提出了他自己的观点不应该deadline快到了才开始紧张平时就应该保持适当的紧张状态。多想想如何聪明的工作不要把时间浪费在没有价值的工作上不要浪费别人的时间用积极的态度推动项目。总之不应该在dealine快到来时才动脑筋去想解决办法。平时就应该养成良好的工作习惯。 如果你觉得时间紧迫那么你开会总结一定不会说“这个问题我们留待以后再讨论……”你和组员一定无法容忍事情的拖拉要不删除这项工作要不立刻把它完成。 进度的急迫多数是由于不正确的考虑不正确的工作方式所导致。如果你定的日程表让组员产生了落后恐惧症为了赶上期限而牺牲了产品质量那么该检讨的是这个进度表而不是组员。如果你定出的日程表是个无法完成的目标那只不过是打击团队士气。一旦组员发觉已深陷绝境那你就永远无法让他们表现出最佳状态。他们就会另某高就找个是人做的工作。项目控制 在完成对进度的讨论之后作者提出了他对项目控制的见解 1 进度是基于某些因素上软件的大致完成日期。不要迷信它。不要草率定出不可能的期限导致组员为了赶进度而不顾一切。 2 把长期的大项目分成几个完整而独立的小项目各小项目必须有一个主题。这样既能营造适当的紧迫气氛也让大家有完成目标的成就感。 3 制定测试和质量监控规范这些规范可能涉及产品的速度健壮性安全性等你必须考虑并定出标准。通过质量检测规范的小项目才算真正完成。警惕不要把小项目写成hello world之类毫无意义的测试程序。该有的功能绝对要有该达到的要求绝对要达到。 4 产品的质量远比期限要重要。发现bug立刻清除。你不会知道一个bug到底有多严重存在bug的软件产品会让项目的完成比例被严重高估。更坏的情况下由于bug的存在你会不知道项目究竟什么时候能完成。加班 如果进度落后那表示有个地方出错了。在没有找到问题并解决之前不要粗暴的要求组员加班。这种加班是没有用的。 如果你以进度落后为由强迫组员每天工作12小时。那么他们很可能把私人活动也安排到工作时间里并且在可能轻松的时刻尽可能偷懒。因为他知道每天必定工作12小时不妨把私人活动如看新闻等也在上班时完成。加班通常是浪费时间的面具。 事实上拼命工作并不是成功的关键成功的关键是有一个明确的目标具体而切合实际的计划以及每天不断的向这个目标迈进。 (微软不强制员工的上班时间所以作者如此讨论。但事实上在中国加班一样是最没有效率的控制项目的方式。即使你强迫员工每天12小时坐在电脑前他也很有可能面对屏幕发楞。疲倦的头脑是不可能产生任何创造性活动的。) 加班的目的只是为了赶上进度而已。为了改善我们的工作还有许多手段可以达到这个目的 1 明确工作目标程序员是不是被太多的杂务打乱了开发工作例如不必要的email不必要的电话、讨论、会议。作为主管你有责任把这些障碍找到并一一清除还程序员一个专心开发的环境。 2 合理安排工作例如看email应该在早上中午快下班时看不要在开发过程中让它打乱了你的思路。早上是最有效率的时候让头脑完成有创意的工作而其他时间用来编码等等。 再一次强调你必须牢记自己的目标按进度完成项目并让组员成长。只要你开动脑筋你一定能想到更好的代替加班的方法来达到目的。加班并不是完成这个目标的唯一手段事实上它是最差的能不能赶上进度且不说肯定妨碍了组员的成长。它并不是你的救命稻草如果你依靠加班来完成你的管理工作或者你该考虑走人了。 项目检讨 对项目进行检讨总结的意义不言而喻。但要避免大而无当的总结。检讨应该能做到 1 指出项目的问题所在 2 根据问题考虑防范措施和实际的解决办法虽然有可能只是建议 3 总结经验心得。将来如何利用。 以下是一个例子给出了两个项目检讨的对比 第一个 问题某软件包的Beta版使用者觉得他们的测试报告好像没人注意。因为bug在每一版都出现这主要是因为我们没有建立一套系统的方法去追踪外部的Beta测试报告。所以我们将来应更小心的追踪外部的Beta测试报告并加强后续处理。 第二个 由于对β测试报告的疏忽。不仅影响了项目也影响了关联的其他项目。经理已经同意重新考虑三个追踪Bug的系统我们将在三者中择一使用以便追踪项目的测试报告我们还要把bug和清除bug的行动记录下来。 这个报告是很有效的。他提出了清楚的解决方案详细的执行步骤由谁负责什么时候该完成应用在哪几个项目。还建议了bug的查找方式。 值得一提的是不要等项目结束了才想什么是值得一写的。应该养成平时经常记录的好习惯积累是随时的。管理艺术评估方式 年终评估是最没用的评估。对员工的评估应该随时的进行。员工有什么不足应该立即指出并为他尽量想个改善的方法让他能立刻成长。不要单纯在年终评估记录员工的不足。沟通技巧 有些员工看起来很依赖主管解决问题其实不过是他们的沟通方式有问题。碰到这种员工你可以要求他们 1 清晰表达他们待解决问题是什么 2 有什么解决方法包括他赞同的和否决的 3 陈述赞同和否决的理由。 这样下来通过和员工多次沟通或者你会发现你的员工并不笨他们只是不懂得沟通技巧而已。 一句话你和员工的一起成长是你的目标之一所以不要采用生硬粗暴的方式去对待员工。动脑筋想些更好的法子。人员培养态度正确 你必须让你的组员态度正确。 1 发现bug立刻清除。越晚抓bug越难抓并且能让程序员总结经验。还有如果bug太多那么程序员的功力高下立现。 2 除非我已经完全测试过了没有bug了否则程序不算完工。 3 以用户的观点来看待软件尽善尽美。 4 改正“这不可能”的态度。最好的方法是明确目标然后找出正确的解决方案。 5 鼓励提问。他可能不知道答案但他有权提出问题。 6 未完成的功能绝对不要给用户。 7 善于利用别人的成果。写好的测试过的代码只要符合自己要求就应该用。重复就是浪费。 8 注意提高自己代码的复用性。提高技术 如果某个程序员在你的项目已经毫无进步并且他渴望提高那么让他到其他项目去吧让其他接他的班。短期来看你损失了一个得力干将长期来看你为公司培养了两个人才。 新兵训练先让新人学会一些通用性技术这样他到其他项目组也能用。然后才让他们学会项目专有的技能。训练他们多思考。在设计阶段他们要想得很缜密确定这样的设计没有纰漏写程序时要动脑筋要懂得怎么思考怎么测试这个程序才确保没有bug遇到bug时不要乱猜要思考如何有系统的搜寻bug藏身之处要学会判断是否有相关bug没有现身不但要学习如何对付bug还要思考如何在一开始写程序时就避免它的发生。同时要了解这一行业新知识不断而至他必须不断学习提高才能跟上产业的步伐。工作价值 让组员明白单纯的工作时间是不能衡量员工价值的程序员对项目的贡献在于 1 指出我们在哪里浪费了人力 2 有什么地方可以引用别组的程序代码 3 有什么自动测试程序的好主意 4 想到一个符合用户使用习惯的界面 等等诸如此类。简而言之你必须开动脑筋定下规则鼓励员工学习新的技术养成好的工作习惯做事更有效率从而加快项目的进程。而不是用单纯工作时间来判断员工价值。 转载于:https://www.cnblogs.com/SoulStore/archive/2007/06/26/796379.html
