原博客地址
關於以前的一些疑惑
其實呢，以前本身我這塊不存在特別多的直接疑惑，畢竟以前本人有過相當的項目實踐經驗，對有些事情還是相對了解的。
既然如此，那在這裏筆者就簡單說下之前的問題在本學期中所面臨的一些真實狀況。
PM做開發和測試之外的所有事情
這塊的話，我們團隊整體做的還算可以。分工相對明確，大家都有一定的熱情和積極性。並沒有出現寡頭壟斷的情況，所以自然也不存在後續的崩盤之類的。
豬、雞和鸚鵡的故事
這部分的話，我們團隊內各自對這個項目，以及這個項目中自己的得與失，還算是基本拎得清的。總而言之整體上合作愉快。
新的問題
如何與技術段位差距較大的人相處或達成一致
筆者之前的話，其實在多個技術團隊做過事情，基本上沒啥問題。
但是，之前的團隊不管怎麼說，協作者都是有着相當完善的工作經驗的。而在軟工課程中所面對的這個團隊確實一羣完完全全的學生。於是在很多地方就存在了思想上的衝突：
- 我：
- 這個項目應該如何計劃才能做的更大，效益更好？
- 這個地方代碼應該如何維護才能未來更方便？
- 這個地方需求如何設計才更有效益？才能用最小代價換取最大收益？才能在市場上佔據一定的主動權？才能在和學校有關部門交涉的時候有足夠的籌碼？
- 學期結束後，我們應該如何把這個項目進行安置，才能讓其真正的穩定而不至於人去樓空人周茶涼？
- 學生：
- 這個項目如何才能拿到更高的分數？
- 這個地方應該怎麼寫才能更快地寫出能跑的程序？
- 這個地方需求如何設計聽起來才最讓老師信服以便給個高分？（沒錯，劃重點：聽起來）
- 學期結束後，我們的項目應該如何處理才能讓我多拿幾分？
這樣的矛盾其實很顯然，雖然我某種意義上大概能理解爲啥很多人會有這樣的學生思維（實際上很早以前的我也差不多，只不過經歷的比較早而已），但是很多時候爲了更長遠的利益，卻又不能妥協。然而講道理卻又不是什麼時候都能行得通的，畢竟視野深度和廣度存在明顯的代差。
於是在這樣的情況下，如何和具有代差的人相處並做好事，就是一個亟待思考的問題了。
管理層如何讓下屬，甚至是高階下屬，在利益上達成共同體，是否有什麼一般性的思路
正如筆者在前面的博客中所寫：
世上只有利益上相互依存的關係，纔可能是穩定的關係。
同時，基於上面一點的論述，不難發現技術段位差距較大的人，已經容易存在眼界和視角上的代差。那麼在現實的組織架構中，一個高層管理所能看到和察覺到的問題，可就和下層的人相比起來差別大了去了。
所以，在這樣情報嚴重不對等，甚至很多時候連深層的信賴關係都難以達成的情況下，能依賴的唯一紐帶就是共同的利益關係。或者也可以說，正是因爲很多的下層人員與上層所共同考慮的問題也基本只有利益（996事件中，大部分基層程序猿的發聲，基本邏輯都是如此），所以利益也是最靠得住的一種紐帶。
那麼問題來了，在這樣嚴重不對等且沒有信賴關係的情況下，利益共同體該如何達成？是否有一些一般性的思路。
先說說個人目前的一些粗淺認識，思路有兩種：
- 充分換位思考，瞭解對方利益訴求
- 這是最開門見山的一種思路，也是解決問題最直接的一種手段
- 但是這樣的方法存在一些操作性上的問題
- “子非魚安知魚之樂”，你再怎麼去試圖理解他們，但你畢竟不是他們。
- 所以，實際上很容易發生即便換位思考，依然不得要領的情況。意識是客觀存在的主觀映像，所謂換位思考思考出來的，與其說是對方，倒不如說是對方+自己。
- 而且事實證明，在這樣的情況下，被換位思考的那一方還基本上不會買賬。就好比，人家要一個蘋果你給人家拉來一車梨。
- 最典型的一個反面教材——世界上有一種冷，叫做你媽覺得你冷；世界上有一種食慾，叫做你媽喊你回家吃飯
- 既然沒有信賴關係，那就建立信賴關係
- 這個辦法需要多一步，但是實際上如果能實現的話效果會很好
- 實際上，很多成功的領導者，甚至政治家，所做到的事情也正是與自己目的路上核心位置的人員全都建立了信賴關係，並以此爲突破口，再以利益關係作爲穩定因素，加強安全性（典型例子：劉備、司馬懿、希特勒等）
- 但是這件事依然存在一些難點：
- 對於所有的人，如果都要建立起信任關係的話，那實際上成本實在太高了（尤其對於高層領導，對下層所有的人都直接聯絡感情？聽起來不太現實）
- 而且實際上，很多人也並不在意這層信賴關係。最典型的就是現在常說的“社畜”，他們就是賺錢，工作時間以外的任何事別來煩我。畫大餅？那是啥？你們做領導的不是最喜歡騙我們麼？責任？那是啥？有錢重要麼？信賴？那是啥？本大爺不對你們這羣黑心壞領導宣戰都是給你們臉了，還信賴，要我們同流合污？腦回路很清奇對吧？但是他們還真就是這麼認爲的，這種心態極其普遍。
- 當然，能遇上好溝通善解人意的人，當然是極好的。但是很顯然，現在的社稷國情下，不能把這類偶發事件當做全部，更不可能只靠這個過日子。
綜上，實際上在上下級這一層的關係維繫上，是存在這樣一個很尷尬的僵局的。所以，這塊應該還是需要一系列更成熟的思路和解決方案。還望不吝賜教。
如何和一般性的其他人或者團體達成利益共同體，是否有什麼一般性的思路
同樣的，實際上在合作方之間，也會存在這樣的一層問題。
簡單來說，人家也有人家的利益。人家不可能因爲你胡吹出來的那點所謂的“情懷”、“信仰”，就來和你談合作，因爲人家也是人，也得吃飯，也和你一樣沒有太多的時間做無意義的事。
和上面一條基本類似，此處不再做詳細描述。
做中學總結
需求
首先，需求層面，需要從兩個角度來分析：
- 甲方。在很多的情況下，需求方只能說出大概的需求（比如，我想做一個場館數據系統，我想做一個用來刷航概的app），更細的，即便問他們，他們也不知道。但是對於甲方而言，如果你把一個產品擺在他的面前，問他合適不合適，對不對，這樣的問題他們是能給出明確答案的。
- 乙方。對於程序猿而言，很多時候只有知道明確的需求才能進行工作。然而如上文所言，甲方是不可能做到直接給出這樣的明確需求的。於是這個時候，PM的一個重要職責就是在甲方和程序猿之間建立一個橋樑，將甲方需求轉化爲開發需求。同時也需要在和甲方溝通的時候，對程序猿們有充分的瞭解（比如大致瞭解哪些東西可做，哪些東西好做，哪些東西不可做）。
設計
在需求層面基本明確的情況下，那麼設計也就該提上日程了。
設計也分爲幾個層面：
- 產品設計。產品設計主要是將需求進行一個整合，和上問的需求分析轉化基本類似。
- 架構設計。架構設計則是在已知的詳細需求下，思考如何構建一整套的代碼，以及軟硬件資源配置。同時，需要從架構層面來考慮後續的可維護性。
實現
實現這塊，則需要在整體架構設計相對明確的情況下進行。
此外，在實現的過程中，最好伴隨着主幹功能的實現，一併將單元測試也進行實現。
除此之外，還需要在開發實現的過程中，注意後續的可維護性（實際上個人感覺開發與維護這塊本身就是一體的）。
課程心得
本學期對我而言，實際上只相當於把以前做過得事情再次弄了一遍。唯一一點比較重要的差異，在於這次的團隊配置和以前大不一樣（前文有說到）。所以能總結的內容其實很有限。
不過實際上，筆者也在思考這個課程的一些得與失。同時，筆者也在這個學期當OO的助教，對有些問題也算是有那麼一些略微的認識，在這個部分我就着重說下這方面的問題吧。
思考與建議
課程週期短，相關內容體現不足
首先，這個課程是一個只有一學期的課程。而且一學期時間，涵蓋了三個階段，包含了那麼多個環節。
老實說，以我之前做創業項目的實際體驗來看，除特殊情況外，一般不會有周期如此之短的事情。
而且這樣的短週期還會帶來另一個問題，那就是很多要素的重要性的體驗嚴重不足。例如：
- 維護前後期的重要性。如此短的一個項目，即便一路無腦硬衝，也基本上不會出啥問題。而且實際上在一學期內，根本也不太會遇到真正的大範圍業務需求變更這樣傷筋動骨的操作（正常的PM應該都會去極力避免）。所以實際上這一塊與現實存在一定程度的脫節
- 與用戶的深入互動。同樣，這個課程項目，作爲一個“課程”項目，在很多組的眼裏，還完完全全是個搖分樹而已。即便要求了用戶指標，他們所做的事情也大都不過只是所有人朋友圈轉一轉，各個大羣發一發而已。而用戶用來到底真實感受是怎樣的？沒有有問題？嚴重問題還是隻是體驗問題？問題出在哪裏？怕是很多組根本就沒有做過詳細的調研。對於繼承項目，尤其有這樣的問題。筆者所在的組還好，最起碼很明確用戶羣體，也有過與相關組織進行直接溝通。但是其他一些組，可就難說了，據我所知，拿來代碼 --> 編寫代碼 --> 羣裏轉轉 --> 截個圖 --> 交作業這樣流程的怕是不在少數。而這麼一個循環弄下來，他們真的能有多瞭解用戶呢？知己知彼百戰不殆，大環境都摸不清楚的團隊，除了能在學校賺點分之外，出了學校是做不成什麼事情的。
實際上，在OO課程哪邊，也一樣存在類似的問題。OO和軟工的一個共同特點，那就是有些內容是很概念化抽象化的，與其說是技術技能倒不如說更像是概念機能。在短週期內想做到這件事，並不容易，甚至一定程度上，軟工比OO面臨的形勢只會更加嚴峻。
在這樣的環境下，如何把握好整個週期，如何把有些該體現的內容充分體現出來，讓學生在學習過程中把這些內容落到實處而不是流於形式，則是需要課程組好好考慮的問題。
相關指導偏向於抽象
如題，很多的指導還是偏向了理論，和實際操作的結合有一定的錯位。這就導致一些組或者個人，到了一定階段會開始陷入很大的迷茫，而且還沒有辦法通過理論課的講解來進行補足。
其實，這件事說來並不能全怪這門課程。學生在學習這門課程之前，實際上一些前置知識還是比較匱乏的。比如一些考慮問題的基本方式，以及一些架構佈置方面的基本功（這塊2016級及以上會表現的比較明顯，因爲OO這塊的整體學習質量不夠好；相比之下2017級，也就是明年開始，因爲今年OO大規模課改，同學們的這塊能力會有明顯的好轉）。於是實際上，我們的指導需要分爲幾個階段：
- 起步階段
- from
personal developmenttoteam-working - from
programmingtocoding, and then todevelopingandproducting - from
doing homeworktoexploringandcreating
- from
- 步入正軌
- 引導學生們真正開始思考有些問題，而且一定需要他們去進行實打實的操作，而不是博客寫幾個字重複幾句套話就了事。
其實OO也有類似的一些過程：
- 起步階段
- 教會大家Java基本語法
- 教會大家多線程基本知識
- 教會大家基本的調試與測試技能
- 步入正軌
- 面向對象
- 設計模式應用
- 契約式設計，Java modeling language
- 深層次設計工具，UML繪圖
今年所採用的模式，是兩部分交織着進行。在第二單元多線程結束後基本完成起步階段的教學，但是正軌部分實際上第一單元就開始了。保證學生做到不至於營養不良，也不至於營養過剩，飯一口一口吃，事情一點一點做。到了起步階段完全結束的時候，一多半的同學已經具備了完整的架構思維，剩下的就是不斷優化追求卓越了。
所以建議課程組也在這個問題上多下一些功夫，要切實瞭解起來學生的真實情況。
助教與學生之間直接互動偏少
如題，實際上助教在同學這邊的存在感實在是很低（相比於機組和OO課程而言），一整個學期除了通知消息之外基本見不到助教出沒，甚至通知消息也都是高階助教一個人在不斷的通知。
助教，其實是個很微妙的職業。說微妙，其實原因如下：
- 老師，瞭解整個學科，但是不容易瞭解學生的一線狀況（不要說老師沒去了解，之前OO也發過調查問卷，結果是什麼樣的你們心裏都清楚，可以上知乎看看；就算不說這個，但是所有學生心裏都有一條不成文的規矩——不在有老師的羣裏說真心話，這個應該助教們心裏也都清楚的）
- 學生，最瞭解一線狀況，但是大部分的學生，對整個學科是沒有特別完整的認知的。（於是，就會總有一部分一瓶子不滿半瓶子咣噹的學生，基於一線狀況和自己那點正確率感人的揣測，鬥天鬥地鬥空氣，鬥來鬥去卻毫無結果。雷打的震天響卻死活見不到一滴雨，除了自嗨任何事都沒見被解決。秀才造反三年不成，說的就是這類人）
- 而助教，作爲過來人，具備一定的學科思維，同時也有很多的機會了解第一線的學生情況。
助教的這一特點其實很微妙，老師、學生，都整體上缺乏某一方的資源，而助教卻完全有這種可能打破資源時空分佈不均的困局（甚至部分比較厲害的助教自己一個人就能完整的掌握兩頭的情報）。
於是，個人認爲，助教的一個職責就是——充當起師生情報傳遞的橋樑。
如果追求更深層次的話，那就是——基於雙邊的情報，優化雙邊資源配置，一達到一個全局更優的解。
所以，其實建議助教們看到這句話也能好好思考一下。我相信助教們也都應該是有志於改進整個課程的人，那就好好思考思考我說的這些，想想看自己到底該做點什麼，而不是隻是一味充當苦力，或者乾脆只是一個傳話筒子（而且搞不好還是單向的）。