LOVELY PROFESSIONAL UNIVERSITY

School of MITTAL SCHOOL OF BUSINESS Faculty of

BUSINESS AND ARTS

Name of the faculty member: AMIT KUMAR SHARMA

Course Code: HRM101 Course Title: Human resource management

Academic Task No: 2 Academic Task Title: CA2

Date of Allotment: 2 feb,2022 Date of Submission: 20 mar,2022

Student Roll No: RQ2110A07 Student Reg. No: 12114152

Term: 2 Section: Q2110

Max. Marks: 30 Marks. Obtained:

Evaluation Parameters

Declaration:

I declare that this Assignment is my individual work. I have not copied it from any other students’
work or from any other source except where due acknowledgement is made explicitly in the text,
nor has any part been written for me by any other person.

Evaluation Criterion: Rubrics on different parameters

Student’ Signature:

Evaluator’s Comments (For Instructor’s use only)

General Observations Suggestions for Improvement Best part of assignment

Evaluator’s Signature and Date:

The performance evaluation for the post of SOFTWARE
DEVELOPER in an JANSSEN and JANSSEN.
PART 1:
Organizations consider different factors while picking the ideal metrics for
performance reviews. This usually depends on the organizational goals of the
software development company.

However, specific metrics cut across organizations due to their relevance in

every engineer performance evaluation. They are:

• Projects, operating engineer / Outcomes. The projects the engineer has

worked on are always considered in performance reviews.
• How their software works in production. The quality or usefulness of the
finished product is checked.
• Readability of code. Easy to read code is essential. Since changes or
modifications to the source code may be necessary, the code that some
developers can easily read is greatly appreciated.
• Interaction. Application engineers never work alone. The hallmark of a
good engineer is that he can easily communicate with his team members.
• Ability to update code. An engineer specializing in code review is always
an important addition to all teams.
• Work speed. High-speed engineers completed projects on time, thus
leading to a higher number of tasks completed in less time.
• Product sustainability. The long-term value of the enhanced product is
also assessed.
• Number of distractions. Program editors who are able to write code with
little or no bugs often have better updates.
• Communication skills. Employees who are able to provide and receive
information, within the team and their managers, usually do better.
• Leadership skills. Application engineers should be able to organize their
team members and make informed decisions without the help or input of
management.
• Test installation. Engineers who pre-install test kits often have high
performance updates.
Types of reviews

1. Manager updates

 These are the most common updates, especially for small organizations.
Managers are expected to be consistent and consistent in their reviews.
 They should also discuss the reason for the review in the team to reduce
any conflicts regarding the process of evaluating the performance of
developers.
 When providing a developer response, the administrator is expected to
provide solutions to software developer challenges.
 That could mean providing tools and resources that allow an engineer, for
example, to learn a new programming language, receive additional
training, or do advanced software courses.
 Visit Essentials for more insightful information that can help improve you
and your software team.
 The biggest problem managers face when making updates to software
engineering is bias.
 In order to be fair to all software developers, the administrator needs:
 Keep the roles and strengths in mind while exploring. Each member of the
team has different strengths and abilities.
 Checking all team members at the same level would be wrong and would
undermine the unique capabilities of application developers. This can lead
to frustration for team members and a lack of enthusiasm for work.
 Refuse to review the group or person you are most unfamiliar with. There
is no shame in admitting that you do not have a solid knowledge of the
job description of a particular team member or attitude toward his or her
job.
 While it is an opportunity for your management skills, refusing to write
reviews based on limited knowledge rather than doing what would
otherwise be far from the truth is a decent thing to do.
 Avoid situations that could lead to biased reviews. If the supervisor is
opposed to hiring a particular engineer or has personal problems that he
or she should address with a team member, it would be wise to skip the
supervisor's review of that team member.
 Other types of revisions may be made on behalf of a particular group
member. This is done just to prevent one-sided reviews.
2. Peer review

 These are the most accurate of all updates. The reason is, our colleagues
in the same software development company as the reviewer is testing.
 The reviewer spent a lot of time with a team member, and probably
worked on similar projects. Therefore, they are in the best position to test
the skills and growth of the reviewer.
 Anonymity is a common practice when conducting peer reviews,
especially when a manager feels that it can be effective in reducing bias in
his team.
 Anonymity promotes openness, increased participation in updates and
does not threaten workplace relationships.
 However, due to a lack of accountability, anonymous reviews can be easily
taken by the reviewer, and the reviewer can easily bias. It is also a
challenge to make anonymous reviews in a small group.

3. Self-examination

 Like other reviews, bias is a common problem in self-examination. People

tend to be overconfident or overconfident.
 Managers should make sure they consider the following when creating a
self-test engineer test form: Avoid open-ended questions as this will
reduce submission Focus on the critical work of team members.

PART 2:
 Before choosing the right appraisal software for software developer
