4 ms·
That sucks. I worked in a role where I had to make decisions like that for the "implementers." Nobody liked that system. I left and so did almost everybody e
by dkarl 6y ago
That sucks. I worked in a role where I had to make decisions like that for the "implementers." Nobody liked that system. I left and so did almost everybody else.
In my current company, design tasks are just tickets, but we tend to assign implementation tasks to the same people who did the design tickets, when possible. However, design gets done in isolation, with little to no consultation. Some factors can trigger a design review, but it comes so late in the process that changing anything at that point is disruptive and regarded as a kind of failure.
Much better (in my opinion) is for one person, who will also implement the design if plans permit, to be responsible for the design, but the process of designing to be done "in public." Somebody is responsible for making sure the design is done on schedule, documented, etc., and they have the final call on any contentious issues, but it is discussed by everybody who is interested, and the meetings are publicized and open to anybody who wants to come. Since it is public, you get ideas from the most people, raise awareness so negative impacts to other systems are more likely to be spotted, and generally raise the level of understanding of the system as a whole among all the developers. Since it is individually owned, there is a single point of contact for product and management, it's clear who needs to be allocated time for documentation and research, and the implementer gets to feel a sense of ownership.