如何讓程序員聽懂需求

① 程序員如何提高理解能力

你要清楚程序的作用是什麼就好了！程序就是把實際需求利用程序去實現、有一句話說的好：一個不好的程序員最後死在需求上。你把一定要換位思考就好了！站在產品需求者上考慮下，不要用你編程的思想去想他的問題。

② 項目負責人如何和程序員溝通

做一名程序員，雖然好的口才不是必要條件， 但不善於表達自己想法以及與上司同事溝通，吃虧的是自己；

最近做一個項目，與項目的負責人出現一些不愉快的事情,出現這種情況雖然與其它雜七雜八的事情有點關聯， 但最重要的原因還是在工作上缺乏溝通； 例如， 上周他給我們C#組的人員分配工作， 每人負責一個小模塊， 資料庫和需求文檔已經提供有，但資料庫的表欄位有可能根據實現開發情況做少許改動，而且也給我們一個例子看， 可能參考該例子來做； 在統一講需求時雖然聽起來明白了，但做起來會發現很多關節的細節沒考慮進去，而這些細節往往會影響到開發的速度， 甚至看駢符合了文檔的需求，但卻不符合負責人或者說是客戶的實際需求;因為文字類型的需求是比較抽象，特別是要做用戶界面， 雖然有例子，但也只能參考，不能照搬也做，這樣做出來的程序很多情況下只符合程序員自己的需求； 已經花了很多時間去做一個可能不需要的功能，如我當時做一個日歷控制項來顯示排班信息，且也接近交貨日期了，到時交到負責人手裡時才發現，這個日歷控制項不是必要的，選擇的時間范圍是在彈出窗口裡，且不保存到數據...， 這時發現做了很多無用功，又要加班加點去趕進度了。雖然這只是一個小例子，但相似的例子在前幾個月里已經發生過幾次，為什麼呢，因為表達能力差，也不善於與人溝通。可以利用日事清管理工具來溝通，把想法寫出來。然後@給項目負責人。不用直接面對，效果不錯。

③ 程序員要怎麼考慮用戶的需求

回答之前先說一句：這不是一個程序員要明白的東西。程序員要做的就是敲代碼。

還有，你說用戶的需求似乎永遠都無法完全滿足，這是錯誤的想法
你要主動的問客戶問題，了解他們的情況。
比如說要實現什麼功能，還有客戶的硬體配置，以及客戶他們的各個部門之間的關系。
他們的業務流程，和他們各部門的許可權。
這些必須要明明白白。也許，你會說這些對軟體有什麼關系啊？
當你真正需要這些東西的時候就會明白了。

然後就是把這些在紙上打出「草稿」讓客戶瀏覽
如果他們滿意就簽字。簽字很重要。

要注意一點：他們不懂軟體。他們是客戶。
他們只要把需要實現的功能告訴你，然後就是把錢給你。
大部分的情況你是在玩一幫不懂軟體的人，所以他們不會理解做軟體需要哪些信息。

④ 要做程序員需要學會什麼

