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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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