Czy produkt opracowany przez programistę to dobra rzecz?

Pracuję w firmie, w której CEO zarządza zespołem ds. Produktu, który wykonuje makiety funkcji i upuszcza na rynek programistów, aby następnie wdrożyć te funkcje. Oczywiście jest pewna iteracja, opinie deweloperów są szanowane. Ale zastanawiam się, jak skuteczny jest ten proces.

Jason Calacanis właśnie napisał :

Doktryna Zuckerberga: programiści projektują produkty o znacznie poprawionej szybkości i funkcjonalności w porównaniu do menedżerów produktów i projektantów, przeważając nad potencjalnymi błędami i wadami.

...

To naprawdę mnie uderzyło: start-upy napędzane przez programistów zawsze wytwarzają produkt szybciej.

Ma to uzasadnienie: nasi nietechniczni ludzie prowadzą dyskusje i debaty, a Zuckerberg koduje swoją kolejną funkcję. Właśnie dlatego nikt nie był w stanie nadążyć za Facebookiem!

Podczas gdy MySpacers debatowali, jak iterować w swoich produktach, Facebook po prostu próbował różnych rzeczy.

Czy to faktycznie działa lepiej w praktyce?

Produkty powinny być ukierunkowane na klienta.

Jeśli Twoi klienci są programistami i korzystasz z własnego produktu (w każdym razie powinieneś), myślę, że możesz być swoim najlepszym klientem.

Ale jako programista Twoja perspektywa jest już zagrożona przez to, co dzieje się pod maską. Musisz poinformować klienta, że ​​to, co robisz za pomocą interfejsu użytkownika lub przepływu pracy aplikacji, jest głupie i nie ma żadnego sensu.

Jako programista musisz znać właściwe pytania, które należy zadawać interesariuszom, abyś mógł połączyć swoje doświadczenia z ich chęcią stworzenia najlepszego możliwego produktu.

Jako programista chciałbym myśleć, że wykonujemy lepszą pracę niż menedżerowie i projektanci. Ale nie sądzę, że można uogólnić.

Jednym z problemów z programistami tworzącymi projekt jest to, że mogą nie mieć kontaktu z potrzebami użytkowników końcowych i mogą nie być dobrzy w zadawaniu właściwym osobom właściwych pytań. Menedżer, a zwłaszcza dobry projektant, może lepiej to rozgryźć.

Myślę jednak, że bardziej przekonującą rzeczą nie są ludzie, ale sposób, w jaki podchodzą do problemu. Podejście, które działa, to zejść na dół i wdrożyć różne rzeczy, zamiast spędzać niekończące się spotkania i ścinać drzewa, aby wymyślić „idealny” projekt. Naprawdę jest to przegląd Agile kontra Waterfall.

(Powinno być jasne, że Facebook również jest przykładem tego, jak NIE robić rzeczy. Na przykład ich nonszalanckie podejście do kwestii prywatności zaczyna powodować kłopoty prawne ...)

IMHO, powiedziałbym, że masz częściowo rację. Brzmi rozsądnie. Może to jednak nie dotyczyć wszystkich produktów / oprogramowania. Ujmę to w ten sposób. Projektant powinien być osobą z dużym doświadczeniem programistycznym pod swoim pasem ORAZ nie tylko to - osoba ta powinna nadal kodować, a nie tylko projektować.

Krótka odpowiedź: czasami.

Długa odpowiedź: Programowanie ukierunkowane na klienta działa, jeśli wiesz, kim są Twoi klienci i wiedzą, czego chcą.

Rozwój programistyczny ma wartość dla osób, które nie zdają sobie sprawy, że uznają je za przydatne. Innymi słowy, czasami klienci nie zawsze wiedzą, czego chcą. Nowe wymagania mogą wynikać z istniejącego doświadczenia dotyczącego niedoboru istniejącego produktu. Nie było żadnych klientów na Facebooku, Zuckerberg stworzył produkt, odpowiedź przed pytaniem. Powstały Facebook jest pod wpływem klientów, ale zanim został stworzony i podczas tworzenia, był pomysłem dewelopera.

Rozwój zorientowany na klienta jest idealny dla ustalonego, być może dojrzałego produktu zarabiającego pieniądze lub nowych iteracji produktu na tym samym rynku, gdzie ignorowanie życzeń klienta byłoby wysoce szkodliwe dla przyszłych strumieni dochodów.

