编写软件操作手册是谁的责任,是谁的工作呢。不能没有人来做吧。
本来是售后(软件售后部门)来写这个稿子的呢。
最近,软件要进行适用期了。也还没有做好准备,今天赶上售后部的人都有事出门了。因此,这一部分初稿,我也来参与写一部分。
操作手册怎么写,写什么呢。我就干脆,把软件的工作流程写一遍,发现自己的水平太低了,组织语言不是很好,当然,我的工作是写程序,分析问题解决问题,至于手册,还是要写一部分手册的呢。
一是自己熟习操作过程,二来嘛,也是自己写的程序,要对程序负责啊。
自己总结一下,软件开发过程,现在的软件能遵守的能有多少啊。
文档先行策略不行。文档跟不上开发人员的进度啊。有些东西, 改得太多了。文档跟不上。
计划赶不上变化,这是文档的最大的缺点。
开发部门,测试部门,售后部门。市场部门,还有办室区构成的公司,也有一定的正规性。
其实文档也不是必须的,所有的源代码都可以表明你做了什么,完成到了什么程序。
本来是售后(软件售后部门)来写这个稿子的呢。
最近,软件要进行适用期了。也还没有做好准备,今天赶上售后部的人都有事出门了。因此,这一部分初稿,我也来参与写一部分。
操作手册怎么写,写什么呢。我就干脆,把软件的工作流程写一遍,发现自己的水平太低了,组织语言不是很好,当然,我的工作是写程序,分析问题解决问题,至于手册,还是要写一部分手册的呢。
一是自己熟习操作过程,二来嘛,也是自己写的程序,要对程序负责啊。
自己总结一下,软件开发过程,现在的软件能遵守的能有多少啊。
文档先行策略不行。文档跟不上开发人员的进度啊。有些东西, 改得太多了。文档跟不上。
计划赶不上变化,这是文档的最大的缺点。
开发部门,测试部门,售后部门。市场部门,还有办室区构成的公司,也有一定的正规性。
其实文档也不是必须的,所有的源代码都可以表明你做了什么,完成到了什么程序。