U30

 U30.

- Em thấy con vẹt dậy trên lưng thằng kia hay không?!

- Ừ, hắn mới bị đột quỵ đó.

- Nhìn trẻ hỉ?!

- Trẻ gì! Bằng tuổi anh đó!

- ?!

📌 Customer-Centric Project Portfolio

 

1. ✅ Định nghĩa

Customer-Centric Project Portfolio là cách tổ chức và quản lý các dự án khác nhau nhưng cùng phục vụ một khách hàng hoặc nhóm khách hàng cụ thể, nhằm tối ưu hóa mối quan hệ khách hàng, giá trị cung cấp và hiệu quả kinh doanh.

👉 Nó không phải một program vì các dự án có thể độc lập về mục tiêu, thời gian, công nghệ, nhưng vẫn cần được theo dõi và điều phối theo góc nhìn khách hàng.

---

2. 🧩 Khi nào nên sử dụng mô hình này?

Tình huống	Có nên áp dụng?
Công ty làm nhiều dự án nhỏ cho một khách hàng lớn	✅ Rất phù hợp
Dự án rời rạc về công nghệ, mục tiêu, PM khác nhau	✅ Vẫn phù hợp
Cần tăng cường chăm sóc, giữ chân khách hàng chiến lược	✅ Cực kỳ hiệu quả
Mỗi dự án đều ngắn hạn hoặc theo yêu cầu đơn lẻ	✅ Phù hợp
Dự án liên quan chiến lược sâu, tích hợp kỹ thuật nhiều	❌ Có thể là Program

Các công thức đặt tên nhàm chán – nhưng phổ biến

 

Các công thức đặt tên nhàm chán – nhưng phổ biến

Mẫu tên	Ví dụ	Ý nghĩa giả định
One + [từ chung chung]	OnePortal, OneConnect, OneDesk	"Chỉ một công cụ cho tất cả"... nghe rất enterprise nhưng không rõ là gì
NextGen + [sản phẩm cũ]	NextGenHR, NextGenCRM	Gợi ý hiện đại, nhưng thường là bản vá lỗi của đời trước, tính năng còn ẹ hơn😅
[Tên sản phẩm] + X	FinanceX, ChatX, AppX	Nghe cool, nhưng dễ nhầm lẫn, ai cũng dùng
Smart + [thứ gì đó ngu]	SmartMeeting, SmartInvoice	Gán chữ "smart" để thuyết phục rằng sản phẩm thông minh
360 + [tính năng]	HR360, Project360	Ngụ ý toàn diện – nhưng đôi khi lại chỉ 36 độ...
Cloud + [gì đó rất cũ]	CloudERP, CloudStorage	Chuyển đồ cũ lên mây, rồi dán nhãn “cloud” cho hiện đại
[Từ viết tắt khó hiểu]	VMS, HEMIS, ERPX	Viết tắt mà chẳng ai giải thích. Càng bí ẩn càng "doanh nghiệp" 😅
[Tên Latin/một từ "kêu"]	Nova, Synergy, Orbit, Quantum	Dễ quên, dễ trùng tên, nhưng nghe ngầu
Pro / Ultimate / Plus	CRM Pro, DevOps Ultimate	Hứa hẹn cao cấp nhưng không rõ hơn bản thường ở điểm nào
i + [danh từ] (Apple style)	iTask, iPlan, iManage	Cố gắng bắt trend Apple từ 2007 😅

🤖 Công thức máy móc (auto-gen):

[Prefix] + [Buzzword] + [Suffix]
Ví dụ: One + Insight + 360 = OneInsight360™

Bạn có thể tự tạo hàng loạt như:

• NextGenOps

• SmartCloudDesk

• OneFinancePro

• VisionX360

🤯 Vì sao lại nhàm chán?

1. Mất cá tính – trùng lặp quá nhiều với các sản phẩm khác.

2. Không gợi hình dung – người dùng không hiểu ngay sản phẩm làm gì.

3. Thiếu cảm xúc – không khơi dậy sự tò mò hay kết nối cảm xúc.

🎯 Cách đặt tên hay hơn?

