Как работать в программе basecamp

Привет. Вы слышали про 37signals? Это ребята, которые изобрели Ruby On Rails, потом построили систему управления проектами Basecamp, после этого пошли уже менее известные проекты: Backpack —система управления знаниями, Highrise —система CRM и мессенджер Campfire. Компания, продуктами которой пользуется более 3 миллионов человек ежедневно — имеет в своём штабе всего 14 постоянных сотрудников. В данной статье я расскажу о глобальных принципах работы, в следующих пройдемся по командным ритуалам, карьерному развитию внутри Basecamp и посмотрим на критерии программистов для устройства в компанию.

2163 просмотров

Чтобы не пропустить посты – подписывайтесь на мой инстаграм и телеграм, там я буду уведомлять о выпуске новых частей, а так же постоянно рассказываю про свою карьеру тимлида в крипте, старте в IT и успешном work-life балансе ✌

Немного про Basecamp и книги от их авторов

Я познакомился с этой компанией и их стилем управления впервые, когда прочитал книгу «Rework: Бизнес без предрассудков». После этого я проникся их идеологией и сразу в ход пошли книги «Remote: Офис не обязателен» и «Не сходите с ума на работе». Книги были особенно актуальны, когда в начале локдауна нужно было переходить на полностью удалённую работу и предстоял процесс выстраивания процессов.

Garmin BaseCamp для начинающих. Инсталляция и первый маршрут. ч.01

По моему мнению, концепты управления проектами от Basecamp конечно довольно принципиальны и трудно выполнимы в больших компаниях (не просто так у них 14 человек), но конечно многому у них стоит поучиться. Но сейчас не о книгах.

Я случайно наткнулся на методичку для работников Basecamp, в которых кратко задокументированы процессы работы в их компании и хотел бы начать конспектировать основные процессы на русском языке.

И так, как же устроена работа в Basecamp?

В Basecamp работают 6-8 недельными циклами. Обычно в году бывает 6 циклов. Два из них – 8 недельные и чаще всего они проходят летом

‍ Почему летом циклы длиннее? В Basecamp есть правило работать не более 40 часов в неделю, но летом количество часов уменьшается до 32. Поэтому время цикла обратно-пропорционально количеству рабочего времени в неделе, что логично. Про факт сокращенной рабочей недели я прочитал в книге “Не сходите с ума на работе”

Работа в таких циклах позволяет не испытывать горящие дедлайны вечно, при этом понимать временные рамки проекта. Ограничение так же помогает сокращать задачи до комфортного объёма и обеспечивает регулярные интервалы для принятия решения о том, над чем нужно работать.

Идея заключается не в том, чтобы ставить задачи длиной в 6 недель. Скорее наоборот – нужно разбивать крупные проекты на такие, которые можно довести до продакшна в 6 недель. Мелкие задачи, в свою очередь, объединяются в единый проект с общей целью, чтобы скомпоновать правильный объём работы и выкинуть не нужное.

‍ Таким образом 10 мелких фич можно сгруппировать в один общий проект на улучшение сферы длиной в 6 недель, а после этого выкинуть из него парочку менее значимых задач

Как работать с Garmin BaseCamp

Этот подход особенно важен для продуктовых команд, так как очень полезно заранее понимать полный объем работы, за которую нужно браться. В компании есть примерная стоимость фич по времени – 1 маленькая фича занимает неделю времени. Более комплексная может растянуться до шести недель, но не более.

Таким образом, планирование задач ограничивается временным бюджетом. Если мы понимаем на планировании, что фича мелкая – она не должна выходить из оценки в 1 неделю, так как бюджет времени на задачи – фиксированный. Мелкие фичи не должны делаться больше срока за счёт большего количества работы сотрудников. Таким образом, почти все проекты укладываются в обычные 6 или летние 8 недель работы.

‍ Кстати, а ведь это очень похоже на то, что проповедует Ильяхов. А именно ФФФ. Почитайте https://fff. works/, а если недостаточно – пишите в комментах, я расскажу подробнее

Перезарядка

Между каждым циклом проводится 2 недели перезарядки (восполнение кулдаунов, как в доте), чтобы остыть. Это время, чтобы разобраться с возникающими ошибками с прошлых задач или поразбираться над мелкими проблемами. Подвести итоги прошлых циклов и понять, за что браться в следующий раз.

