Как знать все чего не знаешь или что такое R&D Department
R&D или отдел Research and Development — это специальный отдел в компании который отвечает из слова Research, за то:
Какие инструменты понадобятся в разработке и как их использовать
Какие новые инструменты появились и можно ли внедрить их в текущие продукты
Как принять и передать знания внутри компании
Из слова Development, за качество кода, выражающимся в:
Проверка гипотезы
Внедрение новых инстументов в продукт
Проверка PRов на знание нового инструментария
Масштабирование
Теперь мы знаем что это такое и углубимся чуть дальше: как строится отдел, из кого состоит и самое важное — процессы. Как же все выглядит изнутри.
Начнем разбирать эту статью в духе R&D, а именно, определим цель.
Конечно R&D не обязательная вещь любой компании, но если ваша команда нуждается в постоянных иновациях продукта и вы чувствуете потребность в таком отделе, то первое что вам нужно это определить цель.
Цель R&D
Если у бизнеса появляется какая-либо сложная или неизученная рынком потребность, то с этой задачей менеджер может обратиться в R&D отдел. Сотрудники отдела декомпозируют бизнес идеи менеджеров, рассмотрят и переделают задачу в технический лад, которую легко смогут читать разработчики в дальнейшем.
R&D отдел может поресерчить подходящие инструменты и выбрать нужные для реализации идеи.
Передав задачу в разработку, сотрудник разработки может обращаться в R&D отдел за консультацией по инструменту.
R&D отдел также исходя из своего названия может заниматься проблемами рефакторинга (выбор стека, ведение рефакторинга в виде проверки PR), оптимизация, улучшение работоспособности продуктов, подбор нового стека если нужно
Построение R&D
На данный момент для создания отдела требуется сформировать команду и инструкцию по его текущим задачам.
Отдел может быть сформирован исходя из бюджета компании, но одной из основопологающих вещей должен быть её руководитель. Остальные сотрудники делятся по вариантам:
Part — руководитель отдела, выполняет все обязанности исходя из определения отдела и может выцеплять разных разработчиков разных команд исходя из их компетенции.
Full — в отделе есть как руководитель так и сотрудники, которые ресерчат задачи и даже могут их выполнять, либо внедряться в какие-то команды временно.
Команде X требуется сложная задача за рамками компетенции сотрудника команды, в таком случае руководитель отдела или её сотрудник ресерчит задачу → описывает ее → делегирует разработчику, еще какое-то время разработчик может вливаясь в задачу менториться у R&D отдела.
Процессы
Давайте рассмотрим пример: ваша задача построить город, у вас есть несколько районов этого города, вам надо выстроить инфраструктуру, обеспечить районы всеми нужными сервисами (продукты, прачечные, спортзалы, парки), а так же регулировать городской трафик.
Светофоры это просто
Задача может казаться невероятной для людей, которые никогда не занимались градоустройством, но углубляясь в нее можно заметить определенные вещи, которые вовсе не кажутся такими уж тяжелыми, например проблемой урегулирования трафика когда-то давно занимались регулировщики, но позже эту задачу делегировали на что-то более автоматизированное, а именно светофоры. Светофоры в свою очередь не управляемые каким-то сложным алгоритмом, они не являются продуктом AI, что определяет когда должен идти пешеход, а когда должна ехать машины. Светофор это просто некое наблюдение человека, который его установил и спрограммированная на нем джоба, которая через опреленное время переключает зеленый свет на красный и наоборот. Такая джоба управляет всем городским трафиком.
Если вы представите работу в R&D таким же процессом, как создание светофора, вы снимите с себя большую ношу и поймете: ориентируемся на легкое решение, а ищем самое подходящее.
Первая задача
Команда столкнулась с задачей, у сотрудников которой нехватает компетенции для её решения. Тикет появляется на борде R&D.
Определяем задачу, выполняем действия по инструкции:
Углубляемся в задачу, выясняем конечный результат и все тонкости, которые к нему ведут.
Четко и ясно обозначаем начало и конец задачи, так чтобы решение понял даже ребенок.
Когда мы имеем точки начала и конца, выстраиваем то, что посередине — реализацию.
Выстраиваем гипотезы, идеи о том как эту задачу можно решить.
Когда у вас в голове есть свежие идеи, взвешиваем все за и против и выбираем одну наиболее выгодную. На этом этапе имеет значение занять позицию и следовать ей, не задумываясь над тем правильную ли мы стратегию выбрали. Такие вещи очень отвлекают и лишь растягивают процесс получения результата, а если вы в процессе поймете что ошиблись, просто вернемся с новым пониманием задачи и определим новую гипотезу.
У вас есть гипотеза! Теперь время для её реализации, начинаем ресерчить инструменты: берем во внимание текущий стек команды, ищем те инструменты, которые легко имплементируются в среду разработки. Таким образом вы сужаете себе область поиска нужных инструментов, статей, методов, техник и заодно облегчаете на будущее задачу программистам, которые будут этот инструментарии внедрять.
Находим инструмент и закрепляем гипотезу уже техническим контекстом. Время углубится в тех часть.
На этом этапе вам потребуется стать мини гуру в том, что вы выбрали. Если вам позволяет среда, я бы посоветовал вам создать себе мини проект и выработать определенный стиль, углубиться в мелкие проблемы выбранных инстументов, настроить их интеграцию с текущим проектом и его стеком.
Вы стали небольшим экспертом: результат покрывает созданную проблему и вам пора передавать решение в разработку.
Передача задачи в разработку
Когда задача передается в разработку, естественно мы не бросаем разработчиков на произвол судьбы с тонной документации, наша первоочередная задача это передать разработчику свои знания.
По моему опыту, передача знании программистам в виде мини документации приводит к абсолютному нежеланию разработки разбираться в проблеме, а лишь скорейшей интеграции в проект непосредственного решения, что в дальнейшем будет приводить людей к вам, при каждой малейшей проблеме вновь и вновь, как к человеку с экспертностью.
Наша задача таких ситуации избежать, поэтому придется по-настоящему потолковать с разработчиком от корня до реализации проблемы:
Какие были альтернативы
Почему была выбрана такая стратегия решения
С какими проблемами вы столкнулись
Базовая конструкция
Лишь пройдя через этот путь сам, разработчик сможет прощупать технологию и получить в ней экспертность.
Контроль
Конечно, на всем пути реализации задачи требуется контроль качества, поэтому обязательно подтверждаем полученные навыки пул реквестами. Что тоже является средством обучения, писать код правильно.
Масштабирование
Отойдем от проблемы внедрения маленьких инструментариев или реализацию в рамке одной небольшой задачи и предположим что вашей задачей является функционал, работа которого подразумевается во многих частях проекта. В рамках обсуждения такой идеи, существует множество вариантов масштабирования, начиная от упаковки функционала в библиотеку, выделенного сервиса в кор функционале приложения или отдельного приложения если угодно. Конечно каждый случай здесь требует индивидуального решения, что делает невозможным обозначить правильное и конечное решение. Если такая задача в частном случай попала в ваш отдел и вы её исполнитель, то вам следует четко осознать границу R&D и отделом разработки. Задача R&D: понять — передать — проследить. Если функционал справляется с задачей, выша задача выполненна на 80%, остальные 20% касаются правильной передачи её в разработку.
Но в целом правила одни:
Выработать стиль
Делигировать задачу в разработку
Проследить за реализации
Эпилог
Ваша задача построить город, у вас есть несколько районов этого города, вам надо выстроить инфраструктуру, обеспечить районы всеми нужными сервисами (продукты, прачечные, спортзалы, парки), а так же регулировать городской трафик.
Это и правда сложная задача, но с пониманием конечного плана она становится куда проще.
