Технологічні та продуктові партнери
Для постачальників ПЗ і продуктових компаній, яким потрібна інженерна команда поруч із власною на роки, а не на спринт. Модуль, за який ми відповідаємо від початку до кінця, платформа, яку ми допомагаємо експлуатувати, або друга команда, що веде дорожню карту, яку ви не можете укомплектувати, причому ті самі люди лишаються достатньо довго, щоб вивчити предметну область.
Це не те саме, що купити проєкт
Проєкт має кінець, і від цього залежить усе в тому, як його комплектують: людей призначають, предметну область вивчають настільки, щоб завершити роботу, і знання йдуть разом із ними. Продукт не закінчується. Від зовнішньої команди йому потрібні наступність, зацікавленість у тому, щоб архітектура витримала наступні два роки, і люди, які заперечують, коли швидкий обхідний шлях згодом коштуватиме більше, ніж заощадить зараз.
Саме такі стосунки описує ця сторінка. З комерційного погляду це зазвичай виглядає як виділена команда, а партнерством це робить те, що ми відповідаємо за результат у вашому продукті, а не за перелік тікетів.
За що ми зазвичай відповідаємо
Модуль, за який ми відповідаємо від початку до кінця
Одна чітко окреслена частина вашого продукту: шар інтеграцій, звітність, адміністративна частина, мобільний клієнт. Ми ведемо її у вашому коді, за вашою архітектурою, і відповідаємо за її дефекти, а не за кількість тікетів.
Друга команда для вашої дорожньої карти
Усе, що ви мали б розробити, але не можете укомплектувати людьми. Паралельна команда працює у ваших репозиторіях і за вашими командними ритуалами, тож дорожня карта рухається одразу на двох напрямах, а не скорочується до одного через перепріоритизацію.
Платформа під продуктом
Хмарна інфраструктура, описана в Terraform, пайплайни, середовища, спостережуваність, робота з базами даних і безпекою. Те, на що в продуктової команди ніколи немає часу і чого їй щотижня бракує.
Модернізація старого продукту
Продукт, який продається, але перестав піддаватися змінам. Дев'ять проєктів, прийнятих від інших команд, найстаріший написано у 2008 році, і щоразу ми починаємо з огляду коду в режимі лише читання та письмового переліку ризиків, а не з пропозиції переписати все.
Що допомагає довгому партнерству працювати
Люди, які залишаються
Співпраця тут триває роками, а не спринтами, і знання предметної галузі залишаються в тих самих людей. Найгірше для партнера: двічі платити за одне й те саме занурення в проєкт.
Ваша архітектура, а не наша
Ми звикли працювати з тим, на чому продукт уже працює, а не підштовхувати його до того, що знаємо самі. Партнерська команда, яка раз у раз пропонує переписати все, перестала бути корисною.
Правила, які переживають передачу
Тести додаються разом із функціональністю, збірка завершується без жодного попередження, безпека працює за принципом «заборонено за замовчуванням», а інфраструктура є кодом. Такий код ваші інженери можуть підхопити самі.
У кожного факту один власник
Похідні значення обчислюються один раз і використовуються всюди. У продукті, де працює кілька команд, продубльована істина стає тією помилкою, яку знаходять через пів року і не можуть пояснити клієнтові.
Підстраховка за наш рахунок
Перевірка архітектури, другий погляд під час рев'ю pull request і підміна на час відпусток надаються за рахунок BigTree108, а не з вашого бюджету.
Ваша інтелектуальна власність на всіх етапах
Кожен фахівець ще до отримання доступу передає компанії права на результати своєї роботи, а компанія передає їх далі вам, тож тривале партнерство не ускладнює питання, кому належить продукт.
Ми самі розробляємо власний продукт
Усе, чим ми користуємося всередині компанії, від найму й онбордингу до обліку часу, договорів і рахунків, працює на одній платформі на тому стеку, який ми пропонуємо партнерам: .NET на Azure Functions, Angular, Azure SQL, Terraform. Це не приклад для портфоліо, а система, від якої залежить компанія, і ми прожили зі своїми архітектурними рішеннями достатньо довго, щоб знати, які з них були помилковими.
Саме за таку виважену оцінку, здобуту на практиці, продуктовий партнер і платить. У кейсі описано, що робить ця система і як вона побудована.
З чого все починається
З чогось невеликого й такого, що можна скасувати. Один інженер на чітко окресленому фрагменті вашого беклогу або огляд лише для читання тієї частини продукту, яка вас найбільше турбує, оформлений як письмовий перелік ризиків у порядку впливу на продакшн. І те, і те дешевий спосіб дізнатися, чи читаємо ми вашу кодову базу так, як ви хотіли б, щоб її читав партнер.
Далі зазвичай це виділена команда, що зростає разом із дорожньою картою. Якщо ви зрештою захочете повністю володіти командою, то у форматі Build-Operate-Transfer ви матимете тих самих людей, але з передачею, прописаною в договорі.
Потрібна друга команда для вашого продукту?
Розкажіть про продукт, ту частину дорожньої карти, яка постійно зсувається, і за можливості дайте посилання на репозиторій. Протягом одного робочого дня ви отримаєте від нас запитання, які в нас ще залишилися, підхід і оцінку.