[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } } ]
{ "author_name": "Редакция vc.ru", "author_type": "self", "tags": ["\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441\u044b","\u0434\u0438\u0437\u0430\u0439\u043d","\u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u0435_\u0440\u043e\u043b\u0435\u0439_\u0432_\u043a\u043e\u043c\u0430\u043d\u0434\u0430\u0445","\u043f\u0440\u043e\u0435\u043a\u0442\u043d\u0430\u044f_\u0440\u0430\u0431\u043e\u0442\u0430","\u0440\u0430\u0431\u043e\u0442\u0430_\u0432_\u043f\u0440\u043e\u0435\u043a\u0442\u0435"], "comments": 14, "likes": 15, "favorites": 17, "is_advertisement": false, "section_name": "default", "id": "10931" }
Редакция vc.ru
6 194

Мнение: Компании должны отказаться от чёткого распределения ролей в проектах

Вице-президент по дизайну Buzzfeed

Поделиться

В избранное

В избранном

Вице-президент по дизайну Buzzfeed Кэп Воткинс опубликовал в своём блоге заметку о проблемах распределения ролей в командах. По его словам, строгое распределение задач между участниками проекта приводит к созданию разрозненных продуктов, поэтому необходимо как можно сильнее размывать роли в компании.

Когда я только начинал работать дизайнером, я очень злился на то, как люди воспринимали мою профессию. В то время сообщество дизайнеров, как одно целое, выражало несогласие с позицией, что дизайнеры занимаются только визуальной стороной проекта — делают так, чтобы все «выглядело красиво».

Почти каждый день появлялись статьи в блогах или подкасты, в которых рассказывалось, как объяснить клиентам или коллегам, что мы можем вносить больший вклад в процесс, и что нам следует заниматься пользовательским опытом, также как и графическим дизайном. И я, тогда еще совсем молодой дизайнер, естественно, безоговорочно верил этому.

Свою злость я пронес через мои первые работы. Я вдруг обнаружил, что отношусь к себе как к «владельцу дизайна» (design owner), в противовес такому термину как «владелец продукта» (product owner) или просто ради того, чтобы противопоставить себя инженерам-разработчикам, которые просто создавали то, что, по их мнению, было правильно.

Нет ничего в моей карьере, о чем я жалел бы больше, чем то, как твердо и долго я придерживался этой идеи. Неизбежно было то, что я лишал права голоса моих коллег, которые с дизайном связаны не были.

Я приводил в своей работе смешные аргументы, которые не имели никакого отношения к продукту, а, скорее, к тому, кто и за какие решения нес ответственность.

Вместо того, чтобы хвататься за возможность сотрудничества и перенимать сильные стороны других дисциплин, я создал вокруг себя бункер, стены, огороженную территорию.

Даже сегодня мы постоянно создаем такие бункеры в своих организациях. Только подумайте, сколько существует компаний, команды в которых выглядят вот так:

Вместо того, чтобы выглядеть вот так:

То, что мы создаем индивидуальных «владельцев» внутри проектов и сфер ответственности, является не только источником затруднений, но и вообще — абсолютно не практично. Инженеры постоянно принимают решения, которые влияют на концепцию продукта и пользовательский опыт. Дизайнеры создают артефакты, которые влияют на то, как продукт внедряется и отлаживается. Менеджеры по продукту постоянно взвешивают и дизайн, и реализацию продукта, а от их способности бороться за идеи своих команд зависит и сам продукт и его будущее.

В конце концов, если держаться за термин «владение», можно нанести непоправимый ущерб своей способности хорошо выполнять свою работу. Оказывается, что лучше всего, чтобы продукт создавался не владельцем, и не группой владельцев. Лучше всего работа делается теми, кто принимает факт, что все, кто работают в команде, владеют продуктом, дизайном и кодом в одинаковой мере.

Люди, работающие в очень успешных командах понимают и принимают неизбежную размытость своих ролей и обязанностей. Они делятся знаниями и совместно принимают решения, что в результате улучшает продукт, над которым они работают.

Мой совет дизайнерам: вам стоит не только начать обращать внимание на то, что заботит членов вашей команды, не только относиться к их вопросам и идеям как к стоящим внимания, но даже наоборот — следует активно узнавать их мнение о продукте.

Вам следует вовлекать коллег в рабочий процесс с самого начала, будь то обмен сообщениями через коллективную доску, или совместный поиск творческих идей, или регулярный обзор дизайна совместно с командой.

Люди не привыкли к тому, чтобы давать обратную связь, так что вам придется вытаскивать ее из них и предоставлять им множество различных возможностей, чтобы внести свой вклад в проект.

Совет инженерам: вам нужно научиться объяснять тонкости разработки программного обеспечения дизайнерам и менеджерам по продукту так, чтобы они могли участвовать в процессе (а это может быть трудно, особенно если речь идет о сложной теме или о некоторых ньюансах).

Лично для меня не было ничего более ценного чем то, что инженеры объясняли мне, как пишется код, и терпеливо отвечали на мои вопросы. Благодаря им я могу разговаривать более уверенно о том, как реализовать детали продукта, над которыми я работаю. Иногда инженеру приходилось объяснять мне что-то различными способами, даже рисовать, прежде чем я мог ухватиться за концепт.

А для вас, менеджеры по продукту, эта работа сводится к составлению перспектив развития продукта.

Вместо того, чтобы приходить к коллегам с планом или списком идей, из которых те будут что-то выбирать, лучше сразу вовлечь их в процесс развития продукта.

Объясняйте команде то, чем вы занимаетесь — что важно, какие стратегии нужно применять, в каком порядке делать дела или как определить объем работ по проекту. Если вы можете предоставить дополнительные возможности инженерам и дизайнерам, если вы поможете им думать так, как думают менеджеры по продукту, тогда ваша команда во многом станет управлять собой.

Но это вовсе не означает, что команда не будет нуждаться в вас. Это означает, что вы по-настоящему хорошо справляетесь со своей работой. А значит, вы сможете сосредоточиться на чем-то более крупном, на более долгосрочных проектах.

Пока я писал все это, я подумал, что нам стоит относиться к своим ролям как к роли эксперта и учителя, а не владельца продукта. Мы должны относиться к себе как к источнику информации, а не как к закрытому бункеру. Мы должны сотрудничать, а не держать всю информацию при себе.

Нужно ослабить хватку и пригласить других помочь вам продвинуть работу вперед. Делая так, мы не только освобождаем время для улучшения продукта, но, кроме того, мы расширяем собственные области знаний и компетентность, мы учимся у тех, с кем мы работаем каждый день.

#Интерфейсы #распределение_ролей_в_командах #проектная_работа #работа_в_проекте

Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

Комментарии Комм.

0 новых

Популярные

По порядку

Прямой эфир

Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления