Half a month ago, the Bull game columnist has a "good talking Li" and raised a question:
"A question: is the programmer a Fumiomi or a warlord?" ”
There are a few answers, but I would like to answer the majority of the "generals".
There are three reasons:
The majority of programmers are more straight, normative and disciplined and military-like.
The programmer's work is groundbreaking, not 0 or 1.
Programmers are generally lower in EQ, relative to document workers. Of course, as it practitioners of you, may have your different views, the benevolent see of the beholder.
As a military commander, in the research and development team, team building is very important, such as:
When you are busy, you are free to fight.
I personally as "programmer", "Team Leader", "Gcdn Community Moderator", "Programmer" "wonderful" experience to share my summary of the development team building:
Team Building, not only eating and drinking, sightseeing, but worth leader to focus on the first priority.
Team Building is not a leisure "food and clothing", but a lasting "national policy".
Team Building, is the team standardization, Unite as one, high execution of the necessary conditions.
My experience of team building over the past few years is no wonder about these points.
A team team busy, whether it is the development process or market process, if in a certain period of time (in years), the overall load high, average performance is low, then the probably problem is in team building, such as more novice, communication problems, coordination is not smooth, project rework and so on: busy There are blind also .
The primary goal of the research and development team is to break down the tasks and indicators and then deliver them efficiently.
However, in the specific implementation process, due to timing problems, the general lack of resources, inexperience, coordination problems and so will lead to such, such problems, these problems accumulate, gradually will be cumbersome, it is likely to become a team disaster: the brain drain frequent, people and people gap, to cope with errands.
These adverse results are collectively referred to as the team's emotional management. This PPT was a training package for team leader, an IBM lecturer, organized by the head office in Beijing many years ago (some excerpts):
So, what should the team building of the research and development team do? Here is a checklist for reference (specifications and forms that need to be tailored to local conditions)
Weeks of regular Freetalk: business experience sharing and technical exploration training
Honest communication: Three satisfied and three dissatisfied, quality.
Regular meeting system: weekly meeting, monthly meeting
Build continuous Integration System, milestone management
Project management tools: bugs, Task decomposition
Im tools: such as QQ Group, Fetion Group, group
Requirements review System, requirements change process
Reasonable overtime adjustment and reasonable salary change
Logistic support: Personal overtime meal, taxi reimbursement, etc.
Assorted: Eating, drinking, traveling, etc.
I would like to add one more: Agile development, but sorry, studied for a long time, but failed to practice successfully.
Of course, not many years of the first-line IT research and development (including technical and document types), it is difficult to debt settled the development cost account:
"Think about making money for the company, not about saving the company." ”
Reference: "Start season: School is school, learning is learning"
Reprint please indicate to go to the entrance season again, talk about the team building of software research and development
In the entrance season, we talk about the team building of software research and development.