什麼是可擴展的小型開發企業項目管理流程？

Question

我們有一個小公司團隊和更小的開發團隊。當前的過程是每個銷售代表（SR）是每個銷售的Web應用程序的實際項目經理。開發人員直接從SR獲取需求，功能和設計。讓開發人員的實際負責人瞭解開發人員的實際工作負載。雖然我們獲得更多項目並因此可能獲得更多銷售代表和開發人員，但此流程不可擴展。

我們考慮過讓技術人員處於SR和開發人員之間的中間位置。

SR1，SR2，SR（N）---> TPM - > DEV1，DEV2

這似乎不錯，但我們目前的過程使我們的銷售代表/ QuasiPM居然在一個非常直接的方式獲得開發人員的時間。而他們實際上正試圖擺脫這一點。

我們當前進程遇到的問題是：

SR1，SR2 - > DEV1，DEV2（即席）

• 沒有知名度，我們的開發人員的工作負荷（使開發者有太多停機時間或工作負荷太多）
• 不能根據緊急時間計劃休假
• 編輯1：我們忘記發佈的另一個問題是SR在早上會議中，並且優先級根據緊急情況每天更改。

我會根據收到的評論添加更多信息。感謝您一如既往的時間。

編輯2： 通常有3個SR或產品負責人，3-4個開發人員，1個技術總監。

Answer 1

不要把PM的在銷售代表和開發人員之間。這裏有兩個無關的問題。

• 您提供了哪些功能？ （只有SR知道這一點。）

• 你正在取得進展;你是否按時完成工作？ （這是一個PM的目的。）

你想要的是這個。

sales rep -> [ developers + PM ] 

此外，你想要一些圍繞交互的結構。

您不能讓SR將隨機需求放到開發團隊中。相反，您希望開發人員將注意力集中到（「衝刺」）目標上併產生一些東西。一旦他們完成衝刺，他們可以與PM和銷售人員會面，以確定下一個衝刺是什麼。

這是Scrum方法，它很好地擴展。它控制交互，而不會讓其他人進入交互。

Answer 2

爲了能見度，考慮某種板子。我們最近開始使用Kanban（Lean的一部分），到目前爲止，它似乎是一個積極的力量。它試圖平衡工作負荷（或流量）。

對於休假/計劃，看板是一種選擇。其他包括XP和Scrum。恕我直言，Scrum更多的是一種管理理念，而XP是一種開發方法。 Planning Extreme Programming絕對值得一讀。

客戶（您的SR）將一直試圖繞過開發流程。 「難道你不能把這個故事放到迭代中間嗎？」您需要獲得管理層的支持，並支持您選擇的任何方法。對於SR，好處是：（1）他們可以優先處理故事（功能請求）;（2）他們可以更好地瞭解他們的故事何時完成。

Answer 3

我會專注於您目前的問題與挑選整個新流程。如果您的主要問題涉及工作跟蹤，請安裝時間跟蹤系統。它將顯示開發人員在哪裏花費時間，反過來它也可能顯示每個項目的利潤/損失。

一般來說，慢慢地演變你的過程，但不斷。監控你的問題和其中一些問題的實際成本，以鼓勵自己只解決那些耗費金錢或士氣的問題，而不僅僅是煩惱老闆的問題。

提示：在企業中實施任何類型的度量標準可能很困難。確保它不帶有太大的粘性，並且建立起來的方式不會讓開發人員和銷售代表在相同的方向上游戲數據。根據您的商業模式和他們的每筆交易，SR可能傾向於推高或推低小時數。對於開發者來說，他們的偏見往往會表明他們比他們更忙，直到有人指出他們看起來不像同齡人那麼熟練或有效。

添加提示：如果這些指標不會用於改變人，請盲目收集它們（所以參與者不會知道）。你可能會得到最準確的信息。

Answer 4

在遇到類似情況時，我會告訴您我們的版本以及我們如何慢慢擴大規模。一般情況下，就像您的情況一樣，我們的PM管理開發人員的時間。我們一直在盲目地做這件事，但現在正在使用軟件，它允許我們優先考慮開發者時間並公開顯示給公司的每個人。我們所有的PM都在同一棟大樓內，因此他們能夠交流並決定開發人員需要共同努力的內容。

然而，這個過程仍然是極其有缺陷的。正如你所說，早上會議可以改變優先次序，但通常只有在項目出現問題時纔會如此。我個人認爲開發人員PM可以解決很多問題，但是由於我們的一些開發人員的遠程工作，這可能對我們有很大的幫助。這裏是我的建議，讓你的下午進程得到控制：

• 文件的一切！（據估計，實際花費的時間，以及每個個體目前的工作）的PM之間的輕鬆協作/離散事件
• 給開發商一個優先級隊列（我喜歡這不必問PM的
• 使用用戶/開發者友好的軟件什麼項目需要未來進行，而不是僅僅通過下一個任務）
• 繼續分析您的工藝和替代領域的必要

我希望我有更多的信息，以提供有關往下壓線，但正如我說我我大概在同一個地方 - 所以我正在給下一個級別的提示。當然，除了小型企業之外，這種模式並不太合理，但它正在幫助我們現在向前邁進。