Đáp: Tôi muốn kể cho bạn một câu chuyện thực về một nông dân nghèo tên là Fleming. Một hôm, khi đang làm việc trên mảnh đất của mình ông ta nghe thấy tiếng kêu cứu từ hồ cạnh đó. Ông ta chạy tới hồ và thấy một cậu bé đang la hét và vật lộn khỏi chìm. Anh nông dân Fleming cứu cậu bé thoát cái chết khủng khiếp. Ngày hôm sau, một chiếc xe xa hoa tới đỗ cạnh nhà người nông dân nghèo này. Một quí ông bước ra, tự giới thiệu mình là bố của cậu bé mà anh nông dân Fleming đã cứu. “Tôi muốn hậu tạ ông,” quí ông này nói. “Ông đã cứu mạng sống con trai tôi.”

“Không, tôi không thể nhận tiền trả cho điều tôi đã làm đâu, mọi người đều làm thế cả. Ông không cần cám ơn tôi,” người nông dân đáp.

Vào lúc đó, cậu con trai riêng của người nông dân này về tới cửa nhà mình. “Con ông đấy à?” quí ông này hỏi. “Vâng,” người nông dân tự hào đáp.

“Để tôi cho nó một học bổng đi học. Nếu con ông cũng tốt như ông thì nó sẽ trưởng thành là một người mà ông có thể tự hào được.”

Và đó là điều ông ấy đã làm. Nhiều năm sau, con của anh nông dân Fleming tốt nghiệp trường Y Dược St. Mary ở London, và tiếp tục trở nên nổi tiếng trên toàn thế giới là Ngài Alexander Fleming, người đã phát minh ra Penicillin. Câu chuyện không dừng ở đó, nhiều năm sau đứa con của quí ông kia bị mắc bệnh viêm phổi. Cái gì đã cứu anh ta? – Penicillin.

Tên của quí ông đó là Quận công Randolph Churchill và tên của con ông ấy là Ngài Winston Churchill.

Cho nên “Có đi có lại” và đó là lí do tại sao tôi tin giáo dục và chia sẻ kinh nghiệm với người khác là món quà lớn nhất.

Hỏi: Liệu có thể dùng Agile trong cải tiến qui trình thay cho CMMI không?

Đáp: Agile KHÔNG PHẢI là khuôn khổ cho cải tiến phần mềm mà là phương pháp phát triển phần mềm, đặc biệt cho các dự án nhỏ nơi có thể có các yêu cầu không được xác định rõ nhưng phải chuyển giao nhanh. Agile KHÔNG PHẢI là giải pháp cho mọi thứ và bạn phải xác định liệu phương pháp này là thích hợp hay không. Bạn cần có vài điều kiện cho phương pháp này làm việc:

Thứ nhất, vì yêu cầu chưa được xác định rõ, điều mấu chốt là khách hàng dành thời gian cùng tổ để giúp xác định các yêu cầu trong toàn dự án. Nếu khách hàng bận và không thể tham gia thì bạn không nên chọn phương pháp này.

Thứ hai, phương pháp này yêu cầu các thành viên tổ phải là những công nhân có kĩ thuật cao và có kỉ luật. Họ phải làm việc có hiệu quả và hiệu lực trong môi trường thay đổi nhanh bằng việc hoàn thành nhiều vai trò và sẵn lòng tiến bước khi cần để đạt tới mức độ mong muốn về hiệu năng và chất lượng. Không có những người có kinh nghiệm tốt, phương pháp agile sẽ không có tác dụng tốt.

Thứ ba, bản chất của phương pháp agile là tự tổ chức cho nên điều căn bản đối với các thành viên tổ là cởi mở và tự do chia sẻ thông tin và giải pháp. Để cách tiếp cận này thành công, mọi thành viên tổ phải biết cách làm việc cùng nhau. Họ phải biết cách trao đổi rõ ràng và tin cậy lẫn nhau trong hoạt động hàng ngày. Không có việc hợp tác có tổ chức mạnh, bạn không nên dùng phương pháp agile.

Hỏi: Cách tốt nhất để triển khai các nhiệm vụ cải tiến được làm tài liệu trong bản kế hoạch hành động là gì?

Đáp: Để triển khai nhiệm vụ cải tiến, có vài cách tiếp cận nhưng sau đây là phương pháp mà tôi thấy có tác dụng nhất trong nhiều tình huống:

