※ 引述《serica (银月奔流)》之铭言： : 这个你只能越级呈报 : 跟上级说SA不懂程式 : 很多东西是程式写不出来的 : 今天如果SA写得出来，就是你的问题 : 问题是SA也写不出来 : 要嘛换SA，要嘛你走 : 不然你们就注定是个充满悲剧的地狱组合 : 所以说SA最好还是由PG出身 : 不然老是答应一堆有的没有的 : 跟本作不到的事情 : 出了问题还搞不清楚状况 : 不过话说上面的若不挺你 : 你还是赶快另寻高就吧 : 良禽择木而居 System Analyst本来就可以不用会写程式， 之前跟不少纯SA合作过，也没出什麽问题。 但前提有三个： ①SA起码要把他的角色做好 ②如果他程式真的完全不会写也没有概念，那麽要有SD罩他，分进合击才行。 ③如果他对UI/UX也没有概念，那原型设计也要有人检核过（最好是F2E） SA的角色在谈需求，而且是甲乙双方都认可的可行需求，而不是那种甲方乱干一通， 不管有没有道理就通通收回来叫底下做的那种。这种的唯唯诺诺SA也不够合格。 接下来他必须要好好研究流程、研究有哪些画面、画面上有哪些按钮、哪些功能， 栏位有哪些、验证规格是什麽、例外状况是什麽、错误操作步骤下，会出什麽警示 讯息。 （是的你可以不会写 <input type="password"> 但不要给我连这页上要不要密码栏、 客户希望密码栏多长、用什麽密码验证方式、要不要大小写混用要不要符号什麽的 都一问三不知、最後还叫开发人员随便选一个） UML图如果懒得用Microsoft Visio画漂亮版本也没差，你可以画在白板上跟客户沟通、 取得客户签名认可，白板上的图大不了拍下来参考即可。 如果客户要这些文件，事後叫文案助理帮忙把白板拍的照片画成漂亮文件即可。不 用浪费时间叫SA画。 由於大部份时间都在做文件、做需求单位与实现单位的沟通，所以沟通、文件能力 绝对是首要。接下来他在该领域的知识，绝不能太弱。如果要支援ERP的SA，结果连 ERP是干嘛的都不晓得，这样的SA太危险，绝对会因为什麽产业例外状况没想到、流 程没设计完善而出包。 最後，完全不会写程式的SA，如果刚好他的UI / UX也没有概念，不清楚Web上与 手机上一般都用什麽元件来实现他的流程设计，那麽最好也有F2E（前端工程师） 帮他看一下原型设计，避免由SA自己做Mockup Prototype，画了一堆很难用、很 不好实现的脱离现实UI。 你觉得你的SA很难配合，只是因为他根本连自己的本份都没做到，他不会做的东西 也没有人帮忙（当然或许他也根本也没有自觉），主管根本也不知道一个软体工程 案子究竟有哪些工作要做，如此而已。 你可以不挂这个职称，小公司或小专案也不可能把什麽F2E、SA、SD全都分给不同人 做。但是上述提到的工作，一定要有人做，不是分工做就是兼职做，而不是推来推 去最後放空。一堆案子的时程管理放空、研究需求叫甲方做甲方说啥就做啥、原型 设计根本跳过，为啥？因为PM每天在应酬没空，然後SA忙着在开Table、协助修Bug…… 台湾人对SA的要求通常希望他全包，最好可以管时程、研究需求、出漂漂亮亮接近 实际状况的原型设计、最好连资料表都会开、做做正规化…… 然後一堆PG想说我翅膀硬惹、老惹就可以升SA惹。 靠夭，再说一次，SA的本职是先做好沟通能力、文件能力、强大领域知识 开发人员的本职是开发程式、技术深入研究、精研设计模式、良好单元测试 PG待久惹、老惹，突然就可以学会SA的本职？ 先看看自己程式注解上有多少错字跟病句好吗……再想想自己去到客户端吓得 屁滚尿流，一切唯唯诺诺、皆曰可行的样子好吗……还想跟我说这样要转SA…… 难怪台湾职场常常碰到不合格的SA。你叫SA去补强非必备的技能，就等於让他放任 自己原本该做的事，更有理由做不好了。最後大家害来害去，专案倒掉。 SA的本职没做好而害惨团队的效果，可比PG本职没做好远远大多了。因为他负责的 可是房子的蓝图。 （SD负责地基与梁柱、PG负责往上盖一路盖到好、QA负责监工） 要是随便就能碰到能独立盖整栋的强者SA，靠北惹，去这种白烂职场被整干嘛， 一起来做SOHO就好惹，欢迎寄站内信给我（？） --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.135.200.163 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1448249222.A.6FB.html ※ 编辑: FantasyRyu (220.135.200.163), 11/23/2015 11:46:19