要做程序員需要學會什麼
程序員的崗位需求很多，例如大型網路公司、軟體開發公司等等都需要程序員。
程序員需要學習：
1、掌握數據及其轉換、數據的機內表示、算術和邏輯運算，以及相關的應用數學基礎知識；
2、理解計算機的組成以及各主要部件的性能指標；
3、掌握操作系統、程序設計語言的基礎知識；
4、熟練掌握計算機常用辦公軟體的基本操作方法；
5、熟練掌握基本數據結構和常用演算法；
6、熟練掌握C程序設計語言，以及C++、Java、Visual Basic中的一種程序設計語言；
7、熟悉資料庫、網路和多媒體的基礎知識；
8、掌握軟體工程的基礎知識，了解軟體過程基本知識、軟體開發項目管理的常識；
9、了解常用信息技術標准、安全性，以及有關法律、法規的基本知識；
10、了解信息化、計算機應用的基礎知識；
11、正確閱讀和理解計算機領域的簡單英文資料。
程序員必備技能：
1、熟練開發工具
做為一名程序員至少熟練掌握兩到三種開發工具的使用，這是程序員的立身之本，其中C/C++和JAVA是重點推薦的開發工具，C/C++以其高效率和高度的靈活性成為開發工具中的利器，很多系統級的軟體還是用C/C++編寫。
而JAVA的跨平台和與WEB很好的結合是JAVA的優勢所在，而JAVA即其相關的技術集JAVAOne很可能會成為未來的主流開發工具之一。
其次，能掌握一種簡便的可視化開發工具，如VB，PowerBuilder，Delphi，CBuilder，則更好，這些開發工具減小了開發難度，並能夠強化程序員對象模型的概念。
另外，需要掌握基本的腳本語言，如shell，perl等，至少能讀懂這些腳本代碼。
2、熟知資料庫
作為程序員，他們自然有自己的理由：很多應用程序都是以資料庫的數據為中心，而資料庫的產品也有不少，其中關系型資料庫仍是主流形式，所以程序員至少熟練掌握一兩種資料庫，對關系型資料庫的關鍵元素要非常清楚，要熟練掌握SQL的基本語法。
雖然很多資料庫產品提供了可視化的資料庫管理工具，但SQL是基礎，是通用的資料庫操作方法。如果沒有機會接觸商業資料庫系統，可以使用免費的資料庫產品是一個不錯的選擇，如mySQL，Postgres等。
3、了解操作系統
當前主流的操作系統是Windows，Linux/Unix，熟練地使用這些操作系統是必須的，但只有這些還遠遠不夠。
要想成為一個真正的編程高手，需要深入了解操作系統，了解它的內存管理機制、進程/線程調度、信號、內核對象、系統調用、協議棧實現等。
Linux作為開發源碼的操作系統，是一個很好的學習平台，Linux幾乎具備了所有現代操作系統的特徵。雖然Windows系統的內核實現機制的資料較少，但通過互聯網還是能獲取不少資料。懂得網路協議TCP/IP。
在互聯網如此普及的今天，如果您還沒有對互聯網的支撐協議TCP/IP協議棧有很好的掌握，就需要迅速補上這一課，網路技術已改變了軟體運行的模式。
從最早的客戶/伺服器結構，到今天的WEBServices，再到未來的網格計算，這一切都離不開以TCP/IP協議棧為基礎的網路協議支持，深入掌握TCP/IP協議是非常必要的。
至少，需要了解ISO七層協議模型，IP/UDP/TCP/HTTP等常用協議的原理和三次握手機制。
4、明白DCOM/CORBA/XML/WEBServices存在的意義
隨著技術的發展，軟體與網路的無縫結合是必然趨勢，軟體系統的位置無關性是未來計算模式的重要特徵之一，DCOM/CORBA是當前兩大主流的分布計算的中間平台，DCOM是微軟COM（組件對象模型）的擴展，而CORBA是OMG支持的規范。
XML/WebServices重要性不言而喻，XML以其結構化的表示方法和超強的表達能力被喻為互聯網上的「世界語」，是分布式計算的基石之一。
5、不要將軟體工程與CMM分開
大型軟體系統的開發中，工程化的開發控製取代個人英雄主義，成為軟體系統成功的保證，一個編程高手並不一定是一個優秀的程序員。
一個優秀的程序員是將出色的編程能力和開發技巧同嚴格的軟體工程思想有機結合，編程只是軟體生命周期中的其中一環，優秀的程序員應該掌握軟體開發各個階段的基本技能。
如市場分析，可行性分析，需求分析，結構設計，詳細設計，軟體測試等。
6、需求理解能力
程序員要能正確理解任務單中描述的需求。在這里要明確一點，程序員不僅僅要注意到軟體的功能需求，還應注意軟體的性能需求。
要能正確評估自己的模塊對整個項目中的影響及潛在的威脅，如果有著兩到三年項目經驗的熟練程序員對這一點沒有體會的話，只能說明他或許是認真工作過，但是沒有用心工作。
7、模塊化思維能力
作為一個優秀的程序員，他的思想不能局限在當前的工作任務裡面，要想想看自己寫的模塊是否可以脫離當前系統存在，通過簡單的封裝在其他系統中或其他模塊中直接使用。
這樣做可以使代碼能重復利用，減少重復的勞動，也能使系統結構越趨合理。模塊化思維能力的提高是一個程序員的技術水平提高的一項重要指標。
就業方向：
1、網路開發
現在網路已經成為世界通訊的一座橋梁，好像Javascript、PHP、Ruby這幾類開發語言大部分是用作網路開發方面。
2、企業軟體開發
JAVA、C#、VB這幾類開發語言都實現了面向對象開發的目標，更多時候用於企業系統的開發。
3、系統軟體
C語言、C++、Object-C這些軟體更多是用在系統軟體開發，嵌入式開發的方面。
當然，這分類不是絕對，像JAVA、C#、VB很多時候也用於動態網站的開發。在很開發項目都會使用集成開發的方式，同一個項目裡面使用多種開發語言，各展所長，同步開發。