Конечно, со стороны менеджеров, часто возникает соблазн продлить цикл на 2 недели, чтобы вместить больше работы. Но общая цель в компании состоит в том, чтобы не поддаваться этому искушению.

Да, процесс не идеален и иногда приходится доделывать ключевые задачи цикла во время кулдауна, но обычно такие ситуации позволяют еще более качественно подойти к оценке в следующий раз. В идеальной картине работа над фичей заканчивается к концу 4 недели, дальше в дело вступает QA, проверяющие со стороны бизнеса и фича готовится к деплою.

Коммуникации

Достаточно трудно уследить за тем, что все делают и что полезного в этом, если просто наблюдать за доской задач или историей коммитов (это так же забирает много времени)

Вместо этого в Basecamp выстроено четыре основных механизма для того, чтобы держать всех в курсе происходящего.

Во-первых, это ежедневный вопрос “Над чем вы сегодня работали?” , который представляет подробную информацию в виде личного рассказа. Этот вопрос является отличной темой для разговора, если вы видите, что кто-то работает над чем-то, что вас волнует или о чем вам интересно узнать побольше. Basecamp просит не игнорировать этот вопрос и периодически просматривать данные логи (минимум два раза в неделю)

Второй вопрос еженедельный – “Над чем вы планируете работать на этой неделе?” . В данном вопросе нужно подробно описать все задачи на неделю, рассказать о ваших идеях относительно выполнения задач и рассказать, какие цели будут выполнены к концу недели

Третий этап – сердцебиение (интересное название ретроспективы ) Этот вопрос является командной версией вопроса “Что вы делали в этом цикле?” . Здесь подводятся итоги цикла, отмечается завершённая работа и подводятся результаты. Каждый руководитель команды обязан написать или поручить кому-то из команды написать этот отчет через неделю после завершения цикла.

И четвертый, финальный этап коммуникации, это старт цикла (kick-off, я не знаю как перевести это дословно). Это так же командный вопрос, в котором нужно написать “Над чем вы собираетесь работать в следующем цикле?” Здесь представляется план на ближайшие шесть (или восемь летних) недель. Каждый руководитель команды обязан написать или поручить кому-то из команды написать этот отчет до начала цикла, чтобы другие участники могли ознакомиться и как-то помочь с выполнением задачи, а так же понимать, могут ли пересекаться рабочие задачи.

Эти четыре вопроса работают как единый механизм и позволяют по максимуму избавляться от синхронных коммуникаций между командами во время работы. В итоге в командах заранее все запланировано, а каждый участник команды может независимо от остальных узнать, что происходит в проекте и выстроить свой цикл работы над задачами.

В компании есть 6 возможностей в календарном году, чтобы принять важные решения о том, над чем будет производится работа. Соответственно, остальное время можно потратить на реализацию краткосрочных планов и работу над ошибками. Имея четкие планы и представления о циклах – всей команде гораздо проще понимать и представлять, к какой цели идет продукт.

Все эти отчеты и вопросы так же идут в финальную говодую презентацию “Что мы сделали”, которая является подведением общих итогов.

Независимо от того, занимаетесь ли вы разработкой продукта или нет, ваш голос и наблюдения могут помочь определить, над чем нам следует работать. Хороший способ улучшения продукта, доступный каждому – это питч.

Ребятам в команде предлагается рассказать свою идею о новом функционале. Это может быть даже принципиально новый продукт, которого нет в компании, но который, по мнению докладчика, следует рассмотреть руководтсву.

Важное условие – питч должен быть хорошо продуман и оформлен. Чем конкретнее идея – тем выше вероятность того, что ее возьмут в работу. Это даст возможность всей компании рассмотреть идею и отреагировать на нее, а затем передать руководству как проект для реализации.

Однако питчей всегда будет больше, чем можно обработать. Поэтому важно иметь реалистичные ожидания относительно того, что произойдет после того, как вы опубликуете его. По умолчанию все, кто занимается разработкой продукта (и, вероятно, большинство других сотрудников компании), прочитают и рассмотрят ваш питч. Это уже победа. Даже если полная идея не будет принята, она может повлиять на другие решения по продукту, проливая свет на слабые места.

