Lead Experience Questions
Есть ли у вас опыт в организации управления командой? (Если есть - опишите процесс и результат)
Input однако не лучшее место для полноценного рассуждения.
Имхо, многое зависит от существующих ролей на проекте и размера команды. Допустим, с PM и мб CTO уже все обсуждено, а размер команды маленький.
Я в основном был в роли "играющего тренера", когда контролировал, как саму команду, так и сам активно коммитил.
С точки зрения руководства, проводил такие процессы:
- ответственность за то, что происходит с командой
- проводил дейлики и иногда заменял ПМ
- делал ретроспективы в конце спринта, чтобы а) всей команде было понятно, что было сделано (особенно актуально, когда человек работал совсем в другом месте проекта и не знает какие фичи появились).
- писал суммари-логи с митов для понимания, где какой прогресс
- вводил, назовем их, "теги" и правила для составления и работы с задачами в жире
- решал конфликты между людьми, зачастую это было между фронтами и беками
- отдельно регулярно созванивался с членами команды либо в качестве помощи, либо в качестве поддержания рабочей дружественный атмосферы
- принимал активное участие вообще во всех созвонах, где речь была о проекте и команде
- собеседовал новых фронтов под нужды проекта
- проводил онбординг
С точки зрения кода:
- ответственность за то, что происходит с проектом
- писал статьи, описывающую архитектуру и дизайн систему проекта
- вел документацию важных функций и компонентов
- контроль комитов, веток, черри-пики, мержи, вот это все
- проверка всех пул-реквестов
- тестирование стабильности и скорости рендера
Input однако не лучшее место для полноценного рассуждения. Имхо, многое зависит от существующих ролей на проекте и размера команды. Допустим, с PM и мб CTO уже все обсуждено, а размер команды маленький. Я в основном был в роли "играющего тренера", поэтому: a) команда, б) проект. а) команда: ответственность за то, что происходит с командой; дейлики, ретроспективы, суммари-логи; созвоны отдельно с каждым коллегой; решение конфликтов, помощь. б) проект: ответственность за то, что происходит с код базой, стабильностью; описание архитектуры, readme/posts; проверка PR; правила проверки/пуши/ведения коммитов/веток;
Что вы будете делать, когда наступит крайний срок (работа не сделана, а сроки сжаты)
Снова все зависит от разных условий xD. Допустим, что мы четко понимаем все задачи, которые блокируют релиз, их приоритеты и ресурсы команды.
- Веду переговоры с PM/CTO, в худшем случае с заказчиком, на тему того, чтобы сдвинуть несколько задач на следующий спринт или даже распределить на несколько
- Сбор ответственных разработчиков за конкретные задачи (либо вся команда) для точного распределения обязанностей ежечасно.
- Зачем? Если времени ну совсем мало, а это все должно было быть сделано вчера, то у нас есть выход либо сделать максимум, либо договориться. Вот когда договориться не вышло, или вышло "наполовину", нужно собрать все силы и грамотно направить их на доработку самых ключевых моментов
- Могут быть "костыльные" решения по типу заглушек и не самой лучшей реализации в плане архитектуры, зато выигрыш по времени в данный момент, но это как говорится unsafe operation.
- Переработка с договорной оплатой в эти часы для членов команды. Обсуждается все с CTO, когда времени совсем мало.
Переговоры с PM/CTO для переноса задач на следующие спринты; точечное планирование для каждого для делегирования, чтобы выжать максимум производительности; возможно переработка; не самые качественные решения в пользу времени — в общем это такой "военный" час для всей команды, самая боевая готовность. Если все устали и нет сил, то говорит о том, что кранч уже был ранее и нужно либо искать еще людей, либо планировать меньше задач спринт.
Заняв руководящую должность, запишите свой план действий
Что я хотел сказать и ответил:
В первую очередь, конечно знакомство с командой и презентация себя. На данном этапе предполагается, что условия работы уже обсуждены с вышестоящим лицом и есть права на действия. Ознакомление с текущими процессами и изучение документацией. Изучение ТЗ, апи проекта, текущие/будущие задачи. В общем надо сначала освоиться, посмотреть как идут процессы и потом начинать принимать ответственность и решения.
Мне нужно разработать сайт типа aviasales.ru, чтобы на сайте можно было покупать билеты на транспорт по всему миру. Ссылка на дизайн - Blablacar. Мне нужна только главная страница с покупкой билетов. Оплата билетов криптовалютой. Пропишите техническое задание для разработчика.
Это в принципе уже можно назвать тех заданием) Более развернуто я это вижу тех документом, подробно описывающим все механики приложение, либо задачами в жире, где я уже проанализировал систему, спроектировал примерную архитектуру и дроблю их на атомарные кусочки, описывая принцип действия и соблюдаемые условия.
Поэтому я просто тут пройдусь поверхностно по общей структуре и технологиям (за базу берем React), опуская "лишний" дизайн с фокусом только на функционал.
2) Форма: селекторы, выбор даты, тип транспорта, число пассажиров, кнопка поиска
- При надобности точечного контроля за формой и валидации, которая тут не очень нужна, но можно использовать react-hook-form и yup
- Можно использовать Antd / MaterialUI для уменьшения времени разработки
- Иначе делать свои селекты с drop-menu результатами поиска по городам
- Делать запрос на бек в момент окончания ввода поиска (debounce), сохранять в глобальный стор не нужно
- Либо antd, либо input type="date" для даты
- input type="number", целочисленный, min={1}
- Submit button, которая делает POST запрос данных формы
- Получаемый токен запроса можно положить либо в стор, либо в sessionStorage
- Так же, если есть потребность шарить ссылки результатов поиска, можно на "новой" странице прокидывать токен в uri options
- Берем токен из стора и делаем GET запрос для получения списка билетов
- Есть два главных компонента: список, фильтры
- Фильтры отдельно получаем тоже GET запросом один раз и тоже нет смысла использовать лишний раз стор. Фильтры могут быть общим объектом стейта, могут быть сделана через react-hook-form, особо разницы нет. При изменении, новый GET запрос на получение списка билетов с новыми фильтрами — либо снова отправить токен, либо данные предыдущей страницы, если сохранили их в стор
- Список подписывается либо на стор, либо на sessionStorage, куда мы можем сложить json всех билетов (если их мало, мало занимают места). При большем количестве либо пагинация, либо виртуализация (тогда тут session может не подойти), в зависимости от требования заказчика.
- Если есть какое-то подтверждение данных пользователя, то дополнительно с покупкой нужен токен авторизации, его почта/телефон
- Далее выполняем транзакцию с помощью Ethers / web3 (rpc / metamask)