⑤ 各位親，一般怎麼跟程序員溝通的

少數程序員是那樣的，經驗不足，或者性格原因，或者疏忽，程序在設計和編寫的過程會出現一些與事先預期不一樣的結果，或者根本沒有考慮到這些情況。

他們已經夠累了，面對重復的更改有時很無奈。對於他們除了要把本職工作處理玩，還要學習新東西，以後不做這個了怎麼辦，自己只對這門語言比較熟，將來出來更新的怎麼辦。對於做網站那種處理界面的繁瑣工作，我想沒有幾個程序員會不煩躁。

眾所周知，程序員學的多，乾的多，掙的少。如果你正在做項目管理或者產品管理，你要懂的第一件事就是與他們溝通，我想沒有幾個程序員是固執己見的，程序員們都明白個道理，在技術行業里，一個人走不了多遠。

與他們溝通很簡單，把他當成朋友，而不是下屬。

⑥ 好累，程序員聽不懂產品經理提的需求，問多了，產品經理嫌煩。該怎麼辦

在我們公司面對產品經理提的需求，我們都有統一的回復：

⑦ 如何與強勢的程序員或設計師溝通需求

年紀輕是可以混口飯吃，年紀越大越不好混，因為能升上去的畢竟是少數，一般30歲左右會有很多人轉行，資深的程序員在中國幾乎沒有。如果35歲還在做coding，在中國是失敗的象徵，但是相對國外，50歲的開發人也是有的。

⑧ 如何正確的給程序員提技術向的需求

一、發需求的方式

我相信所有人都經歷過這么一種場景：

你發了需求，但是對方沒有看到，於是在交付的那天你什麼都沒有收到!

別怪別人!怪自己!

發需求的方式強烈建議2種結合：郵件+口頭

郵件：很正式，內容完整，並且容易回溯

口頭：最好是口頭，因為消息和郵件是繁多的，很容易被忽略，但是語言的交流是印象深刻的。如果無法實現口頭交流，最好是通過IM再提醒一下，讓對方明確的回復已經看到郵件，加深印象。

二、需求是人做的，人心是肉長的

需求之所以復雜就是因為需求是人來做的，如果是機器來做就太簡單了：只要輸入正確的命令，機器會准確的幫你實現好。

有了人的存在，需求就會存在delay、錯誤、品質不夠等問題。

但這並不能成為需求實現不理想的介面，為何別人的需求可以加塞在你的前面?為何別人提的需求實現品質就比你的高?

同一個忙，你找陌生人，朋友，親人來幫，其過程和結果肯定是不一樣的!

那你能不能讓對方成為你的朋友甚至哥們，就要看你的本事了。

三、需求內容需要符合「SMART原則」

Specific——需求必須是具體的，明確的，別摸凌兩可

Measurable——需求必須是可以衡量的，要能夠評價他的好壞

Attainable——需求必須是可以達到的(這個也是對方經常拿出來的理由，遇到之後參見要點一)

Relevant——需求必須和其他目標具有相關性，沒有意義的需求是浪費時間，要告訴對方意義何在

Time-based——需求必須具有明確的截止期限