Вероятность того, что ваша идея сразу же попадет в следующий цикл компании – не высокая. Даже если ваша идея действительно крутая и ее одобряют другие участники команды – нужно понимать тот факт, что идей всегда больше, чем времени и в каждом цикле можно сделать только несколько задач. Питч может быть крутой и полезный, но менее приоритетный. Не расстраивайтесь по этому поводу. Самый долгий питч в Бейскэмпе лежал в бэклоге год, но после этого его все равно взяли в работу.

В Бэйскэмпе есть команда из трех человек, ответственная за питчи. Перед каждым циклом они рассказывают о всех питчах, которые они обработали и говорят планы по взятию их в работу.

Асинхронность

В Basecamp работают люди в разное время и из разных мест. Это само по себе затрудняет внедрение большого количества тесно связанных рабочих процессов в течение дня, но это особенность, а не проблема. Большая часть работы не должна требовать от вас постоянного общения в течение всего дня с другими сотрудниками.

Для концентрации и продуктивности каждого сотрудника будет гораздо лучше, если вы будете осознавать, что вы точно получите ответ, но не обязательно прямо в эту секунду. Первым вашим действием должна быть отправка сообщения, постановка задачи или запрос информации о том, что вам нужно объяснить или узнать. Тогда другие смогут прочитать его по своему расписанию, когда это будет комфортно для них, а не быть прерванными во время состояния потока и продуктивности.

Правда, как и в случае с перерывами между спринтами – это не абсолютная истина. Да, иногда всё же в компании проводятся совместные звонки, обсуждения в мессенджерах и совместные использования экранов. Но это происходит в тех случаях, когда такая возможность очень сильно упрощает работу для нескольких людей. В любом случае планирование задач предполагает, что они будут выполняться асинхронно, поэтому менеджеры должны учитывать это.

При этом, в любом случае желательно подбирать команды таким образом, чтобы совместное рабочее время составляло хотя бы 15-30-60 минут в день. Поскольку если у вас часто будут проблемы, которые можно решить за пару минут – тратить на это целый день будет не приятно и не продуктивно для вас. Старайтесь искать компромиссы.

В некоторых отделах, таких как служба поддержки и DevOps, еще важнее, чтобы люди были доступны в то время, когда они говорят, что будут доступны. В этой работе много работы с дедлайнами, которую просто необходимо сделать прямо здесь и сейчас. Поэтому то, что применимо почти ко всей работе по проектированию, программированию и QA, там может не применяться.

Самодостаточные и независимые команды

Теория организации компаний изобилует описаниями компромиссов между функциональными и проектными структурами компании. Basecamp стремится быть более проектными, чем функциональными. Это означает, что одна проектная команда должна иметь возможность пройти путь от идеи до внедрения настолько независимо, насколько это возможно.

Таким образом, чем меньше других отделов придется пройти команде на пути к внедрению новой функции, тем лучше. Нужно работать над упрощением цепи, которая образуется по умолчанию, когда у вас есть потрясающие, сильные отделы, такие как SIP, мобильный, инфраструктура, тестировщики и так далее.

Например, команда, работающая над новой функцией планирования, должна иметь возможность тестировать и интегрировать свою работу с нативными приложениями без привлечения мобильных разработчиков, если только не требуется что-то особенное. Отдел разработки в iOS не должен нуждаться в особом предупреждении, а значит, в прерывании работы, умственных перегрузках или даже чувстве вины из-за неучастия в добавлении новой фичи. Аналогично, мобильная функция, требующая изменения API, должна выполняться непосредственно командой мобильных разработчиков.

Когда нужно использовать базу данных, это тоже должно выполняться “самообслуживанием”. У нас должен быть сценарий, который каждый может запустить для восстановления. Не нужно идти к девопсам и ждать, пока кто-то сделает это за нас.

Все это не означает, что нам не нужно общаться вместе или спрашивать совета у экспертов с большим опытом или знаниями. Это просто означает, что это не должно быть обязательным и необходимым шагом для того, чтобы сделать Basecamp лучше.

Как только образуются проблемные места, например, множество функций, ожидающих «мобильной интеграции», команду начинает тянуть к микро-менеджменту и расписанию. Оно превращается в сложный путь с зависимостями и обеспечением того, чтобы команда X была доступна в нужный момент для команды А, чтобы никто не был заблокирован. Это плохо согласуется с организационными устремлениями, поэтому Basecamp приходится работать над тем, чтобы противостоять этому.

