Чи корисна для розробників продукція?

Я працюю в компанії, де генеральний директор керує командою продуктів, яка макетує функції та потрапляє в колі розробників, щоб потім реалізувати ці функції. Звичайно, є деяка ітерація, думки розробника дотримуються. Але мені цікаво, наскільки ефективний цей процес.

Джейсон Калаканіс щойно написав :

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

...

Тоді мене це дійсно вразило: стартапи, керовані розробниками, завжди виробляють продукт швидше.

Це безперечно: наші нетехнічні люди ведуть дискусії та дискусії, в той час як Цукерберг кодує свою наступну функцію. Ось чому ніхто не зміг не відставати від Facebook!

Поки MySpacers обговорювали, як повторити свій продукт, Facebook просто спробував речі.

Чи справді це працює краще на практиці?

Продукти повинні бути покупців.

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

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

Як розробник, ви повинні знати правильні запитання для зацікавлених сторін, щоб ви могли поєднати свій досвід із їхніми потребами створити найкращий можливий продукт.

Як розробник, я хотів би подумати, що ми робимо кращу роботу, ніж менеджери та дизайнери. Але я не думаю, що ти можеш узагальнити.

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

Однак я думаю, що більш зухвалою справою є не люди, а те, як вони підходять, підходять до проблеми. Підхід, який працює, полягає в тому, щоб знижувати та реалізовувати речі, а не проводити нескінченні зустрічі та вирубування дерев, щоб придумати «ідеальний» дизайн. Це дійсно Agile проти водоспаду переглянути.

(Має бути зрозуміло, що Facebook - це приклад того, як НЕ робити теж речі. Наприклад, їхній кавалерський підхід до питань конфіденційності починає спричиняти їх юридичні проблеми ...)

ІМХО, я б сказав, що ви частково праві. Це звучить розумно. Але це може не стосуватися всіх продуктів / програмного забезпечення. Отже, я б сказав так. Дизайнером має бути людина, яка має великий досвід досвіду розробки під своїм поясом І не тільки це - людина все одно повинна кодувати, а не тільки проектувати.

Коротка відповідь: іноді.

Довгий відповідь: Розробка замовника працює, якщо ви знаєте, хто ваші клієнти, і вони знають, чого хочуть.

Розвиток, орієнтований на розробників, заслуговує людей, які не усвідомлюють, що вважають його корисним. Іншими словами, іноді клієнти не завжди можуть знати, чого хочуть. Нові вимоги можуть випливати з існуючого досвіду дефіциту існуючого продукту. Клієнтів у Facebook не було, Цукерберг створив продукт, відповідь перед питанням. Зараз створений, Facebook впливає на своїх клієнтів, але до його створення та під час створення він був ідеєю, орієнтованою на розробників.

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

Розробка, орієнтована на розробників, - це бічна сторінка, яка розробляє прототипи, потрапляючи на 20% арену Google, завдяки чому їх розробники витрачають 20% свого робочого часу на власні проекти.

Щоб створити хороший продукт, вам потрібно багато знань про проблемну область. Загальнодоступний продукт, як-от facebook, може бути створений розробниками, тому що він вирішує проблему, яку мають і розробники: як підключитися та підтримувати зв'язок з друзями тощо. Це ж ще більше стосується продуктів, спрямованих на розробників програмного забезпечення: Розробники знають, що IDE має робити і як.

Але для багатьох інших проблемних областей розробники часто просто недостатньо знають. Навіть із загальним розумінням та певним досвідом, вони часто прагнуть реалізувати круті функції чи функції, які легко здійснити, але не додають великої цінності для замовника та роблять продукт більш складним. Це випадки, коли продукцію слід орієнтувати на доменних експертів.

Я думаю, що це, очевидно, найкращий підхід до продукту, орієнтованого на розробників (наприклад, AWS чи Visual Studio), але я не впевнений, що в цілому це краще підхід. Я маю на увазі, як правило, я бачу, що все відбувається навпаки: розробники стоять навколо, аргументуючи найкращий підхід, тоді як нетехнічні люди швидко приймають рішення. Особисто я схильний сказати, що правильна відповідь десь посередині. Повинен бути менеджер продуктів із можливістю задавати широкий напрямок, який потім розробники реалізують.

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

Але найкращим було б програмне забезпечення, кероване користувачами. Користувачі дійсно знають, що їм потрібно, що допомагає їм робити свою справжню роботу. Це був би ідеал.

Що робити, якщо ви робите продукцію швидше, яку ніхто не хоче використовувати?

Зосередження уваги на одному атрибуті (функціональність, час на ринок, ціна, якість та ін.) Може мати сенс для певного моменту часу. Наприклад, Apple начебто кинув iPhone і iPad з дверей. Якість трохи постраждала, але було дуже важливо бути першим.

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

НІ, якщо це не вирішує справжню світову проблему

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

Також примітка до номіналу:

Успіх книжок у лицьових книгах не має нічого спільного з його технічними достоїнствами, його ідеєю про порося назад, яка щойно потрапила на справді великий і сніговий сніг. Книга з обличчям та ін. Трапляються лише один раз на "Google Blue Moon".

Однак:

• Якщо у програміста є справжня проблема "користувача", яка не є проблемою програміста. Тоді ймовірно, що це дуже гарна річ. Якщо учасником є ​​також розробник, то стосовно проблеми є ідеальною ситуацією для чудового вирішення продукту.

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

Чудові ідеї - це ні десяток. Реалізація речі - це важливе значення. Якщо розробник той, хто має чудову ідею, він може просто його реалізувати.