Là một lập trình viên, làm thế nào tôi có thể tăng tốc việc áp dụng và hiểu biết về các quy tắc kinh doanh?


11

Tôi đã là một nhà phát triển trong một thời gian. Tôi ở xa những thứ tốt nhất ngoài kia. (Khi tôi ngồi một mình trong căn phòng này, tôi tự hỏi liệu tôi thậm chí có phải là người giỏi nhất ở đây không.) Tuy nhiên, tôi đã hiểu được các công cụ của mình và tôi đã tin tưởng vào khả năng suy luận và học hỏi của mình.

Khi bắt đầu một công việc mới, tôi luôn tin rằng tôi có thể học được cơ sở mã nếu đó là ngôn ngữ mà tôi biết. Nếu đó không phải là ngôn ngữ hoặc khung mà tôi biết, tôi tin rằng tôi có thể nắm bắt các khái niệm đủ để học nó (và chỉ cần đọc tài liệu). Đây là một phần trong bộ kỹ năng của chúng tôi với tư cách là lập trình viên và tôi tự hào rằng tôi có thể sống theo tiêu chuẩn này.

Mặc dù vậy, đối với tất cả những điều này - một trong những điểm yếu lớn nhất của tôi là học hỏi và tiếp thu các quy tắc kinh doanh cho khách hàng Tôi đang làm việc một cách nhanh chóng - cho dù tôi là nhân viên được trả lương hay nhà thầu. Tôi ổn với các cơ sở mã, nhưng các quy tắc và quy trình kinh doanh cho một doanh nghiệp cụ thể dường như luôn khiến tôi mất một thời gian để hiểu đầy đủ. (Ví dụ: đây có thể là một bộ ba khi viết lại các ứng dụng doanh nghiệp.)

Là một nhà phát triển, cách tốt nhất để đồng hóa các quy tắc và quy trình kinh doanh một cách nhanh chóng và hiệu quả là gì? Có thể mà không phải là một chuyên gia vấn đề hoặc chỉ đơn giản là có nhiều năm kinh nghiệm với khách hàng, công ty hoặc doanh nghiệp?


3
Đây là một câu hỏi rất hay để thảo luận với các lập trình viên khác, nhưng tiếc là nó không có chủ đề cho trang web Hỏi & Đáp này: nó quá rộng (có rất nhiều điều để nói về vấn đề này) và chủ yếu dựa trên ý kiến ​​(những người khác nhau sẽ cho bạn biết khác nhau những thứ, về cơ bản là những gì làm việc cho họ ... làm thế nào bạn sẽ chọn câu trả lời "đúng"?).
Andres F.

Câu trả lời:


4

Đối với tôi, đó là bằng cách đọc và hiểu các cơ sở mã.

Tôi nói vậy vì hai lý do chính:

  1. Người mút. Ồ, không phải cố tình (thông thường), nhưng trong kinh doanh tôi đã thấy rằng mọi người thường có sự hiểu biết tinh tế về các quy tắc kinh doanh. Và mọi người đều có mô hình tinh thần của riêng mình mà đến lượt họ mất đi sự trung thực khi họ cố gắng truyền đạt nó cho bạn. Nhưng mã không nói dối. Mọi người có thể nghĩ những gì họ muốn về cách mọi thứ được cho là hoạt động, nhưng mã là đúng.

  2. Xây dựng nền tảng đầu tiên. Vì vậy, nếu mọi người đều có mô hình tinh thần của riêng họ về các điều khoản và quy trình cụ thể của doanh nghiệp này, làm thế nào để bạn xây dựng doanh nghiệp của mình? Đối với tôi, và tôi mong đợi cho nhiều lập trình viên, tôi xây dựng các mô hình tinh thần của mình tốt nhất từ ​​mã. Mã có mẫu. Mã có trừu tượng. Tôi có rất nhiều kinh nghiệm lấy mã và xây dựng một mô hình tinh thần từ nó. Một khi tôi có ít nhất một hình dạng mơ hồ về những thứ tồn tại và chúng liên quan như thế nào, thì tôi có thể nói chuyện với những người kinh doanh. Sau đó tôi có thể hỏi đúng câu hỏi và phù hợp hơn với câu trả lời của họ vào câu đố.


