艾伟也谈项目管理,个人管理:写书之前应该回答的几个问题

  我在06年和一个同事写过一本Delphi入门的示例书籍Delphi数据库通用模块及典型系统开发当时体会到了写书不像想象中的简单,基本上业余时间都没了,所以我之后就不想出书了,其中更重要的一个原因是,我还没有找到一本真正想与大家分享并且自己能写出来的书籍。

  博客是个好东东,只要你愿意与人分享交流,你的行为就可以赢得大家的认可,如果你的观点或者文章写的又好,那么就会有更多形式与大家分享,例如最近我们可以看到的很多人都由于blog而出书了。同样,我这两年对博客的投入也赢得了一些人的信任,也收到过好几个编辑的邀请,希望能够合作出一本书。

  去年我对个人管理这个系列非常感兴趣,因为我觉得这个话题是很多人都忽略但是又极其重要的话题,我希望通过我个人的一些心得体会能够给在校或者刚步入工作岗位的朋友一些帮助。华章编辑看到我的个人管理系列文章,觉得写得非常不错,所以邀请我写一本关于个人管理的书籍,我也看到一些关注我的朋友希望我也写一本系统化的个人管理的书籍,所以我突然感觉这本书就是我要写的,所以当时我也爽快的答应了。还写了一个序:

  本书是一本介绍个人软技能方面的书籍,文中的内容其实已经酝酿多年了,总有一些想与大家分享的冲动,可是一方面觉得自己的知识还不够系统化,另一方面担心自己不具备这方面专家那样的成就,因此总不敢提笔。但近几年在与同事、朋友交流,以及在博客上与大家的分享中,让我意识到正是由于我不是那些令人敬仰和追捧的专家,而是大多数普通人中的一员,所以我更加与大家有共同话题。随着这些年自身渐进的增长,我对个人成长方面的思考也更具系统化,所以现在才有勇气出版这本书。

  就像做架构一样,很多东西都可以借鉴别人的思想,这本书也并不是我独创的,大部分思想和方法也都是从他人总结中获得的,我做的只是从IT人员的角度,结合我个人成长经历上去做了进一步的理解、融合和整理。

  不过后来有两个原因没有继续下去,一个原因是华章老板不太支持这个主题,还有一个重要原因就是我一直觉得我现在对个人管理的知识还不体系化。第一个原因倒不是很重要,因为后来还有好几个编辑找过我,但是第二个原因一直影响我的选择,我总是觉得我现在写出来的不成体系,即使写出来也不是一本好书,所以我后来基本上都回绝了朋友的邀请。

  下面我想与大家分享一下在写书之前应该回答的几个问题,我想在写书之前问问自己可以避免太早关注写作,而忽略了真正的目的。

  1. 你为什么要写这本书?(Why)
    个人管理中一个重要的步骤就是先找出做事情背后的真正目的,写书当然也不例外,检查自己写书的动机。主要目标和目的是什么?是为了钱,还是提高知名度或者给自己制作机会?
    我写第一本书是给朋友帮忙,后来给另一个朋友写了两张的SQL Server书籍,之后就没有再写了,因为我发现如果我要再写书,首先一定是要我自己喜欢和认可,要不就是有点难度的,要不就是能真正帮助别人成长的,通过写书可以认识更多人,提高自己的知名度,对于钱倒是没有考虑过。
  2. 你希望这本书的读者是谁?(Who)
    做产品商业战略时重要的一步就是市场细分,找出客户,写书也一样,为谁而写?写一本适合所有人的书是不现实的,不同的人需求不一样,如果一开始找错对象了,写出来的书一定也不好,不是不畅销就是内容不对路。
    就像我在 你可能需要的在线电子书中写的几本电子书都分别有不同读者,如果把这些内容都写在一本书上,那估计看得人就不多了。写书之前,想想这本书适合什么年龄、什么阶段、具有什么经验的人才会对这本书感兴趣。
  3. 你想要读者有什么改变?(What)
    我们写了一段代码,兴奋自己如此聪明,但是到最后发现这只是一个镀金的功能,由于它还可能带来复杂性或bug,所以最好的程序一定是用户业务来决定的,而不是自己。与此类似,成功的书一定不是自己说出来的,也不是市场营销出来的,最后一定是读者反馈出来的。读者为什么会说你的书好,那一定是这本书对读者有影响,那我们希望读者有什么改变呢?就就像我们做产品架构时需要分析as-is和to-be一样,读者的to-be是什么呢,这个问题可以很好的帮助我们确定写作范围。
  4. 现有的与你同一主题的书有哪些?(What)
    每个编辑都会赠送我一些书籍,其中至少有与约稿同类型的书籍。参考现有的书籍对写作是有好处的,这就如同做产品去分析竞争对手一样,取长补短,找出你的亮点,写作时突出这些价值点一定会更吸引读者的眼球。
  5. 你可以采用哪些发布方式?(Which)
    相对于以前,现在有更多的发布方式。首先是选择一个好的出版社,或者可以选择自己出版。自己出版这个方式在国外很常见了,我现在就是自己发布了一些电子书籍,感觉像发CTP版本一样:)我觉得这是不错的一种方式,虽然钱不多,但是这本来就不是主要目的,使用这种网上电子书发布的方式可以让出版变得很快,而且不需要像正式书籍那样书写正规和体系化,如果你也有很多知识可以积累成册,那么你也可以尝试一下这种方式,还是蛮好玩的:)
    以下是我的一些电子书列表:   
  6. 你准备如何推销你的书?(How)
    不管你是以赚钱为目的还是提高知名度,你都需要考虑如何推销你的书。如果你是和出版社合作,好的出版社会给你做宣传;如果是自己出版,那么加链接、上论坛是最常用的办法。就像我总在blog最下面加一个我的电子书链接,或者在相关话题下面也链接上相应的书籍。很高兴通过这些方式,我的电子书已经卖了4千元,你可不要小看这些钱,毕竟现在电子书可以在线免费全部查看,即使买也比较便宜,再加上你的电子书也有盗版,所以现在卖了这点钱我还是觉得蛮不错的,从中也感觉到大家的认可和支持,我会不断完善和积累新的书籍的:)

  以上的问题,其实不仅对写书有用,如果你正在写一篇文章或者发布一个blog,也可以问问自己这几个问题。

