If you remember I said engineering was doing waterfall development.
Waterfall development is just a step by step process that says
marketing rights are requirements of what the product should do.
Engineering takes that and translates that into features. Engineering then designs the product.
Either codes it or builds the hardware.
They test it and they maintain it and this is kind of a waterfall life cycle step by step.
But if you really look at this, there's an implicit fallacy that no one ever noticed for 40 years.
To write the requirements and do the design, assumes on day one
you know the problem or need the customer has.
Let me say it again, waterfall development assumes
you understand the customer problem and need on day one.
Now in a large company with existing customers, existing products, existing sales channel,
you know what, this might actually be true but in most startups all you have is the founder's vision
and what you tend to do in a startup is confuse a faith-based vision
with customers facts about problems and needs and what happens?
The consequence of assuming you know the customer problem
means you assume you know every possible feature to ship on day one.
So therefore you shut the door and you start implementing
and instead of just implementing a piece at a time,
you actually implement every possible feature you could think about for version 1.0.
The irony is that we now know somewhere between
85 and 90% of most software product features are unwanted and unneeded by customers.
That's an enormous amount of waste of time and money that ends up on the floor.
We now know that waterfall and product management execution on two knowns
is just kind of the wrong way to approach it in a startup.
It makes all the sense in the world in a large company.
لو تتذكر قلت أن أعمال الهندسة تتبنى التطوير الإنحداري.
والتطوير الإنحداري عبارة عن عملية مكونة من خطوات،
وفيها يكتب قسم التسويق المتطلبات اللازم توفرها في المنتج
فيأخذها قسم الهندسة ويترجمها إلى خصائص. ثم يصمم المنتج.
وإما يصمم البرمجيات أو ينشئ المكونات المادية للمنتج.
ويختبرونه ويبقون عليه، وهذه نوعـا ما دورة حياة هذا التطوير، خطوة بخطوة.
لكن لو تفحصت الأمور، لانتبهت لوجود فكرة خاطئة ضمنية لن ينتبه لها أحد منذ 40 عامًا.
كتابة المتطلبات وعمل التصميم، يفترض أنك منذ اليوم الأول
تعرف مشكلة أو حاجة العميل.
بعبارة أخرى، يفترض التطوير الإنحداري
أنك تعرف حاجة أو مشكلة العميل منذ اليوم الأول.
الآن في شركة كبرى تضم عملاء ومنتج وقناة مبيعات
قد يكون ذلك صحيحًا، لكن في مؤسسة ناشئة لا يوجد سوى رؤية المؤسس،
وما يتم عادةً في المؤسسة الناشئة هو خلط الرؤية الحاسمة
مع حقائق العملاء حول المشكلات والحاجات، فماذا يحدث؟
عندما تفترض أنك تعرف حاجات العميل
يعني أنك تفترض معرفة كل خاصية ممكنة يمكن تسليمها منذ اليوم الأول.
ومن ثم تغلق عليك شركتك وتبدأ في التنفيذ
وبدلاً من التنفيذ المُجزأ على دفعات،
تنفذ كل خاصية يمكنك التفكير فيها في النسخة الأولى من المنتج.
من المثير للسخرية أننا الآن نعرف أنه ما بين
80% و 90% من خصائص منتجات البرمجيات لا يرغب بها العملاء ولا يحتاجونها.
وهذا قدر هائل من هدر الوقت والمال الذي يجري على أرضية المصنع.
نحن نعرف الآن أن النموذج الإنحداري لإدارة المنتج
لا يلائم طبيعة العمل في المؤسسة الناشئة.
في حين يلائم بشكل منطقي بيئة الشركات الكبرى.
Si recordeu, vaig dir que 'Enginyeria' feia Desenvolupament en Cascada.
Desenvolupament en Cascada és simplement un procés pas a pas que diu:
màrqueting escriu els requisits del que han de fer els productes.
'Enginyeria' els tradueix en funcionalitats; després dissenya el producte,
ja sigui que ho codifiqui o dissenyi el hardware,
el proven i després faciliten suport tècnic. I aquest és més o menys el cicle de vida del Desenvolupament en Cascada, pas a pas.
Però si vosaltres l'observeu amb compte, aquí hi ha una fal·làcia implícita que ningu notà durant 40 anys.
Per escriure els requisits i fer el disseny, s'assumeix des del primer dia
que es coneix el problema o la necessitat que té el client.
Permeteu-me que ho repeteixi: el Desenvolupament en Cascada assumeix
que hom coneix el problema i la necessitat que té el client, des del primer dia.
Ara bé, en una empresa gran, amb clients existents, productes existents, canals de venda existents,
¿sabeu què? això podria ser cert; però a la majoria de les 'startup', l'únic del que es disposa és la visió del fundador
i el que hom tendeix a fer a una 'startup' és confondre la visió basada en la fe
amb les dades dels clients sobre els seus problemes i necessitats; llavors, ¿què passa?
La conseqüència de suposar que un coneix el problema del client
és que assumeix que es coneix cada possible funcionalitat per incloure al primer enviament al client.
Per tant, un tanca la porta i comença a implementar,
i en comptes de només implementar un element cada vegada,
en realitat, a la versió 1.0 s'implementen totes les funcionalitats que se li ocorreguèren.
La ironia és que ara sabem que entre
el 85% i el 90% de la majoria de funcionalitats dels productes de software no les desitgen ni les necessiten els clients.
És una enorme pèrdua de temps i de diners, que acaba llençat pel terra.
Avui en dia sabem que l'execució en cascada i de gestió de producte en base a dues dades conegudes
és bàsicament la forma equivocada de fer les coses a una 'startup'.
Té tot el sentit del món en una empresa gran.
Si lo recuerdan, dije que Ingeniería hacía Desarrollo en Cascada.
Desarrollo en Cascada es simplemente un proceso paso a paso que dice:
Mercadeo escribe los requerimientos de lo que deben hacer los productos.
Ingeniería los traduce en funcionalidades; después diseńa el producto,
ya sea que lo codifique o diseńe el hardware,
Lo prueban y luego brindan soporte técnico. Y este es más o menos el ciclo de vida del desarrollo en cascada, paso por paso.
Pero si ustedes lo observan con cuidado, aquí hay una falacia implícita que nadie notó durante 40 ańos.
Para escribir los requerimientos y hacer el diseńo, se asume desde el primer día
que se conoce el problema o la necesidad que tiene el cliente.
Permítanme que repita: el desarrollo en cascada asume
que uno conoce el problema y la necesidad que tiene el cliente, desde el primer día.
Ahora bien, en una empresa grande, con clientes existentes, productos existentes, canales de ventas existentes,
¿Saben qué? Esto podría ser cierto; pero en la mayoría de las startup, lo único que se tiene es la visión del fundador,
y lo que uno tiende a hacer en una startup es confundir una visión basada en la fe
con los datos de los clientes sobre sus problemas y necesidades; entonces, ¿qué pasa?
La consecuencia de suponer que uno conoce el problema del cliente
es que se asume que se conoce cada posible funcionalidad para incluir en el primer envío al cliente.
Por tanto, uno cierra la puerta y empieza a implementar,
y, en lugar de solo implementar un elemento cada vez,
en realidad, en la versión 1.0 se implementan todas las funcionalidades que se les ocurrieron.
La ironía es que ahora sabemos que entre
el 85% y 90% de la mayoría de funcionalidades de los productos de software no las desean ni las necesitan los clientes.
Es una pérdida tremenda de tiempo y dinero, que termina tirado en el piso.
Hoy en día sabemos que la ejecución en cascada y de gestión de producto con base en dos datos conocidos
es básicamente la forma equivocada de hacer las cosas en una startup.
Tiene todo el sentido del mundo en una empresa grande.
اگه یادتون باشه گفتم که بخش مهندسی از روش آبشاری استفاده می کرد.
روش توسعه آبشاری در واقع فرایند قدم به قدمی است که میگه
بخش مارکتینگ لزومات اینکه کالا باید چی باشه را مینویسه
مهندسین اون لزومات را بر میدارند و تبدیلش میکنند به ویژگیهای کالا. و بعد کالا را طراحی میکنند.
یا کد مینویسن براش یا اگه سخت افزاره، شروع میکنند به ساختنش
بعد امتحانش میکنند و پشتیبانیش میکنند و این تمام قدمهای یک پروسه آبشاریه
ولی در این پروسه یک سفسطه نهفته است که کسی 40 سال به آن پی نبرد :
برای نوشتن لزومات و طراحی کالا فرض میکنیم که از روز اول
ما می دونیم که مشکل چیه و مشتری ها چی می خواهند.
بذار دوباره تکرار کنم. روش آبشاری فرض میکند که
مشکلات مشتری ها را از روز اول می داند.
حالا در یک شرکت بزرگ با مشتری های مشخص و کالاهای از قبل طراحی شده و کانالهای فروش از قبل ایجاد شده
شاید این فرض درست باشد. ولی در بیشتر استارتاپ ها فقط دید و جهانبینی بنیانگذاران هست
و اگر این دید ها و بینش ها را با حقایق بازار
و نیازهای مشتری اشتباه بگیری، چه اتفاقی می افتد؟
و اگر فرض کنی که تمام مشکلات و نیازهای مشتریها را میدانی
پس فرض خواهی کرد که تمام ویژگی های کالا که باید عرضه کنی هم میدونی
پس درها را میبندی و شروع به کد نویسی و ساخت محصول میکنی
و بجای اینکه در فاز های مختلف کالا را به بازار عرضه کنی
از همان اول همه ویژگیهایی که تصور کردی را در ورژن اول عرضه میکنی
و جالب اینه که می دونیم چیزی بین
80% تا 95% از ویژگیهای کالا لازم نیستند و مورد استفاده مشتریان قرار نمی گیرند
مقدار زیادی پول و وقت این وسط تلف میشه.
ما الان میدونیم که روش آبشاری در توسعه کالا
در مورد استارتاپ ها اشتباه هست
هرچند در یک شرکت بزرگ شاید منطقی باشد.
अगर तुम्हें याद है मैंने कहा कि इंजीनियरिंग झरना विकास कर रहा था।
झरना विकास कहते हैं कि सिर्फ एक कदम प्रक्रिया द्वारा कदम है
विपणन के अधिकार आवश्यकताओं कि उत्पाद क्या करना चाहिए रहे हैं।
इंजीनियरिंग और कि लेता है कि सुविधाओं में तब्दील हो। तब इंजीनियरिंग उत्पाद डिजाइन।
या तो यह कोड या हार्डवेयर बनाता है।
वे यह परीक्षण और वे इसे बनाए रखने और इस तरह से एक झरना जीवन चक्र कदम से कदम है।
लेकिन अगर तुम सच में इस पर देखो, वहाँ एक अंतर्निहित भ्रम कि कोई भी कभी 40 साल के लिए देखा है।
पर एक दिन मान लिया गया है लिखने के लिए आवश्यकताओं के लिए और डिजाइन, कर
तुम्हें पता है कि समस्या या जरूरत ग्राहक है।
मुझे यह फिर से, झरना विकास मान लिया गया है कहते हैं
आप ग्राहक समस्या को समझते हैं और एक दिन की जरूरत है।
अब मौजूदा ग्राहकों के साथ एक बड़ी कंपनी में, मौजूदा बिक्री चैनल उत्पादों, विद्यमान,
तुम्हें पता है क्या, यह वास्तव में सच हो सकता है, लेकिन ज्यादातर startups में आप सभी संस्थापक का दृष्टिकोण है
और क्या आप एक स्टार्टअप में करने के लिए करते हैं एक विश्वास पर आधारित दृष्टिकोण को भ्रमित है
ग्राहकों की समस्याओं और की जरूरत है और क्या के बारे में तथ्यों के साथ होता है?
मान लें आप ग्राहक समस्या पता का परिणाम
तुम्हें लगता है तुम जहाज पर एक दिन के लिए हर संभव सुविधा पता का मतलब है।
और आप को लागू करने शुरू करते हैं तो इसलिए तुम दरवाजा बंद
और के बजाय सिर्फ एक टुकड़ा एक बार में लागू करने,
तुम वास्तव में आप के बारे में संस्करण 1.0 के लिए लगता है कि सकता है हर संभव सुविधा को लागू।
विडंबना यह है कि हम अब कहीं के बीच कि पता है
85 और सुविधाएँ अवांछित और ग्राहकों द्वारा अनावश्यक हैं ज्यादातर सॉफ्टवेयर उत्पाद के 90%।
जो समय और पैसा है कि फर्श पर समाप्त होता है की बेकार की एक विशाल राशि है।
हम अब जानते हैं कि झरना और उत्पाद प्रबंधन के निष्पादन पर दो knowns
गलत तरीका है इसे एक स्टार्टअप में दृष्टिकोण की तरह ही है।
यह एक बड़ी कंपनी में दुनिया में सब समझ में आता है।
先ほどお話した開発部門のウォーターフォール開発とは
順を追って行うプロセスです
マーケティング部門が商品の必要条件を決め
開発部がその商品に機能をつけ 商品化し
プログラミングするかハードウエアにします
その後テストして メンテナンス
これが順を追ったウォーターフォール開発です
しかしよく見ると40年間
誰も気付かずにいた間違いがあるのです
必要条件を決め 商品化することは初日から
顧客の問題やニーズを知っていないといけないのです
もう一度言います ウォーターフォール開発は
初日から顧客の問題とニーズを
理解していることが前提なのです
すでに顧客がいて 商品化が進み
販売チャネルが確立している大企業なら
分かりますが スタートアップでは
創業者のビジョンしかありません
にもかかわらず夢に描いたビションと
顧客の問題とニーズを混乱させてしまします
顧客の問題を理解していると思い込んでいると
出荷初日から全てを把握していると思ってしまいます
そして一心に実行に移すのです
少しずつ実行するのではなく
思い付く限りの機能をバーション1.0に入れ始めます
今でこそ分かる皮肉ですが
ソフトウエアの85~90パーセントの機能は
いらないことが多いのです
多くの時間と費用が無駄に終わります
ですからウォーターフォール開発と商品開発は
スタートアップの際には間違った方法なのです
しかし大企業では正論と言えます
과거의 엔지니어링 방식은 '폭포수 개발' 모델이었다고 얘기했었죠
'폭포수 개발'이란 순차적인 프로세스를 말합니다
마케팅에 의해 제품의 필수 요건을 정하면
엔지니어링 파트가 이를 받아서 제품을 디자인하죠
프로그래밍 작업이나 하드웨어 제작을 마친 다음
테스트를 거쳐 이를 유지하는 방식이 순차적인 폭포수 모델이에요
그런데 여기에 오류가 내포돼 있다는 걸 그동안 몰랐던 겁니다
제품의 요건을 정하고 디자인을 한다는 것은
처음부터 고객의 니즈와 문제를 알고 있다고 가정하는 거예요
다시 말해서 폭포수 개발 모델은 고객의 문제와 니즈를
처음부터 파악하고 있다고 가정하고 있는 거죠
이미 고객과 제품과 판매 채널을 보유하고 있는 대기업이라면
이런 가정이 맞겠지만 스타트업의 경우, 있는 거라곤 본인의 비전뿐인데
본인의 믿음에 기반한 비전과 고객의 문제 및 니즈라는 팩트를
혼돈하는 경우가 흔하죠, 그러면 어떻게 되겠어요?
고객의 문제를 알고 있다고 가정한다는 의미는
제품에 담아낼 요소를 이미 알고 있다고 가정하는 거예요
그래서 무턱대고 이행에 들어가는데
일단 한번에 하나만 해보는 게 아니라
생각할 수 있는 모든 요소를 첫 제품에 담아내는 거예요
그러다 보니 대다수 소프트웨어 제품의 경우
85-90%의 요소가 고객에게 불필요하다는 결과가 나오는 겁니다
어마어마한 돈과 시간을 낭비하는 일인 거죠
이러한 폭포수 개발 모델과 제품 관리 방식은
스타트업에 맞지 않는다는 걸 이제 아셨을 겁니다
대기업의 세계에서나 통하는 방식이죠
Pamiętasz jak mówiłem, że inżynieria realizuje model kaskadowego rozwoju.
Model kaskadowego rozwoju to stopniowy proces oparty na przekonaniu,
że prawa marketingu określają wymogi co do tego jaki powinien być produkt.
Inżynieria zbiera te wymogi i zamienia na cechy produktu. Potem projektuje produkt.
Koduje go lub konstruuje sprzęt.
Produkt jest testowany, a następnie przyjęty. Tak wygląda ten cały proces - krok po kroku.
Ale jeśli przyjrzysz się dobrze, zauważysz, że jest w tym pewien błąd, który pozostał niezauważony przez 40 lat.
Aby spisać wymagania i zrobić projekt,
trzeba z miejsca znać problemy lub potrzeby konsumenta.
Pozwól, że powtórzę: model kaskadowego rozwoju zakłada, że
z miejsca znasz problemy i potrzeby konsumenta.
W dużej firmie mającej klientów, produkty i istniejący kanał sprzedaży
może to się sprawdzać, ale gdy mamy do czynienia ze startup'em, wszystko co masz to wizja założyciela
i to, co robisz, to łączysz opartą na wierze w swój pomysł wizję
z domysłami nt. oczekiwań klientów. I co się wtedy dzieje?
Założenie, że znasz problemy i potrzeby konsumenta,
oznacza, że jesteś w stanie wymyślić każdą możliwą cechę produktu już pierwszego dnia.
Więc zamykasz drzwi i zaczynasz wprowadzać wizję w życie
i zamiast realizować wizję kawałek po kawałku,
wprowadzasz każdą możliwą cechę produktu jaką potrafisz wymyślić już w wersji 1.0.
Ironia polega na tym, że wiemy, iż od 85%
do 90% większości cech oprogramowań produktów jest niechciana bądź niepotrzebna konsumentom.
To oznacza ogromną ilość zmarnowanego czasu i pieniędzy, które lądują w błocie.
Teraz wiemy, że kaskadowy model i takie zarządzanie produktem oparte na dwóch wiadomych
(problemach i potrzebach konsumenta) nie sprawdza się w startup'ie.
Ma to sens jedynie w dużym przedsiębiorstwie.
Se você se lembra, eu falei que engenharia estava
desenvolvendo em cascata.
Desenvolvimento em cascata é simplesmente
um processo passo a passo que diz
os requisitos de marketing sobre o que o
produto deve fazer.
A engenharia pega isso e transforma em
funcionalidades. Engenharia desenha o produto.
Seja programando ou construindo um hardware.
Eles testam e o mantem e este é o típico
processo de desenvolvimento em cascata.
Mas se você olhar, existe uma falácia que
ninguém notou por 40 anos.
Para escrever os requisitos e fazer o
desenho, assume que no primeiro dia
você conhece o problema ou a necessidade
do consumidor.
Deixe-me falar novamento, desenvolvimento
em cascata assume
que você entende o problema do cliente
e sua necessidade no primeiro dia.
Agora, em uma grande empresa com os clientes, produtos e canal de vendas existentes,
isso pode ser verdade, mas em startups a única
coisa que você tem é a visão dos fundadores.
e a tendência em startups é confundir uma
visão baseada na crença do fundador
com os fatos relativos aos problemas e
necessidades dos clientes e o que acontece?
A consequência de assumir que você conhece
o problema do cliente
significa que você assume que sabe todas
as funcionalidades necessárias no primeiro dia.
Assim, portanto, você tranca a porta e
começa a desenvolver o produto
e no lugar de implementar uma
parte de cada vez
você implementa todas as funcionalidades
possíveis que você pensa para a primeira versão
A ironia é que hoje sabemos que
entre 85% e 90%
das funcionalidades dos softwares não são
desejadas ou necessárias para os clientes.
É uma perda enorme de tempo e dinheiro
que é jogado fora.
Hoje sabemos que desenvolvimento em cascata
e gestão de produto
é a forma errada de abordar o
problema em uma startup.
Faz todo o sentido em uma grande empresa.
Hatırlarsanız, mühendislik bölümünün
şelale geliştirmesi yaptığını söylemiştim.
Şelale geliştirmesi, pazarlama
doğrularının ürünün ne yapması...
...gerektiğini söylediği adımlı bir
süreçtir.
Mühendislik bunu alır ve özelliklere
çevirir. Daha sonra da ürünü tasarlar.
Ya kodlar ya da donanımı üretir.
Ürünü test eder ve bakımını yaparlar.
Bu bir tür adımlı şelale mühendisliğidir.
Dikkatle bakarsanız, burada 40 yıldır hiç
kimsenin fark etmediği bir safsata var.
Gereksinimleri hazırlamak ve tasarımı
yapmak için, ilk günden...
...müşterilerin problemlerini ve
ihtiyaçlarını bilmeniz gerekiyor.
Tekrarlayayım, şelale geliştirmesi...
...müşterinin problemlerini ve isteklerini
ilk günden anladığınızı varsayar.
Mevcut müşterileri, ürünleri, satış
kanalları olan büyük bir şirkette...
...bu yöntem doğru olabilir ama çoğu
girişimde elde olan tek şey...
...kurucusunun vizyonudur.
Bir girişimde genelde yapılan hata,
inanç temelli bir vizyonu...
...müşterilerin problemleri ve ihtiyaçları
ile karıştırmaktır. Sonra ne olur?
Müşterilerin sorununun ne olduğunu
bildiğinizi varsaymanın sonucu olarak...
...ilk günde sevkedilecek ürünün tüm
özelliklerini bildiğinizi sanırsınız.
Bu nedenle kapınızı kapatır ve
uygulamaya başlarsınız.
Ve teker teker uygulamak yerine...
...mümkün olan her özelliği
1.0 versiyonuna koyarsınız.
İroni şu ki, yazılım ürünleri
özelliklerinin yaklaşık...
...%85-90'ının müşteriler tarafından
istenmediğini veya gereksiz bulunduğunu...
artık biliyoruz.
Bu oldukça büyük bir para ve zaman
israfıdır.
Artık iki bilinen nokta üzerinden şelale
geliştirmesi ve ürün yönetimi yapmanın...
...bir girişim için yanlış yollar olduğunu
biliyoruz.
Ama bunlar, büyük bir şirkette
oldukça mantıklıdır.
Якщо Ви пам'ятаєте, я казав, що технічне проектування працювало за методом водоспадного розвитку.
Водоспадний розвиток - процес, який відбувається поетапно і заявляє, що
маркетингові права - вимоги того, що продукт повинен робити.
Технічне проектування перетворює це в характерні особливості. І потім створює продукт.
Або кодує його чи створює обладнання.
Вони його перевіряють, здійснюють його підтримку, що нагадує етапи водоспадного життєвого ціклу.
Але якщо Ви справді поглянете, то побачите приховане невірне сприйняття, яке ніхто не помічав упродовж 40 років.
Припускається, що для того щоб написати вимоги і виконати дизайн,
Ви знаєте проблеми або потреби, які має Ваш клієнт.
Дозвольте мені наголосити знову, водоспадний розвиток передбачає,
що Ви розумієте від першого дня проблему клієнта та його потреби.
Зараз в крупній компанії з існуючими клієнтами, існуючими продуктами, існуючими каналами продажів,
Ви знаєте, що це дійсно може бути правдою, але в більшості стартапів, все, що маєте це - бачення засновника
і, як правило, тенденція, яка характерна для стартапів - сплутати бачення, засноване на вірі
з фактами клієнтами про проблеми і потреби, і що ж відбувається?
Як наслідок Вашого припущення того, що Ви знаєте проблему клієнта,
означає, що Ви припускаєте, що Ви знаєте всі можливі функції для відправки в перший день.
І тому Ви зачинили двері, і Ви починаєте впровадження
і замість того, щоб просто здійснювати поетапне впровадження,
Ви фактично здійснювати всі можливі функції, про які Ви можете подумати для версії 1.0.
Іронія полягає в тому, що ми тепер знаємо, десь між
85 і 90% більшість функцій програмного продукту є небажаними і непотрібні для клієнтів.
Це - величезна трата часу і грошей, які закінчуються в торговій залі біржі.
Ми тепер знаємо, що водоспад і виконання управління продуктом з двома невідомими
схоже на неправильний підхід в стартапі.
Це має сенс у великій компанії.
你是不是还记得我说的工程学是在做瀑布式发展
瀑布式的开发是一个循序渐近的过程
它提出市场需求什么样的产品
工程学获得这个信息,并勾勒出特征,然后设计出产品
生成代码或者是生产出硬件
他们测试,然后维护,这就是一步步的瀑布式周期
但如果你真的去看它,这里面有个40多年没被注意到谬误隐藏其中
写下需求,做设计,假设
你知道客户的问题或需求
让我再重复一次,瀑布式开发假设的是
你在第一天就了解客户的需求或问题
现在,如果是个大公司,有经常性的顾客,有现存产品和现存的销售渠道
那你有可能会知道,但事实上,在创业之时,你所有的只有建立者的理想
然后在创业之时,你更容易有的是以信仰为基础的理解所带来的迷惑
关于客户的问题或需求
假设自己知道客户问题的结果是
你在第一天就知道了每个可能的特征
然后你关上门,开始操作
不是只进行了一小块
实际上你完成了你能想到的在1.0版本里的所有特征
讽刺的就是,我们现在知道
85%-90%软件产品的特征不是客户所需要的
大量的时间和金钱被浪费,最后也是失败
我们现在知道,瀑布和产品管理执行
在创业之初是错误的方法
它们只在大公司里才有意义