Нормально ли для разработчиков предлагать конструктивные идеи владельцам продуктов? [закрыто]

16

Я начал работать в качестве разработчика довольно недавно, прежде чем работал системным администратором.

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

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

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

louniks
источник
15
Конечно, программисты часто знают много вещей, о которых владелец продукта никогда не слышал. Возьмите веб-разработку, есть сервисы, apis, любое количество библиотек и плагинов и элементов пользовательского интерфейса. Мы часто работаем с клиентами, которые не имеют достаточно общего представления о том, что они хотят делать, но не знают, каковы их общие способы реализации или какие дополнительные функции будут возможны.
Торстен Мюллер
1
Чувствуете ли вы какие-либо обиды или негативные последствия для отказа от предложения функций? Похоже, ваша компания хочет поощрять практику, а не наказывать тех, кто этого не делает.
JeffO
Это нормальный процесс в двух компаниях, в которых я работал. Я пришел к выводу, что бизнесмены просто не имеют ни малейшего представления о том, насколько ценны нам, разработчикам, навыки решения / решения проблем. Прыжки с корабля, скорее всего, столкнутся с той же проблемой. Предлагая новые функции для людей продукта, как будто это было там решение, называется управление менеджерами и работает хорошо. Единственная проблема заключается в том, что вы не получаете кредит за свои идеи, но, по крайней мере, ваши функции реализуются.
Джейсон
ИМО это очень хорошая вещь и очень здоровая. Владельцы продуктов могут быть экспертами в области бизнеса, но, вероятно, не знают о каждой новой доступной технологии или техническом подходе. Кроме того, разработчики могут иметь представление о системе, основанной на различных аспектах работы непосредственно с кодом. Вы определенно хотите остаться в компании, которая приветствует идеи от всех, независимо от роли. Это не значит, что владельцы невежественны, это означает, что они открыты для всех.
Кен Лю

Ответы:

2

Это зависит от того, что вы подразумеваете под характерными идеями.

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

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

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

Робби Ди
источник
1
Я не интерпретирую философию моей компании как просьбу разработчиков придумывать истории, и я не помню, чтобы это происходило. Я думаю, что они хотят, чтобы после того, как идея была выдана и разработчик взял на себя ответственность за ее выполнение, разработчик обязан отстаивать эту идею до конца.
Louniks
1
То есть, вы говорите, что раздается сигнал тревоги, когда разработчик думает об идее, о которой не думает владелец продукта? Почему это так плохо?
Стефан Биллиет
1
Бросать идеи хорошо - это неотъемлемая часть планирования игры. Если бы это была новая история, я бы усомнился в этом. Истории приносят потребительскую ценность, которую, честно говоря, разработчики обычно не могут оценить (если они не эксперты в предметной области). То, появляется ли что-то в итерации, определяется историей и усилиями разработчика в игре планирования. Участие разработчиков в создании историй может вызвать здесь потенциальный конфликт интересов. Это не значит, что этого не может быть - просто владелец продукта должен был бы защищать его, иначе это хвост, который виляет собакой.
Робби Ди
47

Причина, по которой вы говорите, что многие разработчики являются «пассивными», заключается в том, что для того, чтобы прийти к хорошим идеям о продукте, требуется определенный объем знаний и опыта. Но если они приходят, нет никаких причин не предлагать им и защищать их.

Имейте в виду, что разработчики, владельцы продуктов, продавцы и т. Д. Работают в одной команде с единой целью: создать успешный продукт. Работайте для достижения этой цели, насколько вы можете.