Само-менеджмент

Менеджеры в Basecamp — это part-time занятость, наряду с выполнением самой работы. Это означает, что команда рассчитывает на то, что каждый сотрудник Basecamp будет в значительной степени заниматься самоменеджментом. Люди, которые делают это хорошо, квалифицируются как менеджеры одного, и мы стремимся к тому, чтобы все сотрудники высшего звена и выше в полной мере воплощали этот принцип.

Это означает, что вы сами определяете направление менеджмента, когда оно не задано. Определять, что нужно сделать, и делать это, не дожидаясь, пока кто-то вам это скажет. Руководитель одного уровня будет хорошо планировать свое время, когда он управляет сам собой. Всегда есть много работы, которую нужно сделать, всегда есть больше предложений, которые можно запустить, всегда есть больше улучшений.

Подход к работе в basecamp (37signals)

Довольно старый но очень познавательный пост в блоге SVN, как они сами написали отвечающий на вопросы:

Как вы парни на самом деле работаете? Как выбираете какими вещами заниматься? Какие у вас команды по размеру? Как вы структурировали вашу работу?

То есть в принципе те вопросы которые всегда интересовали их “последователей”. Как же они за счет такого скудного функционал могут разрабатывать свой продукт. Судя по всему процесс у Basecamp эволюционирует, и если на момент публикации поста в 2017, они по словам Джейсона Фрайда на версии 5.2 то сейчас, в 2023 версия должна быть близка к 7.0 . Что же можно вынести для себя из статьи?

6 недельные итерации

Команды в Basecamp работаю по 6-недельным итерациям, каждый цикл содержит проекты 2 типов (автор использует термин batch, переведу это как пачка).

Большая пачка — проекты которые целиком могут занять весь 6-недельный цикл, обычно они берут 1-2 таких проекта. Для каждого большого проекта существует свой собственный проект в Basecamp где ведется вся коммуникация и документация.

Маленькая пачка более мелкие проекты улучшения, исправления и понятные инициативы которые могут занять и день и пару недель. Обычно берут 4-8 таких проектов.

После завершения цикла берут 1-2 недели на проекта за пределами расписания, исправления проблем, pet-projects и на подготовку нового цикла.

Интересное замечание что это не спринты:

Note: These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

Действительно, спринты и готовая работа часто не совпадают. Вернее нормальная работа обычно занимает больше стандартного спринта. Basecamp же ориентирован на результат.

Что можно взять себе:

• Есть время на незапланированную работу и на подготовку нового цикла. Эта Одна из причин почему я не очень верю в спринты по 1 неделе, просто безумные ресурсы уходят зря
• Есть понимание что проекты могут занимать больше времени.
• 6 недель хватает на любую запланированную фичу, либо, в рамках перерыва между циклами можно понять как уместить в следующие 6 недель работающую фичу. то есть подход к планированию из ограничения.

Экстремально маленькие команды 2-3 человека

Один большой проект — одна команда. Команды собираются на лету и по желанию — кто чем хотел бы заняться. В команде 1-2 программиста и дизайнер (я так понимаю 1 бекэнд, 1 фронт). Руководит дизайнер. Вера что дизайнер должен уметь затащить разработку меня радует, хотя, далеко не всякому дизайнеру такое под силу.

We only hire designers who are capable of leading projects, but yes, small team sizes help reduce management requirements to begin with. So it’s sort of a 1–2 punch — designers who can lead, small teams.

Мне нравится такой подход, и я понимаю почему Basecamp его продвигает — снизить нагрузку на административку, снизить количество менеджеров. И я могу только посоветовать всем бизнесам нанимать дизайнеров и QA-инженеров которые могут потянуть самостоятельную работу.

Все работаю в одной среде

Для “сигналов” это естественно basecamp, считается что разделение команд по инструментам это:

• крайне неэффективно
• не дает полную картину команде

Что верно но к сожалению не всегда возможно. Если невозможно то что делать? Об этом ниже.

В Basecamp не придерживаются трекинг времени так как считают что бесполезно оценивать запланированные и полученные результаты. Задача в том что есть фиксированный лимит времени — 6 недель. Точка. Можно двигаться внутри если команда успевает или наоборот опаздывает.