Nếu muốn sáng tạo, bạn có thể:

• Dùng ẩn dụ (ví dụ: “Trello” – lấy từ tiếng Ý "tấm bảng").

• Dùng tên gợi cảm xúc hoặc hành động (ex: “Slack”, “Zoom”, “Figma”).

• Dùng tên kết hợp có cá tính (ví dụ: Notion, Asana, GitLab…)

• Tạo từ mới (như Spotify, Shopify).

Nguồn: lượm lặt từ Internet

🌲 Đồi Thông Thiên An – Hơi thở xanh lặng lẽ của Huế

🌲 Đồi Thông Thiên An – Hơi thở xanh lặng lẽ của Huế

Nằm cách trung tâm thành phố Huế chỉ khoảng 7km, đồi Thiên An là một thế giới hoàn toàn khác: yên tĩnh, mơ màng, và đậm chất thiền. Đây không phải là điểm đến ồn ào, không có tour ồn ã, mà là nơi người ta tìm về để lắng nghe tiếng lòng giữa rừng thông thơm lừng, rì rào trong gió.

---

🛤️ Con đường quanh co dẫn lên đồi

Con đường nhỏ dẫn vào Thiên An uốn lượn theo triền đồi, hai bên là rừng thông xanh mướt, như tấm màn thiên nhiên che chắn bụi bặm thành phố. Dưới chân là lớp thảm lá thông khô, giòn nhẹ và thơm ngát – thứ mùi đặc trưng khiến ai từng đến đều nhớ mãi.

---

🌲 Rừng thông Huế – không cao, nhưng sâu

Thông ở Thiên An không cao vút như thông Đà Lạt, không phủ sương mù dày đặc, nhưng lại có vẻ kín đáo, dịu dàng, đúng kiểu của Huế. Những hàng thông mọc san sát, rợp bóng mát, gió lùa qua từng tán cây tạo ra âm thanh xào xạc như lời thì thầm của núi rừng.

Ở đây, bạn có thể ngồi xuống một gốc cây, nghe tiếng chim, hít hà mùi nhựa thông, cảm nhận sự an yên len lỏi vào từng hơi thở.

---

⛪ Điểm nhấn cổ kính – Đan viện Thiên An

Trên đỉnh đồi là Đan viện Benedict Thiên An – một tu viện cổ xây từ thời Pháp thuộc, mang đậm nét kiến trúc châu Âu. Bức tường rêu phong, mái ngói cũ, hành lang đá – tất cả tạo nên một không gian trầm mặc, gần như tách biệt hoàn toàn với thế giới bên ngoài.

Tu viện không mở cửa cho khách du lịch ồ ạt, nhưng chỉ cần đứng bên ngoài, bạn cũng cảm nhận được sự linh thiêng và bình yên khó tả.

---

💧 Gần bên là hồ Thủy Tiên bỏ hoang – đầy chất “art”

Chỉ cách đồi Thiên An vài phút là hồ Thủy Tiên, công viên nước bỏ hoang nổi tiếng vì vẻ đẹp ma mị, kỳ bí. Đây là nơi được các tạp chí nước ngoài gọi là “ghost park” nghệ thuật nhất Đông Nam Á. Một tổ hợp vừa hoang dã, vừa hấp dẫn với các bạn mê nhiếp ảnh, thám hiểm và khám phá những điều khác lạ.

---

🌲💬 So sánh: Rừng thông Đà Lạt vs. Rừng thông Thiên An – Ai đẹp hơn?

Tiêu chí	Rừng thông Đà Lạt	Rừng thông Thiên An (Huế)
Độ cao & khí hậu	Cao nguyên, lạnh, sương mù	Đồi thấp, khí hậu mát nhẹ, nắng nhẹ
Mật độ cây	Thông mọc thưa, rải rác trên đồi rộng	Thông mọc dày, rợp bóng, gần nhau
Mùi hương	Thoang thoảng, tươi mát	Thơm nồng, ngọt và ấm hơn
Trải nghiệm	Rộng lớn, đông đúc, dễ check-in	Kín đáo, riêng tư, sâu lắng
Cảm xúc mang lại	Lãng mạn, sôi động	Thiền tịnh, trầm mặc, sâu sắc

