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

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

  我在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,也可以问问自己这几个问题。

目录
相关文章
|
项目管理
艾伟也谈项目管理,项目管理杂谈-我所期望的新人
  在项目过程中,会有旧面孔的离开,但也有到很多新面孔的加入,什么样的新人是比较讨喜的呢?作为管理者来说,最希望花最小的代价而获得最大的收益,但事实上这样的新人太少了,下面从几个方面谈谈我在工作中期望的新人。
1042 0
|
测试技术 项目管理
艾伟也谈项目管理,对项目管理的几点认识
自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目。中国有句古话叫“旁观者清”,同一个问题站的角度不同,可能会形成不同的结论。下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正。
922 0
|
程序员 项目管理
艾伟也谈项目管理,较大型项目的产品工作心得
  最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。   立项前   1、统一元素设计需考虑周全   也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。
1253 0
|
项目管理
艾伟也谈项目管理,个人管理:从昨天的一个设计评审来谈如何与人交流你的设计思路
  昨天项目组进行了一个设计评审,主要是对OpenExpressApp的AutoUI部分进行重构,我相当于评审人。大家也可以把这个评审过程当做与人交流你的设计思路的一个过程,以下从我评审的一些要素来谈谈与人交流设计思路时需要考虑的内容,也许对大家在实际工作中的架构、设计和沟通都有所帮助。
936 0
|
项目管理
艾伟也谈项目管理,IT项目管理的六种错误思维
  错误一:错误的需求调研阶段,导致很多项目永远无法结束!       在软件行业,在界面设计没有正式展现给客户之前,所有的工作都处于需求调研阶段。其实建筑行业已经给我们做好了先例:客户买房子之前是先要看看样板房和模型的,什么都看不到,这房子你敢买么?除非你不是自己住!而在我们所学的软件工程概念模型中,这是三个阶段:需求调研、需求分析、概要设计。
1214 0
|
Java 项目管理 容器
艾伟也谈项目管理,代码背后的点滴
  有段时间没有更新技术blog了,现在有空每天都写写围脖,记录生活和工作的点滴,但是有时候发现有些技术的想法和工作总结没有像过去那么完整的写很大一篇,但是也有零零散散的不少点滴,因此想着随意的写这么一个连续的片段分享。
1090 0
|
项目管理 开发者
艾伟也谈项目管理,项目的故事
  这是关于一个项目的故事,与其它项目相比,既不非常复杂,也不是很简单: 一个应用程序与数据库以及其它两个系统通信。这在技术和架构角度都是主流,而在管理角度则是标准情况: 所有工作都应该在昨天完成,但还有很多没有完成的。
1193 0
|
项目管理
艾伟也谈项目管理,我的项目管理观点
公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面。我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得。
1011 0
|
测试技术 项目管理
艾伟也谈项目管理,关于项目管理的一点体会
  这段时间,一直在负责一个项目的管理与开发。在时间短、任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品。这其中,经历了需求变更、人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得成功了,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享。
941 0
|
JavaScript 测试技术 项目管理
艾伟也谈项目管理,BUG平台应该是一个知识库
  我很喜欢看各个产品的Bug追踪系统,比如jQuery的Bug Tracker,因为在Bug系统中总能发现一些非常细节的问题,补充自己的知识,慢慢地自己的代码的兼容性会有很大的提高。   但是,在各个Bug系统之中,包括现在公司使用的Trace系统,无一例外地存在一些让我不满意之处,其中最大的原因就是很多Bug系统仅仅是作为Bug的记录系统存在,而没有试图去让一个Bug成为一个知识的积累,让整个Bug系统变成一个丰富充实的知识库。
1061 0