⑨ 初級程序員如何提高項目需求分析能力

找本需求分析的書來看看。其實初級程序員不需要太強的需求分析能力。

⑩ 好的想法製造好的產品經過怎樣的過程

不懂技術，一個好的想法如何讓他實現？

經常聽到很多人說「我有一個很好的idea」，就差一個技術合夥人了。下面就產品的整個服務流程給不懂技術的創業者分享一下一款好的產品的打造流程。客棧3.0昨日剛剛上線，還是以遠程工作為切入點，做互聯網企業的技術遠程中心，做好程序員的經紀人，為程序員和需求方服務，特別是這次3.0版本的短期僱傭服務，徹底解決產品需求方和程序員的溝通障礙，讓程序員駐場到企業提供服務，完美解決項目開發過程中可能遇到的問題。
一個項目的開發流程一般是『想法』『原型』『設計』『開發』『測試』。
一般剛開始創業的人，沒有產品研發經驗的公司負責人，他們提供的word、ppt都是屬於『想法』，無論描述再詳細再怎麼高大上都屬於想法。很多這樣的創始人或者產品負責人，就這樣拿著自己的『想法』滿世界的去找人做開發，就差一個靠譜程序員了，一些程序員自詡技術能力好，樂呵呵的接了項目，然後就是項目爛尾了。程序員客棧剛開始做外包分發也嚴重面臨這個問題。之前一直搞不明白為什麼會這樣，現在才慢慢想清楚就是因為項目沒有流程，介入的人越多結果越亂。項目一開始定位模糊，沒有原型就找設計，沒有靜態設計和流程圖就直接做開發，開發想趕進度就增加人手，開發完成不留文檔擺出再也不想管了姿態。你們感受下，這些都是非常糟糕的做法，這樣折騰產品質量能好才怪。做產品搞開發絕不是找包工頭建房子的那種野路子。
所以能做好產品一定需要對『想法』『原型』『設計』『開發』『測試』這個流程有深刻的認知和實踐。即使不完全按這個來，也要有類似的自己有效的套路，保證產品模塊化有流程可依。要知道現在的產品開發絕大多數不是一個人能做完的，所以團結協同這么多人做開發，需要流程和進度規劃兩手抓。這樣才能保證項目質量，做出優秀的產品。下面就對以上我們理解的每個流程以及下一個流程的啟動條件做一個簡單說明，讓大家有個整體的即視感。
『想法』
所謂想法就是一切的口頭描述、會議溝通、word ppt excel文字描述。無論描述得多麼詳細，講的多麼讓你懂，都只是屬於想法。之前和一些非技術行業要跨界到互聯網的老闆溝通時，他們經常這樣描述自己的產品：對，這里就是和微信一樣。吧啦吧啦，你懂了沒？沒懂是吧，要不我再給你講一遍。然後程序員居然就懵懵懂懂的懂了，接著就去悲劇的搞開發了。當我走訪到很多創業團隊也正在這樣操作時，瞬間整個人都不好了好嗎。千萬不要相信一個處於『想法』階段的產品通過不斷的多講幾遍能變成『原型』，即使你聽懂了，那也不叫原型。其實我們知道程序員心裡苦，只是程序員不說。
那又為什麼，很多企業的官方網站交給豬八戒、地方建站團隊、甚至老師學生團隊也能做好呢？他們也沒有什麼流程。你一定要相信，豬八戒、地方一般的建站公司也只能做好企業展示網站了（或者修改代理軟體）。因為這一塊是比較標准化的東西，一個後台，成百上千種前端風格，足以滿足你的各種需求。而需要改造世界的偉大創業者，就不要把自己的產品寄託在這樣的公司平台了，還是自己搭團隊做產品靠譜。互聯網企業產品是核心，核心都外包了，你還做什麼啊。重要的是外包基本都是爛尾的，這倒是很現實的有木有。
『原型』
原型是對『想法』的中流程、產品布局等的詳細描述。一般的原型圖可以用Axure、Sketch或者現在新出來的一些移動原型工具來畫。畫出來基本就能看到產品什麼樣子了。從『想法』到『原型』這是產品經理需要做的事情，他要理順產品邏輯，找到重點，建立流程。所以不要逢人就說：我們沒有產品經理，我自己就是產品經理，即使你一定要是產品經理相信也遠遠沒有那樣的專業內涵深沉。在這個大眾創業萬眾創新的時代，一些很草莽原始的開發團隊中，如果有一個非常能被折騰設計師，當然也是可以不需要原型的，直接把想法告訴給設計師好了，這樣好炫酷有木有，然後做幾個版本挑一個，巨大的溝通成本加上不斷的修改，也是能做出來，起碼產品外表好看了。為了更好的理解『原型』是什麼玩意，這里挑了程序員客棧的原型放出來給看看