2
Cách tiếp cận của bạn âm thanh một chút gà và trứng.
Robert Harvey

@RobertHarvey Bạn có thể giải thích ý của bạn về 'gà và trứng' không?
Falgantil

3
@ BjarkeSøgaard: Bạn viết mã để hiểu các quy tắc kinh doanh mà không cần hiểu các quy tắc kinh doanh trước để bạn có thể viết mã phù hợp. Xem thêm Gà và Trứng nếu bạn hỏi thành ngữ đó có nghĩa là gì.
Robert Harvey

Để rõ ràng, tôi tập trung vào việc đọc mã đầu tiên.
Telastyn

1
@Telastyn Đôi khi, mã không đầy đủ hoặc không chính xác - hoặc không tồn tại. Tôi đã phải viết mã cho các quy trình kinh doanh không có giấy tờ - như là một tính năng mới hoặc là một hệ thống mới. Hơn nữa, thông thường, mã không bao gồm tất cả khi tuân theo các quy tắc kinh doanh - mã cho hệ thống kiểm kê có thể cho bạn thấy quy trình hoạt động như thế nào , nhưng không nhất thiết tại sao quy trình được xác định theo cách đó. Tôi tin rằng biết tại sao mọi thứ hoạt động và tại sao chúng được thực hiện luôn dẫn đến các giải pháp tốt hơn.
bữa ăn trưa317

3

Đừng quá khó khăn với chính mình. Đôi khi tôi tự hỏi tại sao họ thậm chí còn bận tâm gọi họ là "quy tắc" kinh doanh nhưng tôi đoán gọi họ là "cách chúng ta thường làm trừ khi có những điều khác áp dụng thì chúng ta làm khác đi" có lẽ sẽ xúc phạm họ. Kinh doanh lộn xộn. Họ tung hứng các nhu cầu của khách hàng, cơ quan pháp lý, kế toán, quy định, nhà cung cấp, nhân viên, nhà quản lý và chính quyền địa phương. Họ không phải lúc nào cũng có lý do.

Tôi nghĩ cách tốt nhất là đảm bảo bạn dành thời gian với càng nhiều doanh nhân càng tốt. Điều này có thể khó khăn cho một số người ở vị trí kỹ thuật.

  1. Ngân sách thời gian của bạn và tôn trọng của họ, nhưng nhận được càng nhiều càng tốt.
  2. Bạn sẽ cần đặt câu hỏi. Họ không suy nghĩ như lập trình viên và phá vỡ mọi thứ và hoàn toàn hiểu được thông tin liên quan đến nhau như thế nào.
  3. Đừng giả như bạn hiểu. Nếu bạn biết nhiều như những người kinh doanh khác, họ sẽ bắt bạn làm cả hai công việc. Xem # 2.
  4. Đừng mong đợi tài liệu. Cung cấp rất nhiều lời khen ngợi nếu bạn nhận được bất kỳ.
  5. Giữ lời chỉ trích. Các quy trình và thủ tục có thể có dự phòng và hiệu quả nhà trọ tiềm năng khác, nhưng có thể có một lý do cho điều đó. Tìm hiểu lý do tại sao, nhưng đừng sốc khi họ nói, "Chúng tôi đã luôn làm theo cách đó."
  6. Hãy lịch sự, tử tế và chia sẻ đồ ăn nhẹ của bạn. Bạn đang giao dịch với mọi người. Xin chào. Hỏi xem họ đang làm như thế nào. Hỏi về lý do tại sao họ đi vào ngành, họ đã làm việc với công ty được bao lâu.

Bạn không phải là một khoảng trống được gọi là lập trình viên, bạn là một người. Cho họ biết bạn đang ở đó để làm cho công việc của họ dễ dàng hơn. Thật không may, bạn có thể là anh hùng hoặc con dê. Đó là bản chất kinh doanh của chúng tôi.


Tôi thực sự phải làm việc ở số 5 ..... Tôi sẽ cố nhớ điều này.
bữa ăn trưa317

