Как знать все чего не знаешь или что такое R&D Department

R&D или отдел Research and Development — это специальный отдел в компании который отвечает из слова Research, за то:

Из слова Development, за качество кода, выражающимся в:

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

Начнем разбирать эту статью в духе R&D, а именно, определим цель.

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

Если у бизнеса появляется какая-либо сложная или неизученная рынком потребность, то с этой задачей менеджер может обратиться в R&D отдел. Сотрудники отдела декомпозируют бизнес идеи менеджеров, рассмотрят и переделают задачу в технический лад, которую легко смогут читать разработчики в дальнейшем.

R&D отдел может поресерчить подходящие инструменты и выбрать нужные для реализации идеи.

Передав задачу в разработку, сотрудник разработки может обращаться в R&D отдел за консультацией по инструменту.

R&D отдел также исходя из своего названия может заниматься проблемами рефакторинга (выбор стека, ведение рефакторинга в виде проверки PR), оптимизация, улучшение работоспособности продуктов, подбор нового стека если нужно

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

Отдел может быть сформирован исходя из бюджета компании, но одной из основопологающих вещей должен быть её руководитель. Остальные сотрудники делятся по вариантам:

Команде X требуется сложная задача за рамками компетенции сотрудника команды, в таком случае руководитель отдела или её сотрудник ресерчит задачу → описывает ее → делегирует разработчику, еще какое-то время разработчик может вливаясь в задачу менториться у R&D отдела.

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

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

Если вы представите работу в R&D таким же процессом, как создание светофора, вы снимите с себя большую ношу и поймете: ориентируемся на легкое решение, а ищем самое подходящее.

Команда столкнулась с задачей, у сотрудников которой нехватает компетенции для её решения. Тикет появляется на борде R&D.

Определяем задачу, выполняем действия по инструкции:

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

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

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

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

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

Отойдем от проблемы внедрения маленьких инструментариев или реализацию в рамке одной небольшой задачи и предположим что вашей задачей является функционал, работа которого подразумевается во многих частях проекта. В рамках обсуждения такой идеи, существует множество вариантов масштабирования, начиная от упаковки функционала в библиотеку, выделенного сервиса в кор функционале приложения или отдельного приложения если угодно. Конечно каждый случай здесь требует индивидуального решения, что делает невозможным обозначить правильное и конечное решение. Если такая задача в частном случай попала в ваш отдел и вы её исполнитель, то вам следует четко осознать границу R&D и отделом разработки. Задача R&D: понять — передать — проследить. Если функционал справляется с задачей, выша задача выполненна на 80%, остальные 20% касаются правильной передачи её в разработку.

Но в целом правила одни:

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

Это и правда сложная задача, но с пониманием конечного плана она становится куда проще.