Organizations: cross-disciplinary collaboration

[amyjko]

In the bullet points for the important implications of what it means to be a software engineer, I see how the second bullet point could touch more on the importance of being a good collaborator as a software engineer. I see that there is a reference to “Cross-Disciplinary Perspectives on Collaborations with Software Engineers”, I believe it is good to recognize the importance of understanding the different roles but to also recognize why it is so crucial for software engineers to be good collaborators. Is it crucial to completing requirements, building ethical software, and more? How does it overall benefit an organization to have collaborative software engineers?

This chapter explains the various roles of software engineering teams, and how organizations are important. The content is explained clearly and shows how different roles contribute in different ways and make different types and levels of decisions. It could be beneficial to have an estimated number of each roles in software engineering teams. While a definitive number would vary based on the size of the team and company or the software type, it could be said that, for example, on a team of __, there might be around __ marketers, __ product managers, __ designers, __ software engineers, __ support members, and __ sales members. This would help a reader know, for example, are there typically more designers or software engineers? I think knowing the proportion of various roles would help myself and other readers better understand the structure of a software engineering team or organization.

In this chapter, the author described the different roles that are within a software organization and how these individual roles take on a very different task that makes the organization successful. Though one thing that I wished the author covered was how these very different roles interact and collaborate to achieve an organizational goal. For example, how a product manager will work with essentially everybody from policy regulators to marketers to engineers. It’s important to establish an understanding for each individual role but understanding how they connect and relate to each other can deepen students’ understanding of software organizations and the role of a software engineer.

In this chapter, including examples of how complex planning is and how it's done may add to the chapter. By highlighting or adding in pictures of planning boards, task assignment planning screenshots, or how all of that is upkept may help students relate that to other class (like INFO 380) which at the time may have not seemed as relevant in concept.

After reading chapter 2 of Cooperative Software Development a few ideas popped up in my head. It was mentioned in the chapter that when there is a division of roles, oftentimes there are parts of the organization where they don’t share knowledge even when it could be beneficial for everyone. I was wondering why this would happen and what could be done to mitigate this issue? I tend to think that in a working environment, teams/organizations would have multiple meetings to talk and share about their progress. Wouldn't this already be one way to solve the issue of the lack of knowledge spread inside of an organization? I was also curious about the Professor’s experience with taking on so many diverse roles at AnswerDash, was it challenging and if it was, how did you overcome those challenges and do you have any advice to give to others as to how to successfully tackle all the different roles.

This chapter really focused on explaining the different roles and how they all come together to make a final product. It was mentioned that it can be difficult to share information between each role. I'm just a little curious about how companies, especially bigger ones, typically share their information with one another? For example, it will probably be easy for a designer and software engineer to communicate if they are in the same room working for a small business, but how do they normally do this in a larger company?