1. Введение
С увеличением количества команд и постоянным повышением технического уровня членов, развитие бизнеса также выдвигает более высокие требования к команде/индивидуалу, поэтому мы должны продолжать изучать техническое направление. концепции, сила индивидуальных способностей не определяет уровень эффективности исследований и разработок всей команды.Только когда каждый имеет способность систематически мыслить, команда может сформировать движущую силу для восходящей технической атмосферы и способствовать тому, чтобы каждый член имел понимание технологии развития высшие цели. В настоящее время наша фоновая группа использует стек технологии Java.Хотя технология стабильна, используемые инструменты промежуточного программного обеспечения всегда обновляются и повторяются, со все новыми и новыми функциями и новыми способами использования.Группе фоновой разработки необходимо составить полный план для приспособиться к нему с копанием.
Подводя итог, можно сказать, что обеспечение более качественной и быстрой поддержки развития бизнеса, содействие формированию хорошей технической атмосферы в команде и тенденция технического развития — все это важные причины, по которым мы должны хорошо выполнять техническое планирование.
2. Что такое техническое планирование?
Прежде всего, давайте разберемся, что планируется?
планирование, смыслличныйилиорганизацияСформулированный относительно всеобъемлющий и долгосрочный план развития представляет собой обдумывание и рассмотрение общих, долгосрочных и основных вопросов в будущем, а также проектирование всего комплекса будущих действий.план.
Основываясь на трех характеристиках планирования, мы можем связать его с технологией, так какие же аспекты нам необходимо учитывать?
**Интеграция: техническое планирование должно быть систематическим осмыслением существующей системы, и должен быть получен всесторонний и общий план улучшения, не останавливаясь на некоторых конкретных точках оптимизации; **Например, фон с нашей стороны теперь доменные услуги являются основными, и каждая доменная служба требует отдельного управления трафиком/авторизацией.Мы думаем о том, можем ли мы получить доступ к единому шлюзу для управления трафиком, авторизацией и т. д., что требует общего рассмотрения архитектуры, доменов и систем;
**Долгосрочный: общий цикл технического планирования составляет квартал, полугодие или даже год, что означает, что этот вопрос является относительно долгосрочным и стабильным и нуждается в постоянном продвижении; **Определяются определенные направления или планы и Долгосрочные «операции», такие как внедрение нового инструмента промежуточного программного обеспечения, должны следовать концепции «итерации версии» от анализа осуществимости -> использования -> оптимизации и улучшения.
** Направленность: техническое планирование должно выдвигать относительно долгосрочную цель для определенного направления и разрабатывать комплексный план развития и план действий; ** Технические направления часто разнообразны, например, эффективность НИОКР, производительность фоновой архитектуры и другие направления. Здесь нужно разделить приоритет, например, если следующему этапу нужно нести большой объем трафика, то мы повысим приоритет производительности архитектуры.
3. Как составить технический план?
3.1 Предварительная подготовка
В команде есть новые и старые, уровень развития участников неравномерен, и у всех разное понимание общей структуры и процесса НИОКР. Поэтому, прежде чем приступить к техническому планированию, мы должны дать всем хорошее представление о текущей внутренней архитектуре НИОКР и спецификациях системы. Если взять в качестве примера внутреннюю бизнес-структуру нашей команды, основными сценариями применения текущего бизнеса являются качественное образование, организационная реклама, совместное использование семей и т. д. Конкретная бизнес-структура показана на рисунке ниже.
В настоящее время в соответствии с тремя этапами технологических исследований и разработок: «разработка, компиляция и развертывание и работа в режиме онлайн» мы разобрали технические компоненты/инструменты, задействованные на каждом этапе, и разделили их на компоненты/промежуточное ПО/бизнес-инструменты. /код и документация на стадии разработки Спецификация/сотрудничество и другие технические моменты для формирования технической панорамы, которая удобна для всех, чтобы иметь четкое представление о фоновом стеке технологий.
3.2 Техническое направление
В соответствии с реальной ситуацией нашего существующего поддерживающего бизнеса, обязанностей отдела, ресурсов отдела и т. Д., Его можно разделить на шесть технических направлений, включая поддержку бизнеса / производительность системной архитектуры / создание технологической атмосферы / качество НИОКР / технические характеристики / эффективность НИОКР. Каждое из этих технических направлений должно учитывать несколько ситуаций:
Направление поддержки бизнеса: поддержка бизнеса всегда является главным приоритетом технического планирования. Все делается для предоставления более качественных, быстрых и эффективных фоновых услуг для бизнеса. Это направление должно учитывать поддержку планирования продукта (новый бизнес/технические требования для новых линеек продуктов) , сторонняя стыковка проектов (стыковка данных/управление проектами) и оптимизация всего процесса НИОКР;
Направление производительности системной архитектуры: доступность службы (индикатор SLA) производительность параллелизма службы (QPS/TPS) масштабируемость (рассмотреть план расширения) безопасность (архитектура безопасности/защита данных/аудит) открытые возможности (открытый интерфейс/домен) возможности эксплуатации и обслуживания (устранение неполадок поддержка сценария /FAQ) и др.;
Направление эффективности НИОКР: здесь мы в основном пишем менее повторяющийся код, извлекаем части, которые можно использовать совместно, и тратим время на написание повторяющегося кода на понимание фреймворка; фокусируемся на оптимизации бизнес-инструментов, построении общих компонентов CBB, новых инструментах/фреймворке. /язык и т.д.;
Направление качества НИОКР: качество - это срок службы продукта, в основном с учетом покрытия модульными тестами, инструментов автоматизированного тестирования, способов повышения эффективности тестирования, стресс-тестирования и т. д .;
Технические характеристики: в основном для улучшения всей команды, извлеките набор стандартных правил поведения из разработки, документации, эксплуатации и обслуживания и т. д., аналогично «Руководству по разработке Али», которое высоко ценится нашей командой, что позволяет избежать потребность в том, чтобы неоднократно наступать на яму, также может накапливать технологии команды и выполнять передовой опыт, который может служить нескольким целям;
Создание технической атмосферы: основная цель состоит в том, чтобы позволить каждому создать техническую атмосферу для обучения и роста, чтобы участники больше стремились к технологиям, эффективности и качеству.
3.3 Цели
3.2.1 Целевые источники
Источник целей технического планирования в основном основан на планировании продукта, отраслевом сравнительном анализе и т. Д. Например, во второй половине плана продукта необходимо добавить 50 Вт, более 100 Вт ежедневной деятельности, 3000+ запросов в секунду, 6 Вт + ежедневной активности оборудования. , и 10w+ мгновенных пиков.Показатели производительности, такие как QPS и т. д., например, должны поддерживать новые бизнес-сценарии, такие как расширение бизнес-сценариев в других отраслях, рассмотреть необходимость создания промежуточной платформы для базовой информации о организационная структура. В настоящее время сложно провести отраслевой бенчмаркинг, особенно когда мы занимаемся бизнесом 2B, в основном учитывая, что продукт и бизнес-форма очень разные, бессмысленно просто сравнивать показатели.
3.2.2 Постановка целей
Постановка технических целей должна соответствовать принципу SMART, то есть конкретные (Измеримые), достижимые (Достижимые) должны быть связаны с другими целями (Актуальными) и иметь четкие сроки (Временные). Возьмем каштан: Например, сформулирована цель "улучшение доступности системы". Очевидно, что эта цель совершенно некондиционна и может быть изменена на такую, "H2 (второе полугодие)-Q3 (третий квартал) -7 (месяц) оборудование Доступность интерфейса доменной службы xxxx должна достигать более 99,9% (в настоящее время 99,5%)»
3.4 Разложение цели
Разбивайте каждую большую цель на маленькие, что помогает проанализировать рациональность цели.Чем конкретнее цель, тем выше достижимая скорость цели. После декомпозиции цели ее можно передать в управление целями отдельного лица/команды в качестве ежемесячной цели технического планирования.Если есть цель, будет выход.Минимальная степень детализации вывода должна быть операционной системой или документом со структурой.
3.5 Основные действия
Это тесно связано с целью, каждое ключевое действие выполняется для достижения технической цели, а ключевое действие также связано с индивидуальным планом работы на неделю/день. Ключевые действия также подчеркивают итоги вывода, и следует уловить ритм.
3.6 Шаблон документа управления техническим планированием
Мы используем простые документы для управления целями/декомпозицией целей/ключевыми действиями/ответственными лицами и т. д., как показано в следующей таблице, а элементы в ней представляют собой направление улучшения производительности системной архитектуры в качестве примера.
направление планирования
Цель
целевое разложение
ключевое действие
государство
Ответственный
Производительность системной архитектуры
H2-Q3 (квартальный целевой показатель Q3 во второй половине года): увеличить количество запросов в секунду для сервисов в поле xx до xxx+
Q3-M7 (цель на июль): число запросов в секунду интерфейса a службы домена xxx достигает xxx+
Q3-M8: QPS интерфейса b службы домена xxx достигает xxx+
Q3-M7-W1 (первая неделя июля): создайте среду стресс-тестирования и проведите стресс-тестирование;
Q3-M7-W2: по результатам опрессовки оптимизируйте qps интерфейса a до xxx
@xxxx
4. Меры предосторожности
4.1 Консенсус команды
Очень важно достичь консенсуса среди всех участников, чтобы действовать в унисон, добиться сильного приземления. От первой версии технического планирования до завершения действия требуется не менее двух недель.В течение этого периода мы проведем множество дискуссий или встреч и объединим предложения и идеи разных сотрудников, таких как бизнес, продукт, управление проектами, фронт - конец, оборудование и т. д., и пересмотреть каждую цель во всех направлениях. Наконец, есть церемония «закрытия», как начало проекта, чтобы все поняли важность этого плана.
4.2 Механизм проверки
Наш бэк-офис был создан в течение почти трех лет, а техническое планирование было выполнено в течение двух лет, но фактический эффект посадки неплох.Сделан вывод, что необходим сильный механизм проверки.Обычно мы назначаем двух членов команды как технический Подробный механизм проверки для «руководителя» реализации планирования выглядит следующим образом:
1. Каждую субботу супервайзер будет рассылать скриншоты прогресса и ссылки в группе и @ всем.
2. 14 и 29 числа каждого месяца супервайзер будет присылать скриншот и ссылку прогресса в группе и @@ всем.
3. 15-го и 30-го числа каждого месяца супервайзер будет проводить встречи в конференц-зале для подведения итогов и @ для всех желающих принять участие.
5. Резюме
Эта статья в основном обобщает недавний процесс технического планирования в команде, разъясняет важность технического планирования команды и фокусируется на направлении, целях, целевой декомпозиции, ключевых действиях в техническом планировании, а также мерах предосторожности в процесс планирования и реализации, механизм проверки и другие вопросы познакомили вас с нашим практическим опытом, и я надеюсь, что вы сможете вдохновить техническое планирование.