前幾天跟朋友聊天時，朋友說他剛剛從一家知名軟體公司面試出來，朋友去面試的是一家公司的技術管理崗位，所以在面試的時候被問及的問題也偏重於技術管理方面的問題，在與朋友的聊天中將這幾個問題歸納了一下，大致歸為如下幾個問題。
在日常工作中你是如何行使管理職能的
這個問題以我的經驗以及參考常見的一些開發方法，在實際中我都是早詢問及晚反饋的方法。也就是早上上班後的半個小時內主動詢問開發人員是否有不能及時解決的問題，如果有，組內組員討論解決方法；下班的時候，組員可以以郵件或者其它方式匯報自己的進度，並評估當前進度與預計進度相比是否有滯後。為防止有些內向的組員不能用口頭的方式反饋自己在開發中所遇到的問題，可以允許他在下班前的反饋報告中說出自己所遇到的重難題。作為技術管理人員，可能在工作中管理也要佔相當一部分時間和精力，抽出適當的時間和精力做做走動式管理，也就是主動走到開發人員身邊詢問他們目前手頭的工作並詢問是否有無法解決的難題，盡早發現問題盡早解決問題，使專案盡量按預計日期交付。
如果發現因為種種原因導致實際工期遠遠超出預計工期時，你應該怎麼做
實際上除非客戶主動限定交付日期，一般自己估算工期的時候都會在理論工期（根據經驗估算出來的）的基礎上再乘以乙個係數作為交付日期，但是確實也有即使這麼做了仍遠遠超出工期的情況，比如在開始的時候對某些風險預計不足等，遇到這種情況個人覺得可以採取如下幾種辦法：
一、增加人手，增加人手可以適當縮短專案週期。
二、增加每日工作量，增加每日工作量儘管會被廣大開發人員討厭（我自己也相當討厭，但是在沒有辦法的辦法之下只好如此），但是也可縮短專案週期。
三、和客戶人員反饋和交涉，看能否博得對方理解而延長工期。
四、如果客戶人員不同意延長工期，那就再和客戶人員商量，是否可以將專案的優先順序列出來，在規定時間內將高優先順序的功能開發出來，這樣不影響客戶使用大部分功能，其餘功能可以在客戶使用過程中逐步新增。
五、如果客戶人員不同意延長工期並且也不同意在規定期限內部分交付，那就要和自己的上級匯報，畢竟處在自己所在級別範圍內該做的、能做的都做了，那麼就向上級反饋，讓公司級別的高層與對方公司級別的高層交涉，看是否有變通的辦法。
六、如果以上均行不通的話，那麼只能退而求其次，盡量在滿足使用者使用和不違反合同約定的情況下簡化或者縮減功能。
專案實際工期比預計工期長，這種情況並不少見，有時候由於種種原因，比如開發隊伍人員變動大或者對原有技術難點估計不足都有可能會導致這種問題。遇到這種情況之後我們首先嘗試從我們自己的層面看能否解決這個問題，如果確實不能解決就應該及時反饋到公司高層，從高層的角度尋求解決辦法，而不是設法掩蓋問題，等到公司高層發現問題時連補救的辦法都沒有了，給公司造成經濟和聲譽上的損失。
在平常需求分析階段你們以哪些方式與客戶進行交流和反饋
最常見的乙個辦法就是合同約定，將客戶需要的功能以白紙黑字的形式描述在紙上，這種情況下客戶對將來交付的產品僅僅限於我們的描述，不過一旦客戶簽字之後，即使客戶發現最終交付的產品與自己所期望的產品不一致也不能有什麼辦法，畢竟這些都在白紙黑字上寫明了並且客戶簽字確認了的。這樣做的壞處是這次可能會交付成功（啞巴吃黃連），但是客戶與公司之間不會再有下次合作機會了。
在實際中我們還用過一種辦法，那就是介面原型法。對於**，那就是設計一套靜態頁面形成的**，客戶可以通過我方人員的演示看到各個頁面之間如何跳轉及每個頁面的功能；對於軟體，也是設計出各個介面，客戶可以通過演示看出各個介面之間如何互動及每個介面的功能。通過原型法，客戶可以直觀感受將來交付的產品是什麼樣子的，避免僅通過語言交流而帶來的理解誤差。一般情況下我都是採用這種發發和客戶交流的。
在客戶不能描述自己期望的產品的情況下，你應該如何和客戶進行交流和反饋
在有些情況下我們會遇到一些客戶，他們很希望借助軟體來改變目前落後的操作和管理方式，但是客戶也無法用語言來描述自己所期望的產品的功能和樣子，這種情況下我們該怎麼做呢？
首先看市面上是否有類似於客戶所需要的產品，如果有，可以借鑑這些產品並結合我們的理解做出介面原型來與客戶進行進一步的交流（朋友說我這樣有抄襲的嫌疑，呵呵）。
如果不使用上面的方式，那我們還可以採用引導的方式和客戶交流。就像我們去生病去醫院，我們通過自己身體的不舒服知道自己生病了，但是我們不知道自己得了什麼病，醫生就會引導我們，比如會問頭暈不暈、嗓子疼不疼、眼睛酸不酸、腿軟不軟等，通過這些詢問醫生就能確定我們得了什麼病了（當然在醫院裡，我說的那些是理想情況，若遇上一心撲在偷菜事業上的醫生，人家只會引導你進鬼門關了，還有那種醫生一進去就不管三七二十一就讓你做一大堆化驗的醫生，曾經有位哥們感冒了被化驗出宮外孕來，白衣天使成了奪命魔鬼）。通過對客戶的引導，可以進一步發掘需求，並且將客戶的一些不太合理的要求化解，使我們能在盡量滿足客戶要求的基礎上開發出比較理想的產品。
當然以上是朋友能回憶起的問題和我針對這些問題的理解，事實上針對軟體的開發和管理有很多辦法，我們不能實際也不可能紙上談兵式對這些問題進行闡述。就像在資料庫設計時我們可以盡可能遵循一些正規化，但是並不是滿足了這些正規化的系統就是乙個好的系統，我們也不是一定要滿足所有的正規化，我們可以結合具體情況進行分析，最終我們的產品是乙個在各種因素影響之下的產品。
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...