chapter 3 thu th p y u c u n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 3: Thu thâ?p yêu câ?u PowerPoint Presentation
Download Presentation
Chapter 3: Thu thâ?p yêu câ?u

Loading in 2 Seconds...

play fullscreen
1 / 68

Chapter 3: Thu thâ?p yêu câ?u - PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on

Chapter 3: Thu thập yêu cầu. Requirements Elicitation Or Requirement gathering. Nội dung. Thu thập yêu cầu (Requirement elicitation) là gì? Các kỹ thuật thu thập yêu cầu Chọn lựa kỹ thuật thu thập yêu cầu Quy tắc nghiệp vụ và chính sách

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 3: Thu thâ?p yêu câ?u' - hope


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 3 thu th p y u c u

Chapter 3: Thu thập yêu cầu

Requirements Elicitation

Or

Requirement gathering

n i dung
Nội dung
  • Thu thập yêu cầu (Requirement elicitation) là gì?
  • Các kỹ thuật thu thập yêu cầu
  • Chọn lựa kỹ thuật thu thập yêu cầu
  • Quy tắc nghiệp vụ và chính sách
  • Quản lý mối quan hệ khách hàng
slide3
A major aspect of requirements engineering is the elicitation of requirements from the customer.
requirement elicitation
Requirement elicitation
  • Elicitation là quá trình xác định yêu cầu và làm giảm sự khác biệt giữa các nhóm có liên quan để rút ra các yêu cầu đáp ứng được nhu cầu của tổ chức hay dự án trong khi vẫn giữ được các ràng buộc.
  • Có rất nhiều kỹ thuâṭ elicitation khác nhau
ph n bi t gi a elicitation va analysis
Phân biệt giữa elicitation và analysis
  • Elicitation là sự tương tác với stakeholders để nắm bắt được nhu cầu của họ.
  • Analysis là tinh chỉnh (refinement) nhu cầu của stakeholder thành các đặc tả sản phẩm chính thức.
t m quan tro ng
Tầm quan trọng
  • Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication-intensive aspect of software development.
  • Elicitation chỉ có thể thành công thông qua mối quan hệ hợp tác giữa customer và đội development .
ca c ky thu t thu th p y u c u
Các kỹ thuật thu thập yêu cầu
  • Document Sampling
  • Interviewing
  • Survey and observation
  • Questionaires
  • Workshop and Brainstorming
  • JAD (Joint Application Development) sessions

Ba kỹ thuật phổ biến nhất là Document sampling, interviewing và questionaires

ca c ky thu t thu th p y u c u1
Các kỹ thuật thu thập yêu cầu
  • Assignment 13: Document Sampling
    • Nhóm???
  • Assignment 14: Questionaires
interviewing
Interviewing
  • Là kỹ thuật trực tiếp và đơn giản
  • Câu hỏi context-free có thể giúp hoàn thành các phỏng vấn bias-free interviews
  • Then, it may be appropriate to search for undiscovered requirements by exploring solutions.
  • Tập hợp lại 1 số nhu cầu chung sẽ tạo “requirements repository”để dùng trong suốt dự án
  • Questionnaire không thể thay thế cho interview.
interviews
Interviews
  • Interview cá nhân hay nhóm các người dùng là nguồn thu thập yêu cầu kiều truyến thống cho cả sản phẩm thương mại cũng như các hệ thống thông tin.
  • Tìm hiểu cách nghĩ của người dùng khi họ trình bày các yêu cầu, rút ra các quyết định có tính logic của người dùng. Để mô tả quá trình đưa ra các quyết định logic có thể dùng flowchart và cây quyết định (decision tree) bảo đảm mọi người hiểu được tại sao hệ thống phải thực hiện các chức năng này.
  • Đôi khi các yêu cầu của người dùng phản ánh các quy trình nghiệp vụ đã lỗi thời hay không hiệu quả nữa và không nên đưa vào hệ thống mới.
interview context free question
Interview: Context free question
  • Là câu hỏi có thể dùng cho bất kỳ dự án nào đang khảo sát.
  • Là các câu hỏi chung về bản chất của dự án và môi trường mà sản phẩm sẽ được dùng.
  • Được dùng trong mỗi giai đoạn khác nhau của cuộc phỏng vấn.
