
Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)?
Published on: June 28, 2024
Last updated: July 11, 2024 Xem trên toàn màn hình
Last updated: July 11, 2024 Xem trên toàn màn hình



- 24 Jan 2024
Stakeholder là gì? Các mô hình phân loại Stakeholder 632
- 11 May 2021
Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 538
- 04 Jan 2023
Phát triển phần mềm linh hoạt theo mô hình Big Bang 488
- 01 Jan 2021
Các biến thể của ma trận công việc RACI (Responsible, Accountable, Consult, Inform) 475
- 15 Feb 2021
Ứng dụng thuyết ngũ hành trong quản lý 469
- 18 May 2021
Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 414
- 04 Mar 2019
Quản trị Team là gì? Team và Group khác nhau như thế nào? 392
- 03 Mar 2020
Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 373
- 01 Jan 2024
Tổng hợp 25 quy luật quan trọng trong quản lý dự án 357
- 03 May 2022
Mô hình Hybrid Agile là gì? 353
- 18 Mar 2021
Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 316
- 01 May 2022
Có thể xác định vị trí địa lý của địa chỉ IP với độ chính xác đến từng địa chỉ con phố? 300
- 20 Jul 2021
Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 275
- 19 Aug 2024
Kiểm toán công nghệ thông tin (IT Audit) - Nghề mới mẻ ở Việt Nam 273
- 02 Aug 2021
Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 272
- 01 Aug 2021
Hiện tượng Gold plating (mạ vàng) là gì? Tại sao có ảnh hưởng quyết định đến chất lượng dự án? 268
- 02 Aug 2023
Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 257
- 01 Sep 2023
"Data steward" là gì? 242
- 01 Aug 2023
Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 242
- 05 Aug 2024
Giải mã 10 sai lầm về quản lý thay đổi 235
- 02 Mar 2018
Tại sao ví Scrum như dòng điện xoay chiều? 207
- 08 Mar 2021
PMO là gì? Vai trò của PMO trong quản trị doanh nghiệp? 194
- 08 Aug 2023
Mất kiểm soát phạm vi dự án (Scope Creep) và hiệu ứng quả cầu tuyết (snowball) 194
- 04 Sep 2023
Giải mã nhóm tính cách (ISTP - Nhà kỹ thuật) 186
- 14 Apr 2019
Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 178
- 08 Jan 2022
Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 156
- 08 Apr 2024
Hiệu ứng Matthew: Tác động và Ứng dụng trong Chuyển đổi Số và Công nghệ tại Việt Nam 144
- 12 Jan 2024
Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 142
- 08 Feb 2021
Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 142
- 24 Mar 2019
Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 136
- 14 Dec 2022
Phương pháp kiểm tra Fagan Inspection là gì? 135
- 13 Apr 2021
Ví sao thuê nhân sự bên ngoài (staffing outsourcing) là xu hướng mới trong thời đại 4.0? 131
- 10 May 2021
Phát triển Phần mềm Tinh gọn (Lean Software Development) 129
- 01 Jul 2024
Lập kế hoạch dự án là "đặt rồi quên" hay "đặt rồi kiểm tra"? 128
- 07 Jan 2025
Phân biệt Proxy, HMA và VPN 121
- 21 Apr 2020
Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 112
- 22 Jul 2020
Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 75
- 08 Aug 2019
10 lý do tại sao việc sử dụng và vận hành phần mềm điều hành doanh nghiệp không được hiệu quả 62
Thuyết bất khả tri về công nghệ là một tư duy khuyến khích các kỹ sư luôn cởi mở và không thiên vị khi đánh giá các công nghệ, nền tảng và ngôn ngữ khác nhau.
Tech agnosticism is a mindset that encourages engineers to remain open-minded and unbiased when evaluating various technologies, platforms and languages.
Tìm hiểu lý do tại sao chúng tôi tin rằng cách duy nhất để đảm bảo giải pháp tốt nhất có thể cho dự án phần mềm của bạn là áp dụng cách tiếp cận bất khả tri về công nghệ. | Find out why we believe the only way to ensure the best possible solution to your software project is by taking a technology-agnostic approach. |
Thuyết bất khả tri về công nghệ cho rằng không có “một công nghệ thực sự”; không có một hệ thống đơn lẻ hay cách tiếp cận nào phù hợp cho tất cả có thể đưa ra giải pháp hoàn hảo cho mọi thách thức có thể xảy ra mà khách hàng có thể gặp phải. Dành thời gian để hiểu vấn đề thực tế (ví dụ "niềm đau" - pain point) mà hệ thống hoặc công cụ phần mềm mới dự định sẽ giải quyết giúp chúng ta - trong khi vẫn giữ thái độ cởi mở và không thiên vị - là cách duy nhất để đảm bảo rằng giải pháp tốt nhất được triển khai. | Technological agnosticism posits that there is no “one true tech”; there is no single system or one-size-fits-all approach that can claim to offer a perfect solution to every possible challenge that our clients may face. Taking time to understand the real world problem that the new system or tool is intended to solve - while remaining open-minded and unbiased - is the only way to ensure that the best possible solution can be identified and delivered. |
No favouritism, unbiased
|
|
Một số lập trình viên là những người dẫn đầu thế giới về một công nghệ, ngôn ngữ lập trình hoặc nền tảng cụ thể. Họ có thể cố gắng thuyết phục bạn rằng với chuyên môn của họ, có thể được áp dụng cho bất kỳ vấn đề nào mà doanh nghiệp của bạn có thể gặp phải. Mặc dù họ đủ thông minh để thao túng bằng cách thuyết phục đưa giải pháp của họ vào vấn đề của bạn, nhưng lòng trung thành đối với một công nghệ cụ thể này có thể dẫn đến một giải pháp quá phức tạp cho vấn đề, có thể gây khó bảo trì và tốn kém hơn mức cần thiết. Tốt hơn hết hãy tìm những người sẵn sàng suy nghĩ sáng tạo và khác biệt; những người sẵn sàng linh hoạt trong sử dụng nhiều ngôn ngữ lập trình và các công nghệ khác nhau, thay vì ưu tiên lòng trung thành mù quáng với (các) sở thích cá nhân của họ. | Some developers are world leaders in a particular technology, coding language or platform. They might try to persuade you that with their expertise it can be applied to any problem your business might throw at it. Although they might be clever enough to manipulate your square peg into their preferred round hole, this tribal loyalty to one particular tech could result in an overly complex solution to your problem that may prove difficult to maintain and cost more than is necessary. Better to find those who are willing to think creatively and divergently; who are open to using multiple programming languages and different technologies, rather than prioritising a blind loyalty to their personal favourite(s). |
Project Questionnaire
|
|
Trước khi bắt đầu một dự án phần mềm, điều quan trọng là bạn phải thực sự dành thời gian để truyền đạt chi tiết về vấn đề mà bạn đang cố gắng giải quyết. Chỉ khi đó các nhà phát triển phần mềm mới có thể xác định giải pháp tốt nhất có thể. Càng cụ thể thì chúng ta càng được tự do tiếp cận vấn đề theo cách thực sự cởi mở, để đánh giá nhiều khả năng công nghệ sẵn có cho đến khi chúng tôi tìm ra sự kết hợp phù hợp với bạn. | Before you set out on a software project, it’s crucial that you really take time to communicate the details of the problem you are trying to address. Only then can your developers begin to work out how best to proceed in identifying the best possible solution. The more specific you can be, the more we are set free to approach the problem in a truly open-minded fashion, to assess the many available technological possibilities until we have found the right combination for you. |
Latest does not automatically mean best
|
|
Chúng ta làm việc trong một ngành mà công nghệ tại biên đôi khi được đặt lên bệ đỡ, trong khi các hệ thống cũ bị loại bỏ ngay lập tức. Chúng ta tin rằng việc chỉ tập trung vào động lực phía trước có nghĩa là bạn có thể có nguy cơ bỏ lại phía sau những công nghệ vẫn có thứ gì đó độc đáo và hữu ích có tính khả dụng cao. Vấn đề khác khi thiên về các giải pháp hoàn toàn mới là có ít người có đủ chuyên môn cần thiết để triển khai chúng một cách hiệu quả. Trong tương lai, bạn có thể chỉ còn lại một phần mềm "sáng loáng" nhưng không ai trong nhóm của bạn đủ trình độ để bảo trì một công nghệ tương đương với một con voi trắng.
|
We work in an industry where bleeding edge tech is sometimes put on a pedestal, while old systems get rejected out of hand. We believe that solely focusing on forward momentum means you could risk leaving behind technologies that still have something unique and useful to offer. The other problem with skewing exclusively towards brand new solutions is that there are fewer people with the sort of expertise needed to deploy them effectively. In the future you could be left with a shiny piece of software that nobody on your team is qualified to maintain, the tech equivalent of a white elephant. |
Ask the right questions of the right people
|
|
Đôi khi chúng tôi gặp phải sự mất kết nối giữa những yêu cầu của nhóm quản lý dự án và nhu cầu thực tế của những người sẽ sử dụng hàng ngày. Chúng ta mong muốn phát triển các hệ thống phù hợp với tất cả những người sẽ tương tác. Một ví dụ thành công về điều này là công việc với một chuỗi nhà chăm sóc (care homes) cần một hệ thống có thể giải quyết nhu cầu của cả nhân viên chăm sóc tại chỗ và ban quản lý tổ chức nhân viên của họ. Với tư cách là những người theo thuyết bất khả tri về công nghệ, chúng tôi nhanh chóng nhận ra rằng sẽ không có giải pháp 'giải pháp túi càn khôn một cỡ phù hợp cho tất cả' (one-size-fits-all) mà thay vào đó đã phát triển hai hệ thống riêng biệt dành cho thiết bị di động và máy tính để bàn để bổ sung cho nhau một cách độc đáo. | We sometimes encounter a disconnect between what a project management team is asking us to produce and the needs of the people who are going to use it day-to-day. We want to develop systems that work for everyone who will be interacting with them. A successful example of this has been our work with a chain of care homes who needed a system that would address the needs of both care workers on the ground and management organising their staff. As technological agnostics we quickly saw that there wasn’t going to be a ‘one size fits all’ solution and instead developed two distinct systems for mobile and desktop that would complement each other nicely. |
Những người theo thuyết bất khả tri về công nghệ tin rằng một dự án thành công xuất hiện thông qua việc giải quyết vấn đề trong đời thực; chúng ta tự hào vì nhanh chóng nắm bắt được nhu cầu của khách hàng và cam kết khuyến khích các nhà phát triển phần mềm thoát khỏi vùng an toàn và những thứ đã quá quen thuộc để chúng tôi có thể thiết kế giải pháp mạnh mẽ hơn, đáng tin cậy và tiết kiệm nhất cho doanh nghiệp của mình. | Technology agnostics believe that a successful project comes about through real-life problem solving; we pride ourselves on quickly getting to grips with the needs of our clients and our commitment to encourage our developers to stray from the safe and familiar so that we can design the most robust, reliable and economical solution for your business. |
[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"1\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"Charles Rea - Technical Lead, Ghyston\",\"sourceValue\":\"https://www.ghyston.com/insights/why-the-best-developers-are-technology-agnostics\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":true,\"isAutoNumbering\":false,\"isShowKeyHeadingWithIcon\":false}]"},{"bannerInfo":"[{\"isBannerBrightnessAdjust\":false,\"bannerBrightnessLevel\":\"\",\"isRandomBannerDisplay\":true}]"}]
Nguồn
[{"LocalizationCommonClickToOpen":"Xem thêm","LocalizationCommonClickToClose":"Đóng lại"}]
{content}