Ограждения проекта: разработка комитетом
Когда вы заключаете контракт на создание решения для других — в первую очередь в Интернете, поскольку это та область, в которой я работаю, — я думаю, что есть ряд факторов, которые важны для проекта :
- Не должно быть «дизайна комитетом».
- Никто другой, кроме основной команды разработчиков, не должен иметь возможности обеспечивать разработку, подготовку и производство.
- Никто не должен иметь возможности писать для производства, кроме команды разработчиков (и даже тогда должен быть процесс развертывания).
Я всегда не решаюсь делать подобные заявления, поскольку они выглядят догматическими, но я обнаружил, что чем дольше я работаю в этой отрасли, тем больше я считаю эти три правила важными.
Или, возможно, они действительно просто рекомендации. В конце концов, есть выстрелы, сделанные до того, как мы на самом деле закончим.
Независимо от того, являются ли они больше предложениями или правилами, это не имеет большого значения. Есть причины, по которым мы все приходим к таким выводам, верно? Итак, в следующих нескольких постах (а не в одном длинном посте) я поделюсь причинами, по которым я считаю эти три правила важными.
Дизайн Комитета
Используя этот термин, я не имею в виду, что один человек должен нести ответственность за разработку сайта. Я просто имею в виду, что за это должно отвечать агентство или группа тех, кто занимается дизайном.
Дизайн комитетом — пренебрежительный термин для проекта, в котором участвует много дизайнеров, но нет единого плана или видения.
Таким образом, «комитет» в данном случае — это когда группа людей, или клиенты, или лица, связанные с клиентами в той или иной степени, приходят посмотреть на результат реализации (или даже просто на дизайн), отправить по электронной почте предложения о том, что они хотели бы сделать. хотелось бы увидеть и ожидать, что это произойдет.
То есть опыт, если данный дизайнер приносится в жертву мнению другой группы.
Принцесса Лея не была комитетом.
И, возможно, в крайних случаях (хотя я никогда не сталкивался с этим лично) использовать оплату как рычаг, чтобы добиться своего.
Дело в том, что люди, привлекаемые для разработки решения для заказчика, должны быть, как заявлено, экспертами в данной области. Они понимают типографику, цвета, разрешения экрана, специальные возможности и так далее.
Оставить их наедине с их областью знаний — всегда хорошая идея.
Забота о проекте
Ничто из этого не имеет ничего общего с тем, что кто-то имеет больший контроль над проектом, чем кто-либо другой.
Речь идет о том, чтобы убедиться, что все заинтересованные стороны проекта работают вместе друг с другом и не пересекают зоны ответственности. (Представьте, скажем, GIF-файлы, которые использовались бы для рекламы, если бы разработчики отвечали за рекламу. 😏)
Суть в том, что успешный проект — это когда каждый остается в своем углу и работает вместе в своей области знаний.
В противном случае все закончится рассинхронизацией и, по сути, создаст больше проблем, когда их не было (ну, по крайней мере, в определенной области), с которых можно было бы начать.
Что дальше?
В следующем посте я расскажу об идее предоставления сред, о том, что это значит и как это влияет на общую роль управления проектами. Но подробнее об этом я расскажу в посте.
В конечном счете, речь идет о том, чтобы убедиться, что у тех, кто имеет доступ для чтения и записи к различным областям, в которых может быть развернуто приложение или проект. Конечно, для некоторых, читающих это, это может показаться немного похожим на контент для «новичков» или вообще не похожим на контент, связанный с «разработкой».
Но если вы работаете над созданием решения вместе с другими, то вы, вероятно, столкнетесь с этими вещами, и проще иметь план, основанный на ошибках, сделанных другими (а именно мной 🙂), чем учиться чему-то новому. Трудный путь.