1) Có tổ hành động qui trình – Process Action Team (PAT) bao gồm vài người (2- 4) để xác định giải pháp cho vấn đề được nhận diện trong bản kế hoạch hành động (Pha xác định).

2) Cùng tổ này có thể thử nghiệm giải pháp trong 2 tới 4 dự án để xem liệu nó có tác dụng không (Thử & Sai). Tuy nhiên, rủi ro là tổ gốc có thể bị thiên vị. Do đó, tôi gợi ý tổ nên thay thế một hay hai người nguyên gốc bằng người mới trong pha thử nghiệm. Giải pháp có thể được thử nghiệm trong cùng dự án nơi tổ bắt đầu hay trong dự án khác hay là tổ hợp cả hai (tôi thích việc tổ hợp hơn).

Xin lưu ý rằng mặc dầu có vài miền thử nghiệm, giải pháp phải vẫn còn trung thành như bản gốc nhất có thể được, đừng vội sửa đổi giải pháp. Chìa khoá là xem liệu giải pháp gốc có làm việc không hay cần thay đổi. Nếu nó cần thay đổi thì ghi lại chi tiết của điều cần được thay đổi và nếu nó thực sự cần thay đổi lớn thì có thể giải pháp gốc không được xác định tốt hay quá tổng quát.

3) Tổ thử nghiệm giải pháp có thể xác định lại nó dựa trên kết quả thử nghiệm hay thay thế một thành viên tổ mới trong pha này. Kết quả của pha này là bản hướng dẫn được làm tài liệu, thủ tục để giải quyết vấn đề (chẳng hạn thủ tục để làm kiểm điểm mã, hướng dẫn lập kế hoạch dự án v.v.)

4) Nếu tổ coi giải pháp là không được xác định rõ, bạn có thể quay lại bước 2, nhiều thử nghiệm và làm mịn thêm trước khi thể lệ hoá. Dữ liệu cần được thu thập ở đây. Xin lưu ý rằng không có giải pháp hoàn hảo, đừng cố vì hoàn hảo.

5) Giả sử mọi thứ đều làm việc tốt thì bắt đầu qui trình thể lệ hoá như sau:

a) Thông báo cho SEPG rằng bạn có giải pháp.

b) SEPG sẽ kiểm điểm để trắc nghiệm rằng nhiệm vụ này là đầy đủ và sẵn sàng được dùng chung.

c) SEPG sẽ lập kế hoạch trao đổi cho nhiệm vụ này.

d) SEPG sẽ ban hành bản ghi nhớ để công bố về nhiệm vụ này.

e) SEPG sẽ thu xếp huấn luyện cho tổ chức (Tất cả các thành viên đề xuất giải pháp này, thử nghiệm giải pháp và duyệt giải pháp nên huấn luyện người khác, KHÔNG PHẢI thành viên của SEPG)

f) Sau khi huấn luyện xong, SEPG sẽ điều phối việc dùng giải pháp mới bên trong tổ chức về tính hiệu quả và thu thập dữ liệu hỗ trợ cho nó.

g) Nếu nó được dùng một cách hiệu quả, SEPG sẽ đề đạt một chính sách cho quản lí cấp cao để tuyên bố giải pháp này là một phần của “qui trình ưa chuộng” được dùng từ bây giờ trở đi.

SEPG sẽ tiếp tục điều phối việc dùng “qui trình mới” cho những cải tiến liên tục mà có thể chỉ ra nhiều chỉnh sửa hơn khi nhiều người hơn dùng chúng. SEPG có thể gợi ý cho tổ rằng “qui trình mới” là tốt nhưng có thể cần hướng dẫn và đó là miền khác cho việc cải tiến (liên tục). Lưu ý rằng việc thể lệ hoá bao giờ cũng mất thời gian lâu hơn. Pha này yêu cầu rằng SEPG phải tích cực tham gia. Nhớ rằng để qui trình được thể lệ hoá đầy đủ, nó phải được Xác định, được Làm tài liệu, được Dùng, được Đo, được Trắc nghiệm, được Bảo trì (Huấn luyện) và liên tục được Cải tiến (làm nó nhiều lần).

Hỏi: Phần lớn các qui trình trong CMMI yêu cầu rằng chúng được phát triển theo thủ tục được làm tài liệu. “Thủ tục được làm tài liệu” được chi tiết thế nào?