Стефан Биллиет
источник
Я думаю, что вы прибили это - я попал в команду, работающую с технологиями, с которыми у меня очень мало опыта, поэтому мне трудно быть активным. Должен быть период обучения, в течение которого я остаюсь пассивным. После того, как я начну чувствовать себя комфортно с технологией, я могу начать проявлять инициативу.
Louniks
1
@louniks нет, ты упускаешь суть. Технология не имеет значения. Бизнес это то, что имеет значение. Насколько прозрачны деловые люди? Знаете ли вы, как бизнес собирается зарабатывать деньги? Знаете ли вы, как продукт, над которым вы работаете, соответствует другим продуктам компании? Если нет, то ваш работодатель несправедлив по отношению к вам. Вы не можете предложить функции, если вы не знаете бизнес-план.
Рибальд Эдди
3
@RibaldEddie Я не согласен с последней частью. Любой должен быть свободен, чтобы предложить функции. Менеджмент и владельцы продуктов по-прежнему могут определять, будет ли эта функция где-либо. Не забывайте, что разработчик, обладающий достаточными знаниями предметной области и техническими знаниями, может предложить огромную, прибыльную функцию, которая полностью выходит за рамки первоначального бизнес-плана. Владелец продукта может никогда не прийти к той же идее из-за ограниченных технических знаний.
Дэн Лайонс
1
Это похоже на опасную ситуацию: это означает, что деловые люди, на которых вы работаете, не знают, что делают. Это их работа, чтобы быть экспертами в этой области. Иначе почему они там? Шутки в сторону. Если разработчики предоставляют такую ​​информацию, разработчики могут просто руководить компанией. Все остальное - пустая трата времени.
Рибальд Эдди
Вам не всегда нужны подробные знания предметной области, чтобы предлагать технические улучшения ...
Робби Ди,
5

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

Ну, в моей организации я этот человек. Я инженер по требованиям, тот, кто научился составлять хорошие спецификации и выбирать функции, которые приводят к созданию высококачественного программного обеспечения с удобным дизайном взаимодействия. (В других организациях эту же работу получает человек из UX, возможно, вы более знакомы с этим термином).

И я могу вам сказать: получить хорошую спецификацию сложно. Конечно, разработчики ненавидят это делать. Для них это бремя - они здесь для того, чтобы создавать программное обеспечение, а не думать о силовых играх среди заинтересованных сторон и ментальных моделях ленивых пользователей. Но вы знаете, что? Это бремя для владельцев продуктов тоже. Они не знают лучше, какие функции должно содержать их программное обеспечение, чем разработчики или пользователи. Создание жизнеспособной спецификации - это выученный навык, и если вы никогда его не изучали, вы не можете быть в этом хороши. Конечно, есть много разработчиков и владельцев продуктов, которые могут сделать это, потому что они должны были сделать это в предыдущих проектах. Но средний владелец или разработчик продукта борется с этим, потому что это, естественно, не их работа. Не каждый, кто может водить машину, может создать машину; так же,

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

Когда в структуре проекта нет инженера требований, возникает другая проблема: модератора нет. Все разработчики находятся на технической стороне, все владельцы продукта на стороне бизнеса. Когда две культуры сталкиваются, могут возникать конфликты, когда каждая сторона считает другую глупой и необоснованной (потому что она использует свою собственную систему ценностей для оценки). Итак, поговорите с владельцем вашего продукта о возможных функциях, но будьте вежливы и терпеливы, даже если вы думаете, что он этого не заслуживает; Успех проекта зависит от того, насколько хорошо вы двое можете ладить, и иногда принятие неоптимального решения лучше, чем вообще никакого решения из-за конфликта. Может быть полезно установить иерархию и дать одному из вас последнее слово, так как это предотвращает тупиковые конфликты. Если он получит последнее слово, поверьте ему, даже если вы чувствуете, что это несправедливо.

О «пассивной» части: если у вас нет идей, не пытайтесь придумать что-то, чтобы просто проявить активность. Если владелец продукта уже небезопасен и не знает хороших критериев для оценки своих или ваших идей, странные идеи «просто иметь что-то» сделают и без того сложную ситуацию еще более сложной. Создание хороших идей не волшебство, а знание. Если вы не изучили его из учебников, вам, вероятно, понадобится несколько лет опыта разработки, особенно в проектах, где вы знакомитесь с пользователями или сгенерированными пользователями данными о юзабилити (аналитика, измерения удовлетворенности), прежде чем ваш мозг сам разберется с шаблонами. и вы начинаете замечать: здесь есть проблема, которую мы можем решить. Пользователи, кажется, что-то упустили на этой странице, что это может быть? Тогда у вас будут хорошие идеи для обмена.

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

