Если хочешь начать с начала, советуем прочесть 1 часть статьи, где мы дали обзор принципа взаимозаменяемости разработчиков.
Будет ещё 3 часть, где мы соберем основные плюсы, минусы и промежуточные итоги применения принципа взаимозаменяемости разработчиков. Следи за новостями в нашей группе на Фейсбуке. : )
Наш стек
Общий стек формирует Битрикс24. Это php, приготовленный разработчиками Битрикс24, в который нужно встроиться и играть в основном по чужим правилам. Это огромный опыт во всякого рода оптимизации — чужие правила то и дело норовят подсунуть искусственные ограничения или устроить конфликт.
Разработка наших собственных приложений для Битрикс24 подразумевает немного другой стек — работа с протоколом AMI, с конфигуратором FreePBX под виртуальную АТС Asterisk, разные подвиды javascript, включая и клиентские фреймворки, и серверную Node.js, — и это ещё не всё!
За годы заказной разработки на базе Битрикс24 мы реализовали обмен данными с самыми разными системами, включая ERP-системы, самописные учетные системы, Microsoft Active Directory, отраслевые агрегаторы, платежные системы, движки сайтов и лендингов, системы веб-аналитики, разные виртуальные АТС и SMS-сервисы. Еще мы периодически мигрируем данные в Битрикс24 из разных систем.
Раньше мы работали и с сайтами на “БУС” (CMS “1С-Битрикс”), но уходим от этого. Специализация на автоматизации бизнесов оказалась интереснее.
Специализация разработчиков
Каждый разработчик выбирает из общего стека технологий то, что ему по душе. Более матерые разработчики так или иначе умеют многое, но у всех есть предпочтения.
Разработчик вправе обозначить то, с чем ему не хотелось бы работать. Нет смысла давать в работу то, с чем человеку иметь дело откровенно не по душе. С другой стороны, разработчик может указать на технологии, которые ему интересны, — по такому случаю иногда можно сменить технологию в задаче с запасом по времени.
Иногда разработчик хорошо делает специализированную задачу и становится приоритетным исполнителем по задачам такого рода.
Развитие разработчика
Специализация позволяет постоянно, хотя и медленно, расширять и обновлять стек технологий — и лично для разработчика, и для компании. Этому способствует постоянная ротация проектов, длящиеся проекты на поддержке и появление новых с простором для программного проектирования.
Обсуждение и оценка проекта с разными разработчиками позволяют позволяет для каждой задачи находить альтернативы решений и всегда иметь поле для маневра. Поиск альтернатив нешуточно повышает уровень понимания и организации кода в команде, а ещё дает буст менее опытным разработчикам.
Ограничения специализации
Если технология специфичная, вроде определенного js-фреймворка, она ставит существенные ограничения на применение принципа взаимозаменяемости: выбор исполнителя сужается до одного-двух конкретных разработчиков, знакомых с инструментом.
Такое ограничение не создает больших проблем, потому что большинство проектов — общего стека, и их несложно перераспределить, высвободив время спеца.
Например, сейчас мы осваиваем Vue.js силами двух разработчиков. Это не означает, что мы не можем поручить задачи на Vue.js другим разработчикам. Можем, и более того, — обязательно сделаем это. Но в некоторой перспективе выбранные первопроходцы будут задействованы во всех проектах с использованием Vue.js. Это одна из переменных в планировании.
Сила в декомпозиции
Есть один лайфхак, который лежит на поверхности. Любую задачу можно декомпозировать до выполнимости практически любым разработчиком. Декомпозиция на мелкие задачи, которые можно раздать всей команде, — вот в чем сила.
Главное, не забудьте про зависимости и необходимость мержей, а то неловко получится.
Конечно, бывают затыки с программным проектированием. Тут на помощь приходят продуманные артефакты продуктового дизайна, совещания с постановщиком задачи, а также совет и помощь самых опытных разработчиков.
Обучение и взаимопомощь
Принцип взаимозаменяемости разработчиков предполагает постоянную работу в команде, которая, в свою очередь, формирует культуру общения, взаимопомощи и взаимного обучения.
Программа стажировки в боевых условиях
Уже не первый год в нашей компании действует программа стажировки студентов МИЭТа, зеленоградского ВУЗа технической направленности, в качестве разработчиков под наш стек. Несколько стажеров работают постоянно, двое из них уже стали полноценными разработчиками.
Однако МИЭТ готовит специалистов не совсем нашего профиля, плюс в компании есть свои нормы организации кода и подходы к решению множества типовых задач. Не все стажеры сразу ориентируются в нашей системе организации рабочей среды и, тем более, в Битриксе. Чтобы снять основные вопросы, мы проводим для новичков разовую встречу-знакомство с нашей средой, правилами и Битриксом.
Обучение новых членов команды
Все наши разработчики учатся на курсах Битрикс24 и получают сертификаты. Для стажера это может оказаться не самой тривиальной задачей, но с опытом и со временем справляются все.
У нас принята своя и система наставничества, назовём её условно “Сенсей и его падаваны”. Сенсей — один из ведущих разработчиков. Он располагает практически неисчерпаемыми запасами здравого смысла, логики, терпения и простых программных решений, “чтобы заработало”. Под его крылом обучились и продолжают обучаться уже четыре человека — это весомо для нашей небольшой команды.
Стажер всегда может обратиться к более опытному разработчику за советом, решением и внимательным code review с разбором логики и программной реализации. Такие взаимодействия происходят ежедневно. Кроме всего прочего, это помогает нам поддерживать достойный уровень реализации всех проектов без исключения.
К тому же стажеры часто работают над задачами в паре с опытным разработчиком, дополняя и переиспользуя уже реализованную функциональность. Это позволяет стажерам находиться в потоке оптимальных программных решений и всяческих тонкостей, не замыкаться в отдельно стоящих задачах и не выпадать из рабочего процесса.
Совет и взаимопомощь
Стажёры стажёрами, а культура совета и взаимопомощи живет внутри всей команды разработчиков. У нас нет места личностной конкуренции. Хотя надо признать, что есть дух соперничества в плане качества создаваемых решений, и этот дух каждый разработчик воспринимает индивидуально. Кто-то впахивает, чтобы его решения всегда были не хуже, чем у коллег. Кто-то вообще не воспринимает соперничество — работает себе, и всё.
Посоветоваться с коллегой в плане выбора решения — нормально. У каждого разработчика есть собственная планка, после которой он или она предпочитает обратиться за советом. Взаимопомощь живет и работает благодаря человеческому и профессиональному подходу разработчиков — и благодаря применению принципа взаимозаменяемости тоже.
P.S. Инженеры
Я говорю о “разработчиках”, имея в виду и нашего инженера по Asterisk. Он пишет код на своей стороне, к нему часто приходят “паломники” посоветоваться по поводу поведения АТС и выбора архитектуры. Наш модуль интеграции Битрикс24 с Asterisk на основе конфигуратора FreePBX, его поддержка и развитие на протяжении уже 2 лет — во многом заслуга именно инженера по телефонии.
Наш технический директор — тоже инженер по телефонии, с уклоном в Cisco, но не только. Техдир периодически примеряет на себя то роль разработчика, то роль системного администратора (особенно когда наш штатный сисадмин в отпуске). На его счету множество разрешенных технических проблем и советов разработчикам.
Наш системный администратор — вообще золотой человек, повелевающий всеми средами разработки, тестирования, продакшнами, бэкапами и прочими жизненно важными вещами. Всегда оперативно поможет разработчику по своей части, посоветует, а иногда и поработает в паре.
Ну и наш генеральный директор, конечно. Он тоже инженер с опытом разработки и периодически не отказывает себе в удовольствии разрулить пару-тройку сложных технических казусов.
Так что не забывайте инженеров, когда ведёте речь о разработчиках, и уж тем более — о взаимопомощи и обучении.