Đáp: Câu trả lời là: Đủ chi tiết để hữu dụng, nhưng không quá chi tiết để thành vô dụng. Vấn đề ở đây là khuôn khổ CMMI để nhiều linh động dưới dạng mức độ chi tiết. Có một số nhân tố ảnh hưởng tới cách bạn làm tài liệu qui trình như kích cỡ tổ chức của bạn, kích cỡ dự án, công cụ mô tả qui trình, ngân sách, và văn hoá tổ chức. Với tổ chức nhỏ, vài trang giấy có thể là đủ nhưng với tổ chức lớn hơn, nhiều trang có thể là câu trả lời đúng.

Hỏi: Yêu cầu đối với tác nhân thay đổi của SEPG là gì?

Đáp: Tác nhân thay đổi có triển vọng nên:

Thông cảm:

Nỗ lực của tác nhân thay đổi được hướng tới các thành viên trong việc chuyển đổi tới mức độ là tác nhân này có kinh nghiệm làm việc trong hay với tổ chức của các thành viên và có thể xây dựng quan hệ với tổ chức đó, người này có khả năng tốt hơn để thông cảm với tình huống của họ.

Đáng tin:

Tác nhân thay đổi phải là người đáng tin về mặt công nghệ và cá nhân. Người này là người kiên trì trong đối diện với thất bại ban đầu. Người này phải thông thái về công nghệ phần mềm cần được thực hiện. Người này phải có lịch sử thành công trong công việc chuyển đổi công nghệ phần mềm khác hay các dự án phức tạp tương tự cần tới tri thức chuyên gia cả về kĩ thuật và quan hệ con người.

Sắc sảo chính trị:

Tác nhân thành công phải có khả năng tiếp cận tới người trong tổ chức của các thành viên, người quan tâm tới thay đổi, người có thể chống lại nó, người sẽ có nguồn nhân lực giúp cho thay đổi và người sẽ có nhân lực để chấm dứt thay đổi.

Người nhận diện vấn đề và người giải quyết vấn đề:

Tác nhân thay đổi thành công phải có khả năng phân tích tình huống và tìm ra căn nguyên của vấn đề. Người này cũng phải có khả năng xem xét nhiều công nghệ như các giải pháp có thể cho vấn đề của các thành viên. Người này phải có khả năng nhận diện và hiểu nguồn của chống đối tiềm năng, và dịch điều này thành phản hồi cho người phát triển công nghệ phần mềm.

Người quản lí dự án quá khứ:

Cùng những kĩ năng vốn là quan trọng trong quản lí dự án thì cũng quan trọng trong quản lí nỗ lực chuyển đổi. Tác nhân thành công có hồ sơ ghi lại đã được chứng minh là người lập kế hoạch dự án tốt. Người đó làm việc trước và trong khi chuyển đổi để dự đoán và chẩn đoán các vấn đề chuyển giao công nghệ phần mềm và thực hiện. Người đó liên tục thu thập và hợp nhất dữ liệu về nỗ lực chuyển đổi và điều phối các tiêu chí cho việc chuyển đổi thành công. Người đó biết ai trong tổ chức có nhiều khả năng chấp nhận công nghệ phần mềm hơn, và người đó nhận diện mọi người trong tổ chức của người tham gia, người sẽ là người lãnh đạo dư luận tốt. Người đó làm sáng tỏ và thưởng cho sự hỗ trợ người đó nhận được từ những người trong cấp quản lí và từ các thành viên.

Thông thái về công nghệ phần mềm:

Tác nhân thay đổi thành công quen thuộc và thiện nghệ với công nghệ phần mềm được chuyển đổi.

Và trên hết, bạn phải là người trao đổi tuyệt hảo, người thương lượng có kĩ năng, nhà tư vấn, huấn luyện viên, người canh tân, người bảo vệ, người viết bài, thầy giáo, chính khách, nhà sản xuất, người biểu diễn và người quảng cáo.

Hỏi: CMMI có tác dụng thế nào trong dự án nhỏ kéo dài 3 tới 4 tháng và ít hơn 5 người?

Đáp: Nó có tác dụng tốt nếu bạn tính tới điều tôi gọi là “nghĩa thông thường.” Phần lớn thực hành CMMI có thể được sửa đổi cho khớp với nhu cầu. Nhớ, chìa khoá là giải pháp chứ không phải là tài liệu.

