Является ли продукт, ориентированный на разработчиков, хорошей вещью?

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

Джейсон Калаканис только что написал :

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

...

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

Это понятно: наши нетехнические люди ведут дискуссии и дебаты, в то время как Цукерберг кодирует свою следующую особенность. Вот почему никто не смог идти в ногу с Facebook!

В то время как MySpacers обсуждали, как использовать свой продукт, Facebook просто попробовал что-то.

Это на самом деле работает лучше на практике?

Продукты должны быть ориентированы на клиента.

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

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

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

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

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

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

(Должно быть ясно, что Facebook является примером того, как НЕ делать вещи тоже. Например, их неосторожный подход к вопросам конфиденциальности начинает приводить их к юридическим проблемам ...)

ИМХО, я бы сказал, что вы частично правы. Звучит разумно. Но это может относиться не ко всем продуктам / программному обеспечению. Итак, я бы сказал так. Дизайнер должен быть человеком с достаточным опытом разработки под его поясом, и не только этим - человек должен все еще программировать, а не просто проектировать.

Краткий ответ: иногда.

Длинный ответ: Разработка, ориентированная на клиента, работает, если вы знаете, кто ваши клиенты, и они знают, чего хотят.

Разработка, ориентированная на разработчиков, имеет ценность для людей, которые еще не осознают, что они покажутся ей полезными. Другими словами, иногда клиенты не всегда могут знать, чего они хотят. Новые требования могут исходить из существующего опыта того, насколько существующий продукт имеет недостатки. У Фейсбука не было покупателей, Цукерберг создал продукт, ответ перед вопросом. Созданный сейчас, Facebook находится под влиянием своих клиентов, но до того, как он был создан и во время создания, это была идея, ориентированная на разработчиков.

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

Разработка, ориентированная на разработчиков, является побочной, прототипной деятельностью, которая входит в сферу деятельности Google на 20%, в результате чего их разработчики тратят 20% своего рабочего времени на собственные проекты.

Чтобы создать хороший продукт, вам нужно много знаний о проблемной области. Разработчики могут управлять таким общедоступным продуктом, как Facebook, потому что он также решает проблему, с которой сталкиваются разработчики: как подключаться и оставаться на связи с друзьями и т. Д. То же самое относится и к продуктам, предназначенным для разработчиков программного обеспечения: разработчики знают, что IDE должен делать и как.

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

Я думаю, что это явно лучший подход к продукту, ориентированному на разработчика (например, AWS или Visual Studio), но я не уверен, что это явно лучший подход в целом. Я имею в виду, что обычно я наблюдаю, как все происходит наоборот: разработчики обсуждают лучший подход, в то время как нетехнические люди быстро принимают решения. Лично я склонен сказать, что правильный ответ находится где-то посередине. Должен быть менеджер по продукту, способный задавать широкое направление, которое затем реализуют разработчики.

Программное обеспечение, управляемое разработчиком, в большинстве случаев может быть лучше, чем программное обеспечение, управляемое менеджером. Менеджер видит наибольшую ценность в функциях (в основном в модных словечках), которые хорошо смотрятся в рекламе или могут быть использованы в речи. Разработчики видят разные ценности: производительность, меньшие ошибки, бережливый дизайн, ремонтопригодность. Это приводит почти к лучшему программному обеспечению.

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

Что делать, если вы производите продукты быстрее, которые никто не хочет использовать?

Сосредоточение внимания на одном атрибуте (функциональность, время выхода на рынок, цена, качество и т. Д.) Может иметь смысл для определенного момента времени. Например, Apple как бы бросила iPhone и iPad за дверь. Качество немного пострадало, но было очень важно быть первым.

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

НЕТ, если это не решает проблему реального мира

• Программисты обычно любят решать проблемы, иногда проблемы, которых еще нет :)
• Программисты обычно делают ужасные графические интерфейсы, потому что это вторичная мысль
• Большинство проблем пользователей не совпадают с проблемами программистов .
• Таким образом, продукт, управляемый программистами, обычно будет полезен для других программистов, но не так хорош для пользователей.

Также примечание на фейсбуке:

Успех фейсбуков не имеет ничего общего с его техническими достоинствами, скорее с идеей свиной спины, которая только что завоевала популярность. Фейсбук и другие случаются только один раз в «Google Blue Moon».

Тем не мение:

• Если у программиста есть настоящая «пользовательская» проблема, то это не проблема программиста. Тогда вполне вероятно, что это очень хорошая вещь. Если заинтересованным лицом является также разработчик, то по отношению к проблеме идеальная ситуация для отличного решения продукта.

(О боже ... где я только что прочитал что-то вроде: «У меня есть отличная идея! Все, что мне нужно, это разработчик». Думаю, это было в течение недели. Во всяком случае ...)

Великие идеи - это десять центов. Реализация вещи - вот что важно. Если разработчик обладает идеей, он может просто реализовать ее.