Нерухомість · Архітектура · Мінливі вимоги
Платформа нерухомості з нуля
- Період
- 2024
- Роль
- Frontend Engineer
- Галузь
- Нерухомість
- Результат
- 0зірваних термінів
Виклик
Реальна проблема
Нова платформа без задокументованих вимог, фіксована дата запуску, узгоджена з зовнішнім партнером, і ключові учасники, пріоритети яких змінювалися щотижня. На першій зустрічі, куди я потрапив, прозвучали три суперечливі визначення мінімально життєздатної версії — кожне активно захищав окремий учасник.
Підхід
Як я це вирішував
- У перший тиждень провів дві робочі зустрічі, щоб узгодити вимоги. Вийшов з одним впорядкованим за пріоритетами списком, на який можна було посилатись щоразу, коли пріоритети змінювалися
- Обрав архітектуру, яка легко адаптується до змін. Чітка структура, жодних передчасних абстракцій, екрани самодостатні — правки залишаються локальними
- Випускав одну готову функцію на тиждень, від початку до кінця, замість того щоб вести кілька паралельно у стані часткової готовності. Команда і замовник реагували на робочий продукт, а не на написані специфікації
- За два тижні до встановленого терміну зафіксував обсяг запуску. Нові запити йшли у наступний план розвитку, а не ставили випуск під загрозу
- Кожне важливе технічне рішення виписував на одну сторінку, разом з поясненням — не лише що зробили, а й чому. Щоб той, хто продовжить роботу, розумів логіку, а не лише результат
Стек
Інструменти, на яких це зроблено
- Next.js
- React
- TypeScript
- Tailwind CSS
- PostgreSQL
- Vercel
Результат
Що вийшло
- Трансформував початкові ідеї ключових учасників у конкретні впорядковані бізнес-цілі протягом першого тижня
- Спроєктував і побудував платформу з нуля разом з командою
- Вимоги продовжували змінюватися протягом усієї розробки. Дата запуску лишилась незмінною.
- Запуск у домовлену дату, з узгодженим обсягом, і жодних критичних інцидентів у перший тиждень
Схожа ситуація у вас?
30 хвилин розмови, без продажів. Швидко зрозуміємо, чи я підійду для цієї задачі.