«Якщо вас не бентежить перша версія вашого продукту, ви запустилися занадто пізно», — Рід Хоффман. У Splits ми дотримуємося такого підходу до створення програмного забезпечення: змусити його працювати → зробити його правильним → швидким. Порядок має значення. Ось що ми дізналися про доставку на кожному етапі:

Змусити його працювати = функціональний прототип. Він повинен бути шорстким. Він повинен бути жалюгідним. Швидко донесіть його до користувачів. Як ми оцінюємо MVP: 1) Перерахуйте все, що, на нашу думку, може бути важливим або мати відношення до проекту. 2) Який *абсолютний мінімум* з цього списку, що ми можемо закінчити і мати функціональний прототип?

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

Зробити це швидко = оптимізувати продуктивність. Чесно кажучи, ми все ще вивчаємо цей етап. Більшість Teams зараз перебуває в режимі 🤷 ♂️ «виправити» Але ось що нас рухає інспо:

Чому такий підхід працює: Послідовність – це стратегія. Те, що ви вивчаєте сьогодні, формує те, що ви будуєте завтра. Пропустіть вперед, і у вас не буде інформації, необхідної для правильного вирішення проблем. Дія продукує інформацію. Але *навмисні* дії виробляють *більше корисної* інформації.

Пастка намагається зробити все правильно в той же час, коли ви змушуєте це працювати. НІ. «Дозвольте собі відправити те, що, як ви знаєте, не так» — @wminshew