|
|||
![]() If I could distil my experience of successful and unsuccessful software projects I have worked on into one key point it would be this: One person and one person only should be responsible for owning all aspects of a design. This person should be thought of as a Design Dictator. The Dictator will be able to explain the rational for any design decision made and give it their full support, unless they come up with a very good reason to change their mind. The rest of the team should give the Dictator absolute loyalty in public, but within the team anyone should be able to propose changes to a design and be allowed to freely agitate within the team to gain support for their ideas. But the final decision must be made by the Dictator. The Dictator may decide to delegate certain responsibilities to another team member, but if they do this they have to support their delegate to the hilt and cannot dump any blame onto them. The buck definitely stops with the Dictator. The Dictator could be anyone in the project team, they might be a manager, designer, programmer or even a user. In extreme circumstances they could be overthrown and replaced, but this should be viewed as a failure of the project. The Dictator must work full time on the project and cannot just appear once or twice a week handing down pronouncements from on high. The Dictator must also take on responsibility for future maintenance and support of the system and cannot absolve themselves of this by passing the system onto another team. If the maintenance and support issues aren't resolved with the first release of the system then they will never be adequately resolved and the system will be a failure in the long term. Too Many Cooks Spoil the Pot This organisational system is only being honest about what really happens in most successful projects. Projects that succeed always have a character with a vision of what they want, and the determination to make it happen. This is often the reason why very small teams of 1 or 2 people can be very productive and very successful, but there is no reason why large teams cannot achieve the same results. Very often functionality is implemented in a system just because someone thought that it seemed like a 'cool' idea, and no-one has the authority to just say no. This is how we end up with software products where 99% of all users only use 5% of the functionality. ![]() But What About The Users ? If the Dictator wants to produce a successful system, then they will make damn sure that they understand what users need from the system and they will ensure that the rest of the team understand how important it is too. Usability should not need to be imposed from the outside. If a Dictator decides to use usability reviews and then disregard the results, then that is their choice and all the complaining in the world won't change it. But if the usability expert understands what the vision of the system is, then they should be able to tailor their contribution so that they become an integral part of the design process, rather than a box checker. |
|||
| email: |