ca c da ng c u ho i context free
Các dạng câu hỏi context free
  • Opening Questions: khi bắt đầu phỏng vấn, câu hỏi context free sẽ giúp khởi đầu cuộc phỏng vấn và vượt qua được các lúng túng ban đầu.
  • Redirection: có thể được dùng để chuyển hướng phỏng vấn khi nội dung cuộc đối thoại ra ngoài chủ đề hay quá sâu không cần thiết, đưa cuộc đối thoại về lại vị trí trung lập để hướng đến chủ đề mong muốn.
  • Closing: dùng để kết thúc cuộc phỏng vấn “Is there anything else you would like to tell me?”  cho người được phỏng vấn (interviewee) cơ hội được chủ động và chia xẽ các thông tin khác.
la m th na o th c hi n interview
Làm thế nào đề thực hiện interview
  • Phải chuẩn bị một danh sách các câu hỏi context free trước khi phỏng vấn. Có thể đặt cùng 1 hay 2 câu hỏi cho người được phỏng vấn (interviewee) để tìm ra điểm khác biệt.
  • Thông qua câu hỏi context free để giúp người tham gia phỏng vấn có hiểu biết chung
  • Không bận tâm vào câu trả lời “right/wrong”. Nhiều câu hỏi dùng gây ấn tượng hơn là để thu nhận dữ liệu, dùng để thu thập chi tiết hơn yêu cầu đang khảo sát.
interview show time
Interview: Show time

Nên dành thời gian để:

  • Establish Customer or User Profile
  • Assessing the Problem
  • Understanding the User Environment
  • Recap the Understanding
  • Analyst’s Inputs on Customer’s Problems
  • Assessing Your Solution (if applicable)
technique requirements workshop
Technique: Requirements Workshop
  • Có thể là kỹ thuật năng động nhất để thu thập yêu cầu.
  • Tập hợp tất cả các stakeholder chính cùng với nhau trong 1 giai đoạn tuy ngắn nhưng rất tập trung.
  • Sử dụng facilitator có kinh nghiệm từ bên ngoài trong quản lý yêu cầu có thể bảo đảm cho sự thành công của workshop.
  • Brainstorming là phần quan

trọng nhất của workshop.

preparing for the workshop
Preparing for the workshop
  • Bảo đảm có sự tham gia của các stakeholder phù hợp
  • Công tác hậu cần (Logistics)
    • Cố và tránh luật Murphy’s law
    • Bao gồm cả du lịch, giải trí và ăn nhẹ buổi chiều (“afternoon sugar filled snacks.”)
  • Tài liệu đầu buổi hội thảo (Warm-up materials)
    • Thông tin của buổi hội thảo
    • Out-of-box thinking preparation
trong lu c workshop
Trong lúc Workshop
  • Để dễ dàng giao tiếp, nên sử dụng từ ngữ của miền ứng dụng thay vì bắt khách hàng hiểu các thuật ngữ máy tính.
  • Nên đưa các thuật ngữ nghiệp vụ vào glossary để các thành viên cùng dùng chung các định nghĩa
  • Customer nên hiểu là việc thảo luận về chức năng không hẳn là 1 nhiệm vụ phải có trong sản phẩm.
trong lu c workshop1
Trong lúc workshop
  • Kỹ năng để dẫn dắt các cuộc thảo luận phân tích yêu cầu phải có được từ kinh nghiệm, tập huấn phỏng vấn, hỗ trợ nhóm, giải quyết xung đột, ..
  • Người phân tích phải khảo sát cẩn thận (probe) nhu cầu thực sự của khách từ 1 loạt các yêu cầu mà khách hàng đề ra.
    • Hỏi "why" nhiều lần
    • Hỏi các câu hỏi mở (open-ended question) để giúp hiểu được quy trình nghiệp vụ hiện hành của người dùng và để thấy hệ thống mới có thễ cải thiện việc thực thi như thế nào.
    • Điều tra tìm hiểu (Inquire) những thay đổi xảy ra cho người dùng khi hệ thống mới được đưa vào sử dụng.
    • Thử đóng vai trò người tập sự (apprentice) học hỏi từ người dùng chính.
