Запуск продукту
Потрібно випустити продукт у фіксовану дату?
Повний цикл розробки продукту: аналіз вимог, архітектура, фронтенд, перевірки коду, запуск. Одна точка відповідальності на всьому шляху.
Senior Frontend Engineer
Відкритий до нових проєктів
Продукти, що виходятьу домовлену дату.
Понад вісім років створюю продукти у fintech, SaaS та нерухомості. Найсильніший я в інтерфейсі, з яким працюють ваші клієнти. Коли проєкт цього вимагає, беру повну відповідальність за продукт: архітектура, релізи, запуск.
Проєкти
Три історії проєктів за останні чотири роки. Кожна починалася однаково: з чесної оцінки того, що насправді не працює, до того, як написано хоча б рядок коду.
30
днів до запуску
Fintech · Лідерство команди · Процес випуску
Запуск Fintech-продукту
Приєднався до платіжного продукту, який уже відставав на чотири місяці. Двоє розробників у команді, функціонального процесу випуску оновлень немає, тестового середовища для перевірки змін до того, як їх побачать клієнти, теж немає, і ніхто в команді не міг назвати надійну дату запуску. Терпець у клієнта і CEO був на межі.
- Команда масштабована з 2 до 8 фахівців за напрямами
- Перший випуск для клієнтів доставлений за 30 днів, компенсувавши чотиримісячне відставання, успадковане до мого приходу
- Процес випуску стабільний з першого тижня, нуль аварійних відкатів за перший квартал
- Випуски вийшли на щотижневий ритм — достатньо передбачувано, щоб клієнт планував навколо них інтеграції
3×
швидша розробка
SaaS · Дизайн-система · Масштаб
Дизайн-система та бібліотека компонентів
Три SaaS-продукти під одним брендом, кожен розроблявся і підтримувався окремо, кожен відображав ту саму кнопку трохи по-різному. Кожна нова функція означала повторну розробку компонентів, які дві інші команди вже збирали раніше. Дизайнери витрачали половину робочого тижня на усунення неузгодженостей замість того, щоб проєктувати.
- Три продукти уніфіковано на одній спільній бібліотеці — узгоджені кнопки, діалоги і поля форм по всьому бренду
- Швидкість розробки нових функцій зросла приблизно втричі порівняно з періодом до бібліотеки
- Неузгодженості між продуктами скорочено до нуля: кожен компонент відповідає конкретному дизайну у Figma і запису в живій галереї
- Команда дизайну повернула собі приблизно 40% робочого тижня і спрямувала цей час на дослідження продукту
0
зірваних термінів
Нерухомість · Архітектура · Мінливі вимоги
Платформа нерухомості з нуля
Нова платформа без задокументованих вимог, фіксована дата запуску, узгоджена з зовнішнім партнером, і ключові учасники, пріоритети яких змінювалися щотижня. На першій зустрічі, куди я потрапив, прозвучали три суперечливі визначення мінімально життєздатної версії — кожне активно захищав окремий учасник.
- Трансформував початкові ідеї ключових учасників у конкретні впорядковані бізнес-цілі протягом першого тижня
- Спроєктував і побудував платформу з нуля разом з командою
- Вимоги продовжували змінюватися протягом усієї розробки. Дата запуску лишилась незмінною.
- Запуск у домовлену дату, з узгодженим обсягом, і жодних критичних інцидентів у перший тиждень
Де я допомагаю
Чотири напрями, у яких до мене звертаються найчастіше. Більшості проєктів потрібні два з них одночасно.
Дизайн-системи
Декілька продуктових команд, неузгоджений інтерфейс?
Спільна бібліотека компонентів: кнопки, форми, навігація, модалі. Її використовують усі продуктові команди: одне джерело правди, швидша розробка, менше розбіжностей між продуктами.
Ритм релізів
Команда зриває ритм випусків?
Заходжу в команду, яка зупинилася, і повертаю ритм: найм, адаптація, передбачуваний процес випусків і перші цикли планування, які я веду особисто.
Технічне консультування
Велике технічне рішення на горизонті?
Друга думка перед вибором інструмента, фіксацією архітектури чи інвестицією в продуктивність. Порада до рішення завжди дешевша за переробку після.
Процес
Чотири етапи від першого дзвінка до передачі. Жодного з них я не пропускаю: саме на цьому проєкти найчастіше зривають терміни.
Вступний дзвінок, 30 хвилин
Обговорюємо продукт, команду і те, що стоїть на шляху. Я ставлю питання, які допоможуть зрозуміти, чи я підійду для цього завдання. Ви отримуєте чітку відповідь без тиску продажів.
Аналіз перед реалізацією
Перед тим як писати код, я документую проблему, ризики і план. Кілька днів тут: це різниця між реальною датою запуску і тією, яка постійно зсувається.
Прозора розробка
Щотижневі оновлення: що зроблено, що далі, що потрібно від вас. Не доведеться нічого випитувати. Якщо щось під ризиком, ви дізнаєтесь про це від мене першого.
Запуск і належна передача
Готовий до роботи продукт і документація, якою ваша команда дійсно користуватиметься. Лишаюсь на зв'язку ще два тижні після запуску, щоб передача справді закріпилася.
Розкажіть
про ваш проєкт.
Кількох рядків контексту достатньо. Відповідаю протягом доби, зазвичай швидше.
Або напишіть безпосередньо
alex.belost@gmail.com