Nhảy vọt về phần mềm sẽ sớm trở thành căn bệnh rất phổ biến của các công ty. Thay đổi phần mềm này sang phần mềm khác vì mọi điều nhỏ nhặt, nhảy từ công nghệ này sang công nghệ khác, thử nghiệm một hoạt động kinh doanh trực tiếp đang trở thành thông lệ. Cùng lúc đó, một cuộc nội chiến thực sự bắt đầu trong văn phòng: một phong trào phản đối việc thực hiện được hình thành, các đảng phái đang tiến hành công việc lật đổ hệ thống mới, các điệp viên đang thúc đẩy một thế giới mới dũng cảm với phần mềm mới, quản lý từ chiếc xe bọc thép của cổng thông tin công ty đang phát sóng về hòa bình, lao động, KPI. Một cuộc cách mạng thường kết thúc bằng sự thất bại hoàn toàn về một phía.
Chúng tôi biết hầu hết mọi thứ về việc triển khai, vì vậy hãy cố gắng tìm ra cách biến một cuộc cách mạng thành một cuộc tiến hóa và làm cho việc triển khai trở nên hữu ích và dễ dàng nhất có thể. Chà, hoặc ít nhất chúng tôi sẽ cho bạn biết những gì bạn có thể gặp phải trong quá trình này.
Hình dung lý tưởng về sự chấp nhận của nhân viên đối với phần mềm mới. Nguồn - Yandex.Images
Các nhà tư vấn nước ngoài sẽ bắt đầu bài viết này như thế này: “Nếu bạn cung cấp cho nhân viên của mình phần mềm chất lượng có thể cải thiện công việc của họ, có tác động định tính đến hiệu suất, thì việc áp dụng một chương trình hoặc hệ thống mới sẽ diễn ra một cách tự nhiên”. Nhưng chúng tôi đang ở Nga nên vấn đề nhân viên nghi ngờ và hiếu chiến là rất có liên quan. Quá trình chuyển đổi tự nhiên sẽ không hiệu quả, ngay cả với phần mềm tối thiểu như ứng dụng nhắn tin hoặc điện thoại phần mềm của công ty.
Chân của vấn đề đến từ đâu?
Ngày nay, mọi công ty đều cài đặt cả một kho phần mềm (chúng tôi lấy trường hợp chung, vì ở các công ty CNTT, số lượng phần mềm tăng gấp đôi hoặc gấp ba và các vấn đề về thích ứng chồng chéo một phần và rất cụ thể): hệ thống quản lý dự án, CRM/ERP, ứng dụng email, tin nhắn tức thời, cổng thông tin công ty, v.v. Và điều này là chưa kể thực tế là có những công ty mà ngay cả việc chuyển đổi từ trình duyệt này sang trình duyệt khác cũng được thực hiện bởi toàn bộ nhóm mà không có ngoại lệ (và cũng có những nhóm hoàn toàn dựa trên Internet Explorer Edge). Nói chung, có một số tình huống mà bài viết của chúng tôi có thể hữu ích:
- Đang có một quá trình tự động hóa cơ bản của một số nhóm nhiệm vụ: CRM/ERP đầu tiên đang được triển khai, cổng thông tin công ty đang mở, hệ thống hỗ trợ kỹ thuật đang được cài đặt, v.v.;
- một phần mềm được thay thế bằng một phần mềm khác vì lý do nào đó: lỗi thời, yêu cầu mới, mở rộng quy mô, thay đổi hoạt động, v.v.;
- các mô-đun của hệ thống hiện có đang được xây dựng nhằm mục đích phát triển và tăng trưởng (ví dụ: một công ty mở sản xuất và quyết định chuyển từ trên với chức năng tối đa);
- Một bản cập nhật phần mềm chức năng và giao diện chính đang diễn ra.
Tất nhiên, hai trường hợp đầu tiên có biểu hiện gay gắt và điển hình hơn nhiều, hãy đặc biệt chú ý đến chúng.
Vì vậy, trước khi bạn bắt đầu làm việc với nhóm (những người đã nghi ngờ rằng sẽ sớm có những thay đổi), hãy cố gắng hiểu lý do thực sự của việc thay đổi phần mềm là gì và liệu bạn có đồng ý rằng những thay đổi đó là cần thiết hay không.
- Chương trình cũ khó làm việc: đắt tiền, bất tiện, không hoạt động, không còn đáp ứng yêu cầu của bạn, không phù hợp với quy mô của bạn, v.v. Đây là một sự cần thiết khách quan.
- Nhà cung cấp đã ngừng hỗ trợ hệ thống, hoặc việc hỗ trợ và sửa đổi trở thành một chuỗi phê duyệt vô tận và tiêu tốn tiền bạc. Nếu chi phí của bạn đã tăng lên đáng kể và trong tương lai chúng hứa hẹn sẽ còn tăng hơn nữa thì không còn gì phải chờ đợi nữa, bạn cần phải cắt giảm. Đúng, một hệ thống mới cũng sẽ tốn tiền, nhưng cuối cùng thì việc tối ưu hóa sẽ tốn ít chi phí hơn so với việc hỗ trợ như vậy.
- Thay đổi phần mềm là ý muốn bất chợt của một người hoặc một nhóm nhân viên. Ví dụ: CTO muốn khôi phục hệ thống và đang vận động hành lang để giới thiệu một hệ thống mới, đắt tiền hơn - điều này xảy ra ở các công ty lớn. Một ví dụ khác: người quản lý dự án ủng hộ việc thay đổi Asana thành Basecamp, sau đó là Basecamp thành Jira và Jira phức tạp thành Wrike. Thường thì động cơ duy nhất của những cuộc di cư như vậy là để khoe khoang công việc bận rộn và giữ vững vị trí của mình. Trong những trường hợp như vậy, cần phải xác định mức độ cần thiết, động cơ và lý do biện minh và theo quy luật, bằng một quyết định kiên quyết từ chối những thay đổi.
Chúng ta đang nói về lý do chuyển đổi từ phần mềm này sang phần mềm khác chứ không phải về tự động hóa chính - chỉ vì tự động hóa là điều cần thiết trước tiên. Nếu công ty của bạn làm điều gì đó một cách thủ công và thường xuyên nhưng có thể được tự động hóa, thì bạn chỉ đang lãng phí thời gian, tiền bạc và rất có thể là dữ liệu có giá trị của công ty. Tự động hóa nó!
Làm sao bạn có thể vượt qua: bước nhảy vọt hay con hổ đang cúi mình?
Trong thực tế thế giới, có ba chiến lược chính để chuyển sang phần mềm mới và thích ứng với nó - và chúng có vẻ rất phù hợp với chúng ta, vì vậy chúng ta đừng phát minh lại cái bánh xe.
Big Bang
Việc áp dụng phương pháp “Big Bang” là quá trình chuyển đổi khó khăn nhất có thể, khi bạn đặt ngày chính xác và thực hiện di chuyển nhanh chóng, vô hiệu hóa 100% phần mềm cũ.
Ưu điểm
+ Mọi người làm việc trong một hệ thống, không cần đồng bộ dữ liệu, nhân viên không cần giám sát hai giao diện cùng một lúc.
+ Đơn giản hóa cho quản trị viên - một lần di chuyển, một nhiệm vụ, một hỗ trợ hệ thống.
+ Tất cả những thay đổi có thể xảy ra tại một thời điểm và gần như có thể nhận thấy ngay lập tức - không cần phải tách biệt những gì và tỷ lệ ảnh hưởng như thế nào đến năng suất, tốc độ phát triển, doanh số bán hàng, v.v.
Nhược điểm
— Chỉ hoạt động thành công với phần mềm đơn giản: trò chuyện, cổng thông tin công ty, tin nhắn tức thời. Ngay cả email cũng có thể bị lỗi, chưa kể đến hệ thống quản lý dự án, CRM/ERP và các hệ thống nghiêm trọng khác.
— Sự di chuyển bùng nổ từ hệ thống lớn này sang hệ thống khác chắc chắn sẽ gây ra sự hỗn loạn.
Điều quan trọng nhất đối với kiểu chuyển đổi sang môi trường làm việc mới này là đào tạo.
Chạy song song
Thích ứng song song với phần mềm là một phương pháp chuyển đổi nhẹ nhàng hơn và phổ biến hơn, trong đó một khoảng thời gian được đặt ra trong đó cả hai hệ thống sẽ hoạt động đồng thời.
Ưu điểm
+ Người dùng có đủ thời gian để làm quen với phần mềm mới đồng thời nhanh chóng làm việc với phần mềm cũ, tìm ra điểm tương đồng và hiểu logic mới của tương tác với giao diện.
+ Trường hợp có sự cố đột xuất, nhân viên tiếp tục làm việc theo chế độ cũ.
+ Đào tạo người dùng ít khắt khe hơn và thường rẻ hơn.
+ Thực tế không có phản ứng tiêu cực nào từ nhân viên - xét cho cùng, họ không bị tước đoạt các công cụ hoặc cách làm việc thông thường (nếu tự động hóa xảy ra lần đầu tiên).
Nhược điểm
— Vấn đề quản trị: hỗ trợ cả 2 hệ thống, đồng bộ dữ liệu, quản lý bảo mật trên 2 ứng dụng cùng lúc.
— Quá trình chuyển đổi kéo dài vô tận - nhân viên nhận ra rằng họ gần như còn lại một khoảng thời gian vô tận và họ có thể mở rộng việc sử dụng giao diện quen thuộc thêm một chút.
- Nhầm lẫn của người dùng - Hai giao diện khó hiểu và gây ra lỗi vận hành và dữ liệu.
- Tiền bạc. Bạn trả tiền cho cả hai hệ thống.
Áp dụng theo giai đoạn
Thích ứng từng bước là lựa chọn nhẹ nhàng nhất để chuyển sang phần mềm mới. Quá trình chuyển đổi được thực hiện theo chức năng, trong khoảng thời gian xác định và theo bộ phận (ví dụ: từ ngày 1 tháng 20, chúng tôi chỉ thêm khách hàng mới vào hệ thống CRM mới, từ ngày 1 tháng 30, chúng tôi thực hiện giao dịch trong hệ thống mới, cho đến ngày XNUMX tháng XNUMX, chúng tôi chuyển lịch và các trường hợp, và đến ngày XNUMX tháng XNUMX, việc di chuyển hoàn tất của chúng tôi là một mô tả rất sơ bộ nhưng nhìn chung là rõ ràng).
Ưu điểm
+ Tổ chức chuyển tiếp, phân bổ tải giữa các quản trị viên và chuyên gia nội bộ.
+ Học tập chu đáo và chuyên sâu hơn.
+ Không có sự kháng cự trước sự thay đổi, vì nó diễn ra một cách nhẹ nhàng nhất có thể.
Nhược điểm - gần giống như đối với chuyển đổi song song.
Vì vậy, bây giờ chỉ là một sự chuyển đổi dần dần?
Một câu hỏi hợp lý, bạn sẽ đồng ý. Tại sao phải gặp thêm rắc rối khi bạn có thể lập lịch trình và hành động theo một kế hoạch rõ ràng? Trên thực tế, không phải mọi thứ đều đơn giản như vậy.
- Độ phức tạp của phần mềm: nếu chúng ta đang nói về phần mềm phức tạp (ví dụ: ), thì việc thích ứng pha sẽ phù hợp hơn. Nếu phần mềm đơn giản (messenger, cổng thông tin công ty) thì mô hình phù hợp là khi bạn thông báo ngày và vô hiệu hóa phần mềm cũ vào ngày đã định (nếu may mắn, nhân viên sẽ có thời gian lấy ra tất cả thông tin họ cần). , và nếu bạn không trông cậy vào may mắn, thì bạn cần cung cấp tính năng nhập tự động dữ liệu cần thiết từ hệ thống cũ sang hệ thống mới, nếu có thể về mặt kỹ thuật).
- Mức độ rủi ro đối với công ty: việc triển khai càng rủi ro thì càng chậm. Mặt khác, sự chậm trễ cũng là một rủi ro: ví dụ: bạn đang chuyển từ hệ thống CRM này sang hệ thống CRM khác và trong thời gian chuyển đổi, bạn buộc phải trả tiền cho cả hai, do đó làm tăng chi phí và chi phí triển khai hệ thống mới, điều này nghĩa là thời gian hoàn vốn được kéo dài.
- Số lượng nhân viên: Big Bang chắc chắn không phù hợp nếu bạn cần mở rộng quy mô và cấu hình nhiều hồ sơ người dùng. Mặc dù có những trường hợp việc triển khai cực nhanh lại mang lại lợi ích cho một công ty lớn. Tùy chọn này có thể phù hợp với các hệ thống được nhiều nhân viên sử dụng, nhưng có thể không có yêu cầu vì việc tùy chỉnh không nhằm mục đích. Nhưng một lần nữa, đây là một bước đột phá lớn đối với người dùng cuối và là một công việc lớn theo từng bước đối với cùng một dịch vụ CNTT (ví dụ: hệ thống thanh toán hoặc truy cập).
- Các tính năng của việc triển khai phần mềm đã chọn (sửa đổi, v.v.). Đôi khi việc triển khai ban đầu được thực hiện theo từng giai đoạn - với việc thu thập yêu cầu, sàng lọc, đào tạo, v.v. Ví dụ, nó luôn được triển khai dần dần và nếu ai đó hứa với bạn “triển khai và cấu hình trong 3 ngày hoặc thậm chí 3 giờ” - hãy nhớ bài viết này và bỏ qua các dịch vụ đó: cài đặt ≠ triển khai.
Một lần nữa, ngay cả khi biết các tham số được liệt kê, người ta chắc chắn không thể đi theo con đường này hay con đường khác. Đánh giá môi trường doanh nghiệp của bạn - điều này sẽ giúp bạn hiểu được sự cân bằng quyền lực và xác định mô hình nào (hoặc sự kết hợp một số yếu tố của chúng) phù hợp với bạn.
Tác nhân gây ảnh hưởng: cuộc cách mạng hay sự tiến hóa
Điều đầu tiên bạn nên chú ý là những nhân viên sẽ bị ảnh hưởng khi triển khai phần mềm mới. Thực ra vấn đề mà chúng ta đang xem xét hiện nay thuần túy là yếu tố con người nên việc phân tích tác động đến nhân viên là không thể tránh khỏi. Chúng tôi đã đề cập đến một số trong số họ ở trên.
- Lãnh đạo công ty xác định phần mềm mới sẽ được chấp nhận rộng rãi như thế nào. Và đây không phải là nơi dành cho những bài phát biểu quảng cáo và những bài phát biểu nảy lửa - điều quan trọng là phải thể hiện chính xác nhu cầu thay đổi, truyền tải ý tưởng rằng đây chỉ là việc chọn một công cụ mát mẻ và tiện lợi hơn, giống như việc thay thế một chiếc máy tính xách tay cũ. Sai lầm lớn nhất của ban quản lý trong tình huống như vậy là rửa tay và rút lui: nếu ban quản lý không cần tự động hóa công ty thì tại sao nó lại được nhân viên quan tâm? Hãy tham gia vào quá trình này.
- Trưởng bộ phận (quản lý dự án) là mắt xích trung gian phải tham gia vào mọi quy trình, quản lý sự không hài lòng, thể hiện ý chí và làm việc bất chấp mọi phản đối của đồng nghiệp, đồng thời tiến hành đào tạo chuyên sâu và chất lượng cao.
- Dịch vụ CNTT (hoặc quản trị viên hệ thống) - thoạt nhìn, đây là những người đầu tiên của bạn, có khả năng thích ứng và thích ứng tốt nhất, nhưng... không. Thông thường, đặc biệt là ở các công ty vừa và nhỏ, quản trị viên hệ thống phản đối mọi thay đổi (tăng cường) cơ sở hạ tầng CNTT và điều này không phải do bất kỳ biện minh kỹ thuật nào mà là do sự lười biếng và miễn cưỡng làm việc. Ai trong chúng ta chưa từng tìm cách trốn tránh công việc? Nhưng đừng để điều này gây tổn hại cho toàn bộ công ty.
- Theo quy luật, người dùng cuối một mặt muốn làm việc tốt và thuận tiện và giống như bất kỳ người sống nào, họ sợ thay đổi. Lập luận chính của họ rất trung thực và đơn giản: tại sao chúng tôi giới thiệu/thay đổi, giới hạn kiểm soát là gì, công việc sẽ được đánh giá như thế nào, điều gì sẽ thay đổi và rủi ro là gì (nhân tiện, mọi người nên đánh giá rủi ro - mặc dù chúng tôi là nhà cung cấp , nhưng chúng tôi không cam kết rằng mọi việc luôn diễn ra suôn sẻ: luôn có rủi ro trong bất kỳ quá trình nào trong một doanh nghiệp).
- “Chính quyền” trong công ty là những đảng phái có thể gây ảnh hưởng đến các nhân viên khác. Đây không nhất thiết phải là người có chức vụ cao hoặc kinh nghiệm dày dặn - trong trường hợp làm việc với phần mềm, “người có thẩm quyền” có thể là một người hiểu biết nâng cao, chẳng hạn, đã đọc lại Habr và sẽ bắt đầu đe dọa mọi người về việc mọi thứ sẽ trở nên tồi tệ như thế nào. Anh ta thậm chí có thể không có mục đích phá hỏng quá trình thực hiện hoặc chuyển đổi - chỉ cần thể hiện và có tinh thần phản kháng - và nhân viên sẽ tin anh ta. Bạn cần làm việc với những nhân viên như vậy: giải thích, đặt câu hỏi và trong những trường hợp đặc biệt khó khăn, gợi ý về hậu quả.
Có một công thức chung để kiểm tra xem người dùng có thực sự sợ điều gì đó hay không hoặc liệu họ có mắc chứng hoang tưởng nhóm do một nhà lãnh đạo hiểu biết lãnh đạo hay không. Hỏi họ về lý do không hài lòng, về những lo lắng - nếu đây không phải là trải nghiệm hoặc ý kiến cá nhân, các cuộc tranh luận sẽ bắt đầu nổ ra sau 3-4 câu hỏi làm rõ.
Hai yếu tố quan trọng để vượt qua thành công “phong trào phản kháng”.
- Cung cấp đào tạo: nhà cung cấp và nội bộ. Hãy đảm bảo rằng nhân viên thực sự hiểu mọi thứ, đã thành thạo và sẵn sàng bắt tay vào làm việc, bất kể trình độ đào tạo của họ như thế nào. Thuộc tính bắt buộc của đào tạo là hướng dẫn in và điện tử (quy định) và tài liệu đầy đủ nhất trên hệ thống (các nhà cung cấp có uy tín sẽ phát hành nó cùng với phần mềm và cung cấp miễn phí).
- Tìm kiếm những người ủng hộ và chọn những người có ảnh hưởng. Các chuyên gia nội bộ và những người áp dụng sớm là hệ thống hỗ trợ của bạn, vừa giáo dục vừa xua tan những nghi ngờ. Theo quy định, bản thân nhân viên đều vui lòng giúp đỡ đồng nghiệp và giới thiệu cho họ phần mềm mới. Nhiệm vụ của bạn là tạm thời giải tỏa công việc cho họ hoặc thưởng cho họ một khoản tiền thưởng xứng đáng cho khối lượng công việc mới của họ.
Những gì bạn cần chú ý?
- Mức độ tiến bộ của nhân viên bị ảnh hưởng bởi những thay đổi như thế nào? (Nói một cách tương đối, nếu ngày mai họ phát minh ra một chương trình kế toán mới, Chúa cấm bạn thò mũi vào bộ phận kế toán với những phụ nữ trên 50 tuổi và đề nghị chuyển từ 1C, bạn sẽ không thể sống sót).
- Quy trình làm việc sẽ bị ảnh hưởng bao nhiêu? Việc thay đổi người đưa tin trong một công ty 100 người là một chuyện, việc khác là triển khai hệ thống CRM mới, dựa trên các quy trình chính trong công ty (và đây không chỉ là bán hàng, chẳng hạn như trong các phiên bản cao cấp, nó ảnh hưởng đến sản xuất, kho hàng, tiếp thị và những người quản lý cấp cao, những người cùng với nhóm sẽ xây dựng các quy trình kinh doanh tự động).
- Đã được đào tạo chưa và ở mức độ nào?
Sự chuyển đổi hợp lý duy nhất trong hệ thống tư duy của doanh nghiệp
Điều gì sẽ cứu vãn quá trình chuyển đổi/triển khai phần mềm mới?
Trước khi chúng tôi cho bạn biết những điểm chính nào sẽ giúp bạn thoải mái chuyển sang phần mềm mới, hãy để chúng tôi thu hút sự chú ý của bạn vào một điểm. Có một điều chắc chắn không nên làm - không cần thiết phải gây áp lực cho nhân viên và “động viên” họ bằng cách tước bỏ tiền thưởng, các biện pháp xử phạt hành chính và kỷ luật. Điều này không làm cho quy trình tốt hơn mà thái độ của nhân viên sẽ trở nên tồi tệ hơn: ép thì sẽ có kiểm soát; Nếu họ ép buộc bạn nghĩa là họ không tôn trọng lợi ích của chúng ta; Nếu họ áp đặt một cách mạnh mẽ, điều đó có nghĩa là họ không tin tưởng chúng tôi và công việc của chúng tôi. Vì vậy, chúng tôi làm mọi việc một cách kỷ luật, rõ ràng, thành thạo nhưng không bị áp lực hay ép buộc không cần thiết.
Bạn phải có kế hoạch hành động chi tiết
Mọi thứ khác có thể không tồn tại, nhưng phải có kế hoạch. Hơn nữa, kế hoạch có thể điều chỉnh, cập nhật, rõ ràng và tất yếu, đồng thời có thể thảo luận và minh bạch cho tất cả nhân viên quan tâm. Không thể truyền đạt trực tiếp rằng từ 8 giờ sáng đến 10 giờ sáng có chiến công, đến 16 giờ có chiến tranh với Anh, điều quan trọng là phải nhìn nhận toàn bộ kế hoạch một cách toàn diện.
Kế hoạch nhất thiết phải phản ánh yêu cầu của những nhân viên sẽ là người dùng cuối - bằng cách này, mỗi nhân viên sẽ biết chính xác tính năng mong muốn nào và anh ta có thể sử dụng tính năng đó vào thời điểm nào. Đồng thời, kế hoạch chuyển đổi hoặc thực hiện không phải là một khối nguyên khối bất biến, cần phải để lại khả năng hoàn thiện kế hoạch và thay đổi các thuộc tính của nó (nhưng không phải dưới dạng một dòng chỉnh sửa vô tận và những “mong muốn” mới chứ không phải ở dạng thay đổi liên tục về thời hạn).
Những gì nên có trong kế hoạch?
- Các cột mốc chuyển tiếp chính (giai đoạn) - những việc cần làm.
- Các điểm chuyển tiếp chi tiết cho từng giai đoạn - cách thực hiện.
- Các điểm chính và báo cáo về chúng (đối chiếu số giờ) - những gì đã thực hiện sẽ được đo lường như thế nào và ai sẽ là người ở điểm kiểm soát.
- Những người có trách nhiệm là những người mà bạn có thể tìm đến và đặt câu hỏi.
- Thời hạn là sự bắt đầu và kết thúc của mỗi giai đoạn và toàn bộ quá trình.
- Các quy trình bị ảnh hưởng - những thay đổi nào sẽ xảy ra trong quy trình kinh doanh, những gì cần thay đổi cùng với quá trình triển khai/chuyển đổi.
- Đánh giá cuối cùng là một tập hợp các chỉ số, thước đo hoặc thậm chí là đánh giá chủ quan sẽ giúp đánh giá quá trình triển khai/chuyển đổi đã diễn ra.
- Ngày bắt đầu hoạt động là ngày chính xác mà toàn bộ công ty sẽ tham gia vào quy trình tự động được cập nhật và làm việc trong hệ thống mới.
Chúng tôi đã gặp những bài trình bày của những người thực hiện trong đó ranh giới đỏ là lời khuyên: thực hiện bằng vũ lực, phớt lờ phản ứng, không nói chuyện với nhân viên. Chúng tôi phản đối cách tiếp cận này và đây là lý do.
Nhìn vào hình ảnh dưới đây:
Một con chuột mới, một bàn phím mới, một căn hộ, một chiếc ô tô và thậm chí cả một công việc đều là những sự kiện thú vị, vui vẻ, một số trong số đó thậm chí còn là thành tích. Và người dùng tìm đến Yandex để tìm hiểu cách làm quen và thích nghi. Làm thế nào để bước vào một căn hộ mới và hiểu rằng đó là của bạn, lần đầu tiên bật vòi, uống trà, đi ngủ lần đầu. Làm thế nào để ngồi sau tay lái và kết bạn với một chiếc xe mới, của bạn, nhưng cho đến nay vẫn còn xa lạ. Phần mềm mới tại nơi làm việc không khác gì những tình huống được mô tả: công việc của nhân viên sẽ không bao giờ giống nhau. Do đó, hãy triển khai, điều chỉnh, phát triển bằng phần mềm mới hiệu quả. Và đây là một tình huống mà chúng ta có thể nói: hãy nhanh lên từ từ.
Nguồn: www.habr.com