vai tro cu a requirement analyst
Vai trò của requirement analyst
  • Người phân tích yêu cầu (Requirements analyst) thường tham gia các hội thảo phân tích yêu cầu.
  • Facilitator đóng vai trò chính trong việc lên kế hoạch hội thảo, chọn người tham dự, dẫn dắt người tham dự để kết thúc thành công hội thảo.
  • Khi đội bắt đầu các phương pháp mới để phân tích yêu cầu nên có một facilitator ngoài đội hướng dẫn các workshop khởi đầu, nhờ đó các analyst có thể góp phần nhiều hơn vào các cuộc thảo luận.
role of the facilitator
Role of the Facilitator
  • Xác lập 1 phong cách chuyên nghiệp và mục tiêu rõ ràng cho cuộc họp
  • Bắt đầu và kết thúc cuộc họp đúng giờ
  • Xác lập và nhấn mạnh các quy tắc của cuộc họp.
  • Giới thiệu mục tiêu và lịch trình của cuộc họp
  • Điếu hành cuộc họp và giữ cho mọi người luôn quan tâm theo dõi
  • Tạo điều kiện khi cần biểu quyết nhất trí nhưng tránh tham gia vào.
  • Bảo đảm mọi stakeholder đều có quyền phát biểu góp ý trong cuộc họp
  • Kiểm soát các hành vi gây rối và không phù hợp.
workshop agenda
Workshop Agenda
  • Xây dựng lịch trình (agenda) trước cho buổi hội thảo và công bố nó cùng với các tài liệu chuẩn bị trước của workshop.
  • Giữ ổn định cho buổi hội thảo rất quan trọng, cố gắng theo đúng lịch trình, nhưng cũng không nên tuân theo nó quá cứng nhắc, nhất là khi đang có thảo luận sôi nổi.
  • Đặt ăn trưa (light working lunch).
running the workshop
Running the Workshop
  • Cư xử lịch thiệp và vui vẻ
    • Không nên “attack” thành viên khác.
    • Không nên diễn thuyết nhiều quá.
    • Đừng quay lại muộn sau khi giải lao
  • Thẻ phạt (Workshop tickets)
    • Cấp cho mỗi stakeholder một trong 3 loại thẻ phạt sau: đi muộn, gian lận (“cheap shot”) , phát biểu dài dòng (“soap box”)
    • Facilitator cũng có thể bị nhận thẻ phạt.
    • If you do not have a ticket create a fund to add to, like $1 to pot for after workshop activities.
m t s nguy n t c c ba n workshop tha nh c ng
Một số nguyên tắc cơ bản để workshop thành công
  • Establish ground rules
  • Stay in scope
  • Use parking lots to capture items for later consideration
  • Timebox discussions
  • Keep the team small and include the right participants
  • Keep everyone engaged
workshop problems and suggestions
Workshop Problems and Suggestions
  • Facilitator phải theo dõi thời gian nghỉ giải lao và phát bất kỳ ai đến muộn,
  • Mỗi người chỉ được 5 phút để phát biểu.
  • Facilitator khuyến khích mọi người sử dụng 5 phút được phát biểu và ủng hộ các sáng kiến.
  • Dùng vé phạt (“Cheap Shot Tickets”) và buộc trả chi phí
  • Nên tổ chức ăn nhẹ buổi trưa, giải lao buổi chiều, sắp xếp lại chỗ ngồi
  • Quản lý thời gian
    • Khó bắt đầu lại sau nghỉ giải lao và ăn trưa.
    • Stakeholders quan trọng thường quay lại muộn.
  • Giành quyền phát biểu quá lâu,
  • Thiều dữ liệu từ stakeholders
  • Phát biểu tiêu cực, hành động nhỏ nhen, gây gỗ
  • Mệt mỏi thiếu sinh lực sau khi ăn trưa
product position statement
Product Position Statement
  • For [target end user]
  • Who wants/needs [compelling reason to buy]
  • The [product name] is a [product category]
  • That provides [key benefit].
  • Unlike [main competitor],
  • The [product name] [key differentiation]
brainstorming sessions
Brainstorming Sessions
  • Thường được dùng để phân tích tìm các yêu cầu ban đầu của stakeholder đối với sản phẩm. Phương pháp này được thực hiện với nhiều stakeholders hay customers và các phiên giao tiếp này thường được dẫn dắt bởi 1 facilitators có kinh nghiệm, mỗi phiên (session) thường kéo dài tối đa 1 hay 2 ngày.
  • Mục tiêu của brainstorming session là đưa ra các ý tưởng mới hay các tính năng của sản phẩm trong 1 thời gian rất ngắn.