时间: 2024-10-24 20:18:37

艾伟也谈项目管理,个人管理:写书之前应该回答的几个问题的相关文章

艾伟也谈项目管理,需求管理成熟度的五个级别

需求管理是软件开发全生命周期重要的一个环节,我们每个人都知道它的重要性,但是要真做做好并不简单,我也写了一本在线电子书业务分析与需求.pdf来讲解需求相关内容.对于每种技术和方法,就像以前我写过的企业架构成熟度模型(EAMM)的一样,我们都不可能一下子就精通,而是按照一种学习的曲线进展,本篇本篇主要介绍一下需求管理成熟度的六个级别. 级别0:没有需求(no requirements) 没有任何明确的需求被记录下来,他们假定知道要构建什么,希望节省需求的时间来做开发,但这势必会给开发工作带来混乱,

艾伟也谈项目管理,学习腾讯的产品管理之道

马化腾带着一大批产品高管自上而下,持之以恒地推动产品本位的管理体制规范化,并不断地创新和优化这套体制,使得整个公司上上下下融入了"产品的基因",最终成就了"产品的腾讯". 1.设置一个质量监控小组,由经验非常丰富的高Level的产品人员构成,赋予他们很大的权力,去监控和规范所有的产品项目.并且用KPI来制约产品项目服从这些规范.为了不搞教条主义,很多规范都是在立项之初,由项目经理和这个小组共同确认的,未必是硬性指派,一经确认就受到严格监控.确保好的规范不流于空喊口号

艾伟也谈项目管理,如何管理“人”

我们常说工作中应该"对事不对人",但事都是人做的,不同的人做相同的事效果可能相去甚远,再好的业务如果用错了人也会全盘皆输.正所谓"事在人为"嘛,识人.用人.聚人是一个团队管理者获得成功的基础. 先说怎么认识人   人格矩阵法.即所谓的Topk技术,Topk就是由:tiger.owl.peacock 与 koala 4个英文单词的第一个字母组成,即把人的人格类型总结为老虎.猫头鹰.孔雀与考拉这4种动物的行为智慧: 老虎-此类人表现为:做事结果导向明显(不在乎过程),野

