程序员工作只接触一些不需要高难技术的小项目，该如何提高自己？
程序猿，工作只接触一些小项目，也不需要高难技术，怎么样才能提高自己？ 自学当然能提高，但是还是接触不到大的或者高难度的项目，这方面没法提高，咋办？
按投票排序
自己研究啊，找点小项目来搞搞，搞着搞着你就对技术知道的多了，自己的技术水平自然也就上去了。比如，自己写个WebServer，写完以后你就知道，从单线程响应http请求，到多线程响应；从只支持html，到支持图片、音频啥的，慢慢的，你就能体会server的基本原理；再比如，自己写个网络爬虫，爬点天气预报数据、新闻啥的，从单线程爬，到多线程爬，从每隔一段时间爬，到每天定时定点爬，从爬不需要登录的，到爬需要登录认证的，完事后，啥是多线程、线程池、怎么模拟登录，你还能不明白？爬到天气预报，那你还不写个小android/ios/html5程序，把天气呈现出来，从只呈现一个城市的，到呈现可以选城市的，从没有动画的，到有动画的...什么sqlite、自定义控件、handler、ajax、webservice你还会不熟？我就这么干的，我不是程序猿，这只是我的爱好，但学习让我挺快乐。
我毕业时候跟楼主经历差不多。上面好多”平凡的岗位做出不平凡的业绩”之类的勉励语，实在让人恼火。这些心灵鸡汤，老板说说也就算了，程序猿何必忽悠程序猿。人的成长是需要外部环境的。在一个没有技术气氛的公司工作，当然可能成功，但是你会有很多劣势第一你不能确定真正的技术问题是什么。如果你服务器每天处理的请求就只有八万六千四百个，你在虚拟机搭个阿帕奇就对付住了，你会认为用异步处理的那帮人简直是吃饱了没事干。第二因为问题并不影响你的绩效，你不会有真正迫切的动力去研究解决方案。你知道异步处理很重要，你自己用epoll写了个服务器，然后发现响应速度还不如阿帕奇了。同事都开着玩笑说你屠龙技终于毕业了。领导也觉得你瞎搞，一气之下你又切换回阿帕奇了。其实你只是错用了水平触发而没有用边缘触发。第三你不能跟同事学习交流。你的同事都在研究怎么报销车票或者埋头学习日语。你只好每天跟踪丁香园大哥的博客，在了解阿里巴巴八卦的同时，还学习了脸书谷歌雅虎等等大公司的各种牛逼架构。但是你拿到的只是一副图，生成这副图的过程最宝贵，你却一无所知。于是你不得不另辟犀径，最终你靠着收藏转载评论这些架构图成了网络著名架构师。我觉得，如果你发现自己的技术已经超出了工作所需，唯一的解决方案是跳槽。因为做程序猿正常的状态是，你的技术永远不够用，永远是有无穷的问题需要你去研究。
小项目小需求：做一个专题页面.如果你觉得这是个简单的东西，那就三下五除二就能搞定，熟练的人可能一天能捣鼓出来几个，还能有时间刷个微博。如果你仔细去看你做的页面，就会发现一堆问题。举个例子：页面载入不够快，如何让页面更快? 这不但需要前端技能，还需要后端技术，还需要对网络传输机制，对浏览器机制比较深入的理解。再比如，我的页面搜索引擎搜索不到，怎么能被搜索到? 这需要了解搜索引擎的基本机制和行为，需要做提前规划；做完了怎么排在类似页面的前面? 这需要 SEO 方面的知识，当然，这个不是你网上搜索出来的那些所谓 SEO 的知识，需要你对自己的页面，对内容的处理，有一定的理解和控制。再比如，我的页面，手机上看着是乱的，还需要适应移动设备，适应移动设备有需要哪些知识呢? 如何对不同的移动设备都兼容? 再比如，我的页面上有个表单要用户填写，用户怎么才能用的更舒服，填写尽可能的减少出错? 这个表单如何防范 Spam ? Spam 是怎么回事? 抵抗 Spam 有哪些有效的方式?
以上，可能只是一个专题页面涵盖的技术的一小部分。我真的不觉得这些锻炼不到人。做过大项目的人其实有很多，但很多人也没看到得到什么锻炼。
据我观察一些很小的事比如写个changelog都能区分出高手和菜鸟。所以题主不必在意事情小，在小事上证明了自己，干大事的机会通常自然就来了。建议题主不要以大小来区分项目了，项目就分两类：我的、别人的。把自己的项目做到极致就是最牛逼的事。
Lua也是一个2万行的小项目，做了20年了。可是，人家怎么就做得那么棒呢？所以，有一颗“精益求精”的心是最重要的，而不是项目的大小。
我想到一句話，叫作『越有知就越無知』，你目前不知道怎麼辦，是因為自己沒多少技術儲備。當你覺得工作中是一些『小項目』，『不需要高難技術』的時候，說明你已經完完全全可以勝任當前的工作了，這就是進步，應該更上一個台階。又或者是眼高手低的一類人，這類人，沒建議。選擇專而精還是技術雜家這兩種基本上就是提高自己的兩個大方面了。這兩種都需要足夠的知識儲備和豐富的經驗，肚子裏沒貨，哪樣都當不成。自我們大家從大學畢業進入社會後，就不會有人像老師那樣手把手的教了，即使老師教得也不怎麼樣。還有句老話叫作『師傅領入門，修行在個人』，這就是說以後想怎樣，全都得靠我們自己了，學習的方向，技術的取捨，目前技術上這麽多選擇，沒有人會告訴你怎麼選、怎麼走(整天叫囂一門語言好而鄙視另一門語言的唯我獨大的思想，這特瑪有意思麽？)。只有哪些技術適合在哪些業務下，和哪些需求更為契合。我記得在『艰难一日』這本書裏，男主角被選中進入綠隊，他問老隊員應該帶哪些裝備。老隊員回他『你來海豹六年了，還不知道要帶哪些裝備？』。這就是BBR( Big Boy Rule )-大男孩準則：沒人告訴你怎麼做，你自己拿主意。這同時也是成熟的一個表現。回到你的問題，『想提高自己的技術，怎麼弄』。我個人有這麽幾個建議：先說個最簡單的解決方法，你直接和上司講：『我想從事一些更有挑戰性的工作，目前工作太單調，沒意思，呵呵』，注意要笑著說，如果你一臉嚴肅的講，別人以為你是要加薪，反而還炒了你。說不定老闆那裏正好有這樣的項目，而正好又沒人做，而你又自告奮勇。兩全其美，何樂而不為呢？如果實在沒有，那麽可以考慮謀求一個更大的發展空間了。人都是逼出來的，太安逸反而不利於成長。也可以這樣：1. 看科技博客，這個和工作沒多大關系，可以開闊視野。2. 關注業界的技術文章。比如哪些行業有哪些創業公司啊，他們用了哪些技術啊，為什麼要用這些技術啊等。3. 關注牛人的博客、微博/twitter。關注他們，這些人都會寫一些質量非常高的文章，和微博/twitter不一樣，這樣的文章會寫得很詳細，用心讀他們。更為重要的一點便是，看到的任何技術詞匯，google他們，一定要google他們。鑑於大環境，很多技術名稱都沒有一個準確的中文譯名，即使有正式的中文名稱，也一定要知道它正確的英文名稱，這點非常重要，所以大家在寫文章，分享心得的時候都會直接用英文單詞，這樣就會很容易在文章中發現他們，然後你就可以用google搜索了。那時，你會發現，這又是一個世界，像來到了天堂。沒有國內社區推薦。有問題問google，google會給你指明方向，至少也會把你引到stackoverflow上。帶著問題去做事，一段代碼，寫完了，是好是壞自己最清楚。想辦法讓它更強壯，更有可擴展性，更精簡，更清晰明瞭，其他程序員不會花太長時間讀懂。代碼不能很好說明意圖的情況要用註釋說明。讓自己的代碼有一個風格，給自己編寫一個代碼規範，嚴格執行，不要讓自己的代碼像一坨坨屎。好了，你的代碼已經很強壯了，擴展性也很強，很精簡，別人一看就懂，註釋寫得恰到好處。整個代碼沒有讓人看不懂的地方，即使沒有文檔。事情完了嗎？沒有，接下來，試著換個其它語言重寫一下。一樣的要求。好吧，又成功完成了，這次是驚天地，泣鬼神！這樣，會了兩種語言，有比較了吧？有想法了吧？哪種合適？選那個合適的。沒被選上的就當作技術儲備了。基本上就這樣了。往來幾次多了後，你的技術選擇方案就多了，如果你想當雜家的話，你可以有多個不同的技術組合，像拼積木一樣。又或者，和一門技術卯上了，專攻一門，一直攻到金字塔頂端。這樣一樣，你就會N門語言，N種技術組合，N種解決方案，至少一門技術是大師級別。再回到開頭的『越有知就越無知』。那時，你不會再問這種問題了，你知道自己應該怎麼做，怎麼選。
跟楼主说一个我的亲身经历吧背景：之前在一个大公司工作，但由于大公司分工太细，同时还有别的原因，导致我们部门拿不到项目，一直都在做整合，整日都在改别的项目导致的整合的bug，而且有趋紧于看不到代码的局势，全组都是这样，情况比楼主差好多。期间找过主管谈过，但都是些推诿的话，无果后，开始制定自己的计划了。------------------------ 进入正题 -----------------------------------和主管聊完天之后，开始制定自己的计划，得出的结论是我必须辞职，但是不是现在。于是每天拼命的快速完成部门的活，然后开始做自己的研究，开始的时候是写一个项目，再后来放到sf上去，然后是看开源的项目，每日下班回家也持续到12点，节假日，周末，也如此，这样的情况持续了大概半个月，然后试着找工作，面试，然后被拒绝，再回过头来继续自己弄项目。再后来觉得时机成熟了，辞职（这个时间点和我开始指定计划有1年的时间差距，换句话说就是我准备了一年），然后玩了一个月，找工作一个月，现在在一家公司上班。我现在的状况是有项目做，形式趋近于
的说法，慢慢提高-----------------注意：1、必须要有明确的目标2、要坚持，我每天下班后和周末都会固定写和看代码到24点以后，确实很累3、我个人的原因，我对代码有热情。
记得《黑客与画家》里面保罗-格雷厄姆写到：面试程序员的时候，主要关注的事情就是业余时间他们写了什么软件。因为如果你不爱一件事，就不可能把它做得真正优秀，要是你狠热爱编程，你就不可避免地会开发自己的项目。业余时间自己写的项目对于一个程序员的成长是非常重要的，如果工作中接触到的都是不喜欢的难度很低的项目，在自己业余的时间写对自己有挑战的项目便是很好的选择了。书中还写到：黑客应当找个日常工作糊口, 业余时间做自己喜爱的程序。这里黑客指的是顶尖的程序员~
lz问一直做初中数学题没意思，怎么才能做大学的题，有人回答，有人做了很长时间的线性代数仍然很快乐。
就没有人跟我一样觉得在家写程序更加快乐吗
说明你还没没有足够的自我学习能力，一个看似简单的功能，做完和做好是有本质区别的，很多人做了多年的大项目，也只是重复简单劳动，没有思考。举个简单例子，文件上传，这是一个很常见的功能，里面可挖掘的点也很多的。是简单使用表单post,还是支持文件上传进度提示；同时上传多个文件时怎么办;是否考虑了数据压缩;用户上传一个病毒文件给我怎么办;服务器收到上传文件，临时文件是存内存还是磁盘，临时文件的删除策略如何；文件怎么存储，按类型分类存储还是按大小存储，是否要放在文件名是否做混淆，上传后的文件访问权限怎么控制。我的理解是一个小点，自己能多思考多深入，就能快速提高。
很多程序员觉得自己东西做出来就OK了，但是真正东西做出来到实际投入使用，各种各样问题出来后，如何解决！如何规范化避免可能出错的问题。这里面有很多要思考的地方！小到编码风格，质量，结构，大到系统架构，机制，性能。或者管理角度，开发。发布，测试流程！每一块都有很大的学问！有些人写一行代码，都会思考如何严谨，复用，简单，高效;而有些人只知道就应该这样写，不追求为什么？所以同样一段代码，给有些人会看出一大堆问题和疑问，而有些人什么都看不出来！处处留心皆学问，这句话对程序员来说，再合适不过！上面提到的任何一点，你钻进去都可以成为大牛！但很多程序员，只把自己编码当工作，做完再无任何追求！这种俗称码农，干的是体力活，越搞东西越多，越高越累，没新意！有追求的会把每次做的东西总结，可能新做的跟老的很类似，能改造下复用吗，或者干脆抽成工具包，乐此不疲，越做越简单，越做越少，都自动化了！我相信这个过程最好有个氛围或者导师，指导你趋于进步！到我要说的，这个别人是不会教你的，而是你要先有这个意识，能清楚目标后并有些尝试后，再跟别人沟通，再校正你的看法，再改进和尝试，这样循环才能成功！程序员铭记，学者生，用者死！搞清楚什么叫高级语言，你就自己掌握的那点知识多么站不住脚！题主现在的问题，是心态问题，鄙视自己干的工作。如果你端正心态，再来看问题。如果公司效益不好，市场都不认可，代码有这么乱，没有前途就走吧！如果效益不错，市场反应不错，说明自己产品还有可取之处。看到自己产品的优势，尝试去学习和理解，看到产品的优点和缺点，针对性学习去改进，自己一样会慢慢提高。你看到的问题越多，你成长和进步的机会就越多！端正心态，看清问题，瞄准方向，努力前进吧，少年！
刚刚有小朋友置疑我罗列那么多术语，补充一点我认为最最最重要的吧：永远要清晰的知道自己和别人的差距，而且一旦你努力了，才知道智商的差距更大。我很清晰的认识到，我上面有无数牛人，牛人上面有无数牛人。但是很可惜，我见到无数小朋友刚刚毕业就牛逼哄哄的；当然，很多小朋友也更努力，所以老人也不能松懈。努力吧，骚年们！----------------------------------------------------------------------------------------说一下我自己，也在创业公司，新功能开发&升级都是熟练体力活，但是！1) 你了解你所依赖的平台不？你了解你依赖的平台不？SQLAlchemy的文档仔细看了么？为嘛要这样设计？ZMQ呢？设计思想是什么？消息传递的优势是什么？Twisted、ZMQ等等乱七八糟的网络框架本质是什么？tornado、Django乱七八糟的Web框架呢？MySQL事务的隔离性你知道么？别说事务都没用过。CORBA、SOAP、RIM这些都听过么？优缺点是神马？& 某天和某个小孩聊天，他说他做的东西没有任何意思，没有任何技术难度；我问了一句能说你们所用的框架的处理流程么？直接卡壳了。2) 你的模块够稳定不？你的模块做了单元测试么？功能测试呢？集成测试呢？有没有办法做到持续集成？自动部署呢？还有你如何管理你的依赖环境？知道Mock对象不？知道测试桩不？测试数据如何管理？3) 可维护性呢？运维性呢？表告诉我你发布程序就是哗啦哗啦拷贝一大堆脚本过去，然后就nohup挂在后台跑着了。如何打包？如何管理依赖？如何发布？能不能做到零停机？如果出现问题了如何回滚？如果不能回滚如何处理？是不是脚本自动部署？你的日志如何打印？如何管理？如何及时预警？4) 了解系统构架不？为神马要这样做？有没有神马问题？有问题有优化的余地么？5) 能从大量的业务逻辑中抽象出来一个通用的流程、框架不？6) 系统有没有单点？如何防止？如何备份数据？MySQL Replication有神马问题？如果有冗余，一致性又如何？有没有可能丢数据？7) 能从大量的模块中，抽象出来一些中间件、基础设施不？太多太多了。。。。
无法提高。少数绝顶牛逼的人也许自学自学就更加牛逼了，但是大多数普通人我觉得还是需要工作中的机遇加挑战在后面推一把的。
我觉得应该做些个人项目，满足你自己的需求。
没有机会，制造机会也要上。当年我为了自己学Java，忽悠项目从Delphi迁移到Java，这种事我会随便说吗。
大学学的是计算机科学技术,毕业后就和这个没关系,泪奔中......------------------------------------------------------------------------------------------------------------------------------------------------从非技术角度尝试回答下,纯文字搬运.不过下面的内容我相信.
提到：12. 工作成就定理：唯态度论工作成就（Performance）,能力（Ability）,态度（Attitude）,这三个英文字头组成工作成就定律：P=A*A 而态度（Attitude）提升比能力（Ability）容易千百倍.冬吴相对论 131.激励的艺术(上) 提到 绩效等于能力乘以动力原文：吴伯凡：小剂量的增加，而且不要有那种毒品式的效应，毒品式的效应就需要剂量越来越大。还有一个东西就是毒品最大的坏处是单一刺激，把人的各种功能都废除进行单方面刺激，而好多公司在做激励的时候，往往都是用单一的方式来刺激，这样把人的心理的导向只盯在那个上头了。我们以前也讲到过，吸毒的人除了对毒品产生兴趣，对其他的不再产生兴趣的时候，这个人的所有的功能、他的欲望、他的情绪都会被这个毒品所控制。所以我们在做激励的时候，首先你别忘了激励是为了什么？激励是为了造就更好的绩效，这是最重要的，而绩效有一个公式，叫能力×动力，就是这个人有多大的能力要乘以动力，才是最后的绩效。有过一个调查，100个能力大致相当的人，实际上很多人的能力都是差不多的，也就是差一个10%—20%的这样一个范围，但是最后做出来的绩效会差得非常大、非常大，有的甚至相差20倍，为什么呢？是因为背后的那个动力。比如说前面那个乘数不小，比如说是100，后面的那个乘数有的是1，有的是2，有的是100，有的是0.1，最后得出来的那个得数就很不一样。
做“麻雀虽小五脏俱全”的小项目，小项目也认真对待。产品的开发、发布、后续维护，项目管理，这都值得认真对待。若在大公司大项目中只是当一个螺丝钉是绝对学不到这些东西的。这就是一直持久的就业找大公司还是小公司的讨论的重点之一。PS：我现在还是螺丝钉，说起来都是泪啊！
把小项目用到的技术点都摸透，用熟，还有代码质量也是能力的一部分。平时可以看写代码重构，设计模式之类的书籍，想想自己项目中哪些可以用上。小项目的一个好处就是你可以对项目不断重构，把书上学到的用在上面。环境改变不了，那就改变自己。觉的再怎么努力也很难在小项目中学到东西的话，就跳吧，有得就有舍，去试过才知道什么才最适合自。
看到这个提问，我想到了陈皓的《》，文中总结的三点：1） 只要你想，挑战是无处不在的。那怕是你现有的觉得无聊的东西，只要你想做到极致，那怕是一个简单的功能（比如）也会让你充满挑战。2）观察身边的事物，去思考，去调查，举一反三，这才是你成长的源泉。不要把你的成长推给客观原因。3）我的中说过，第三重门是解决实际问题，让你的业务处理更为的智能，更为地强大。我不知道为什么这一两年，我们的圈子里所有的人都在关注着“云”，“海量数据处理”，“高性能架构”这样的东西，尤其是那些性能调的高性能的东西并不很难，而这些更为实际问题更有挑战性，也更有前景。虽然工作时间不长，一年Java开发，一年Oracle DBA，但从我做过、接触过的项目和项目团队来看，能做到以上三点的人几乎没有。项目不分大小，要么你就是码农，要么你才是真正的程序员。业务流程图的绘制流程分享(一) - 博客 - 伯乐在线
& 业务流程图的绘制流程分享(一)
前言：近来一段时间，忙于整理业务流程图，期间，关于流程图的绘制方法和工具也与内部团队和外部做了心得交流，恰好，个人生活也牵涉在买房，婚礼，户口迁移等流程中。不知不觉，伴随着实践与反思，个人所得的系统知识趋于完整，今儿天气极好，坐在飘窗一隅，听着间或几声鸟鸣歌唱，偶尔瞥一眼窗外的遍地绿荫，真真觉得是个写点什么的日子。所以就整理成文，如果恰好对你有所帮助，那是真真好的。
真实整理的流程牵涉到公司未公布的计划，不好公开，所以在本文中会借助一个简单的案例替代（这个案例呢，也就是计划写本文前30分分钟才想到的，如有考虑不周，请各位见谅），但是仅传达概念和方法，倒也足够了。恩，甄環体告一段落，咱们开始吧。
图1：用即时贴与白板做的简单流程图
本文会包含几块内容：
1. 什么是流程图？流程图和其他图表（如线框图，概念图，架构图，用例图）有什么不同？
2. 为什么需要流程图？
3. 流程图的分类？
4. 如何绘制流程图？
5. 流程图绘制工具
视篇幅情况，会在行文时略加划分为系列，敬请关注并多多交流。
第一部分：什么是流程图？
了解一个事情，我习惯从它的定义开始。至于为什么，可以参见我之前的博客文章：http://heidixie./.html
我们因为厌恶十年教育，厌恶背各种定理和定义，所以我发现生活中和工作中很多人都很讨厌给一个事情下定义以及去参考定义。所以你会发现很多人在一起争吵得不可开交，仔细去听，原来是鸡同鸭讲，根本不在一个频道上。对于一个事情的描述，没有一个共同的语言，没有所谓的术语。有定义很好办，你们共同引用一个定义，发现定义有问题，OK，去补充这个定义，并扩展到更多的人群。当然，任何事情过犹不及，我们相互提醒吧。
那什么是流程图呢？说文解字是一种了解定义的好方法。流程图=流程+图，如下图：
图2：流程图的定义
流程：Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。前不久，团队每个人对接一个业务团队去调研流程，反馈给我的流程有一些缺失。询问时，负责人反馈给我的答复是：这一块业务他们没有流程。其实严格意义上讲，业务已经开展，不可能没有流程，只是说没有固定的流程或者你调研的对象也讲不清楚。
图：Chart 或者 Diagram, 是将基本固化有一定规律的流程进行显性化和书面化，从而有利于传播与沉淀、流程重组参考。
从定义可以看出，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。
2. 流程图与其他图表的对比
工作中我们还用到或听到很多其他类型的图表，比如交互设计师们经常说的线框图(Wireframes)，信息架构图或站点地图(Site Map)，，开发工程师们经常说的用例图(Use Case)或E-R图。这些不同的图表要表达的内容有何种差异呢？简单做个对比，如图：
图3：流程图VS其他常用图表
如果要串到某一个项目来说，可以理解成：
用例图（Use Case）：
表现了一个角色在系统里要完成的活动是什么，比如用户这个角色与ATM取款机的交互过程中，用户需要完成的活动有存钱，取钱，查询等。而存钱这个活动再可以进一步细分为插卡，输入密码，输入金额，ATM吐钞，用户收款，退卡等活动。用例图可以不考虑用户动作的前后次序，而仅仅提取一些关键的动宾短语，映射出系统应该满足的功能点。常用用例图的人是产品经理和开发工程师。
流程图则表示用户每一个活动的前后次序，比如用户必须要先插入银行卡，才能够输入密码，且流程图必须直接表现出各种异常判断，比如当密码错误时，出现什么提示，密码输入错误超过多少次时，出现什么提示和动作。常用流程图的人是产品经理，设计师，或者任何需要讲述业务如何运作的人。
信息架构图,站点地图(Site Map)：
表现为了做一个这样的系统，功能与内容的展现层次是什么，比如用户一进去后，欢迎页面的导航如何设计，是否直接出现取款，存款，查询，或者还有别的导航？常用信息架构图的是设计师。但是常用组织架构图的是HR。
线框图（Wireframe）：
将具体每个界面的内容布局和权重表达出来，且标注出一些交互细节的设计，比如当密码错误后，如何提示下一步动作。常用线框图的人是设计师。
实体关系图(E-R图):
则是数据库架构的工作，表示一个业务系统或场景中的实体时间的关系，比如储户与银行卡的关系是归属1对多，通过开卡事件产生关联。一般来讲，用矩形来表示实体，椭圆标识这个实体的属性，比如储户这个实体的属性有：姓，名，手机号码，住址等。而银行卡的属性有：开户行，开户名称，银行卡号等。
以上的这些图表各自都有领域的专家，我这里就不班门弄斧了。
那么流程图要体现出他的差异定义，要素是什么？总结出了流程图的6大要素，希望大家能够记住，这6个要素可以在以后的文章里不断回顾，你也可以拿来判断你所看到的流程图是否专业。
图4：流程图6大要素
●参与者：谁在这个流程中？可以是系统，可以是个打印机，更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要写一个客服角色就可以了。
●活动：做了什么事，比如点餐，结帐等活动。
●次序：这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件？比如客人不结帐，就不会产生送他优惠卡的活动。
●输入：每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。
●输出：每项活动结束后，会输入什么样的文档或数据传递给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好？
●标准化：采用一套标准化的符号用以传递你的流程图，从而使受众更快明白。
关于流程图的标准化，并不是强制的，事实上，我们见过很多种类的流程图，只要能够传递明白任务和次序其实已经归类于流程图了。如下面的图：
但是若在一个公司的环境下，你的流程图的受众又非常多的话，采取标准化的符号会带来很多交流上的好处，总之你懂的。
第二部分：流程图的分类？
常见的流程图有业务流程图（Transaction Flow）, 页面流程图（Page Flow）。
在工作中，作为UED，你可能会发现PD经常谈的是业务流程，而作为交互设计师，我们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢？ 先有谁，其次再有谁呢？
先讲个故事：假设你的梦想是开个中高档的全国连锁餐馆，那么首先你想到的应该不是如何去选址，而是将为何要开连锁餐馆这件事情，以及你的定位，核心竞争力想清楚。是快餐，还是点餐，是连锁还是加盟？定位于社区还是繁华商圈？是川菜还是江浙海鲜？是面向中老年还是年轻人？是家庭主题还是动漫主题？竞争对手是谁？需要什么样的投资？可能的风险是什么？这些都想清楚了，问题都有答案了，所谓战略层要清晰了吧。然后假设你现在分析来分析去，与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅，连锁，但是先在杭州开始第一家，选址定位于年轻人约会，扫街的地域，比如风景区，著名商圈，电影院旁…………等等等等，那么接下来呢？
接下来就是想办法让这些实现吧？那么需要做什么事情呢？选址？拉投资？搞装修？选餐饮菜单？雇佣员工？每一步怎么去做，时间点是什么？等等的任务拆解以及计划，就需要到战术层了。
这些事情的执行，总是需要请人的吧？先是核心团队分工去部署各项建设任务，当餐厅开设起来后，就需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等等，厨房里面还得分工，白案，热菜，冷菜等等吧？每个部门需要设置管理层以及汇报关系吧？所以你的组织结构就诞生了。
那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢？比如，当顾客上门时，谁去引导客人入座，谁去点菜，怎么将点菜的讯息迅速传递到厨房，并分发到酒水间、冷菜间、热菜间？并保证客人尽快能够吃到所点的菜？你必须要考虑各种人员的协作流程，优化效率，所以业务流程就出现了。
人肉运营了一段时间，没有借助任何点餐系统，你发现也还可以。客人点菜时，服务员手抄写下客人的要求，因为有复印纸，所以服务员能够将副本送入厨房，同时写下餐桌号码。厨房规模较小，负责分配任务的员工看下菜单，分别往冷菜处的黑板上写下需要他们处理的，以及跑到热菜区的黑板上写下待处理的菜品，以及去酒水间报下品名即可。可是随着经营的扩大，以上的人肉方式出现了很多问题，首先，手抄效率太低，顾客频繁换菜，响应来不及，手抄出错，导致经常报错菜。厨房很混乱，不得不多招了几个人专门跑堂。而一旦顾客要加菜，撤菜就更麻烦了，需要找出他们当时点的菜，再进行人工的批注和修改，同时要修改厨房后端的各个黑板……
所以你们想要开发一套智能系统，取代很多人肉工作，你们请了系统开发团队，他们经过评估，判断从点菜开始，一直到传菜都可以用系统解决。手持终端，能够快速传递顾客点菜需求到打印机，打印系统能够根据顾客点菜的类型进行自动的分单打印，所以热菜间看到自己的热菜菜单，冷菜间看到自己的冷菜菜单，而酒水间看到酒店菜单。当他们准备完毕后，送出，传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统，将最终确认掉的菜单及消费价格传递到结算前台，收银员能够快速进行操作。
这套系统最终是需要展现出来的，那么手持终端的界面如何设计？服务员能够用更少的点击完成一个菜的点餐吗？结算中心的界面如何设计？
通过以上的故事，是不是更明白从战略、战术、业务流程图到页面流程图的关系了？总结下：
●先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略）
●然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术）
●然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构）
●然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务流程）
●业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支持流程，减少人肉环节，促进数据采集（系统愿景）
●为了设计这个系统，PD需要思考什么功能能够取代某个环节的人肉工作（功能需求，系统流程）
●不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。（页面流程）
当然，除了业务流程，系统流程，页面流程，还有数据流程被人关注。
我们平时工作中，还会经常听人谈到泳道图啊，任务流程图啊等等概念，究竟是神马关系呢？
图5：流程图的分类
本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用，技术们最多参考，UED们最多看到的流程图。
本来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明，但是看目前的篇幅情况，预计会放到下篇，所以先在这里简单说明下吧。
在工作中，我们经常能够看到两种业务流程图，从表现形式来看，一种很好区分，俗称为“泳道图”的它，在样子上也确实像个泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。
另外一种类型是以部门和岗位为单位的流程图，下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑，但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看，很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。
再回过头来说泳道图，泳道图有几个关键点：两大维度，活动流转，流程要素。我们会在以后详解。
第三部分：为什么需要业务流程图？
流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观众快速了解业务如何运转。它包含了几个关键词：谁，什么时候，在什么条件下，做了什么事情，输入什么，输出什么，输出给谁……
与系统流程不同，业务流程更关注于业务本身如何运作，讲的是业务故事，包含的是业务规则。而系统流程则是满足业务流程，实现部分流程或全部流程的信息化和系统化。
所以业务流程是所有环节的前置条件——软件需求分析，信息系统建设也会先进行业务流程的梳理。
下面表现了业务流程图是如何在三个主要场景中发挥作用的：
1. 员工培训
图6：流程图的应用场景之一：培训
在此场景中：流程图能够提供一种快速了解业务如何运作的视图，通过业务流程图，新员工能够快速明白业务的最终目标是什么，中有哪些角色在参与以及他们的职责，以及彼此之间的联接。
除了培训新员工，在员工轮岗、调职场景中，员工也需要业务流程图参考，明白新的工作内容如何开展，以及自己所处的位置，自己的上游是谁，下游是谁，自己需要交付的工作内容是什么。
2：流程优化与重组
图7：流程图的应用场景之二：流程优化
业务流程重组（Business Process Reengineering）的存在可以明确反驳：存在即合理。事实上，存在的业务流程并未是合理的，有可能是参与的多个角色习惯了某种做法，有可能是变革尚未影响到末端的操作，也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革，不是某个部门的事情，而是需要流程中各个部门的通力配合。
更多时候，业务流程优化是自上而下的，但是老板们未必对实际运作的业务流程那么心知肚明，业务流程图能够很好去表现这个“运作模型”。通过看业务流程图，找关键节点的人访问，能够直接切入：为什么要这么做，为什么不这么做？从而探索出更深层次的问题，而不是问：你们现在怎么做？
通过调研，分析业务流程图，引入更多角色，能够分析出目前业务流程的问题：缺失，重复，风险，效率等等。从而制定相应的优化方案。
3：信息化的基础
图8：流程图的应用场景之三：信息化基础
正如上文所述的餐馆梦想的案例，信息系统的一项任务就是解放员工的手脚，取代一些重复的人力劳动工作。系统上了之后，不是说业务流程不需要而是经过了一些调整，其中某个参与者变成了系统，或手持设备，或打印机而已。
那么在做系统的功能设计和系统流程设计时，是不是必须先要了解目前业务是如何运作的呢？从而更好分析分析，更好说明系统在什么环节取代了什么类型的人肉工作？
所以我们看到的PRD往往也会先以业务流程图开始说明，而叙述一个系统建设的好处时，也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析，将愿景中的新的业务流程图背后需要系统的功能点撰写清楚。
第四部分：如何绘制业务流程图？
首先绘制业务流程图本身有没有流程？一定是有的。在软件工程学里听说一句话叫：万物皆对象。那么在流程学里，万事皆流程。吃饭难道没流程吗？就吃饭的动作而言，就有流程：拿筷子——夹菜——入口——咀嚼——吞咽。
有不少同学在这一部份很快想会问一个问题：Heidi，请介绍画流程图的工具吧？
我个人是工具派，从不否认人工欲善其事，必先利其器的道理。好的工具本身就是一名好的老师，除了技能，也能够教会我们一些理论与理念，这些理念也是“器”中很重要的一部分。其次才是具体的工具应用技能。所以我并不建议直接跳转到工具应用。对于初学者而言，笔与纸永远是最好的入门工具，因为你无需和任何一个陌生的软件较劲。
那么，绘制业务流程图有没有可遵循的流程呢？我建议可以从下面4步着手。
如何快速了解业务运作真相？有没有调研的技巧放送？
2. 梳理与呈现
能否快速将调研得到的文字和问题，快速转化为业务流程图？
业务流程图的标准图示是什么？
怎么评价一个业务流程图的好与坏？
3. 评审与确认——能否真正让业务流程图反映现实中的业务？
4. 归档维护——流程不断变更，业务流程图如何快速响应？
这些将会在下篇《业务流程图的绘制流程分享(二)》详解。
第五部分：绘制工具？
如果不搞工具研讨会的话，这部分比较简单.
Windows: 线下工具大家常用的就是下面三个：
小的流程图用用PPT就够了，完了就导出图片或截图。交互设计师们因为常用axure绘制线框图，所以也不必为了流程图去学习新的工具，完全可以用axure的flow控件完成简单的业务流程图的制作。而PD们则常用微软的visio。
此外，特别推荐一个软件：。
我最近的流程图都是用SmartDraw绘制的，你可以下载一个免费版本体验下。这个工具不仅仅是为了流程图而设计的，几乎上包罗万象：线框图，流程图，E-R图，UML ,韦恩图，甚至甘特图，脑图……没有像很多人推荐就是因为他太庞大了，尤其是里面的模版。大家体验下：
自然要推荐. 绘制出来的任何图表不知为何总会觉得很美……
当然，这个软件是可以去下载免费版的……
但是不管windows还是mac，除了线下的工具，还有更多线上的选择：
不过貌似我们对线上工具普遍来说都不太放心，是对服务器，网速，还有对GFW不放心吧。
这个是界面做得最好看的一个工具。我用它来绘制过概念图（Concept map）。如下图即是用以上的工具画的。
转载请注明来处，关注我请点击：
可能感兴趣的话题
好棒呀！！！！
最新评论（期待您也参与评论）
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线博客团队正试图以我们微薄的力量，把优秀的原创/译文分享给读者，做一个小而精的精选博客，为“快餐”添加一些“营养”元素。
新浪微博：
微信号：Jobbole
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选博客文章
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2015 伯乐在线
赞助云主机