brainstorming sessions1
Brainstorming Sessions
  • Khi xác định ý tưởng, điều quan trọng là phải tránh xung đột, e.g., một thành viên chê bài ý tưởng của người khác. Nếu có thành viên lâu niên (senior) tham gia session thì điều quan trọng là giữ cho họ không được đe dọa các thành viên ít kinh nghiệm hơn họ.
vai tro cu a facilitator
Vai trò của facilitator

Vai trò của facilitator rất quan trọng, quyết định session có thành công hay không?

brainstorming
Brainstorming
  • Mục tiêu và thời gian của brainstorming session cần phải được thỏa thuận trước bởi tất cả các thành viên, tốt nhất là ngay trước khi bắt đầu session.
  • Session nên bắt đầu với việc tự do đưa ra các ý kiến, tạo thành 1 tập hợp các kiến nghị về sản phẩm. Nên dùng “sticky notes” và dán vào bảng.
tabular elicitation technique
Tabular Elicitation Technique
  • Việc dùng bảng có thể giúp nắm bắt được yêu cầu của stakeholder rõ ràng và chặt chẽ hơn.
  • Có 2 loại bảng hay được dùng:
    • Decision table
    • State table
decision table
Decision table
  • Bảng quyết định (Decision table) thông dụng nhầt khi:
    • Tập các điều kiện là rời rạc, có thể được xác định bằng “yes” hay “no,”
    • Hành động sẽ thực hiện khi các điều kiện thỏa mãn
    • Tập các rule khi tập các điều kiên là duy nhất và tương ứng với mỗi rule là 1 hành động.
decision table1
Decision table
  • Mỗi hàng biều diễn một condition, mỗi cột biểu diễn 1 rule, i.e,. Một điều kiện và 1 tập các hành động tương ứng.
  • Khi cần phân tích bản phác thảo các yêu cầu lúc đầu của stakeholder thì bảng quyết định được dùng rất hiệu quả để nắm bắt các quy tắc nghiệp vụ. (business rule)
state tables
State tables
  • Được dùng khi đối tượng đang khảo sát có thể có các trạng thái khác nhau ở các thời điểm khác nhau và các sự kiện đơn giản nhưng rõ ràng nào đó có thễ kích khởi việc đổi từ trạng thái này sang trạng thái khác.
  • State machine: là 1 đối tượng mà việc chuyển đổi trạng thái chỉ dựa vào các sự kiện rời rạc và số trạng thái của đối tượng đã biết trước.
  • Ví dụ: bảng người nộp thuế (taxpayer) không phải là bảng trạng thái vì chỉ có 1 trạng thái duy nhất là “about to pay taxes.”
state table
State table
  • State tables chỉ ra hành vi của state machine, thường có 1 trạng thái khởi đầu và một tập các trạng thái mà đối tượng sẽ trải qua và cuối cùng là trạng thái exit thành công hay 1 trong các trạng thái “error”. Mỗi lần thay đổi trạng thái đều có liên quan đến 1 hay nhiều sự kiện (event)
vi du
Ví dụ

Button

ph ng pha p i u tra survey ethnographic techniques
Phương pháp điều tra (survey)-Ethnographic Techniques
  • Một số phương pháp điều tra được dùng rất nhiều để đánh giá các yêu cầu thị trường, mối quan tâm về sản phẩm.
  • Khi số lượng khách hàng tương đồi lớn, có thể thực hiện thống kê trên kết quả điều tra đề đo lường mức độ quan tâm của khách hàng đối với các tính năng của sản phẩm.
  • Một trong các phương pháp điều tra thông dụng nhất để phân tích mối quan tâm của khách hàng là Kano modeling.
ph ng pha p kano modeling
Phương pháp Kano modeling
  • Cung cấp ba biến để đo lường mối quan tâm của khách hàng:
    • One-dimensional quality
    • Expected quality
    • Attractive quality.
