Кожен договір на розробку на папері обіцяє одне й те саме: збудуємо продукт, вчасно, в межах бюджету. Жоден договір не написаний так: «ми виставляємо рахунок за зусилля, а не за результат». Але частина команд працює саме за цим принципом — просто ніхто цього вголос не каже. І засновник зазвичай помічає це не одразу, а десь через рік «прогресу», який так і не став продуктом.Це не про шахрайство. Це про те, куди спрямовані стимули команди. Якщо підряднику платять за години — логічно, що він оптимізує процес під години. Нижче — конкретні сигнали, за якими це видно ще до того, як ви втратили бюджет і час.
Інвойс виглядає ідеально. Продукт — ні
Це перший і найпомітніший сигнал. Години списані, спринти закриваються вчасно, звіти чисті — а те, що ви насправді хочете відвантажити, і досі за шість тижнів, як і шість тижнів тому. Активність і прогрес — це не одне й те саме. У команди, яка виставляє рахунок за час, немає структурної причини розрізняти ці дві речі за вас — навпаки, чим довше різниця непомітна, тим довше триває контракт.
Будь-яка розмова зводиться до скоупу, а не до проблеми
Запитайте команду, орієнтовану на результат: «чи варто робити цю фічу» — і у відповідь почуєте питання, яку проблему користувача вона вирішує. Запитайте те саме команду, орієнтовану на години, — і вона перепитає, чи входить це в скоуп. Жодна з відповідей не є нечесною — просто туди спрямовані стимули. Команда, якій платять за час, ставиться до скоупу як до того, що захищає її години. Команда, яка відповідає за результат, ставиться до скоупу як до того, що захищає ваш продукт.
Естімейти рухаються тільки в один бік
У кожному проєкті трапляються сюрпризи — це нормально, і підрядник, який ніколи не переглядає оцінку, швидше за все, з вами нечесний. Питання не в тому, чи змінюється естімейт, а в напрямку. Якщо терміни й бюджет постійно тільки ростуть, і ростуть приблизно пропорційно до того, скільки у вас лишилось раннвею, — це не невдача. Це команда, яка вивчила вашу стелю і будує проєкт під неї.
Вам ніколи не кажуть «ні»
Це контрінтуїтивний сигнал, бо на перший погляд виглядає як хороший сервіс. Підрядник, який погоджується на все, реалізує будь-який запит і ніколи не сперечається — необов'язково на вашому боці. Часто він просто уникає розмови, яка коштуватиме йому спринта. Команда, яка справді відповідає за результат, скаже вам, коли запит зашкодить продукту, навіть якщо цей запит — ваш власний. Це тертя — не провал у сервісі, а ознака того, що хтось насправді думає про продукт, а не тільки про тікет.
Ніхто не може пояснити архітектуру, не відкриваючи код
Попросіть сеньйора з команди пояснити, без гуглу і без відкритого редактора, як влаштована система і чому саме так. Команда, яка відповідає за результат, впорається за п'ять хвилин — бо думає про систему в проміжках між тікетами, а не тільки під час роботи над ними. Команда, яка продає години проти беклогу, часто не може — бо в неї нема людини, чия робота тримати в голові всю картину, а не лише задачу перед носом.
Що запитати, перш ніж підписувати щось довгострокове
Не обов'язково розбиратись у коді, щоб упіймати це на старті. Достатньо кількох конкретних питань:Що відбувається, якщо спринт показує, що початковий план був хибним — команда повідомляє про це, чи мовчки закриває це додатковими годинами?Хто в команді відповідає за те, чи продукт вдалий, а не тільки за те, чи закриті тікети?Як команда поводилась, коли помилялась із минулим клієнтом — не в теорії, а на конкретному прикладі?Відповіді на ці три питання скажуть про підрядника більше, ніж будь-яке портфоліо чи відгук на Clutch.Чесний партнер з розробки іноді коштуватиме вам фічі, яку ви хотіли, естімейту, який вам не сподобається, або незручної розмови, якої ви б радше уникнули. Це не червоний прапорець. Червоний прапорець — це коли цього немає взагалі.