reviews, understand that reviews should not just fix employees. They
should also teach and encourage them.

 Also, instead of always using annual software developer updates, consider

a common test.

 The timeline for annual updates is very long, and tracking developer
progress can be challenging.
  Instead, they should use weekly admissions, project end assessments,
and quarterly assessments to monitor developer performance.

 What are the best software developer review processes?

 Three key points for developing a software developer review template
include:

Code Quality
 Speed: How fast a software developer can code.
 Collaboration: How well they work with other colleagues.
 Since these three elements are required in the day-to-day operations of
an engineer, they are not as accurate in performing a performance review
as they do not take into account the function of the software developer.
 Why are they writing code?
 Why build software programs?
 In order to achieve best practices, it is necessary to change the way things
look at things that affect user experience. Make that a concern;
 Results: How did your input help us achieve the purpose of the product?
 Sustainability: How long will your product be a solution for users?
 Collaboration: How does your contribution improve other colleagues?
 By emphasizing these three processes from the hiring and first stages,
team managers can incorporate user information as a tradition among
developers. Even if you decide to hire a remote engineer, make sure they
understand the importance of user information.
 What are the challenges for testing application developers?
 In this section, we explore the most common challenges associated with
developer testing.

 Submission. Achieving the goal of app application development reviews

can be a challenge.

 This is because the performance of an engineer will always depend
  on the reviewer's perception of his or her roles, results, and work ethic.
These considerations can be helpful in the analysis if the reviewer pays
attention to the results of each team member and each skill.
 Exploring as a group or individually. Managers often have a say in the
review of an individual or as a team.
 Reviewing as a team may be unfair to the team members who are most
important to the success of the group.
 Also, if you only provide an update for each operation, the unit ceases to
be one. This problem can be solved by providing individual goals that help
to achieve the goal of the whole group.
 Lack of development activities. Performance appraisal is not required if
the organization does not provide staff development services.
 Just as organizations do testing and evaluation, they should also plan
programs to help application developers do better. Your task is not just to
identify the problems but also to help them fix them.

PART 3:
1. Let Your Good Judgment Be Your Guide

 A good manager has good judgment - if he does not, he is not a good

manager. If your supervisors do not have good judgment, find out what
they are doing.
 When it comes to testing good software developers, there is no
substitute for good, sound judgment.
 Think of it this way: You know exactly who the best engineers are, the
producers, the middle ones, and the ones who need to be molded or
exported.
 You can, if you are pressured, even explain automatically why you feel
that way.

2. Use Performance Test

 For two reasons: Encouraging people to do better and documenting poor

performance in the event of termination is required.
 Performance appraisal is a way to build your team members and
encourage them to get better.
  It should also be used to ensure that if you need to evict someone you
can forgive that decision and, if necessary, support the decision, even in a
court of law.

3. Know Your Team

 Use the good judgment I mentioned above to identify the strengths,
weaknesses, and weaknesses of your entire team.
 At any given time, you should know who is doing well and who is not. You
need to be able to name your superstars and those who need to improve,
from the top of your head.

4. Make Sure They Always Know Where They Stand

 This is important - don't let problems grow. If someone is not working well
or needs help, let them know right away and get help.
 Waiting until the end of the year for a review to tell someone you have a
bad problem for everyone. At the same time, be sure to let people know
when they are doing well.
 Managers should always provide feedback so that each team member is
always aware of how they are doing. No one in the company should have
any doubts about his position with his boss at any time.

5. Make Sure Your Righteous People Are Happy

 This is also important. A good, solid engineer equals his weight in gold.
You need to work hard to keep them happy.
 A very successful change can be more expensive than giving a good and
timely bonus or promotion. Happy engineers are productive engineers.
Good storage is very important.

6. Divide Group Members into Four Out of Four Categories

“He is a master engineer. Keep it up!"

“He is a good, solid engineer. Keep it up!"

“She struggles a little. Let's get help. ”

“Here is the box. Gather your things. "

  That separation should not be obvious. You have to say those things over
and over again as needed by the engineer himself.
 If you were going to legitimize it, you were going to have to change the
names, of course, but the idea is there.
 Distribution of those categories should be something like 10% / 80% / 5%
/ 5%. And there is nothing wrong with starting as 10% / 90% / 0% / 0%.

7. Do an Annual Test

 In addition it becomes a management responsibility for both the manager

and the engineer. Besides, if you always let people know where they
stand, you don't have to do it often.

8. Set One Goal: Do Your Work

 Because that's what we want our engineers to do, isn't it? To do their job.
We want them to fix as many bugs as possible.
 We want them to develop new software, in the right way. We do not want
them to be distracted by that simple goal.

Conclusion
 Finally, a good manager knows when an engineer is doing his job. In the
end, this is exactly what any developer wants to know
 that they do a good job and that their work is appreciated.