ph ng pha p kano modeling1
Phương pháp Kano modeling
  • One-dimensional (hay linear quality) được áp dụng ở những nơi mà tính năng của sản phẩm tăng tuyến tính cùng với 1 số ngữ cảnh nào đó của tính năng đó. Ví dụ tính tiết kiệm điện năng của tủ lạnh, nếu tính năng này càng hiệu quả thì khả năng khách hành đặt mua càng nhiều.
ph ng pha p kano modeling2
Phương pháp Kano modeling
  • Expected quality là tính năng bắt buộc phải có đối với sản phẩm nào thànnh công trên thị trường.
  • Attractive quality là tính năng không được mong đợi nhưng bổ sung vào yếu tố tâm lý (emotional appeal) của sản phẩm. Ví dụ camera trong mobile là attractive quality trong nhiều năm trước nhưng bây giờ là expected quality trong hầu hết các thị trường.
ph ng pha p kano modeling3
Phương pháp Kano modeling
  • Một đo lường khác là yêu tố văn hóa. Ví dụ, ở Mỹ hầu hết các khách hàng đều muốn việc mua xe ô tô được chuyển giao tự động, trong khi đó ở châu Âu việc chuyển giao tự động là bình thường.
  • Kano modeling được chấp nhận rộng rãi;một số công cụ quản lý requirements engineering có sẵn chức năng Kano analysis.
joint application development jad1
Joint Application Development (JAD)
  • JAD được như 1 kỹ thuật để phát triển yêu cầu của 1 hệ thống và trong các giai đoạn đầu của dự án phần mềm.
  • Mục đích: tập hợp MIS và người dùng cuối trong cơ chế của 1 workshop, để cùng thống nhất (consensus) với nhau các yêu cầu của hệ thống.
jad va ph ng pha p cu
JAD và phương pháp cũ
  • Bằng cách kết hợp các workshop và nhấn mạnh tinh thần cộng tác (spirit of partnership)
  • Bằng cách kết hợp công nghệ và nhu cầu nghiệp vụ trong 1 quy trình thống nhất, lặp lại và hiệu quả
  • JAD giúp thu thập yêu cầu hệ thống nhanh hơn, chính xác hơn các phương pháp cổ điển.
  • giảm 1 cách đáng kể thời gian, chi phí và lỗi cho dự án.
d a n na o n n du ng jad
Dự án nào nên dùng JAD
  • Liên quan đến nhiều nhóm người dùng khác nhau
  • Rất quan trọng đến sự thành công trong tương lai của tổ chức.
  • Là dự án mới của tổ chức
  • Có trở ngại trong dự án cũ hay mối quan hệ giữa hệ thống và tổ chức
ai tham d jad
Ai tham dự JAD?
  • Executive Sponsor
  • Facilitator
  • User ( từ 3 – 5)
  • IT Representative
  • Scribe ( 1 hay 2)
  • Observer ( 2 hay 3)
executive sponsor
Executive Sponsor
  • Là người của tổ chức khách hàng và có quyền quyết định tối cao về dự án (CEO, người lãnh đạo dự án)
  • Facilitator làm việc với sponsor để khởi động dự án, nhưng sponsor mới là người quyết định chính, không phải là facilitator.
tra ch nhi m cu a executive sponsor
Trách nhiệm của Executive sponsor
  • Nhận trách nhiệm cao nhất về các chức năng của hệ thống.
  • Giải quyết các xung đột về chính sách bằng cách đưa ra các quyết định cuối
  • Công bố kết quả của quy trình JAD.
  • Xác lập vision cho dự án
  • Bảo đảm cho đội dự án tiếp cận và làm việc được với các chuyên gia nghiệp vụ.
  • Tạo ra sự hợp tác và hỗ trợ của khách hàng đối với đội dự án
vai tro cu a executive sponsor
Vai trò của executive sponsor
  • Làm cho khách hàng tin tưởng vào quy trình JAD
  • Trong lúc định hướng JAD, sponsor quan tâm đến cả đội, biểu lộ thái độ hợp tác và hỗ trợ.
  • Sponsor cũng tỏ ra tin cậy vào facilitator, giảm thiêu được sự đối kháng ban đầu của đại diện khách hàng.
  • Sponsor chỉ là thành viên của JAD và thường không tham dự vào các cuộc họp JAD, chỉ cần ghé qua để biểu lộ sự quan tâm hợp tác.