Питчинг

Кажется это самая интересная часть процесса. Этот то момент когда идея, откуда бы она не пришла, обретает форму и готова быть представлена. Делается это в текстовом виде по ряду причин:

• питчера не могу прервать, сбить, загнобить пока он не рассказал идею целиком
• текст позволяет почувствовать поверхность под ногами, при написании текста автор лучше её продумает
• асинхронное взаимодействие, они не особо любят слеки и личные встречи для работы
• есть возможность собрать все возможные все комментарии к питчу как единый источник истины

Запуск цикла

После питчинга, сортировки проектов по пачкам, публикуется пост о запуске где структурирует все работы которые запланированы. Для себя они используют конечно basecamp, один из объединяющих проектов, мне видится что для этого подойдет база знаний (wiki, notion, confluence).

Нравится что это не письмо или сообщение в чате, всегда можно вернуться в прошлое и посмотреть на результат.

Как работает QA

На момент публикации у Basecamp два тестировщика которые переключаются между командами. При это автор озвучивает очевидную мысль — чем раньше подключен тестировщик, тем лучше. За эти годы ничего не изменилось.

Вместо заключения

Меня очень располагает данный процесс, если даже не получается полностью применить его у себя, то можно просто попытаться выбрать самые ключевые моменты и ответить для себя на вопросы:

1. Как вы структурируете вашу работу? Отличается ли подход к реализации
2. Как вы выделяете время
3. Как решаете что делать и что не делать?
4. Как доносите до команды новые идеи?
5. Как вы начинаете новый спринт?
6. Где вы общаетесь?
7. Как организована команда или команды? Насколько они оптимальны?

Ну а после, попытаться найти точки для улучшения.

Разделы: work

Дата изменения: February 21, 2023

Поделиться

Вам также может понравиться

Мысли про работу

менее 1 мин на чтение

Несколько цитат которые подзацепили когда писал статью про работу basecamp.

Что такое хорошая [продуктовая] задача.

2 мин на чтение

Небольшое лирическое вступление. Когда-то я играл в баскетбол и тренер беспрестанно вбивал нам в голову — “если твой пас не приняли в этом твоя вина”, или ес.

Уведомления Jenkins в Telegram

2 мин на чтение

Одно из правил работы с CI — все должны видеть статус сборок, тоесть синхронизация. А что может быть лучше чем уведомление о неудачном, или напротив удачном.

Лицензии при разработке программных продуктов софта

1 мин на чтение

В разработке ПО часто является разумным использовать уже готовые фреймворки и библиотеки для решения тех или иных задач. Важно помнить, что несмотря на стату.

Источник: 42point.com

Инструкция для навигаторов GARMIN с использованием BaseCamp

Данная инструкция по подготовке файлов GPX подходит только для навигаторов от компании GARMIN, и только с использованием программы BaseCamp.

Наша цель – извлечь из навигатора трек пройденного маршрута ЗМУ и обозначенные при этом маршрутные точки. Если за сутки до проведения учета проводилась затирка следов, то аналогичным образом извлечь и трек затирки.

Разработчиком программы BaseCamp является производитель самих навигаторов – GARMIN. Поэтому вопросов совместимости навигаторов с этим программным обеспечением возникать не должно.

Для информации – программа BaseCamp пришла на смену популярной программе MapSource. В отличии от предшественника, BaseCamp обладает более продвинутыми возможностями – ведение собственной базы данных маршрутных точек и треков с распределением данных по различным спискам. То есть, данные уже не хранятся в отдельных файлах на диске, а всегда имеются в программе под рукой. Соответственно, имеется возможность управлять списками и их наполнением.

Установка BaseCamp и подготовка к работе

Скачать программу BaseCamp можно на сайте производителя. Поэтому для начала подготовки рабочего места скачиваем программу, устанавливаем и запускаем.

После запуска BaseCamp перед нами открывается окно программы:

Фактически, программа готова к использованию, но в ней нет карты. При подключенном к компьютеру навигаторе, как правило, в BaseCamp становится доступной установленная в приборе официальная карта. Тем не менее, иногда необходимо поработать в программе без навигатора, а без карты работать будет практически невозможно. Поэтому установим карту.