『設計』
有了原型，後面才是『設計』。不要原型就能一氣呵成設計好一款產品的設計師不一定是好設計師。當然你也可以認為，牛逼的設計師不需要原型，就像牛逼的程序員不需要設計一樣：某個大學導師的學生可牛了，他一個人能把所有的做完，是牛飛起來的全棧工程師，吧啦吧啦，你就信吧。『設計』部分就是我們能看到的產品外觀了。交付給程序員的『設計』不僅包含「視覺」，還有「源文件」、「標注」和「切圖」。設計可以分得更細，就像有UI了，還可以有UE（用戶體驗）。好的設計師能在設計中能照顧到UE，看你產品設計需要深入的程度了。
『開發』
前面搞了這么久，終於輪到程序員上場了，這里的重點就是需要找到靠譜程序員，程序員水平不一樣，開發出來的東西就是一個天上一個地下，靠譜程序員和不靠譜程序員氣質水平差得不是一星半點。一定不要指望一個菜鳥程序員能完美的按照靜態設計把產品完美的做出來，他會告訴你一些普通功能的各種不可能實現的原因。拿到靜態設計圖和原型，後端程序員就可以設計架構開發後端（這又是一個尤其重要並深入的方向，這里就不深入了），前端程序員（web、iOS、Android）再根據後端介面和靜態設計快速開發出來產品。中間的具體疑惑隨時找產品經理，進度問題項目經理負責。一般一些團隊會有自己的進度先後原則。比如：原型先出來，再是做設計和後端，設計和後端領先前端開發一周左右。這樣配合起來，一個好的產品模塊化的一步步的完成，然後就走完了產品中最重要的開發環節。
『測試』
好啦！產品終於做完了，程序員commit了最後部分的代碼，然後給你說：我們做好了。這個叫做內測版，所以是不能發布用的。產品只有經過嚴格的測試，單元測試，公測後才能上線。千萬不要相信一個程序員說：「我做的開發不需要測試」，即使他再牛。當然我相信一些好的程序員在開發的過程中很少留坑，並且邊開發邊寫測試，所以做出來產品質量很高，但是這樣的產品也是需要測試的，因為bug無處不在。我們需要理解產品不正常是正常狀態。所以才需要「運維工作師」嘛，這種職業的存在也讓一些非互聯網行業的人無法理解。我賣你一套軟體和系統，還給你配個人維護，那就說明產品開發出來就是為出問題做好准備的了。
最後提醒下，以上過程中一定要知道程序員的水平高低以及他們的習慣都足以影響你的產品質量，甚至生死。這里給那些開發不做版本管理，代碼就放程序員自己電腦上；介面文檔word提供，沒有版本控制；產品不按模塊化開發；沒有產品經理和設計，產品開發程序員就按創始人口述；沒有任何伺服器備份機制...寫不下去了，你們感受下。這樣的做法遲到要掉大坑裡的，沒有為什麼！如果你們一定要抱著僥幸心理，不考慮各種意外來開發產品，那也是可以的，兵法有說「勝可知而不可為」。就是長期的勝利一定是建立在排除各種失敗原因的基礎上的，然後等待勝利的機會。
經過以上一步步的努力，然後你的產品就可以上線了，普大喜奔~~~燒香求保佑無bug，然後小宇宙爆發~~~一切都交給運營汪吧。