走出软件作坊文档格式.docx
《走出软件作坊文档格式.docx》由会员分享，可在线阅读，更多相关《走出软件作坊文档格式.docx（21页珍藏版）》请在冰豆网上搜索。
1商业眼光，2管理才能，3技术眼光，4产品架构
绝对的结果导向。
老板眼中的能力也好，本事也好，就是能把老板交给的事情办得很圆满很稳妥。
办任何事，都可能会出现这样那样的意外，但真正有本事的人总是能摆平，而那些自以为有能力的人往往会抱怨是这个原因那个原因，甚至归罪于自己的运气不好。
这样的人，只是虚有其表，孤芳自赏。
时间稍长，他便会淡出老板的视线。
在管理中，我发现人是第一重要的，但是很遗憾，总是能看到不少心胸狭窄、眼光短浅的老板，把员工当傻瓜，把客户当傻瓜。
其实，人对了，世界就对了。
支持自己的老板、高素质的员工、高素质的客户，貌似只有三者齐全了，才能把好的方法实施下去，把事情做好。
然而，在一个再普通不过的环境里：
公司并非国际巨头，甚至也不是国内知名企业，老板并非魅力名人般的大胸怀大眼光，员工也很少出自名牌大学，所从事的管理软件行业也不是暴利行业，客户千奇百怪，从挖煤发了财的暴发户到内部勾心斗角要死不活的国企，什么样的都有。
在这样的环境里，如何将方法用起来。
最重要的是，认可了一下观点，即一个职业经理人和老板的关系。
1．老板多是疑人也用，用人也疑。
用人不疑，疑人不用，我不奢望老板会这么想，因为这不现实。
2．再劳苦功高，我也只是职业经理人，我不拥有这个企业的哪怕1%所有权，所以我做好职业经理人本分。
注意职责权利范围，不越矩。
3．计划不计划一件事情，执行不执行一件事情，一定要以老板的利益为目的。
老板不赚钱，一切好事一切好想法都会被老板推翻，老板就是老板。
老板赚钱赚得眉开眼笑，其他的事情就好办得多。
这是很多职业经理人居然都认识不到的，盲区啊。
他们总抱怨老板限制得太死，什么资源也不给，干活还贼累。
根源就在这里了。
想实现你的想法，必须在实现了老板想法和目的的前提下才能做。
所以我的方法能实现，都是因为有了先让老板赚钱的前提。
//想让别人按你期望的做，首先要得顺着人家的意思，先满足人家的需求，让人家尝了甜头，你取得了人家的好感和最初的信任，才好让人家顺着你的意思做事。
说话也是这样，先扬后抑。
说他人不太好接受的话，事先得先塞颗糖。
4．方法都是为了解决实际问题，为了老板赚钱更快、更省成本、更容易，员工更省力，客户更满意，而且每个方法都是在本企业能力和成本范围内能执行落地的解决方案。
这样的解决方案，哪个老板会不支持呢？
但奇怪的是，很多研发部主管都忽略这个重点，老板在想利益，他在想技术。
意见不一致时，找合适的时机向老板说明思路。
注意时机。
如何创造好的氛围？
1.抓大放小，搭台让人唱戏。
许多管理者喜欢对下属揉捏有余，雷厉风行，显得自己很有手腕。
我更喜欢给大家提供舞台，引导目标，提供经验指导，让他们互相搭配表演一场好戏。
我不是一个喜欢控制的人，我喜欢抓大放小。
往往大部分事务的成败，也就有那么两三个关键点。
你抓住了关键点，事务就不可能偏得太远。
有了问题，我会在远处静静看着，也不干涉，我要看看我的团队会如何应对，这样很锻炼一个团队，我也会在合适的时机插手，以防事情失去控制。
有问题解决问题，没有问题你茫然什么，你又什么压力，你慌什么？
我总是这样对我的下属说。
2.师傅带徒弟
团队的凝聚力、配合性、归属感、责任感，很多问题都被人的感情消化了。
3.朝九晚五，禁止加班
4.搞好环境、整好形象
5.立即奖励，马上兑现
引进人才的心得：
1.第一当数责任心
没有责任心，做起事来吊儿郎当，最后的结果是很平庸。
这样的高才自己觉得很自傲，觉得自己应该有更高的薪水，但是他就不看他最后的产出，就看自己满身的“才”。
这有什么用，我们看的是结果。
2.人的年龄和工作经验要拉开距离
招聘这事得年年招，时时招。
不断看人、试人、滤人、培养人，形成有阶梯有接力的员工组织，层次分明，结构合理，绵绵不断，前赴后继，不会出现人才地震、集体疲劳，小团伙争斗。
3.技术第二，EQ第一
我的测评方法仍然是不讲道理，要讲经历。
没有工作经历，至少有学习经历和生活经历吧。
其实，试用期的三个月主要就是看他的EQ和他的技术能力、理解能力、学习成长能力，而不是片面只看他的现状技术能力。
4.专业发展，流程协作
如果不专业化，老板有什么活就分配什么活，时间短了还认为自己是在学习更多知识在锻炼。
时间长了就会觉得自己就像个混子，什么都干过，但什么都拿不起来。
5.互相交流，制定下一阶段的目标
交流，是为了能给员工制定一个切实可行的、某段时间段内可达到的、他喜欢也愿意努力的，且对他未来职业发展很有好处的职业目标。
没有目标的工作，虽然他很努力，但是他容易迷失方向。
给机会给项目锻炼人。
润物细无声的方法教育人。
//不弄专门的培训，这种状况，在小公司是合理的。
但大公司，还是需要一个合适的较长的培训。
我也经常用高于他能力一倍的项目锻炼人。
我不会给他看书学习时间，我相信实战锻炼人。
商战不见硝烟，他死不了。
我也不会把项目成败的关键点任务给他。
物以类聚，人以群分。
我不厌其烦地重复这个成语。
如果你老遇到让你很倒霉的客户，那么请你先检查一下你自己。
团队文化不能强来。
企业文化就是老板的性格，团队的文化就是团队经理的性格。
和你性格不匹配的管理方法，你再坚持也会很累，直到你自己都坚持不下来。
所以，还是回归平实一些比较好，自己是什么样的人，就采用什么样的管理方法，万物没有唯一的一条道，管理时最不能照搬的，只要达到老板的目标就OK。
团队配合
大部分的企业管理软件企业，3-5个人10来只枪，从售前支持、软件开发、测试、打包发布、文档编写，到实施安装、培训、技术支持都做。
混乱的状况：
1.一个人负责一个产品或一个项目，一个人从头跟到尾，而且负责多个客户的维护工作。
随时老板会找来八竿子打不着的新活，要得还挺紧，突然要开发，打乱所有计划。
最后懒得按计划行事，每天撞钟。
磨洋工，没事就上网装作在工作。
2.老板和员工互相斗智斗勇，在年终奖、报销、出差、平时福利上，明争暗斗。
老板卡得紧，员工就在项目和产品上下药，还不知道是谁占了谁便宜，谁给谁打了工。
3.员工一边刻苦钻研各种开发工具，阅读源代码，UML、设计模式、单元测试、敏捷编程等，却懒得修改现在公司的产品，有问题就打补丁，客户不嚷嚷就懒得修改，代码不优化，界面不友好，架构没架构，封装不封装……
中国软件行业大部分都是这样的公司。
从每年CSDN的程序员调查都可以看到，中国软件公司大部分都保持在这种开发团队规模，开发人员大部分都是毕业1-3年的学生。
这种局面大家都不想看到。
但是，why?
我们想好好地专心开发软件，但我们的时间都被实施、安装、培训、技术支持占去了。
怎么把这些开发以外的东西剥离掉呢？
这种状况的原因：
1我们根本没有需求记录工具。
哪家客户提的需求，当时为什么提，是为了解决什么问题，都没有记录下来。
当然，没有专门分配任务的人管理进度和分配任务，也没有专门负责设计的人员先做设计，程序员自己就改掉了。
2一个改变了的功能，却没有帮助说明文档。
因为没有文档人员。
改变了的功能到底好不好用，改动出了问题没有，不知道，因为没有测试人员。
如何走出这种怪圈？
1有帮助说明文档。
这样实施部门的人会使用软件了。
这样就不用程序员亲自出差做实施培训了。
2减少bug?
专门的测试人员
3如何判断bug。
需要有专门的设计人员把软件的正确流程和正确数据状态都详细写下来。
4程序员技术能力参差不齐。
需要牛人写核心代码和公共代码，其他人少些代码或写辅助代码，这样即使有了问题也影响不大。
5程序员修改代码的过程中，如果有服务人员又把电话转给程序员怎么办？
谁能把这一工作分担下来？
工作：
写帮助文档
搞内部培训
测试员
编写软件设计文档
编写核心代码和公共代码
比服务部更懂软件的支持人员
测试员兼任支持，
写帮助文档的兼任内部培训
一个研发部：
1名研发部经理，1-2名开发人员，1名项目经理，1名公共代码开发人员，1名测试，1名文案。
共5-6人。
有时候，团队小了，研发部经理就是项目经理，公共代码开发人员就是主程，这样，开发团队3-4人就OK了。
一般，一个产品或一个项目：
一名业务开发组组长、一名主程、一名辅程。
业务开发组组长：
负责设计、任务分配、任务调度、人员调度、质量控制、进度控制。
主程和辅程专门负责开发代码。
业务开发组组长和项目经理差不多。
有的项目经理偏向于开发经理，有的偏向于售前经理，有的偏向于纯粹的项目组织、协调、报告。
项目简单：
开发组组长、一名主程。
都写代码
项目经理：
还会参加销售打单，做售前技术支持。
对于项目型的，项目经理有时还担任需求调研经理。
公共代码开发人员：
一般就一个人。
他还负责新技术跟踪、新技术介绍、新技术试验。
对有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。
如果大家认可这种方法，会选择适当的时机在产品中引入。
研发部的测试人员：
一般也兼任配置人员，产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。
测试人员，还兼任着服务部门对口的技术支持人员。
兼职的好处：
更了解客户是怎么使用的，测试更有效。
研发部也就配1-2名测试人员。
根据同时并行的项目及产品开发和开发的强度来定。
我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者的博弈上做到一个质量的平衡。
换句话说，要求并没有那么高，并不需要达到国际一流水准。
详细工作：
业务开发组组长，在功能设计方面，详细负责功能点清单整理、功能优先级划分、详细功能说明书编写。
1业务开发组组长从需求管理系统、Bug管理系统中，决定本开发周期内需要开发那些需求，解决那些Bug。
2对筛选的需求和bug标示好功能的重要性优先级。
3如果某个功能复杂，就会再被拆分粒度，直到复杂性都差不多均匀。
预估大概的项目开发周期。
确定任务时间段，让开发组组长和开发人员都接受的时间。
注意：
为保证项目进度，还有一个条件：
不允许开发人员在客户现场开发，更不允许开发人员和业务开发组组长不在一起。
因为，在客户现场，往往开发进度和功能需求变更容易受客户控制。
。
不允许开发团队出现多种技术。
不允许团队使用最新技术，只使用最合适的技术。
设计方面使用：
PPT+WORD+脑图+Excel
版本控制：
版本控制工具来控制设计文档和源代码的版本
自动每日构建工具，每天晚上整体编译
自动测试工具，压力测试工具
Setup打包安装工具
版本自动更新工具
项目经理
每日给项目组的所有人和所有相关人员发送每日工作报告，发生了什么事做了什么事，进展如何，阻力在哪里。
专业email。
做项目经理，做程序员，做销售，都有个共同特征，就是眼光敏锐，思考清晰。
我们现在在哪里，我们将要干什么，我们要怎么干，我们面对的阻碍是什么，我们都要心里明明白白。
如果你啥也会点啥也不精，说明从你学校一毕业就没有目的，就是随波逐流，这样的人，即使做个项目经理也是随波逐流没有目标。
“现在的问题是，我是项目经理，工作做了很多，上面却还有一个事业部总经理。
活都是我干了，功劳却都是他的。
“没关系，看来他会很快走的，因为你已经把他架空了。
项目经理的两大重点：
1业务需求。
研究业务梳理业务，总结。
思路目标清晰，达到的效果清晰。
有根有据。
分析了项目的所有关系人和切入点。
2项目计划、项目报告、项目异常解决、项目推进、人员调度。
也许世界就是这样，60%的人要成为基层人员，25%的成为中层骨干，12%-15%的人成为高层，1%-3%的人成为塔尖。
架构师：
1掌握核心软件技术
2了解产品特性
3了解软件趋势
4具备创新技巧
了解业务的思路，和我了解技术是一个思路，都是来龙去脉法，研究一项事情的过去、现在、未来，以及和这件事情关联的其他事情。
我一般都是把我们这个产业的竞争格局现状了解清楚，把我们的过去现在，竞争对手的过去现在都了解清楚。
我们现在是占了多大比例，我们还能占领哪些客户群。
理解客户行业：
1客户行业的这个群体有多大？
大中小规模各有多少家，各分布在什么省？
我们面对的最佳客户是什么规模什么信息化程度的？
我们的次佳客户是什么规模什么信息化程度的？
2我们的上层竞争对手、本层的竞争对手、下层竞争对手目前的产品怎么样？
各自的优点、缺点是什么？
我们应突出自己的哪些优点，我们的缺点是什么？
3客户行业的过去5年、近2年、未来3年地发展历史和趋势是什么？
他们面临哪些挑战和机遇？
4我们现在的典型客户，他们的组织结构、人员规模、每个岗位每日的业务流程、异常处理业务流程，输入表格，常用数据查询，统计报表……
5针对以上的了解，客户面对未来挑战和基于，未来应该如何变更他们的岗位、指责和流程，尽量做到流程少，效率高，运转快？
当心中有了客户行业的业务框架后，就能清楚地看到这个行业的过去、现在及未来，所以能识别出一个需求是稳定的还是临时拍脑门想出来的。
架构师必须对开发工具，对使用的技术有深刻的掌握，但每个人也不是神人，能掌握方方面面的东西，越专的人懂得越窄。
过程管理
老系统维护：
许多人认为，一个老系统要维护好，必须具备以下关键因素：
有责任心，有文档，设计前做好详细的需求分析，要有需求管理，要OO编程，要有专门的测试人员。
事实上，不会这么完美。
维护老系统，也要像经营企业一样，不断继承包袱，不断细心剖析问题，剥茧抽丝理清思路，不断改进，才能渐渐从恶性循环走向良性循环，才能把一套烂代码扭转成可持续维护的代码。
写代码的8项建议：
1重点把控输入数据的校验。
在保存按钮第一步代码中写好集中的详细的校验。
而且，这块代码要写成函数，不要大流水，省得代码复杂性会让程序加速崩溃。
2需求、功能函数化。
以后的需求再往上加，都写成函数。
遇到比较大的IF…ElSE判断，就从其中的代码段再分出一个函数。
3加功能，尽量不要做成联动触发的。
保存，最好是单表保存。
即使是主从结构的单据，如果客户部强烈反对，也先保存主表后再让录入明细表。
而且录入明细表要单独的窗口，这样功能和代码都简化了。
查询一张单据，最好是双击主摘要，弹出独立的窗口显示明细。
4分离特殊处理业务和正常处理业务的功能代码。
5对不常用的功能做一些隐藏处理，将其放到一个不起眼的位置。
使用的人就会越来越少。
到时候就适机真正隐藏掉，不让它触发了。
6心平气和阅读理解先前的代码。
有时候你觉得程序烂，是以前程序员的代码排版可能和你不一样。
抱怨变量都是M、N、S、Button1之类的，但其实你阅读理解代码，并不会使你理解有歧义或者读不懂，只不过你不爽而已。
真正危害大的是全局变量和大流水代码。
写代码，要严格避免这两个坏因素。
7修改需求或Bug的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改。
按照模块来集中修改，你会通盘考虑所有这些需求和Bug，而不是糊窗户式的补窟窿。
8多写视图多写存储过程。
有的老代码，SQL语句都在代码中执行，没有视图。
对于这样的老系统维护，就是把这些SQLCopy出来，做成视图，这样就好维护了。
表结构说明不仅需要描述每个表中字段的中文含义，也得描述表之间的关系，这和视图能表达的效果是一样的。
详细功能设计书。
组织实施人员写功能操作说明帮助。
客户需求很多……
1客户业务部门不能随便提需求，必须集中汇总到客户IT部门，由客户IT部门汇总过滤完，再集中报给软件公司
2客户IT部门的需求，必须由客户方负责IT项目的老板签字才能生效，才能报给软件公司。
3不能随时报，每3个月报一次。
4不能口头包（即使在现场实施支持也不行），不能电话报，只能Email或传真来报。
5必须按照我们规定的格式报，要严格写清楚需要实现的功能的界面，输入数据或输出数据，输入输出数据的格式要求，谁操作，多长时间操作一次。
好处：
客户疲了，需求提得少了。
坏处：
其实相当于是限制了遏制了客户的需求，没有很好地满足客户的需求。
客户并不真正满意。
需求，有很多方面。
有关于功能的（尤其是每家客户特殊的业务需求），有关于异常错误的，有关于性能的，有关于兼容性的，有关于易用性的，有关于特殊权限的，有关于美观的。
不是客户需求在变，而是你对客户的需求理解在不断加深。
需求多，其实是个幻觉。
1把需求分类，作个Excel表格，量化解决。
这个需求管理表格有下列这些项：
客户名称、需求提出人、提出日期、需求关闭时间、功能模块名、客户现在版本号、需求描述、需求分类（需求、Bug）。
有了这个表格，要定期（一周，或一个月）给老板一份，一则表明你的工作量，让他看看你确实一直很辛苦地在工作，而且干了这么多活。
二则这也能看出你工作的仔细负责态度。
2需求描述不清晰是反复修改的罪魁祸首。
对于Bug，要有错误报错整个的屏幕截图，千万不要就截那个错误消息框那么一小块。
对于需求，要给出表格格式，还有每一项数据的来源，有公式关系的药给出明确的计算公式。
每一个输入项的要求：
可选值、默认值、不可为空、唯一性、约束输入、数字要有小数点后精确度、日期要分辨精度是到日期还是时还是到分。
实施作为公司的命根，老板盯死软件开发和软件实施，客户使用效果好才能以后有更多的单子做。
老板认为你们作为开发人员，不接触客户，怎么理解某个需求的真正意图呢？
当然老板的思维逻辑对。
当然实施人员最了解，提的需求最有权威，换你做老板都会这么想。
我也经历过这段日子。
人和人的信任，都是在做事中不断看人试人品人，才能取得信任，才能放权。
我的老板也如此。
如何应对？
1在网上写对行业的观点，结交许多知名的行业内管理专家，被称赞观点独到，思考有远见。
把文章的链接适机转给老板，转给喜欢思考提升的实施顾问。
也经常把和我思想观点相似的文章链接转发给老板。
---取得老板的好感，初步的信任。
2走访客户。
开发人员会意识到客户提的需求要解决什么样的问题。
但开发人员如果在现场，就能分析问题根源，不像先前那样只看表面问题现象。
开发部综合平衡考虑，会得出更好的解决方法。
走访客户的三个目的，1）改善老板和实施人员对开发部的认知。
2）改善开发人员和实施人员的冲突。
3）了解客户现状，想方法如何去引导与引导客户。
3把业界知名专家的一篇文章中提到的评价模型内嵌到软件中。
有了一个可以讲可以量化的管理模型，这套评价模型成了这个软件的核心亮点。
客户为了应用这套评价模型，也乐意录入数据，维护数据。
4然后，提出需求管理系统，web型。
让大家随时随地把需求录入到需求管理系统中。
需求分类，分优先级，量化安排开发计划，有的放矢吸收需求，改进软件。
每年召开用户需求会议。
邀请有思路有积极改进想法的客户参会。
大家面对面交流共同的问题、共同需求，共同探讨未来行业机遇挑战，共同寻找解决方法。
引领客户，引领老板和实施人员提高对产品，对业界，对未来，对竞争的认知。
建议一位网友开始进行版本管理时，他这么说：
CVS、VSS之类的就不必了。
因为这是一个人的战斗。
连版本都没有概念，一上来就是特正规的工具，大半感觉太麻烦，又退回到最初原始状态，还对版本管理产生了不好的印象，觉得繁琐还没什么用。
所以我们有一句话：
一管就死，一放就乱。
其原因就是缺乏一个中间过渡的解决方法。
//其实，大多数时候，无论是工作学习还是生活中，某些习惯，某些思考、做事的方式方法，想改变时，最好还是一点点地变，这样效果最稳健有效。
除非你目标特别明确，意志特别坚强，有能力有毅力一击即中。
大多数时候，还是顺其自然，一点点改变。
建议先把版本意识提上来，按照版本管理的方法走，走顺了就自然接受了正规的版本管理工具。
版本管理的几个过渡性建议：
1有大的修改或没有把握的修改之前，先把代码备份到其他的机器上。
备份目录要跟上日期。
2在大的修改前，先定一个稳定的版本发布出去。
3即使是琐碎的修改，也要每天或隔天备份一份源代码。
4有不少文本对比软件，如WinMerge之类的，可以对比两个文件的差异。
这个功能和版本管理工具的“源代码差异对比”功能是一样的效果。
5如果每次发布新版本，就把上一版本发布之日后关闭的需求列表都单独摘成一个文件，附带到这次新发布的版本之后。
这样即使没有人写更新说明文档，根据追溯也能明白这次版本解决了哪些问题和需求。
很多程序员没有需求管理表格，版本发布要求写更新说明文档，这才从脑海记忆中想，想得就有些遗漏，甚至是错误的。
好多程序员有过这些情景：
我记得改了呀。
真正一翻代码，一点没动。
大叫：
“我的代码怎么没了，我记得我改了呀！
项目开发
项目和产品的区别？
做项目，是和做产品相对而言的。
产品是标准的，不修改，就这个东西。
您看着好您就买，看着哪点不舒服也没有办法，我们不修改，您觉得不修改就不买我们也没有办法。
您买了，我们给您去安装、配置、初始化数据、培训，就这样。
遇到没章法的客户，都是先心平气和地开会，不断烘托突出双方合作是共同把事情做好的理念，而非你买我卖的这种生硬关系，不断暗示双方不是对立的，而是共同促成一个目标。
统一共识的基础上，开始收集需求。
需求收集上来，最常见的一个问题是，客户希望有个Demo看看。
严重的问题是，大家对Demo的注意力放在一些很初级的需求上，如界面不好看，太难用，有Bug用不下去等。
等程序员花几周时间把Demo表面修改得不错时，客户才提出深需求、核心需求（真正实质上能帮助他工作的需求）。
制作Demo原型，HTML+CSS+Table。
规律：
接的C/S结构的项目，客户对PPT原型就挺接受；
接的B/S结构的项目，对HTML的
升级会员 