Hỏi: Tôi nghĩ mọi người lập trình đều nên học lập trình cực đoan để cho chúng ta có thể viết mã nhanh. Chúng tôi KHÔNG cần làm tài liệu cải tiến qui trình. Thầy nghĩ sao?

Đáp: Đầu tiên, phương pháp lập trình cực đoan là tốt cho các dự án nhỏ (2 tới 8 người) trong đó trao đổi giữa các thành viên là dễ dàng và từng người làm nhiều điều từ giao diện khách hàng cho tới thiết kế, viết mã, kiểm thử và đưa ra. Điều này có thể làm tốt trong môi trường dự án lớn có yêu cầu nỗ lực tích hợp. Lập trình cực đoan yêu cầu những cá nhân đa kĩ năng, người ‘có động cơ tự giác’, biết điều tra, phân tích, sáng tạo, có kĩ năng liên con người rất mạnh để hiểu vấn đề của khách hàng và có nhiều hoạt động có tổ chức có kỉ luật để đưa ra sản phẩm trong thời gian được phép. Tôi không chắc vài người lập trình có thể làm việc trong những tình huống lớn, phức tạp trong đó phần mềm đượcc phát triển và hỗ trợ ngày nay. Bạn cần hiểu rằng dự án phần mềm không chỉ là viết mã.

Hỏi: Tại sao chúng tôi cần cải tiến qui trình khi công nghệ đang thay đổi rất nhanh chóng? Tại sao không chỉ mua công nghệ là đủ?

Đáp: Công nghệ tiến hoá nhanh hơn nhiều so với khả năng của chúng ta giải quyết với thay đổi. Ngày nay, phần lớn công nghệ có tuổi đời quãng ba tới năm năm. Điều đó nghĩa là sự lỗi thời xuất hiện với tỉ lệ quãng 20% tới 40% hàng năm. Mua công nghệ sẽ KHÔNG giải quyết được vấn đề nghiệp vụ. Tổ chức thành công là tổ chức nhận ra điều không đổi duy nhất là thay đổi và liên tục cải tiến qui trình của mình.

Hỏi: Tôi nghĩ tôi có thể làm ra nhiều tiền trong việc học những điều mới và đi vòng hơn là làm việc như người kĩ sư phần mềm. Thầy nghĩ sao?

Đáp: Tôi bao giờ cũng tin rằng nhà chuyên môn phải tính tới trách nhiệm cá nhân về phát triển nghề nghiệp của mình. Điều dễ dàng cho mọi người là chuyển từ hãng nọ sang hãng kia và kiếm lương cao hơn qua mỗi lần chuyển. Dòng chảy tự do của những người phát triển là tốt bởi vì các ý tưởng mới chuyển vận quanh và dễ dàng cho công nhân tìm việc. Tôi cũng hiểu rằng với tỉ lệ tăng lên của thay đổi công nghệ và độ phức tạp sản phẩm, có khái niệm rằng giá trị của công nhân ít hơn điều họ biết chi tiết về nghiệp vụ nhưng nhiều hơn về việc họ có thể học nhanh chóng thế nào các điều mới. (như. Web, e-Business v.v.)

Tuy nhiên, tôi tin rằng đây là xu hướng ngắn hạn bởi vì một nhà chuyên môn phải hiểu chi tiết về mục đích và mục tiêu nghiệp vụ, cách cải tiến sản phẩm, thu được sự thoả mãn của khách hàng để kinh doanh theo cách tốt hơn. Trong khi mọi người có thể bắt lấy những công nghệ mới như Web, Java, v.v còn nhanh chóng hơn (vài tuần hay vài tháng), tôi tin rằng sẽ mất nhiều năm để học tất cả những chi tiết của miền nghiệp vụ, chi tiết thực hiện hệ thống, và cách kinh doanh được thực hiện. Đó là chọn lựa cá nhân và bạn biết điều đó rõ hơn tôi.

English version

Question: Why do we need to share things with other on process improvement so someday they may compete with us?

Answer: I would like to tell you a real story of a poor farmer name Fleming. One day, while working on his land he heard a cry for help coming from a nearby lake. He ran to the lake and found a boy screaming and struggling from drowning. Farmer Fleming saved the boy from what could have been a terrible death. The next day, an expensive car pulled up to the poor farmer house. A nobleman stepped out, introduced himself as the father of the boy Farmer Fleming had saved. “I want to repay you,” said the nobleman. “You saved my son’s life.”