New Software Development vs Maintenance Project

 First, the similarities and differences between NEW SOFTWARE DEVELOPMENT projects and SOFTWARE MAINTENANCE projects:

A new software development project and a software maintenance project both play crucial roles in the lifecycle of a software product. However, they have distinct goals, processes, and challenges. Here are the fundamental similarities and differences between these two types of projects:

 

Similarities:

Both new development projects and software maintenance projects share several core commonalities:

• Need to meet user/customer requirements: Both types of projects aim to satisfy the needs of end-users or stakeholders. Whether building new functionalities or fixing bugs and improving existing ones, the ultimate goal is to deliver value to the user.
• Require project management: Both need to be managed systematically, including planning, resource allocation (personnel, time, budget), progress tracking, risk management, and quality assurance.
• Undergo similar phases (to some extent): Although the focus differs, both can include elements such as requirements analysis (whether for entirely new requirements or change requests), design (new design or partial redesign), programming, testing, and deployment.
• Demand technical skills: Both require teams with knowledge and skills in software technology, programming languages, databases, and related development tools.
• Produce technical documentation: Creating and updating documentation is necessary in both types of projects to ensure understanding, transferability, and future maintainability.
• Aim for software quality: The ultimate goal is to ensure the software operates stably, efficiently, securely, and meets the defined quality standards.
• Can apply similar development models/processes: Methodologies like Agile or Waterfall, Scrum can be adapted for both new development and maintenance, depending on the scope and nature of the task.

Differences:

The differences between new software development and software maintenance are very distinct in many aspects:

Feature	New SW Development Project	SW Maintenance Project
Primary Goal	Build an entirely new software product from scratch to address an unmet need.	Modify, update, improve, or fix bugs in an existing and currently used software product.
Scope of Work	Usually broad, encompassing all aspects of the software from architecture to detailed features.	Often focused on specific parts of the system needing modification, bug fixing, or upgrades.
Creativity	Higher, with more room for introducing new solutions, architectures, and technologies.	Lower, often constrained by existing architecture, technology, and prior design decisions.
Risks	Risks related to new technology, unclear requirements, inaccurate estimations, market non-acceptance.	Risks of changes in one part affecting other parts (regression), misunderstanding the existing system, lack of documentation.
Initial Requirements	Typically gathered from the beginning, may change and evolve during the project.	Based on reported issues, user feedback, or the need to adapt to new environments.
Design	Design of the entire system, architecture, database, user interface.	Often involves adjusting, extending, or optimizing the existing design. Sometimes refactoring.
Working Environment	Building on a "clean slate," less constrained by what already exists.	Working on an operational system, must ensure compatibility and stability.
System Knowledge	The team gradually builds system knowledge during development.	Requires the team to have a deep understanding of the current system, which can be complex and poorly documented.
Time Pressure	Often has specific product launch schedules.	May include urgent bug fixes (hotfixes) or long-term upgrade plans.
Documentation	Creation of all new documentation.	Updating and supplementing existing documentation. Lack of initial documentation is a common challenge.
Team Motivation	Often enthusiastic about creating something new.	May feel the work is repetitive or less challenging (however, solving complex maintenance issues is crucial and requires high skill).
Cost	Large upfront development costs.	Costs are typically spread throughout the software's lifecycle, potentially constituting the majority of the total cost of ownership.

 

In summary:

• New SW development projects focus on creating a software solution from zero (0), are highly creative, and face the risks of building an unproven product.
• SW maintenance projects focus on sustaining, improving, and extending the life of existing software, requiring a deep understanding of the system and the ability to work within existing constraints.

Both types of projects are essential for the success of a SW product. New development lays the foundation, while maintenance ensures the software continues to operate effectively, securely, and meets changing needs over time. 😃

 

 

COMPARISON OF DIFFICULTIES AND ADVANTAGES IN PM FOR NEW DEVELOPMENT AND SW MAINTENANCE 