# 5 là rất lớn. Tôi làm việc trong ngành dược. Một câu hỏi có thể trở lại với "Tôi không biết máy tính có thể làm điều đó" hoặc "Trừ khi chúng ta làm theo điều này cụ thể mọi người có thể chết ." Theo hướng đó, đừng bao giờ nói "tại sao bạn không chỉ " bởi vì "chỉ" thường sẽ cho thấy sự thiếu hiểu biết của bạn về sự phức tạp của một tương tác nhất định.
Alan Shutko

3

Tôi khuyên bạn nên đọc một cuốn sách có tên 5 yếu tố tư duy hiệu quả của Edward Burger và Michael P. Starbird. Nó liên quan đến việc hiểu các khái niệm mới nói chung nhưng tôi nghĩ nó áp dụng cho tình huống này.

Dưới đây là một số điểm thú vị từ cuốn sách:

Nắm vững những điều cơ bản

Nếu bạn không biết những điều cơ bản, bạn sẽ xây dựng sự hiểu biết của mình trên một nền tảng run rẩy. Vì vậy, bạn cần phải hỏi những câu hỏi nghe có vẻ ngu ngốc mà không ai hỏi.

Hãy để lỗi là hướng dẫn của bạn

Đôi khi nó giúp đặt câu hỏi sai rõ ràng để bạn có thể phát hiện ra sự thiếu hiểu biết của mình. (Ví dụ: Bạn có nghĩa là quản trị viên có quyền truy cập vào mọi tài liệu? Oh. Tại sao?)

Dạy hoặc giải thích nó cho người khác

Khi bạn cố gắng dạy nó cho người khác, bạn sẽ bắt đầu phát hiện ra nơi bạn gặp khó khăn trong việc hiểu.

Mong rằng sẽ giúp!


0

Là nhà phát triển, tôi đã nhận ra rằng tôi trực tiếp dịch doanh nghiệp thành mã, cấu trúc dữ liệu, các lớp có thể, v.v ... Tôi đi từ một cái gì đó trừu tượng và thường, không xác định thành một cái gì đó cụ thể, một cái gì đó có "hình dạng". Tôi bắt đầu viết mã ngay lập tức và, việc thiếu thông tin , dẫn tôi đến các nhà tái cấu trúc thường xuyên. Mọi nhà tái cấu trúc đều khiến tôi nghĩ rằng có quá nhiều lỗ hổng trong cách hiểu về kinh doanh .

Làm thế nào tôi đã bắt đầu để giải quyết điều này?

Tôi buộc bản thân phải đọc tất cả các tài liệu được thực hiện trong quá trình phân tích chức năng và các giai đoạn trước đó. Tôi cố gắng làm điều đó vì tôi là khách hàng hoặc người dùng cuối . Tôi cần hiểu khách hàng đang tìm kiếm điều gì với ứng dụng và yêu cầu như vậy. Nhưng tôi cần tránh xa nhà tôi.

Công việc của chúng tôi cung cấp cho chúng tôi một kỹ năng tuyệt vời mà khách hàng không có. Chúng tôi nghĩ rằng trong các cấu trúc có điều kiện theo cách mà người khác không. Vì vậy, tôi bắt đầu đối đầu với các yêu cầu. Tìm kiếm mâu thuẫn hoặc mâu thuẫn . Một chút não bộ xung quanh những gì tôi đã hiểu. Xây dựng các tình huống giả định.

Nó dẫn tôi đến những câu hỏi và nghi ngờ. Tôi gõ xuống tất cả mọi người trong số họ và cuối cùng tôi đã thiết lập một cuộc họp với bất cứ ai có thể giải quyết những nghi ngờ của tôi.

Tóm tắt tôi thay đổi quan điểm của tôi. Tôi cố gắng nhìn vấn đề từ một góc độ khác. Nhưng tôi đưa một số kỹ năng của nhà phát triển vào quá trình. Những gì kết thúc trong một loạt các câu hỏi và nghi ngờ để được giải quyết. Sau khi giải quyết, sự hiểu biết của tôi về kinh doanh sâu sắc hơn.

Nghiên cứu> Nghi ngờ> Câu hỏi> Câu trả lời> Hiểu (lặp đi lặp lại chu kỳ)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.