Бесплатную актуальную карту OSM для BaseCamp всегда можно скачать на сайте garmin.gis-lab.info. Выбираем нужный регион и скачиваем карту в формате GMAPI. Или можно сразу скачать карту всей России. После скачивания карты закрываем BaseCamp, распаковываем архив с картой. Внутри распакованного архива находим каталог FAMILY_XXX.gmapi, внутри него – каталог FAMILY_XXX.gmap. Это каталог (FAMILY_XXX.gmap) необходимо скопировать внутрь каталога Maps настроек BaseCamp:

• Windows XP: C:Documents and Settings\Application DataGarminMaps
• Windows 7-10: C:users\AppDataRoamingGarminMaps

Если указанные шаги выполнены успешно, то карта уже установлена на компьютер. Снова запускаем программу BaseCamp и убеждаемся в этом:

Для навигации по карте можно воспользоваться кнопкой “Инструмент руки“. Выберите его кликом левой кнопки мышки.

После этого с помощью той же левой кнопки мышки можно перемещаться по карте – зажимаем левую кнопку мышки и двигаем ее в нужную сторону.

Когда курсов мышки расположен на карте, с помощью колесика мышки можно увеличивать и ее уменьшать масштаб.

На этом подготовка BaseCamp к работе завершена, а мы научились навигации по карте. Можно переходить непосредственно к работе с навигатором.

Подключение навигатора GARMIN и извлечение данных

Для считывания данных из навигатора GARMIN подключаем прибор к компьютеру используя для этого USB-кабель. При подключении прибора, в зависимости от модели навигатора, к компьютеру могут добавиться один или два съемных накопителя или не добавиться вовсе. Не обращаем на это внимание. Главное, что бы на экране самого прибора появилась информация о подключении его к компьютеру.

Когда прибор подключен, BaseCamp автоматически его обнаруживает и отображает информацию об этом в панели “Библиотека“. Что бы увидеть маршрутные точки и треки в памяти навигатора – нужно кликом левой кнопки мышки выделить соответствующий раздел памяти – “Внутренняя память” или “Данные пользователя” (если в навигаторе имеется SD-карта).

Теперь мы должны научиться ориентироваться в извлеченной из навигатора информации. Обратите внимание, выделенный в нижней левой панели объект (маршрутная точка или трек) подсвечивается на карте, если текущая область просмотра карты включает в себя местоположение этого объекта.

Если же объект на карте не выводится, то что бы переместить карту на нужный объект нужно кликнуть на него правой кнопкой мышки и в открывшемся контекстном меню выбрать пункт “Показать на карте“. Того же результата можно достичь двойным кликом левой кнопки мышки по маршрутной точке или треку.

Выделить объект (трек или маршрутную точку) можно так же кликом левой кнопкой мышки по объекту на карте. При этом он будет выделен в нижней левой панели.

Используя двойной клик левой кнопкой мышки по объекту можно открыть окно с детальной информацией о треке или маршрутной точке. В этом окне отображается такая информация как наименование объекта, координаты, высота над уровнем моря, а так же дата и время фиксации объекта в навигаторе.

Таким образом, мы определяемся какие объекты нам нужны (относятся к маршруту ЗМУ), а какие нет.

Теперь нам нужно перенести необходимые данные из навигатора на компьютер, в базу данных BaseCamp. Но сначала необходимо вспомнить в том, что данные в BaseCamp можно группировать по спискам. Более того, BaseCamp позволяет группировать списки в папки. Например, можно создать папку “ЗМУ“, в которой будем хранить данные раздельно по каждому маршруту. Итак, создаем папку “ЗМУ“. Для этого:

• Кликаем правой кнопкой мышки на корневой элемент библиотеки “Моя коллекция“;
• Кликом левой кнопкой мышки выбираем пункт меню “Папка нового списка“;
• Вводим название новой папки – “ЗМУ” и нажимаем ENTER.

Теперь внутри папки “ЗМУ” создаем список с данными по нашему маршруту. В нашем примере создадим список с именем “Маршрут 1”. Для этого:

• Кликаем правой кнопкой мышки на созданную ранее папку “ЗМУ“;
• Кликом левой кнопкой мышки выбираем пункт меню “Новый список“;
• Вводим название новой папки – “Маршрут 1” и нажимаем ENTER.