PM Aspect	New SW Development Projects	SW Maintenance Projects
ADVANTAGES
Shaping and Creativity	- Opportunity to shape the product: Project management can be deeply involved in shaping the vision, architecture, and technology for the product from the outset. - Greater creative freedom: Less constrained by old decisions, allowing the application of the latest methods, tools, and technologies.	- System is somewhat familiar: If the team has worked with the system before, understanding its structure and operation can make managing changes easier. - Clear user feedback: Maintenance requests often stem from specific issues or direct user feedback, helping to define the scope of work more clearly.
Team and Motivation	- Attracting talent: New projects are often more appealing to engineers who want challenges and to learn new technologies. - High initial motivation: The excitement of building something new can boost team productivity and engagement.	- Less pressure for "big ideas": Focuses on specific improvements and bug fixes, reducing the pressure to create an entirely new breakthrough product. - Visible impact: Fixing bugs or improving performance can bring immediate satisfaction to users and the team.
Planning	- "Tabula Rasa" (Clean slate): Can establish processes, tools, and team structures from scratch without being encumbered by old legacies.	- Easier estimation for small tasks: Small bug fixes or minor change requests are often easier to estimate in terms of time and resources than building large, entirely new features.   - More predictable technical risks: Potential issues are often related to the existing system, helping to focus on known risk areas.
DIFFICULTIES
Requirements and Scope	- Unclear or changing requirements: The initial phase often makes it difficult to define requirements precisely, leading to "scope creep." - Difficulty in visualizing the final product: Both clients and the team may have different expectations for the product.	- Correctly understanding complex systems: For large, old, and poorly documented systems, fully understanding the impact of a small change is a major challenge. - Prioritizing conflicting requests: Must balance bug fixes, performance improvements, new minor features, and technical requirements (e.g., technology upgrades).
Estimation and Risks	- Difficulty in accurate estimation: Estimating time, cost, and resources for a non-existent product is very challenging. - High technology risks: Choosing and applying new technologies can come with unforeseen risks.  - Market risks: Uncertainty about market acceptance of the new product.	- Regression risk: Changes in one part can unintentionally cause errors in other parts of the system. Thorough regression testing is needed. - Pressure for urgent bug fixes: Critical bugs affecting users need immediate attention, disrupting plans. - Obsolete technology: Maintaining systems using old technology can face difficulties in terms of human resources and compatibility.
Team and Knowledge	- Building the right team: Requires time to recruit and build a team with the necessary skills and good coordination. <br> - Learning curve: The team needs time to familiarize themselves with new requirements, technologies, and processes.	- Retaining personnel for maintenance work: Maintenance work is sometimes seen as less attractive, making it difficult to retain skilled engineers. - Lack of or outdated documentation: Makes it difficult to understand and modify the system.  - "Knowledge silos": Knowledge about specific parts of the system may reside with only a few individuals.
Stakeholder Management	- Managing stakeholder expectations: Requires frequent and clear communication to ensure stakeholders correctly understand the project's progress and challenges.	- Impact on current users: All changes can potentially affect users currently using the system, requiring careful management of deployment and communication.  - Justifying the value of refactoring or technical upgrades: Sometimes it's hard to convince stakeholders of the long-term benefits of preventive or perfective maintenance activities versus new feature requests.
Budget and Time	- Budgets are easily overrun: Due to difficult estimations and changing requirements.  - Pressure for time-to-market.	- Maintenance budgets are often cut: Maintenance is sometimes not prioritized as highly as new development.  - Work is never-ending: Maintenance is an ongoing process, and it can be difficult to define a clear endpoint for a specific maintenance "project."

Dù Noel rơi vào những ngày cuối tháng 12, nhưng tôi bao giờ thật sự để ý nó.

Mãi đến khi đèn sao năm cánh lấp lánh nhà hàng xóm, tôi mới chợt nhận ra Noel đã về. Với đám trẻ ngoại đạo chúng tôi, Noel đơn thuần là dịp náo nức quanh nhà thờ Dòng Chúa Cứu Thế. Giờ lễ đến, lũ trẻ con vô tư kéo nhau vào thánh đường, chẳng màng ý nghĩa tôn giáo, chỉ đơn giản là một ngày hội.