Programowanie przez deweloperów jest działaniem pomocniczym i prototypowym, wchodzącym w skład 20% areny Google, przy czym ich programiści spędzają 20% czasu pracy na własnych projektach.

Aby zaprojektować dobry produkt, potrzebujesz dużej wiedzy na temat dziedziny problemów. Ogólnodostępny produkt, taki jak Facebook, może być prowadzony przez programistów, ponieważ rozwiązuje on również problem programistów: jak się łączyć i utrzymywać kontakt ze znajomymi itp. To samo dotyczy jeszcze bardziej produktów skierowanych do programistów: programiści wiedzą, co IDE powinno zrobić i jak.

Ale w wielu innych domenach problemowych programiści często po prostu nie wiedzą wystarczająco dużo. Nawet z ogólnym wglądem i pewnym doświadczeniem, często mają tendencję do wdrażania fajnych funkcji lub funkcji, które są łatwe do wdrożenia, ale nie dodają wiele wartości dla klienta i sprawiają, że produkt jest bardziej złożony. Są to przypadki, w których produkty powinny być prowadzone przez ekspertów w dziedzinie.

Myślę, że jest to zdecydowanie najlepsze podejście do produktu zorientowanego na programistę (takiego jak AWS lub Visual Studio), ale nie jestem pewien, czy jest to ogólnie lepsze podejście. Mam na myśli, że zazwyczaj widzę, że dzieje się na odwrót: programiści opowiadają się za najlepszym podejściem, a osoby nietechniczne szybko podejmują decyzje. Osobiście jestem skłonny powiedzieć, że poprawna odpowiedź jest gdzieś pośrodku. Powinien istnieć menedżer produktu z możliwością ustalenia szerokiego kierunku, który następnie wdrażają programiści.

Oprogramowanie sterowane przez programistów może być w większości przypadków lepsze niż oprogramowanie kierowane przez menedżera. Menedżer widzi największą wartość funkcji (głównie modne funkcje), które dobrze wyglądają w reklamie lub mogą być użyte w mowie. Programiści dostrzegają różne wartości: wydajność, mniejsze błędy, oszczędny projekt, łatwość konserwacji. To prawie prowadzi do lepszego oprogramowania.

Ale najlepsze byłoby oprogramowanie sterowane przez użytkownika. Użytkownicy naprawdę wiedzą, czego potrzebują, co pomaga im wykonywać swoją prawdziwą pracę. To byłby idealny.

Co jeśli produkujesz produkty szybciej, z których nikt nie chce korzystać?

Skupienie się na jednym atrybucie (funkcjonalność, czas wprowadzenia produktu na rynek, cena, jakość itp.) Może mieć sens w określonym momencie. Np. Apple rzuciło iPhone'a i iPada za drzwi. Jakość trochę ucierpiała, ale to było ważne, aby być pierwszym.

Myślę, że to cię boli, jeśli skupisz się na jednym aspekcie tylko na dłuższą metę.

NIE, chyba że rozwiąże problem rzeczywistego świata

• Programiści zazwyczaj uwielbiają rozwiązywać problemy, czasem do problemów, które jeszcze nie istnieją :)
• Programiści zwykle tworzą okropne GUI, ponieważ jest to drugorzędna myśl
• Większość problemów użytkownika nie jest tym samym, co problemy programisty .
• Tak więc produkt sterowany przez programistę będzie zwykle dobry dla innych programistów, ale nie tak dobry dla użytkowników.

Również uwaga na facebooku:

Sukces face-booków nie ma nic wspólnego z jego zaletami technicznymi, jest raczej pomysłem typu piggy back, który właśnie wpadł na naprawdę dużą i śnieżną kulę. Face-book i in. Zdarzają się tylko raz w „Google Blue Moon”.

Jednak:

• Jeśli programista ma prawdziwy problem z użytkownikiem, taki, który nie jest problemem programisty. To prawdopodobne, że to bardzo dobra rzecz. Jeśli interesariusz jest również deweloperem, to w odniesieniu do problemu jest idealna sytuacja dla doskonałego rozwiązania produktu.

(O rany ... gdzie właśnie przeczytałem coś takiego: „Mam świetny pomysł! Wszystko, czego potrzebuję, to programista.” Myślę, że minął tydzień. W każdym razie…)

Wielkie pomysły to kilkanaście groszy. Najważniejsze jest wdrożenie tej rzeczy. Jeśli programista ma świetny pomysł, może go po prostu wdrożyć.