Каждый раз, когда вы начинаете новую роль, легко почувствовать себя подавленным. Вы беспокоитесь о том, чтобы проявить себя и как можно быстрее набрать обороты. Вас засыпает потоком новых знаний.
Вот несколько вопросов, которые, как мне кажется, следует задать разработчикам программного обеспечения при присоединении к новой команде разработчиков для эффективной адаптации:
- Кто являются целевыми клиентами продукта / программного обеспечения, которое разрабатывает команда? Какова цель и долгосрочное видение с точки зрения клиента?
- Какая система хранения данных используется? Каков источник достоверности хранимых данных? Кто последующие потребители данных?
- Какие типы сервисов (REST / RPC) принадлежат команде? Каков механизм маршрутизации запросов и соответствующая инфраструктура? Каков протокол работы с ошибками для каждой службы?
- Каков процесс управления пакетами кода? Какой инструмент сборки используется? Какой инструмент используется для управления зависимостями и контроля версий? Как происходит настройка среды IDE и среды разработки?
- Каков жизненный цикл разработки программного обеспечения? Какая процедура развертывания? Как выглядит цикл развертывания? Как работает механизм отката?
- Каковы стандарты и передовой опыт команды в отношении качества кода? Что такое механизм проверки кода? Кто отвечает за объединение пул реквестов? Для разнообразия, сколько рецензентов требуется?
- Какая процедура тестирования? Есть ли автоматизированные наборы тестов? Подвергаются ли сервисы нагрузочному тестированию / тестированию производительности?
- Какова стратегия команды по работе с операционной нагрузкой? Есть ли модуль Runbook и панель показателей для звонков по вызову? Какие шаги предпринимаются для решения производственных проблем?
- Как выглядят типичные офисные встречи? Какой гибкий механизм используется? Какие методы используются для оценки задач?
- Какие методы используются для управления и проверки документов? Попросите проектную и технологическую документацию, относящуюся к команде.
Бонусные подсказки -
- Держите свою команду в курсе и говорите на языке своей команды, общение укрепляет доверие.
- Не делайте поспешных оценок дизайна или качества кода.
- Не предлагайте сразу же улучшения. Вместо обвинений излагайте свое мнение в виде вопросов.
- Не суди себя слишком строго. Вы, наверное, фантастически хорошо справляетесь. Даже опытному инженеру требуется месяц, чтобы понять, что происходит в вашей команде. Дайте себе 3 месяца, чтобы разобраться в вещах.
Спасибо за чтение! Если вам это показалось интересным, вот несколько следующих шагов, которые вы можете предпринять: