当前位置： 查字典图书网> 管理> 走出软件作坊> 从一个程序员到领导者转型

从一个程序员到领导者转型

qintao 对 走出软件作坊 的书评 发表时间：2009-07-14 09:07:26

读阿朱的这本书感触蛮多，有些思想和内容在很早的时候就在一些资料就见到过，但是这些观点虽然都是很明显的，但是只有在自己真正经历之后才会明白其中的含义。
  软件开发一个市场人员看上去很简单的工作，实际的复杂性可能是无法预测和想象的，在前期项目准备中可能公司的业务会盲目的给客户打包票，说我们技术多NX 多NX ，什么都能做，这个现象应该在很多公司都有遇到吧，其实很多东西都是无法完成的，但是业务部门的人用很感性的眼光认为zhe这些都是很简单的东东，开发人员和业务部门都会互生怨气。业务开始激情万丈，但是一听到程序员说这样不能做，那也不能做，顿时心里面就开始打小算盘了，比如以前一个业务，说 我辛辛苦苦、跟客户谈了好久好久。。。。结果。。。
   我个人认为应该把业务和开发编排在一个队伍中。开发经理应该先个业务部门一个大概的实力估计，业务部门应该及时的反馈和明确公司的研发能力。 大家先跟外面谈判和交流的时候，一条心去做，解决掉内部的问题，一条心去项目，应该大家合作起来会更加愉快。
     
   打包票。。。这个东西业务人员特别喜欢，不管怎样先把项目接下来再说。。。
    软件作坊 需要项目，但是我觉得项目多了。反而或许会拖累整个公司的开发进度和质量， 比如说以前公司做了一个电子商务系统，然后又有单子做 社区系统，然后公司还在做核心软件的研发，但是公司的美工配置是有限的，美工组是作为所有项目的协调使用，但是在做社区系统的时候客户不满意的多在于UI前端，今天不满意，明天也不满意，刚把这改了，又要改那，UI毕竟是个人喜好的东西。或许UI工程师觉得满意了，用户都觉得满意了，但是客户说这个不好看，，没办法。你不能定量的去衡量的东西，真够麻烦的。研发项目这边技术难度是最大的 大部分是核心代码的编写，几百行代码都要计算很多草稿纸的那种类型，但是UI 也很重要，因为UI 能反映出我们最后需要的什么效果，但是客户不满意 UI 就要继续花很多精力在上面，研发项目的UI 设计只是你要求他才设计，这是UI设计的一个比较忌讳的事情。毕竟是偏向艺术的技术活。这也不能怪UI，因为UI的精力有限，在反复修改的情况下，心里面就会变得烦躁不安，灵感或许就丢失了。。
最后没办法 只有先忍痛割爱了，砍掉一个项目，最后是草草收尾，

做软件作坊 应该先考虑做精 一个东西，就已经能够算得上很有成就了。
你做电子商务，就专心攻克，你做游戏 就专心做游戏。做系统内核就老老实实的研究操作系统，这或许更有成功和壮大的可能性，因为把所有的力量都集中在解决一个问题上面了。今天想做这个，明天想做那个 天天研究，天天讨论，最后撒东西都做不出来。

  感觉在开发中 团队开发中问题很多很多，有很多程序员都有自己的个性，自己写的代码根本不能让人看懂，而且很多代码都是硬代码和基本不能移植和重用的代码。反而他们认为自己很NX，这种心理应该很多程序员都有的吧。不过感觉代码写多了就好了，
  程序员都不喜欢运动，这个会影响到开发效率，程序员老是坐在那儿敲代码，不参加一些运动，我在观察中发现这样会影响开发的进度和开发的质量。 最好是每个星期 几个人组织打一次球之类的活动，像我们公司公司夏天的时候每个星期组织一次游泳。。虽然很多CODER 都是旱鸭子，不过也可以活动筋骨和促进血液循环，大脑的供血充足，思考的就会更加敏捷。而且在运动的时候有可能找到新的灵感和问题的解决方法。

有用 4 无用 0

您对该书评有什么想说的？

对“从一个程序员到领导者转型”的回应

在路上
在路上 2009-07-14 21:50:24

从一个程序员到领导者转型，迈出的第一步应该是：
1把来自各方的需求都汇总到你这里
2你自己整理成统一的格式，归属好是什么人员提出的，什么时间提出的。
3你自己分析好为什么要这样提，有什么更合适的解决方法没有？
4你自己分析好优先级
5适当的挑出一些安排进下个月的开发人员开发计划中
6天天跟踪进展，及时确认完成质量，及时关闭
7及时关闭后，及时发邮件通告这个需求的原报告人，邮件可以备忘备查。

因为寻求别人的协同，往往走出第一步很困难。先做好自己，证明自己能够成功值得信任，别人才愿意与你合作。

回应他

《走出软件作坊》热门书评

走出软件作坊

书名： 走出软件作坊
作者： 阿朱
出版社： 电子工业出版社
出版年： 2009-1
页数： 403
定价： 39.80
装帧： 平装
ISBN： 9787121065392