vai tro cu a ca c tha nh vi n jad
Vai trò của các thành viên JAD
  • Vai trò của facilitator
  • Vai trò của scribe

Assignment??

ca c quy t c nghi p vu do kha ch ha ng xa c i nh customer specific business rules
Các quy tắc nghiệp vụ do khách hàng xác định Customer-Specific Business Rules
  • Business rules là loại đặc biệt của yêu cầu khách hàng.
  • Khác với các nhu cầu cố định của khách hàng, các quy tắc nghiệp vụ dùng để:
    • mô tả việc thực thi chính sách của khách hàng
    • có thể bị thay đổi bởi chính khách hàng sau khi sản phẩm được phân phối.
quy t c nghi p vu va chi nh sa ch
Quy tắc nghiệp vụ và chính sách
  • Một tổ chức có thể ban hành, chỉnh sửa hay hủy bỏ các quy tắc nghiệp vụ mà các quy tắc này sẽ chi phối và hướng dẫn tổ chức.
  • Chính sách (business policy) là yếu tố quản lý, không trực tiếp được thi hành mà dùng để hướng dẫn tổ chức hoạt động. Chính sách không đòi hỏi phải diễn tả có cấu trúc (không cần thuật ngữ tiêu chuẩn) như là quy tắc nghiệp vụ.
vi du1
Ví dụ
  • “Bank customers should not be able to make too many bank withdrawals in a single day or withdraw more than a certain amount of money in a fixed period of time; the maximum amount being based on their total account value and history.”

Đây là chính sách hay quy tắc nghiệp vụ????

why are customer specific business rules important
Why Are Customer-Specific Business Rules Important?
  • Các quy tắc nghiệp vụ do người dùng xác định phải tách riêng khỏi các yêu cầu thông thường, vì chúng không thực sự là yêu cầu.
  • Yêu cầu khách hàng có thể được suy diễn từ quy tắc nghiệp vụ, các yêu cầu có thể khác với quy tắc mà chúng được suy diễn.
why are customer specific business rules important1
Why Are Customer-Specific Business Rules Important?
  • Chính quy tắc nghiệp vụ do khách hàng xác định dùng để thực thi chính sách (policy) của công ty, nhưng quy tắc nghiệp vụ có thể thay đổi sau khi hệ thống đã được phân phối.

 Nên xây dựng hệ thống sao cho khách hàng có khả năng thay đổi quy luật mà không làm cho hệ thống bị sửa đổi theo.

vi du2
Ví dụ
  • Policy: The hospital shall be able to define the difference between adult and child patients for check-in and medical records purposes.
vi du3
Ví dụ
  • Rule: Any patient under the age of 14 checking in shall be considered a child. When a child checks into the hospital, depending on the hospital’s business policy, a parent or guardian may have to accompany the child and sign all the admission forms. Detailed rules explain under what circumstances (e.g., an accident, emergency, or life-threatening situation) a child may be checked in without a parent’s or guardian’s consent.
vi du4
Ví dụ
  • Requirement: A facility shall be provided with the system such that the hospital check-in process for adults and children can be changed by hospital administrators without the need for system or software modifications.
managing the customer relationship
Managing the Customer Relationship
  • Quản lý mối quan hệ khách hàng là quan trọng trong suốt chu kỳ dự án, và là chủ yếu trong suốt quá trình phân tích.
  • Cả người tiêu dùng lẫn nhà cung cấp cần phải hiểu biết về sản phẩm.
  • Cần tiếp tục tương tác với khách hàng để duy trì mối quan hệ; e.g., thông báo cho họ tin xấu sớm tốt hơn là báo muộn. Tốt hơn là nên giao tiếp thường xuyên với khách hàng có thể tránh được các rắc rối nghiêm trọng có thể xảy ra sau đó.
managing the customer relationship1
Managing the Customer Relationship
  • Cần phải bảo đảm được sự hợp tác của khách hàng để có thể thu nhận được chuyên môn nghiệp vụ (domain expertise).
  • Ví dụ: nếu 1 dự án có lịch biểu cố định và mối quan hệ với khách hàng không được tốt, vì vậy việc tiếp nhận về chuyên môn bị hạn chế, dẫn đến kết thúc dự án bị quá hạn.

 It is our experience that constant communication with the customer