艾伟也谈项目管理,【项目管理】关于异地开发中的源代码管理问题

最近在带领一个异地的团队在进行.Net B/S系统开发工作.两地相隔1000多公里, 两地都有开发人员,源码的统一管理就成了需要解决的问题.针对这个问题,想到如下的解决方法: 一.利用Microsoft Visual SourceSafe的Internet功能 优点: 1.考虑使用VSS是因为他与Microsoft Visual Studio集成的很紧密.可以在编译器中对源码进行直接Check in 和 Check out.使用的效率很高. 2.团队成员入手容易.在对需求清楚的情况下,可以快速溶

艾伟也谈项目管理,技术管理中常见的几个问题

前几天跟朋友聊天时,朋友说他刚刚从一家知名软件公司面试出来,朋友去面试的是一家公司的技术管理岗位,所以在面试的时候被问及的问题也偏重于技术管理方面的问题,在与朋友的聊天中将这几个问题归纳了一下,大致归为如下几个问题. 在日常工作中你是如何行使管理职能的 这个问题以我的经验以及参考常见的一些开发方法,在实际中我都是早询问及晚反馈的方法.也就是早上上班后的半个小时内主动询问开发人员是否有不能及时解决的问题,如果有,组内组员讨论解决方法:下班的时候,组员可以以邮件或者其它方式汇报自己的进度,并评估当前

艾伟也谈项目管理,架构组织管理

架构组织管理的五大原则:构想.节奏.预见.协作和简化 架构组织的三在概念:准则.模式和反模式 准则:为了把原则运用到实践中,需要实施细节.准则把广泛的原则翻译成是否和如何执行原则的细节. 模式:描述了开发或者使用软件架构时可能遇到的常见问题的解决方案. 反模式:反模式描述了组织在实践中可能遇到的陷阱,描述了不该做的事情,或者用在错误背景下的解决方案. 一.构想       说明了如何向架构的受益人描述一幅一致的.有约束力和灵活的未来图景.构想需要维持一致性和协调性(灵活性).      [其实就

艾伟也谈项目管理,项目管理实战之团队管理

一个系统不仅需要优秀的分析和设计,更需要一个良好的过程将其从蓝图转化为实现.这个过程中最重要的是对团队的管理,也就是人的管理.一个优秀的团队和一个糟糕的团队的效能是天壤之别,她们之间的比例不是1:100或1:1000这样量化的数字能够表示的.就像一个团队建造了一幢摩天大楼屹立于云霄,而另一个团队的建筑物还没有10米高便开始摇摇欲坠!这是质的差别,也是团队灵魂的差别. 而团队的领头人就是项目经理,他的能力/素质直接影响着项目的成败!我们不需要一个团队的所有成员个个都是优秀的,但是为了确保你的项目成

艾伟也谈项目管理,工作感言:任务分配及管理

      前面说到过,刚开始带小组,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间"小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多,而且小组里有的人做完了无事可做,有的人则忙得焦头烂额,容易打击组员的积极性,造成组员之间的不满.      随着经验的积累,要想把任务分配得比较合适,首先要对自己的组员有一定的了解,最好能量化,其次要把握好任务(这就看需求

艾伟也谈项目管理,软件公司的两种管理方式

这篇文章是我的一个外国的同事Gareth推荐给我的,我和他一起工作过一段时间.他之所以觉得非常不错,是因为这篇文章让他身有体会,他觉得我也一定会有体会,并让我考虑一下翻译到我的blog上来.我看完后觉得很有代表性,而且觉得说得太对了,所以翻译过来,希望大家都读一读,最好转给你的公司老板. 这篇文章来源于 StakeExchange 上的一个问题--"为什么BA和PM的薪水要比程序员要高?",顶在一楼的回复分析了这个原因,并指出了两种管理文化. -------------------正文