Поговорим о том, как «варить» RnD в крупном энтерпрайзе. Какие при этом возникают странные вещи и антипаттерны. Расскажет об этом Александр Токарев, CTO разработки в Xsolla. Он работал в командах разных размеров, возглавлял RnD в Сбертехе, а сейчас его основная задача — балансировать между красотой архитектуры и финансовой выгодой.
Александр объяснит, как устроена мотивация топ-менеджеров, которые потребляют результаты от RnD-команд и почему они получают неожиданные вещи на выходе. Также он расскажет о типах, жизненном цикле продукта RnD, командных топологиях и артефактах. В качестве бонуса вы получите чек-лист по проверке RnD-команд, в которую вас зовут и что нужно спросить у того, кто приходит на RnD позиции к вам.
Типы RnD
RnD бывает научным, который занимает года и уже к нему привыкли. Также есть RnD в промышленности, без которого не работают фабрики и заводы. А есть RnD в IT или просто RnD, как клёвое слово.
Разобраться с типами RnD поможет hh.ru. На hh.ru более 130 вакансий в RnD. Посмотрим самую первую:
И что тут RnD?
Разбирать инциденты, писать код на Python, интегрироваться с 1C — непонятный RnD. Самая обычная разработка.
При этом в другой вакансии от ИТМО непонятны вообще три четверти слов, но видно, что это на века:
Ясно, что делается то, что до вас не делали никогда.
RnD есть даже во «Вкусно и точка». Только раньше эти люди назывались технологами:
В этой вакансии самое главное то, что есть создание прототипа и доведение его до продакшена.
Позиция руководителя RnD в МТС уже очень конкретная:
Превосходно оформленная вакансия, перечислены основные зоны ответственности данного руководителя. По ней видно, что основное, чем занимается руководитель RnD — создаёт почву, где его инновации будут приниматься.
В вакансии разработчика нет никакого техстека, но указано, что надо выбирать техстек, инструменты, решать конкретные задачи конкретной предметной области:
Это очень важный элемент чек-листа вакансии на RnD. Если в RnD есть техстек, скорее всего, это не RnD, а классическая разработка.
Что такое RnD и откуда он берётся?
RnD — это создание технологии с нуля любыми доступными способами без гарантии доставки результата. То есть это то, что обеспечивает предприятию возможность существовать долгое и продолжительное время за счет постоянного притока новых прибыльных идей.
Gartner hype cycle
Gartner hype cycle — это некая эмпирическая кривая, которая описывает жизненный цикл любого продукта:
Продукт появляется в точке инноваций. Потом поднимается на вершину и оттуда часто скатывается в никуда. После этого, если он выживает, то постепенно развивается и доходит до плато продуктивности.
Hype cycle чётко показывает появление новых технологий и обновляется каждый год, причём не только в целом, а и в разрезе предметных областей и технологий.
Посмотрим на hype cycle за 2022 год:
На примере AI видно, что технологии машинного зрения уже практически достигли величины продуктивности. В то время все знают, где находится Chat GTP как представитель генеративного ИИ.
Таким образом, инновации начинаются в самом начале Gartner hype cycle.
Чтобы заниматься инновациями, нужно иметь свои базовые продукты на плато продуктивности, пройти испытания большим количеством лет жизни и людей в штате. Прожить с этим какое-то количество времени, а главное, быть прибыльным.
Попытаться можно и без этих условий, но результаты будут весьма сомнительны.
RnD sides
RnD — это очень многосторонний процесс в котором участвуют:
Внутренние или внешние клиенты, которые запрашивают RnD;
Команды, которые выполняют RnD;
Продуктовые команды — те, кто превращают RnD в настоящий продукт;
Топ-менеджмент — те, кто этим управляет.
Top management prerequisites
RnD — это прежде всего про commitment, то есть про готовность потреблять RnD, который разрабатывается. Чтобы не выходило так, что вы производите огромное количество MVP, и они просто складываются, а RnD — это место, куда ссылают активных людей.
Нужно уметь внедрять MVP в инфраструктуру вашего предприятия. Рекомендую ознакомиться с методологией Agile change agent, суть которой сводится к тому, что можно обходить организационные барьеры внедряя изменения, даже если это крупные энтерпрайзы.
RnD — это про положительную бюрократию с комитетами и процессным управлением, потому что RnD — это первично про управление портфелем.
Важно понимать, что в RnD MVP может не удастся и это нормально, команду при этом не трогают - договоритесь про это с топ-менеджментом.
Чтобы это RnD подразделение работало быстро, нужна своя инфраструктура или облако, желательно внешнее. Как только появляется внешнее облако или отдельная инфра, в энтерпрайзе должна быть договорённость: об отдельном периметре кибербезопасности или об отдельном юрлице.
Должны быть определены бюджеты на минимальные и максимальные MVP и в целом годовой бюджет на всё RnD подразделение. RnD — это про FinOps. Практически всегда это бюджет потерь, с которым надо уметь работать на ежедневной основе.
Бизнесовые, инфраструктурные и ML MVP отличаются друг от друга как по составу команд, так и по длительности разработки и сложности внедрения.
Чтобы определить источник MVP, надо смотреть боли предприятия. Они находятся очень просто — в чатах, Confluence и ретро. Информация с ретро команд — это самый ценный способ получения болей вашего энтерпрайза. А еще это можно автоматизировать и автоматически организовывать пополнение беклога MVP.
Можно посмотреть в интернете. Например, на сайте Researchgate.net, учёные публикуют свои статьи, которые полностью следуют по Gartner hype cycle.
Аналогично и по топовым конференциям:
Маркетинг
RnD внутри энтерпрайза — это про маркетинг. Но очень важно не путать маркетинг для стартапов и маркетинг для энтерпрайза, потому что в энтерпрайзе самое важное — это продукт. Одной-двух презентаций достаточно. Если делать много презентаций, то можно показаться всем просто менеджером презентаций без какого-то результата. После этого ваш бюджет быстро зарежут.
MVPs portfolio management
RnD — это про портфели. Kanban Portfolio Management — это некий шаблон этапов, по которым проходит MVP и рекомендуется Александром для RnD команд. Он включает в себя:
Funnel — первый этап, в котором помещаются все идеи;
Reviewing — первичная приоритизация идей;
Analysing — важнейший этап, на нём определяется, что такое MVP, какие есть альтернативы, стоимость этого MVP и производится дополнительная переприоритизация;
Portfolio backlog — те MVP, которые гарантировано точно будут делаться, как только освободится какая-либо из RnD-команд;
Implementing с самим MVP и этапом persevere, на котором делается продукт. Но продукт на самом деле делать не надо, потому что его сделает продуктовая команда в случае успеха.
Самое главное в портфолио Kanban системе — это её статусы. Они одолжены у SAFe, который превосходно описывает эту методологию. Можете детально прочитать про неё в их документации.
Методы приоритезации:
1. RICE;
2. Eisenhower matrix;
3. MoSCoW;
4. ABCDE;
5. ICE;
6. Value versus Effort matrix;
7. WSJF;
8. Kano;
9. Walking skeleton.
На собеседованиях кандидата на топ-менеджмент в RnD, проверьте, знает ли он эти методы приоритезации и понимает ли, какие использовать. При этом он должен выбирать только те методы, которые позволяют приоритезировать MVP в условиях неопределённости, а в данном списке таковые далеко не все.
RnD product lifecycle MVP stage
MVP – это то, что доказывает осуществимость и жизнеспособность идеи. MVP для RnD — это продукт, который качественно реализует бизнес или техническую идею. Это говорит о том, что в MVP RnD-команду можно запустить реальных пользователей. Этот MVP может быть передан продуктовой команде в случае успеха с учетом тех commitments, которые мы заключили на этапе подготовки Kanban-портфолио.
Это радикально отличает продуктовую разработку от MVP-разработки в RnD, потому что в RnD всегда есть две команды: одна делает, другой обязательно передадут, что сделано.
Они появляются на этапе Portfolio backlog канбан системы.
В крупном энтерпрайзе все знают, в какой департамент переедет MVP. Если не знают, просто не занимайтесь этим, иначе это будет RnD ради RnD.
Out of MVP
RnD, как уже говорилось ранее, это про commitment, это то, о чём вы договорились, чего будет и не будет там.
В MVP чаще всего не входят:
Мониторинг/метрики;
Логирование с разными уровнями;
Инфраструктура как код;
Кибербезопасность;
CI/CD pipeline;
Энтерпрайзный CI/CD pipeline.
Именно кибербезопасность и энтерпрайзные pipeline в состоянии заруинить всю RnD-разработку.
Team topology
Роли: тех/тимлиды, бэкенд, фронтенд и очень важный персонаж — инфраструктурный инженер. Именно он будет ставить огромное количество продуктов, которые вам нужны для быстрого достижения цели, но которые не запустятся как есть, а если и запустятся, то не будут никак интегрированы между собой
SRE понадобится, так как у вас могут быть реальные production юзеры, но он может быть разделяемым на весь RnD.
QA, скорее всего, появится в продуктовой команде. На него обычно не хватает ресурсов.
3-6 команд одновременно. Если вы занимаетесь RnD, вести одновременно более 3-6 проектов — это просто бесполезно.
Максимально осторожно относитесь к аутсорсу. Он хорошо работает тогда, когда ему чётко поставлена задача, а RnD — это не про чёткую постановку задач.
Если всё же нужна помощь — обращайтесь к кратковременному адресному консалтингу.
RnD — это про то, чтобы его потребляли. Любой крупный энтерпрайз не сможет затянуть в свою инфраструктуру и стандарты кибербезопасности более, чем 1-2 MVP в год. Поэтому можно делать MVP сколько угодно, но если никто не будет принимать, то через год они станут абсолютно ненужными и ваш RnD будет просто тратить деньги. Поэтому достаточно 3-6 команд.
RnD engineer
RnD-инженеры — это самодостаточные люди, которые не боятся размытых требований. Они способны декомпозировать задачи и решать те задачи, которые просто отсутствуют как класс на Stack Overflow. Эти люди умеют переключаться на другие языки и технологии, не рефлексируют по месяцу после того, как их продукт убили или передали в продуктовую разработку.
Это настоящие инженеры!
Настаивайте, чтобы HR’ры проверяли как человек рефлексирует после того как проект закрыли, это критично важно. Многие люди просто выпадают из потока после закрытия проекта на довольно длительное время.
Engineer vs Developer — парочка примеров из реальной жизни.
Пример 1
Есть задача создать multi-tenant инсталлятор для K8S.
Разработчик героически садится, пишет свой оператор, берёт напрямую работу с Helm API. В результате ничего не работает, потому что самое весёлое API — это API чистого Helm.
Инженер берёт готовый Helm charts, находит в интернете какой-то компонент, который выставляет Helm через REST, делает пару фиксов — оно работает.
Пример 2
Задача — сделать возможность расширения Postgres на любом языке в любой точке.
Разработчик страдает 3 недели, а потом говорит: «Ну, блин, ребята, есть же Pl/Python!» — «Серьёзно? Ну, спасибо большое!» И это за три недели.
В то время как инженер в состоянии перелезть за 7 дней на Rust, найти какую-нибудь опенсорсную штуку а-ля https://github.com/wasmerio/wasmer-postgres, портировать её на последнюю версию Postgres, и всё — POC работает!
Кстати, почему и откуда мы взяли вдохновение на этот RnD? Например, на Kubecon есть такая штука как XDays. То есть, это выделенные целиком дни, посвященные какой-то технологии. Именно оттуда можно почерпнуть свежие идеи:
RnD lead
Руководитель вашего RnD это ключевой персонаж RnD-активности, это именно тот кто драйвит ваших лидов и демонстрирует постоянную готовность к созданию нового.
К примеру, так выглядела четверть чата Александра в Telegram. Он каждый день просматривал его, когда работал со своим портфелем в части инфраструктурного RnD:
Этот человек умеет управлять ожиданиями, опытнейший фасилитатор между бизнесом и технологиями. Это важно потому, что вы будете постоянно убивать MVP и надо объяснять бизнесу, что это норма.
Это человек с опытом tech presale и энтерпрайз-архитектуры. Потому что если делать MVP, который не может быть интегрирован в ландшафт этой организации, то зачем всё это надо? Человек должен понимать, какие есть сети, подсети, СУБД и т.д. RnD в энтерпрайзе в вакууме бесполезно и контрпродуктивно.
Это человек с превосходными презентационными скилами. Он должен уметь доносить на 1-2 презентациях мысли абсолютно разным людям. Фактически он выступает как и продуктовый директор.
Так как это довольно редкие люди, нужно в их работе каждый день использовать практику shadowing, то есть постоянно бэкапить RnD лида.
RnD spirit
В RnD критично важен дух, в котором поддерживается постоянный темп инноваций в условиях жесточайших временных рамок и бюджета, когда реально идёт борьба с продуктовой разработкой. Это происходит потому, что обычно MVP проект — разный и технически сложный.
Александр считает, что надо пересобирать команду на каждый MVP проект. Поэтому когда в RnD нанимаются люди, им не говорят: «Ты будешь тимлидом, тем, сем, пятым, десятым». Для каждого проекта в соответствии с принципами холакратии выбирается нужный тимлид и нужные инженеры, которые могут дать максимальный профит конкретному MVP. Это сложный процесс — continuous roles rotation, о котором надо говорить на интервью, потому что многие люди приходят на должность, а не на роль. То, что человек сегодня тимлид, а завтра просто бэкенд-разработчик, многим может не зайти.
Давайте поймем что же такое скорость, плотность и сжатые рамки.
За 10 месяцев команде надо:
Сделать ускорение вычислений запросов на FPGA;
Разработать FinOps-платформу;
Разработать DLP-систему на Service Mesh;
и это ещё половина задач...
При этом чтобы выполнить эти задачи придется использовать все возможные языки, которые существуют: Verilog, C, C++, Go, Java, Python, PromQL, Rego, OPA, Graphana, Istio, глючный Envoy, неработающий WASM, C++…
И это реально можно сделать, если бороться с продуктовой разработкой.
Понять, что команда туда скатилась очень просто — если в её задачах появилось то, что связано с эксплуатацией с хард-продакшн:
1. Autoscaling, rate limits, log level, мониторинг;
2. Заглушки для A/B тестов;
3. Просто огромный API — в RnD не может быть большого API.
Посмотрим на примере как команда внезапно становится продуктовой.
Есть задача сделать функционал S3 Select с аппаратным ускорением.
Как должен выглядеть API:
CreateBucket, CreateObject, SelectObject - Создать Бакет, создать объект и Сделать выборку на SQL.
2 месяца, а метода SelectObject нет. Но зато есть:
CreateIAMGroup, CopyObject, EncryptObject, SetLifeCyclePolicy.
Это значит, что вы упустили команду, и команда просто начала делать S3 хранилище. Непонятно зачем...
В общем, используйте технологии, позволяющие быть максимально эффективными в рамках конкретного MVP, в которых ваша RnD-команда наиболее компетентна. Важный нюанс — даже если вы в этом компетентны, всё равно надо быть близким к тому языку разработки, в котором живёт ваш энтерпрайз. Потому что очень важно состояние вашего продукта после того, как вы его передали в продуктовую команду.
Выбор технологии в RnD — это компромисс между производительностью работы департамента, удобством реализации конкретного MVP и той болью, которую получит продуктовая команда, когда будет переписывать ваш продукт и адаптировать его к реальности энтерпрайза. Именно эту задачу RnD-лиды решают на постоянной ежедневной основе.
SDLC methodology
Не должно быть никакой конкретной предопределенной методологии. Это комбинация, которая подбирается исключительно под каждый MVP. Скорее всего, в начале, когда огромная неопределённость будет Kanban. Когда появятся первые пользователи, будет Scrum.
Передача MVP
Предположим, сделано MVP и надо передавать его в продуктовую команду. Эта встреча должна обязательно происходить лично, где собираются все те, кто делал MVP и объясняют, что действительно нет совершенного кода, открываются все срезанные и задокументированные проблемы и углы. Эта встреча это место обсуждения вопросов.
Часто встречаются примеры, когда RnD-команда даёт продуктовой ссылку на GitLab и говорит: «Ну, и вопросики в Confluence пишите!». Так не работает! RnD команда должна быть максимально заинтересована в гладкости процесса передачи в продуктовую.
Артефакты для продуктовой команды
Что надо передать продуктовой команде:
Сам MVP;
Техдолг;
Техдолг должен обязательно быть передан в техтрекере, потому что это выравнивает MVP-команду с командами продуктовой разработки. Они понимают, что это не просто какие-то фантазёры что-то на коленке после школы накарябали, а понимают процесс разработки софта, но сознательно идут на упрощения.
Текущую и целевую архитектуру;
Передача целевой архитектуры — это максимально нежный процесс, потому что продуктовая команда живёт с продакшеном каждый день. Она знает его в 800 тысяч раз лучше, чем вы. Любые ваши идеи по целевой архитектуре будут максимально наивны и смешны, но должны быть озвучены.
ADRs;
ADR (Architecture Decision Records) — это то, где вы описываете, почему и как вы пришли к таким-то архитектурным решениям. Это критично важная часть для RnD, потому что когда продуктовая команда начнёт затаскивать то, что вы сделали в продакшен, она посчитает, что вы далеки от реального продакшена и не в курсе, как делают нормальные люди. Поэтому с большой вероятностью переизобретёт или попытается переизобрести то, где вы уже набили огромное количество шишек и уже от чего-то отказались или наоборот приняли такое решение. Это ещё один пункт, радикально отличающий RnD-разработку от продуктовой. Существуют продукты, живущие 3-4 года без ADR, но ADR обязаны быть для RnD разработки!
Deploy скрипты, если они у вас есть;
CJMs;
Бэклог фичей;
В отличие от списка известных багов, он может быть передан в чём угодно, потому что довольно быстро станет не ваш.
Контакты клиентов;
Идея.
Важно передать саму идею, при этом передача product vision как документа чаще всего не работает. Идея всегда в людях. Поэтому передавать надо человека!
В процессе реализации MVP вы должны вырастить product owner-а. На этого человека должна быть выделена ставка. Если вы чувствуете, что взлетает POC и начинает получаться MVP, появляется product owner. Именно его нужно передать в продуктовую команду.
Важнейшая часть RnD — это бюджет. Он должен быть на product owner в RnD подразделении, ровно как и у энтерпрайза должен быть бюджет, который примет этого product owner вместе с MVP в процессе передачи.
Ещё нужны HR-процессы, позволяющие быстро искать таких людей в команду.
RnD product lifecycle Project development stage
Когда продуктовая команда переняла MVP, она не будет делать в нём ровным счётом ничего. Она будет дотягивать его до того уровня, когда можно воткнуть его в прод по требованиям энтерпрайза.
Чтобы это произошло, вам необходимо:
Пообещать реальную гарантийную поддержку на предсказуемый интервал времени;
Менторить того самого product owner, которого вы от сердца оторвали и вырастили с 0;
Поработать с клиентами, объяснить им, что сейчас прошла передача и предупредить может быть, будут какие-то косяки в процессе погружения продуктовой команды.
Ну просто ходите в продуктовые команды, если вам интересно, происходит с вашим MVP что-нибудь или нет.
RnD product lifecycle Product development.
Это самый последний этап, который уже полностью не под вашим контролем.
В процессе проектной разработки product owner уже переобуется и станет душой другой команды - just relax
Deathgating metrics
MVP взлетает не всегда, его убивают в принудительном по следующим метрикам:
по длительности MVP;
по выходу за бюджет;
по отзывам конечных пользователей.
Длительность — это важная метрика. Она радикально зависит от каждого проекта и должна быть фиксированной. Именно её наличие даёт тот самый темп инноваций, о котором говорилось в части про дух RnD.
Для бизнесовых продуктов можно уложиться в 3 месяца. Потому что есть много пользователей, которые могут проверить вашу идею.
Если же изобретать технологию, о сроке менее 6 месяцев говорить бесполезно. Существует огромное количество опенсорса, и то, что задумано как инновация, скорее всего, уже придумано до вас и написано на Rust :) Поэтому когда вы делаете инфраструктурный MVP, делайте вначале POC, игнорируйте запрещённые лицензии, снижайте риски для вашей организации.
Есть и другие причины убиения MVP, не только вылет за метрики. Во-первых, у вас может быть плохой лид, не умеющий управлять фокусом, работать с технарями или не владеющий портфельным управлением. Может, он просто выбирает кривые идеи, и это опять-таки вопрос про портфельное управление. Как вариант, он набрал плохую команду или набрал идеальную, но она заточена только под продуктовую разработку.
Если RnD-команда грустит, когда убила или передала свой MVP, надо смириться. Адекватная команда будет страдать в любом случае. Если команда не грустит при передаче продукта в продуктовую разработку или при закрытии — это первый признак проблем внутри. Главное чтобы длительность страдания была ограниченной.
Сходите в бар, заведите какой-то стандартный ритуал. Детально подумайте и порефлексируйте почему так произошла ситуация. При этом важно понимать, что единственное по-настоящему успокаивает команду — это портфель проектов для дальнейшей работы. Если смотреть статистику просмотров примерно за месяц до завершения MVP, можно увидеть, как вся команда стабильно раз в неделю смотрит ваш портфолио Kanban.
RnD — это про прозрачность. Портфолио Kanban должно быть открыто абсолютно всем. Не надо ничего скрывать, если вы не хотите психологических стрессов у команды.
Опять таки, результаты MVP можно опубликовать на Хабре или выложить опенсорс. Например, у Тинькофф был очень интересный продукт по синтетическому мониторингу и они опубликовали его в опенсорс, хотя сейчас уже не поддерживают. Зато людям от этого польза и команды чувствуют свою нужность.
Важно понимать, что если вы сделаете это самовольно, это повлечёт нарушение прав интеллектуальной собственности. Лучше такие вещи согласовывать с руководителями. Желательно на этапе создания подразделения.
Deathgating ratio
Какая нормальная пропорция живых и мёртвых проектов в RnD для энтерпрайзов? По опыту Александра и по тому, что пишет ResearchGate, это где-то 1:3. Если больше, то портфель плохой, а значит, наверно, вы плохой RnD лид. По-крайней мере, так о вас подумает руководство. Это ключевая разница между RnD в энтерпрайзе и RnD, которое есть в стартапах. В стартапах 1 к 100 это абсолютная норма.
Энтерпрайзы, у которых продукты находятся на плато продуктивности, радикально нетерпимы к ошибкам. Они их все уже прошли на всех этапах жизненного цикла Гартнера. Довольно часто ключевой бизнес говорит, что давайте лучше выжмем 1% с имеющихся продуктов, чем будем гнаться за 10% с вашего RnD.
Success metrics
Метрики успешности критично важны для RnD. Самое простое начать с базы:
Метрики по цифрам: изучайте, сколько у вас задач на Kanban, размер портфеля в разрезе по состояниям swimlanes, сколько убито MVP;
Метрики по стоимости: стоимость RnD, средняя стоимости MVP, которые потом переводятся в эффективность RnD. Ключевая воронка — сколько вы потратили на весь RnD, сколько в итоге докатилось до прода и сколько принесло реальных денег;
Метрики по времени: длительность реализации MVP, как долго продуктовая команда онбордится в MVP, как долго после онбординга команда докатывает до прода продукт.
Собирать эти метрики надо минимум 2 года. Это к вопросу о бюджете — когда вы будете устраиваться в RnD-команду, аккуратно узнайте, сколько там денег. Может быть, их не хватит даже период сбора метрик об успешности команды.
Изучайте ResearchGate:
Там раскрыто множество подходов о том, как правильно «варить» RnD.
Выводы
Требуйте, чтобы RnD приносил вам идеи.
Ежедневно работайте с портфелем.
Беспокойтесь о качестве. Не надо создавать изначально «кривые» MVP.
Останавливайте MVP, нарушившие метрики deathgating, мгновенно.
Работайте с бюджетом.
Будьте очень внимательными в работе с рисками.
RnD — это самая интересная работа, которая есть. Но помните - в условиях текущей ситуации в мире RnD-подразделения — это предмет рассмотрения на сокращения в первую очередь.
Чек-лист RnD вакансий
Что вы должны спросить:
Сколько MVP сейчас в процессе разработки?
Сколько MVP вообще в беклоге есть?
Это для ответа на вопрос, а что я буду делать потом.Сколько проектов выжило через год после того, как прошли старт MVP, спрашивайте конкретику. Часто руководители RnD галлюцинируют об успешности их подразделений.
Обязательно узнавайте пропорцию deathgating — сколько на самом деле живых MVP?
Откуда они берутся?
Как принимаются решения при перемещении MVP между статусами?
Конечно же, какой бюджет?
Как проверить кандидата?
Спросите у него три примера RnD-проекта.
Попросите его описать, как он видит идеальный для него RnD-процесс.
Как он видит идеальную RnD-команду мечты, в которой бы хотел работать.
Что должно быть, по его мнению, передано в продуктовые команды?
Когда и как останавливать проект?
Всё остальное спросят ваши технари.
Этот чек-лист универсален и для разработчика, ровно как и тимлида, лида лидов, потому что он полностью отвечает на вопрос, как человек понимает RnD.
Ну и конечно же интересно какой вопрос заваливают 90% собеседуемых? На самом деле большинство не правильно отвечают на самый первый вопрос. Очень мало кто понимает, что такое RnD проект.