“No, I can’t accept payment for what I did, everybody would do the same. You do not need to thank me” the farmer replied.

At that moment, the farmer’s own son came to the door of the family house. “Is that your son?” the nobleman asked. “Yes,” the farmer replied proudly.

“Let me give him a scholarship for his education. If your son is good like you he’ll grow up to a man that you can be proud of.”

And that he did. Several years later, Farmer Fleming’s son graduated from St. Mary’s Hospital Medical School in London, and went on to become known throughout the world as Sir Alexander Fleming, the man who discoverer Penicillin. The story did not end there, many years after the nobleman’s son was stricken with pneumonia. What saved him? – Penicillin.

The name of the nobleman is Lord Randolph Churchill and his son’s name is Sir Winston Churchill.

So “What goes around comes around” and that is why I believe in educating and sharing experiences with others is the greatest gift.

Question: Is it possible to use Agile in process improvement instead of CMMI?

Answer:  Agile is NOT a framework for software improvement but a method software development, especially for small project that may not have all requirements clearly defined but must deliver fast. Agile is NOT a solution for everything and you must determine whether or not this method is appropriated. You need to have several conditions for this method to work: First, since requirements are not well defined yet, it is critical that customer spend time with the team to help define the requirements throughout the project. If the customer is busy and can not participate than you should not select this method; second, this method requires team members to be highly technical and disciplined workers. They must work effectively and efficiently in a fast changing environment by fulfill many roles and willing to step in as needed to achieve the desired level of performance and quality. Without good experienced people, agile method will not work well. Third, the nature of agile method is self-organizing so it is essential for team members to be open and freely sharing information and solution. For this approach to be successfully, all team members must know how to work together. They must know how to communicate clearly and trust each others during the daily activities. Without strong teamwork, you should not use agile method.

Question: What is the best way to deploy improvement tasks documented in the Action plan?

Answer: For deployment of improvement task, there are several approaches but following is the method that I found work best in many situations:

1) Have a Process Action Team (PAT) consists of few people (2- 4) to define a solution to a problem identified in the action plan. (Define phase)

2) The same team can pilot the solution in 2 to 4 projects to see if it works (Trial & Error) However, the risk is the team who originated the solution maybe biased. Therefore, I suggest the team to replace one or two original member(s) with a new one(s) during the pilot phase. Solution can be piloted in the same project where the team comes from or in different projects or a combination (I would prefer a combination). Please note that although there are several pilot area, the solution must remain as faithful as the original if possible, do not hurry to modify the solution yet. The key is to see whether the original solution works as is or need changes. If it needs changes then note the detail of what need to be changed and if it really needs a major changes then maybe the original solution is not well defined or too generic.

3) The team pilots the solution could refine it based on pilot results or substitute a new team member during this phase. Result of this phase is a documented guideline, procedure to solve a problem (For example a procedure to do code review, a guideline to plan project etc.)

4) If the team does not think the solution is well defined, you could go back to step 2, more pilots and refinements before institutionalization. Data need to be collected here. Please note that there is no perfect solution, do not strive for perfection.

5) Assume everything is working well then start the process of institutionalization as follow:

a) Inform the SEPG that you have a solution.

b) SEPG will review to verify that the task is complete and ready to be shared

c) SEPG will plan a communication plan for this task

d) SEPG will issue a memo to announce the task

e) SEPG will arrange for organization training (All members who come up with the solution, pilot the solution and revise the solution should train others, NOT member of the SEPG)

f) After the training take place, SEPG will monitor the use of the new solution within the organization for effectiveness and collect data to support it.

g) If it has been used effectively, SEPG will secure a policy from senior manager to declare this solution is part of the “Prefer processes” to be used from now on.

SEPG will continue to monitor the usage of the “new process” for continuous improvements which may indicate more revisions as more people use them. SEPG may suggest to the team that the “new process” is good but a guide maybe needed and that is another area for improvement (Continuously). Note that institutionalization always takes longer time. This phase requires that the SEPG must be actively involved. Remember that for a process to be fully institutionalized, it must be Defined, Documented, Used, Measured, Verified, Maintained (Training) and continuously improved (Do it several times).

