好久没有业绩了，但还在不停加班，你如何向老板证明你做了什么。 苦逼的程序员和苦逼的IT经理，这种噩梦永远在上演：天天加班，有时候是天天无偿加班，而似乎老板或客户还是不满意，总是在追问 “项目什么时候完成？” “你们最近到底做了什么？” 似乎潜台词是： “开发团队的效率怎么这么低？” “你们有没有偷懒啊？” 这种状况真让人受不了，IT经理不禁拍拍自己的脑袋问——我到底在干啥？我这么做有意义么？做IT经理到底为了啥？是不是我入错行了…… ：） 其实上面的困扰，很多人都碰到。最后大多数情况，项目或好或坏的都有了收尾，解决方法也是八仙过海各显神通，但中间经历的痛苦都是类似的。今天笔者不讨论如何解决上述困扰，而是重点说说如何预防上述困扰的产生。 第一：搞清楚项目成功的决定因素不是你 IT经理的作用当然很重要，他是将项目目标转换成代码，将代码转换成可用的软件或系统的关键人物。但绝大多数情况下，一个项目是否成功，往往不是IT经理决定的。成功大多数取决于老板的英明神武高瞻远瞩（或者说是拍脑袋的成功率），有的时候取决于系统使用人群的支持和理解，也许取决于实施时举措是否得力…… IT经理要清楚认识到“自己不是万能的”，别把项目成败的责任都往自己身上揽。项目开发是一个团队协作的工作，在这个工作中，你的老板才是老大，你只是一个关键的配合人物。所谓成绩是大家的，责任也是大家的。这样的心态会避免以后的很多错误。 第二：搞清楚项目成功的定义是什么？ 你可能会问：这有什么好说的？项目成功就是实现了项目目标，而目标早在项目立项的时候已经提出来的。 其实不然。项目成功的定义，可能范围会很广。比如： a. 做出一个理想中完美的软件？还是做出一个可用的软件？ b. 是实现单独的一个大目标？还是预设5个小目标，实现任意3个？ c. 我们的目标是满足 老板的需求？IT经理的雄心？具体使用者的感受？ d. 实现我们的目标？避免目标走向彻底失败？哪个更重要？ 上面几个问题，能够拓展思路。IT经理千万别将自己的身家性命绑定在一个固定的、单一的目标上。要用发散性思维，定义复合型成功的标准：包括小目标、阶段性目标、可用性目标、预防风险性目标、针对不同人群的目标实现等。 三、将复合型成功的目标，告诉你的老板、团队成员、兄弟部门 这需要反复的宣讲、沟通、互相理解。 四、优先做省时省力效果好的事情 我们面前一大堆工作，这是让人头疼的事情。既然已经了有复合型成功的目标，那么就筛选一下，看看哪些工作省时省力效果好。优先做哪些不费什么劲就能见到明显效果的改善，马上取得阶段性成功。 没错，这就是偷懒，不过对于企业来说，需要这样的懒汉。有个名人说过：如果一天工作两小时，我的工作成果会比一天八小时多得多（^_^这名人是我的朋友Sam Chan，他是创思集团的技术总监，经常以此为理由偷懒）。大多数人都在忙忙碌碌的干着不知所谓的事情，忙的唯一意义就是为了显得自己很忙，骗了别人也在试图骗自己。 这种偷懒的经验，也适用于寻找解决问题的方法：实现一个事情有两个方法，一个很简单但老土没有技术含量，一个要用复杂的推理求证编程求解的过程，傻瓜才会选择后者，但搞笑的是，绝大多数人选择后者。 五、有成绩就表功 没错，就是要经常跑到老板办公室，告诉他：我们又取得了阶段性胜利了！ 如果你是在没什么胜利可说，那就告诉他：我们又避免了一次彻底的失败了！！ 呵呵…… 这可不是王婆卖瓜。你要知道经常跑去老板那里告诉他好消息，目的并不单纯为了自己的前途和加薪，而是为了项目的长期顺利进行。 人的职位往往和他能够听到或见到的实际情况的信息量成反比的。如果你不走去汇报，你的老板在大多数情况下是聋子瞎子。他们如果一直聋下去瞎下去也没问题，关键是他们半年后可能突然跑过来问一句：“项目怎么还没完成啊”，那个时候你就很难解释了。 所以多点汇报，不仅汇报困难，更要汇报成功。让他们感觉到项目一直在进展，目标一个个再达成。 上面只是讲了预防，没说解决方法。不过如果按照上面的方法操作了，大多数问题可能已经不存在了。 作者: 谭砚耘@用户体验与可用性设计-科研笔记 版权属于: 谭砚耘 （TOTHETOP至尚国际 ） 版权所有。转载时必须以链接形式注明作者和原始出处 http://www.webusability.cn/it-manager-5th-agony-in-small-company-big-project-what-have-you-done-343/ [...]
IT项目管理
IT经理或项目经理可能都会遇到这个问题，某个特别优秀的程序员或者是项目中的主力程序员，太有性格了，经常和你发出不同的声音。尤其是写代码不牛（网上有很多类似争论，项目经理要不要会写代码）的项目经理，可能还会被明星欺负。 怎么解决这种困扰呢？ 首先，良好心态。 我很欣赏王蒙写的一篇短文《安详》，这篇短文是王蒙写给自己看的，但对每一个人都满适合。里面有一句说到：“安详属于强者，骄躁流露幼稚。安详属于智者，气急败坏显的可笑。安详属于信心，大吵大闹暴露了其实没有多少底气”。这句话说得很好。IT经理首先要具备的心态，就是安宁、平静、沉着有定。 有时候沟通就像登天一样难，但如果心态好，爬楼梯还是能看到美丽风景的。 如果你尊重你的程序员，如非得已，尽量不要采用冲锋式的开放方法。鼓励激情对于销售团队也许有用，但对于程序员，更多的应该Leading Quietly。当你见到明星程序员高声说话的时候，不要先入为主认为他在挑衅你的管理权威。回避正面冲突，然后单独思考一下几个问题： a. 他是在找茬还是在反应问题？ b. 我觉得不舒服，是否仅仅是因为他音调偏高？或是他当众表达相反观点？ c. 他是否代表了其他程序员的想法？其他人没有出声是否仅仅因为自己不是明星，不敢出声？ d. 我以前是否和他沟通的不足够？ 多数情况下，问了上述问题后，你会发现事情没有自己想得那么糟糕。抱着“安详”的心态，世界本身会发生改变。 第二，把不同的声音控制在例会中。 当面对质疑的声音的时候，多数人选择了辩论。用语言取胜，得到的结果经常不太理想，虽然短暂压制了反对声音，可能会给下一次反弹积压更大的能量。 所以，我们需要聆听，聆听不同的声音，或者说是给不同声音一个渲泄的出口。 我的建议是：让不同的声音在例会中充分表达，但仅限于此。 传统开发多数的例会，在检讨进度、需求分析、任务调整，也会让大家表达意见。表达意见的环节往往走过场，不同的看法往往在会上就马上被压制。而笔者是鼓励敏捷开发的，大多数需求分析、任务调整的工作，已经面对面和程序员沟通了。在敏捷开发的例会中，花费更多时间在反映问题，提出观点，通常是不同的声音。如果你只有一个明星程序员，这个时候发声的往往只有一个人。如果建立了这种允许不同观点的分为，更多的人愿意表达。而你会发现很多合理的反面意见，不仅仅是明星程序的想法，也是大多数程序员的想法。 大庭广众的反对声音会显得更加刺耳，而私下交流的反对声音会显得更加柔和。例会提供了一个公开发表反对声音的场合，让大家习惯在这个场合发言，而且提倡发言不针对个人。这提供了一个机会，让你可以在会议后思考，或者是与发言人单独沟通的机会。 这种例会很有效，关键在于例会的组织者需要有包容百川的心胸，同时领导力也是不可或缺的。大多数人认为合理的做法，不一定是正确的做法，或者不一定是最适合目前情况的做法。有领导力的IT经理或项目经理，在接纳不同声音的同时，也应该取得团队大多数人的理解，让大家明白为什么要走一条更艰难的路。坦诚的沟通，让每个程序员都明白公司的目标、团队的目标、你的目标，当然还有你的痛苦，都不妨在例会上分享。 这样，用强制或引导式的做法，将不同的声音限制在例会中，而不是日常工作沟通中。 第三，用目标控制。 敏捷开发有的时候被认为是目标散乱的，实际上并非如此。敏捷开发的最重要目标就是：满足用户多变的需求，说白了就是最大程度的让客户满意。这一目标，要时时刻刻灌输给自己的团队。做成一件事有n种方法，只有最大程度满足用户需求的那几种方法，才是考虑范围。 这样的原则如果让每个程序员都接纳，不太可能，但至少要让大部分人认同，从而变成团队的目标。 一个明星程序员，有的时候耍大牌，只要不触及“用户满意度”这条红线，都不是大问题。但如果他的任性行为会影响到项目的发展，进而给用户造成不利，那么就需要沟通（比如通过上面的例会模式），面谈等方式来解决。 第四，平衡的力量。 如果你发现明星程序员，是对人不对事的，是危害到项目发展的，而且你做出了努力无法改变的。那就要采取行动了： a. 减少明星程序员在项目中的重要性：包括缩减工作量，负责更少的模块开发 b. 尽量安排比较独立的项目，减少和其他人员的沟通 c. 招聘或内部培养同等能力的替代人员 d. 功能类似的两个模块，可以考虑两个人并行开发，鼓励一定程度的内部竞争和比较 在笔者的项目经历中，明星程序员更多是有性格的程序员，理解、包容和沟通，都能使绝大多数问题得到解决。 作者: 谭砚耘@用户体验与可用性设计-科研笔记 版权属于: 谭砚耘 （TOTHETOP至尚国际 及 创思集团 ） 版权所有。转载时必须以链接形式注明作者和原始出处 http://www.webusability.cn/it-manager-4th-agony-in-small-company-big-project-how-to-treat-star-programmer-246/ 如果你希望与作者交流，请发送邮件到 tanyanyun/at/163.com 别忘了修改小老鼠
激励与奖励，一直都是团队领导面对的大课题。而IT经理面对的是一群苦逼的程序员。网上调侃程序员的例子多不胜数，比如经典的《程序员和妓女》。 不少人印象中，程序员是蓬乱头发、因加班而睡眠不足的表情，还有不少人觉得程序员代表着高智商。实际上，除了程序员这一工种的智商水平和其他工种没有特别差异，在良好的规划下，程序员也完全可以规律的工作。甚至，良好的管理可以让程序员从“苦逼”变成“酷毙”。 IT经理应该本着尊重和换位思考的态度，来面对自己的开发团队： 1. 告诉你的程序员：他们在做着一项重要的工作！ 这一点很重要。我们通常会告诉程序员， 这个项目很紧急…… 这个功能很重要…… 必须在deadline之前完工…… 但却很少人告诉程序员， 这个项目对公司的意义…… 这个客户对公司很重要…… 他做的这一部分是整个项目的核心环节…… 给员工分配一项关键的任务，代表着你对员工的尊重，这是一条颠扑不破的真理，包括对待程序员。 我们经常错误的认为程序员是有自我实现的动力的，他们完成了一段代码，就会自然而然的获得满足。实际上这是不够的，他们不仅仅需要完成代码的编写，也期望公司能够告诉他们这段代码对公司的意义。 2. 把适合的工作交给适合的程序员，并且告诉他：你信任他。 信任感是每个人都需要的。不同的程序员能力有区别，有高低的区别，也有能力适用范围的区别。合理安排不同能力的人做适合的工作，并且肯定的告诉他，这项工作适合他，而且只有他能最棒的完成，这样的激励措施是很有效的。 举个例子，有个程序员在独立完成客户项目的时候，总是被其他部门的人投诉，说他干活毛糙而且态度不好。实际上大家没有发现他的重要优点，就是工作速度特别快，工作非常投入。这个程序员和别人沟通总是不畅顺，原因则是因为他讲话没技巧，嗓门大。 那么他的确不适合做一些需要马上提供成果给客户的项目，也不适合进行跨部门沟通。但一些内部应用工具，短小精悍的内部项目。工作调整后，他沟通的人减少了，但工作成果增加了。其他部门的同事获益于他的工作成果，夸他的人也多了。 3. 工作的时候，别总是走到程序员背后 如果一定订好了进度和计划，就不要习惯性的走到背后干扰你的程序员。尽管有的时候你是好意，走到背后也许只是说：“嗨，今天天气不错”。但这的确就是一种干扰。 有啥话，在计划会上说，在总结会上说，哪怕在会议上聊聊私生活活跃一下气氛，也是不坏的。 总之，不要为了展示你的魅力或你的权力，而去打扰一位忙碌的程序员。 4. 经常总结成果，经常说谢谢 在例会或总结会上，除了督促进度外，要花更多的时间来总结成果，并且对这段时间表现优异的人或事说“谢谢”。 绝大多数员工，都希望看到自己的努力带来了改变。程序员也希望看到自己的代码变成实实在在的效益或效果，尽管往往软件正常运作后都看不到程序员的影子。 IT经理要理解这种心理，要善于发现平凡代码中的闪光点： 我看到这个功能用了最新的技术，很棒…… 总经理查看了进度，对xxx的工作很满意…… 我们的客户看了演示版本，称赞了公司…… 销售人员用了改进的版本，业绩提升了10%…… 5. 给予合适的酬劳和令人舒适的工作环境 酬劳的问题和公司、市场有关，往往不是IT经理能决定的。但舒适的工作环境则是IT经理可以协助创造的，比如适当的弹性工作时间，在请假方面的人性化，电脑配置，适当的户外集体活动等等。 如果IT经理关注了上面5个问题，你会发现程序员在士气方面会得到不同程度的改善。那样，你的工作也就好做多了。 经理关注了上面5个问题，你会发现程序员在士气方面会得到不同程度的改善。那样，你的工作也就好做多了。 作者: 谭砚耘@用户体验与可用性设计-科研笔记 版权属于: 谭砚耘 （TOTHETOP至尚国际 ） [...]
困扰二：很难制定长期计划，老板的想法变了，IT项目的方向也会发生变化 小企业小团队的软件开发项目，经常会遇到需求变化的情况，这也是让IT经理很头疼的问题。 如果我们沿用最传统的，也就是瀑布开发模式，流程按照需求分析，设计，实现，测试 (确认)， 集成，和维护线性执行。这要求在开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，的确能有效的确保系统品质。但从另一个角度而言，这对需求分析提出了很高的要求，一旦需求在开发过程中产生变化，会造成巨大的资源浪费。 要解决这个问题，建议采用敏捷软件开发模式。 敏捷开发模式的简单定义：不苛求完美，尽快推出可满足基本使用的软件版本或演示版本，让用户在使用过程中测试并调整需求，程序员根据需求不断推出微调后的新版本，最后臻于完善。 敏捷开发有如下几个特点： – 要尽快的开发出可供使用的软件，而不是一个完美的软件； – 经常推出可供使用的新版本，周期越短越好 – 欢迎需求的变动，随时调整，保持客户的竞争优势 – 业务人员和开发人员要始终在一起配合工作，而不仅仅是需求阶段 – 各路人马之间最有效的沟通方法是面谈，而不是邮件、电话、远程、文档等拖沓的方式 – 提倡可持续开发，保持不变的开发节奏。而不是一会通宵加班，一会又无所事事的开发方式 – 提倡简单、简化的思路——用各种手段减少开发工作量 – 追求卓越技术和良好设计，将有助于敏捷 – 团队定期总结经验，商讨提升效率的方法并实施 根据笔者的实际经验，对于小企业小团队开发，敏捷开发是最适合的。 因为企业小，在竞争中需要不断变化以保持优势，所以需求也在不断变化中； 因为团队小，无法在系统最开始提供完备的规划、需求分析、质量控制文档等； 因为企业小团队小，所以没有那么多职位的层级架构，经常是在老板和IT经理的带领下，各团队之间可以快速沟通，面对面沟通。 笔者有一个例子： 项目是开发一款以邮件营销为主的saas系统，系统的目标客户是机械及模具企业。 1. 项目到来之后，经过简单需求分析，确定了大致方向。 2. 刚好这个时候有一个客户找上门，刚好要做一款类似的但简单得多的单机版软件，供每个销售员人手一套。 3. 于是我们答应用很低的费用帮客户设计软件，前提是开发完成后，软件可以重复销售给其他用户。客户答应了。 4. 协议签订后，软件团队迅速行动起来，在一周后提供了第一套可供使用的单机软件，交付客户使用。 5. 客户使用过程中，顺便帮我们做了测试工作，并提出一些新要求。 6. 软件团队持续改进，以每周一个新版本的速度提供给客户。 7. 客户提出了颠覆性的需求，单机版不再满足需求，需要一个网络版可以管理全公司所有业务员的邮件营销行为。 8. 2周后，网络版推出。客户满意。 9. 我们继续完善软件，将软件修改为部分Saas结构，并添加了搜索信息、传真营销、短信营销以及安装了一些营销实用工具。 10. [...]
困扰一：需求可能不是来自于前线部门，而是来自于老板的脑袋瓜 需求分析，是软件项目最关键的第一步，也是最容易出错、最困难的一步。错误的需求导致错误的开发方向，最后轰轰烈烈的走向失败。 大企业的需求分析有很多步骤，比如需求可行性分析、绘制系统关联图、创建接口模型、创建需求模型、制定开发标准化手册等。 而小企业的IT项目，往往是“老板驱动型”。情况往往是：某家正在盈利中的企业，突然发现IT支持无法跟上企业发展了，于是老板觉得应该做些什么，于是需求产生，IT项目也产生了。 需求来自于老板，而不是业务相关部门。这当然不一定是坏事，起码证明公司最高决策层认可这个项目，并且会成为项目的支持者。 但也会带来一些潜在的问题，如下： 1. 老板的需求可能和相关业务部门的需求产生冲突。 老板处于决策层最上端，对大方向把握自然更准确，但他对相关业务部门的实际面对的问题不一定完全理解，可能和相关业务部门的实际需求产生冲突。 2. 过于理想化可能会导致项目变得臃肿而降低实用价值。 老板的需求可能是理想化、宏大的，恨不得一次到位解决所有问题，往往造成项目预期过高、时间过长、尾大不掉，项目会搞得各部门很疲劳，最后草草收尾，而使用效果很差。 3. 老板会成为项目唯一的驱动力，这是很危险的。 对于一个长期的IT项目，要成功必须依赖各部门团队领导的不断推进。如果只考虑老板的需求而忽略其他部门，会造成老板成为项目唯一驱动力，其他部门勉强配合的局面。最后结果可能是老板气死，IT经理累死，其他部门憋屈死的情况。 对小企业的大项目，要避免上述情况，可以参考下面的建议： 1. 首先要弄清楚老板提出需求的真实原因，也就是老板的潜在需求。 有这么一个笑话。三个女孩都想嫁给一个有钱人。有钱人出了一道题目，要用1两银子买东西填满整间屋子。女孩1号买了一大堆棉花，填满了1/3房间；女孩2号买了一大堆气球，填满了1/2房间；女孩3号买了一盏油灯，灯光填满了整个房间。最后有钱人选择了哪个？——选择了胸最大的那个。 上面这个故事告诉我们，需求是很难琢磨的。 真实需求如何探知呢？可以直接问“您为什么要启动这个项目”，但往往得不到你想要的答案。有技巧的询问，也许有帮助，如： a. 您想采用A方案，为什么不考虑B方案呢？ 注：将自己代入一个“无知的问题少年”的角色，有的时候会问出意想不到的有价值的内容。 b. 竞争对手有没有采用同样的做法？（如果有，我们为什么要跟随？如果没有，我们为什么不跟随？） 注：企业的老板，对竞争对手的做法是很关心的。他们往往会给出思考后的答案，这对了解潜在需求也是有帮助的。 c. A方案的潜在风险（可能的困难）有哪些？有没有同行类似的失败案例？原因是什么？ 注：为了避免老板拍脑袋之后随意产生需求，这个问题很重要。当然需要注意询问的语气，因为老板可能会反问“你觉得呢？” d. 在方案A中，哪一部是最关键的，或者是见效最快最明显的？ 注：可以得到一条重要信息：老板最关注什么。对于之后的沟通很重要。 e. 在实施方案A中，哪个部门将受到最大的影响（收益？损害？），对于与这个部门的沟通，您有没有什么建议？ 注：为了下面的部门沟通获取情报。 2. 与各部门的沟通，了解改革可能造成的痛苦指数，预计最坏情况 和老板沟通的同时，要开始和各部门领导沟通。 这个时候，项目启动的消息往往已经传遍整个公司，应该先找哪个部门谈呢？ 如果你按照上文询问过老板，加上你自己的判断，找哪个部门很容易做到。 新的项目意味着新的流程，会遭到各种各样的疑问和不配合。但现在不需要辩论，只需要倾听，倾听他们在项目实施后可能遭遇到的各种痛苦和各种抱怨。 信息的精确度和完整性往往随着接收者的职位成反比，你的老板可能意识不到这一点，但作为项目的执行者，IT经理必须要意识到这一点。 业务部门在抱怨和牢骚的过程，也是一个提出需求的过程。也许他们对于项目的大方向和老板是一致的，但在对具体某些关键细节上，会有不同的要求。这些都是很宝贵的。 通过自己的独立思考分析和评估，你可以给出相对客观的部门痛苦指数，并预计项目实施后可能遇到的最差情况。 3. 找出痛苦指数相对低但效果比较明显的改进方案 综合与老板、部门的谈话。找出折中的需求方案。 4. 将你的折中方案和部门经理讨论，并说服他们 [...]
小企业轻团队大项目: IT经理的5种困扰（零）
十一 21
IT项目经理怎么做？太多相关的文章，网上搜索一大把：你可以看到诸如：团队文化、梦想、沟通、目标、激励、合作等关键词，也能看到系统分析、框架设计、CDM、PDM等专业术语。 以上的经验，很多来自于行业巨头公司的IT项目经验分享。 大项目的IT项目经验固然有用，但更加适合大型企业，开发团队成员也达到数十人或更多。 而实际的项目经常是这样的： 1. 小企业（并不是所有公司都是世界500强） 2. 大项目（这是的“大”是相对的，是指项目对企业很重要，公司业务围绕该项目运作，可能会持续数年开发和完善） 3. 轻团队（可能你只有3～10个程序员，1个页面设计师） 4. 多合一 （IT经理、产品经理、项目总监三个人实际上就是同一个人） 上述的情况，实际上是最常见的IT项目。如果我们按照教科书式的《IT项目经理ABC》来操作的话，会发现你会面对很多原来想不到的种种问题： 1. 需求困扰：核心需求不是来自于前线部门，而是来自于老板的脑袋瓜 2. 计划困扰：很难制定长期计划，老板的想法变了，IT项目的方向也会发生变化 3. 人员困扰：你面对一群苦逼的程序员，工作没有荣誉感 4. 明星困扰：唯一的明星开发人员太有性格了，渐渐成为项目的阻碍 5. 成绩困扰：好久没有业绩了，但你们还在不停加班，你如何向老板证明自己做了什么？ 以上的问题，相信每一个IT经理或项目经理都遇到过。 之后会陆续就以上5种困扰，讲讲自己的一些感受。 作者: 谭砚耘@用户体验与可用性设计-科研笔记 版权属于: 谭砚耘 （TOTHETOP至尚国际 ） 版权所有。转载时必须以链接形式注明作者和原始出处 http://www.webusability.cn/it-manager-5-agony-in-small-company-big-project-97/ 如果你希望与作者交流，请发送邮件到 tanyanyun/at/163.com 别忘了修改小老鼠