Теперь у нас есть отдельное хранилище для хранения маршрутных точек и треков по пройденному маршруту. Но в нем пока еще нет этих данных. Настало время перетащить необходимые данные из навигатора в наш новый список “Маршрут 1”. Для этого:

• В области “Библиотека” кликаем левой кнопки мышки на память навигатора (“Внутренняя память” или “Данные пользователя”);
• В нижней панели со списком маршрутных точек и треков удерживая клавишу CTRL левой кнопкой мышки выделяем необходимые нам объекты (маршрутные точки и треки);

• Кликаем левой кнопкой мышки на любой из выделенных объектов и в открывшемся диалоговом меню выбираем пункт “Отправить на…“;

• В открывшемся диалоговом окне выбираем созданный ранее список “Маршрут 1” и кликаем кнопку “ОК“;

В результате, отправленные нами маршрутные точки и треки будут скопированы в список “Маршрут 1”.

В итоге, у нас из навигатора мы должны скачать один или два трека, в которых имеется информация о пройденном маршруте (при выполнении учета и при затирке следов), а так же зафиксированные на маршруте точки (начало, повороты, следы, птицы, конец).

Если с первого раза отправили в наш список “Маршрут 1” не все необходимые данные, аналогичным образом копируем недостающие.

Теперь навигатор теперь можно отключить от компьютера, т.к. все необходимые нам данные мы из него взяли.

Управление маршрутными точками и треками

В данной части стати представлена инструкция по подготовке файлов GPX на пройденные маршруты для навигаторов GARMIN с использованием программы BaseCamp.

Если на предыдущем этапе мы скопировали в список “Маршрут 1” лишние данные, то сейчас нам необходимо их удалить. С лишними маршрутными точками и треками все просто – правый клик мышки по маршрутной точке и далее либо пункт “Удалить“, либо “Удалить из Маршрут 1“.

Кнопка “Удалить из Маршрут 1” удалит объект из нашего списка (“Маршрут 1”), но поместит его в список “Не включенные в список данные“. Кнопка “Удалить” удалит объект из всех списков, где этот объект встречается. В последнем случае, объект будет удален из базы данных BaseCamp безвозвратно.

Теперь по поводу треков…

Довольно часто бывает так, что пройденный маршрут – это не отдельные треки навигатора, а лишь составляющая часть одного или нескольких длинных треков. Как правило, такое может быть если в навигаторе включена постоянная запись трека. В этом случае мы можем увидеть один сплошной трек, в котором содержится информация о всех путешествиях владельца навигатора.

Так или иначе, а нам вся эта информация не нужна. Поэтому теперь следует разделить большие треки на участки. Для этого в BaseCamp имеется возможность разделения треков. Что бы разделить трек делаем следующее:

• Левой кнопкой мышки выделяем трек в панели списка объектов или на карте;
• Правой кнопкой мышки делаем клик в точке трека, где хотим его разделить;
• В появившемся контекстном меню выбираем пункт “Разделить трек здесь” .

Таким образом разделяем трек в точках начала и окончания пройденного маршрута. В результате у нас в нижней левой панели объектов будут располагаться как треки с нужными нам участками, так и с лишними. Лишние треки удаляем.

Итак, теперь у нас осталось всего один или два трека в зависимости от того, имело место прохождение маршрута для затирки следов или не имело.

Для сдачи электронных материалов по пройденному маршруту этих данных вполне достаточно. Если предполагается оформление бумажных материалов (“Ведомость ЗМУ”, “Схема маршрутного учета”) без использования сервиса ЗМУ.РФ, то можно уже сейчас сохранить всю информацию в файл GPX и на этом закончить. Для сохранения данных (треков и маршрутных точек) в файл нужно:

• Убедиться, что в панели “Библиотека” у нас выделен нужный список. У нас это “Маршрут 1“;
• Воспользоваться пунктом главного меню “Файл“, далее выбрать пункт “Экспорт“, далее выбрать пункт “Экспортировать Маршрут 1“
• В открывшемся диалоговом окне указать желаемое имя файла, а в качестве типа файла указать “Формат GPS eXchange (*.gpx)“.

Файл будет сохранен в указанном месте в формате GPX.

Требования сервиса ЗМУ.РФ