Question: Most processes in the CMMI require that they are developed according to a documented procedure. How detailed is a “Documented procedure?”

Answer: The answer is: Detailed enough to be useful, but not too detailed to be unusable. The point here is that the CMMI framework leaves a lot of flexibility in terms of level of detail. There are some factors that influence how you document your processes such as the size of your organization, the size of your project, process description tools, budget, and organization culture. For a small organization, a few pages maybe enough but for larger organization, a several pages maybe the right answers.

Question: What are the requirements for a change agent or SEPG?

Answer: The prospective change agent should be:

Empathy:

The change agent’s efforts are oriented toward the participants in the transition to the extent that the change agent has experience working in or with the participants’ organization and can build rapport with that organization, he is better able to empathize with their situation.

Credible

The change agent must be technologically and personally credible. She is a person who persists in the face of initial failures. She must be knowledgeable of the software technology to be implemented. She should have a history of successes in other software technology transition work or on similarly complex projects calling for both technical and human relations expertise.

Politically Astute

A successful change agent must be able to assess who in the participants’ organization is interested in the change, who is likely to resist it, who will have the resources to help the change, and who will have the resources to put a stop to the change.

A Problem Identifier and Problem Solver:

A successful change agent must be able to analyze a situation and uncover root causes of problems. She must also be able to consider multiple technologies as possible solutions to participants’ problems. She must be able to identify and understand sources of potential resistance, and translate this into feedback to the developers of the software technology.

A Past Project Manager

The same skills that are important in managing a project are important in managing a transition effort. A successful change agent has a proven track record as a good project planner. He works before and during the transition to predict and diagnose software technology delivery and implementation problems. He continually collects and consolidates data on the transition effort and monitors the criteria for a successful transition. He knows who in the organization is more likely to adopt the software technology, and he identifies people in the participants’ organization who would be good opinion leaders. He highlights and rewards the support he receives from people in management and from the participants.

Knowledgeable of Software Technology

The successful change agent is familiar and adept with the software technology to be transitioned.

And most of all, you must be an Excellent Communicator, Skilled Negotiator, Consultant, Trainer, Leader, Innovator, Defender, Writer, Teacher, Politician, Producer, Performer and Advertiser.

Question: How does CMMI work in small project such as 3 to 4 months in duration and less than 5 persons?

Answer: It works fine if you taken into consideration of what I called “Common sense”. Most CMMI practices can be modified to fit the needs. Remember, the key is the solution not the documentation.

Question: I think all programmers should learn extreme programming so we can code fast. We do NOT need to do process improvement documentation stuff. What do you think?

Answer: First, Extreme programming method is good for small projects (2 to 8 people) in which communication between members is easy and each person does many things from customer interfaces to design, code, test and release. This may not do well in large project environment which is require integration efforts. Extreme programming requires multi-skilled individuals who are ‘self-motivating, investigative, analytical, creative that have very strong inter-personal skills in order to understand customer’s problem(s) and much disciplined teamwork to release product within time allowed. I’m not sure that few programmers can work in large, complex situations, in which software is developed and supported today. You need to understand that software project is not just code.

Question: Why do we need to improve the process when technology is changing very fast? Why not just buying technology?

Answer: Technology evolves much more rapidly than our ability to deal with the change. Today, most technology has a life of three to five years. That means obsolescence occurs at the rate of about 20% to 40% per year. Buying technology will NOT solve business problems. The successful organization is the one that recognizes the only constant is change and continuously improving its process.

Question: I think I could make more money in learning new things and move around than work as software engineer. What do you think?

Answer: I always believe that a professional must take personal responsibility for their career development. It is easy for people to move from one firm to another firm and get a higher salary with each move. The free-flow of developers is good because new ideas move around and it is easy for workers to find work. I also understand that with the increasing rate of technology change and product complexity, there is a notion that the value of the workers is less in what they know business in detail but more in how quickly they can learn new things. (i.e. Web, e-Business etc.)

However, I believe that this is a short-termed trend because a professional must understand in detail the business goals and objectives, how to improve products, obtain customer satisfaction to business in a better way. While people can pick up new technologies such as Web, Java, etc. rather quickly (Few weeks or few months), I believe that it will take years to learn all of the details of a business domain, system implementation details, and how business is done. It is a personal choice and you know it better than me.