А если вы в команде с инженером требований?

Я люблю слышать идеи от всех! Да, иногда идеи разработчиков ужасны (когда они хотят, чтобы пользовательский интерфейс следовал логике программирования). Идеи владельцев продуктов также часто бывают ужасными (когда они хотят, чтобы солнце и луна были ограничены в бюджете - о, и пользователь должен вводить страницы личной информации с высочайшим качеством данных, не получая ничего взамен). Но моя работа заключается в том, чтобы придумать спецификацию, которая будет полезна для всех в команде. И даже если ваша идея никогда не сработает, услышав ее, я осознаю, что у вас есть проблемы. Возможно, вы выбрали неправильное решение, чтобы предложить, но это не делает ваше беспокойство менее обоснованным. Если вы заметили это, это, вероятно, необходимо устранить (или мне нужно найти причину, по которой это не является угрозой). Если у вас есть инженер по требованиям, отвечающий за спецификацию, не стесняйтесь обращаться к ним с предложениями. Если они не слышат вас, они делают что-то не так (обратите внимание, что «рассмотреть» не означает «принять»).

Инженер по требованиям должен рассматривать проект с точки зрения каждого участника отдельно (а иногда и одновременно). Мы всего лишь люди, и мы часто терпим неудачи. Если вы готовы предоставить свою истинную точку зрения, а не ту точку зрения, которая, как мы думаем, у вас есть, то ваш вклад очень ценен.

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

Вывод 2: Если в команде есть инженер по требованиям, обратитесь к ним с предложениями по особенностям продукта. Вам не нужны бархатные перчатки на этот раз.

И, наконец, что, если нет инженера по требованиям, владелец продукта перегружен и борется за идеи, начальник демонстративно смотрит на вас, а у вас нет идей предложить?

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

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

Третий вариант - на самом деле изучить некоторые инженерные требования самостоятельно. Это умение высоко ценится в наши дни. Даже если вы никогда не планируете занимать должности, на которых вы работаете инженером по работе с требованиями на полный рабочий день, наличие этого навыка повышает вашу ценность как разработчика, поскольку позволяет лучше понимать других членов вашей команды (и ваших пользователей) и делает Процесс разработки проходит более гладко. И вам не нужно углубляться во все это. Учебник начального уровня, в котором объясняются задачи, рабочие процессы, ментальные модели и модели данных, ориентированные на пользователя, уже позволит вам обнаружить множество возможностей для улучшения программного обеспечения, разработанного командой бизнесменов и разработчиков. Дон» t для самых толстых книг, предназначенных как справочник для академиков (как недавний перевод Pohl на английский язык) - они - больше список всех возможных методов для каждого маленького шага, без объяснения, как фактически сделать их. Выберите что-то ориентированное на практику.

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

Заключение 3: вместо того, чтобы ждать годами, чтобы получить интуитивное понимание, прочитайте одну или две книги, и у вас уже будут хорошие идеи

rumtscho
источник
+1 Это действительно исчерпывающий ответ. «Выводы» работают как хорошие TL;DR.
Джеймс Хури
4

Да, это вполне нормально.

Хорошо известная 80% работа - 20% инновационная модель в Google, где люди 20% своего времени посвящают тому, что им нравится. Таким образом, они получают не только новые функции, но и совершенно новые продукты и услуги.

Я слишком пассивен, должен ли я проявить инициативу и начать рассылать идеи владельцам продуктов?

Это зависит от вашей личности. Я работал с действительно страстными людьми, но также и с людьми без каких-либо эмоций, которые делают свою 8-часовую смену и уходят домой.

BЈовић
источник
Похоже, что в Google разработчики проводят некоторое время, будучи владельцем продукта.
JeffO
Сотрудники Google, работающие над своими собственными проектами, не одно и то же, если вы не говорите о другой инициативе?
Робби Ди
@RobbieDee Да, верно. Они работают над своими проектами, но Google продает сервисы, которые выходят из проектов.
BЈовић
Я имею в виду, что такие проекты не обязательно находятся в рамках существующего гибкого проекта. Они могут быть полностью автономными.
Робби Ди