Tôi hay la cà xem đám bạn chơi bóng bàn dưới tầng hầm nhà thờ. Đến giờ vẫn thấy lạ, sao ở Huế mưa dầm lại có một tầng hầm nhà thờ mà người ngoài có thể nhìn xuống được?

Ngay cạnh nhà thờ là dãy nhà dài bí ẩn, cửa luôn đóng im ỉm, hình như chỉ dành riêng cho người có đạo.Tuổi thơ tôi và đám bạn cứ thế gắn liền với những mùa Noel "ngoại đạo" vui vẻ như thế. Nhà thờ không chỉ là nơi vang vọng tiếng kinh cầu mà còn là sân chơi rộn rã tiếng cười trẻ con. Chúng tôi lớn lên bên cạnh những biểu tượng tôn giáo mà không thực sự hiểu hết ý nghĩa sâu xa, nhưng vẫn cảm nhận được không khí hân hoan, ấm áp lan tỏa trong những ngày cuối năm.

Sau này lớn lên, mỗi khi nhìn thấy những ánh đèn Noel lung linh, trong lòng tôi vẫn trào dâng một cảm xúc khó tả. Nó không hẳn là niềm hân hoan tôn giáo, mà là sự pha trộn giữa ký ức tuổi thơ tươi đẹp và một chút tò mò về thế giới tâm linh mà mình chưa từng thực sự chạm đến. Dãy nhà dài đóng kín cửa bên cạnh nhà thờ vẫn là một hình ảnh gợi nhiều suy nghĩ, về những ranh giới vô hình, về những điều mình có thể thấy nhưng không thể biết. Noel, dù vậy, vẫn luôn mang một dấu ấn đặc biệt trong dòng chảy ký ức của tôi, một mùa lễ hội của ánh sáng, niề
m vui trẻ thơ và những bí ẩn chưa lời giải đáp.

Comparison of PMI PMP, CMMI, and ISO 21500 for Project Management

Comparison of PMI PMP, CMMI, and ISO 21500 for Project Management

To compare PMI PMP, CMMI, and ISO 21500 for project management, it's essential to distinguish the nature and purpose of each standard:

1. PMI PMP (Project Management Professional):

• Nature:
  • A professional certification issued by the Project Management Institute (PMI).
  • Focuses on project management knowledge and skills according to the PMBOK (Project Management Body of Knowledge) standard.
  • Emphasizes project management processes, tools, and techniques.
• Purpose:
  • Certifies an individual's competence in project management.
  • Raises the professional standard of project managers.
  • Creates consistency in the project management approach.
• Scope:
  • Focuses on the individual project manager.
  • Applicable to all types of projects and industries.

2. CMMI (Capability Maturity Model Integration):

• Nature:
  • A process improvement model.
  • Focuses on assessing and improving an organization's capability to execute projects.
  • Emphasizes building standardized and optimized processes.
• Purpose:
  • Enhances organizational operational efficiency.
  • Improves product and service quality.
  • Strengthens project predictability and control.
• Scope:
  • Focuses on the organization.
  • Applicable to organizations developing software, systems, and services.

3. ISO 21500 (Guidance on project management):

• Nature:
  • An international standard for project management.
  • Provides general guidance on project management concepts and processes.
  • Emphasizes the fundamental principles of project management.
• Purpose:
  • Creates uniformity in the understanding and application of project management principles.
  • Provides a reference framework for organizations in building project management systems.
  • Creates a global standard for project management.
• Scope:
  • Applicable to all types of projects and industries.
  • Provides guidance to organizations.

Key Differences:

• Target: PMP focuses on individuals, CMMI focuses on organizations, and ISO 21500 focuses on guidance.
• Objective: PMP certifies competence, CMMI improves processes, and ISO 21500 provides guidance.
• Scope: PMP and ISO 21500 are widely applicable, while CMMI is commonly applied in software and systems development.

In Summary:

• PMP is a certification for project managers.
• CMMI is a model for improving an organization's project management processes.
• ISO 21500 is a standard that provides guidance on project management.

Each standard has its own value and application, and they can complement each other in enhancing project management effectiveness.