В прошлый раз я подробно рассказывал об особенностях компании-вендора. Теперь настало время поговорить о мифах и правде в работе компании-вендора. Если тема вам интересна, то давайте начнём.
Миф 1. Особые продуктовые специалисты
Один из наиболее стойких и распространенных мифов. Будто бы существует особый вид специалиста - продуктовый разработчик или продуктовый тестировщик. Очень редкий и ценный зверь. Мне кажется, что таких специальностей не бывает, но, что действительно существует, так это определенные особенности, присущие разработке продукта и как, следствие, продуктовая разработка может показаться скучной или тесной для некоторых людей.
Попробуем разобраться с качествами технического специалиста, которыми мы чаще всего оперируем для оценки в жизни:
Хороший vs Плохой
Соблазн применить эту категорию очень велик. «Хорошесть» или «плохость» не зависит от места работы, опыта работы, роста или цвета глаз. Это интегральная экспертная оценка ;-). Хорошего программиста видно по его коду, который компактен, понятен, легко поддерживается. Хорошего QA видно по въедливости, упорядоченности и понятности его кейсов. Видно его по вопросам, которые он задет до/при реализации/тестировании.
Это видно по скорости и уровню погружения в решаемую задачу и, в конце концов, по тому, к кому ходят задавать вопросы. И я не знаю, как это измерить в попугаях. Так вот, плотность хороших спецов в продуктах, аутсорсе, финтехе, abap, 1с, фронте и бэке одинаковая. И это качество точно не является специфичным для какой-то одной отрасли или направления.
Элитные подразделения существуют только там, где их специально выращивают. Вы встречали такие?
Ширь vs Глубь
Утрирую, но существует глобально 2 фракции (опыт нескольких сотен собеседований, которые проводил автор): “мне интересны новые технологии” и “я хочу видеть стабильность”. Так и тянет сказать что-то вроде “кто не хочет нового в молодости, у того нет сердца, а кто не хочет стабильности в зрелости, у того нет ума”. Но, по моим наблюдениям, это не сильно связано.
С одной стороны, миф появляется из-за разного уровня любознательности (кто-то за жизнь меняет 15 хобби, а кто-то марки всю жизнь собирает). С другой - рынок и современная мифология вокруг разработки ПО вынуждают людей заявлять, что “я ОЧЕНЬ люблю изучать новые технологии. Вместо сна и обеда”.
Не будем пытаться объяснить откуда и по каким причинам формируются эти фракции, просто зафиксируем факт - они есть. И в продукт лучше идти от фракции глубь. Почему? Потому что есть еще один миф “Продукт — это очень технологично и свежо” (об этом – ниже).
Ответственный vs Не ответственный
Достаточно важное качество, влияющее на интегральную оценку Хороший vs плохой. И сразу скажем, речь не идет о 60-часовой рабочей неделе. Речь идет о способности нести ответственность за свои решения и, как итог, способности принимать эти решения. Уровень решений тут не важен. Может быть ответственный джуниор-аналитик, программист или технический писатель.
Рост по административной вертикали - это не рост технических знаний, это рост уровня принятия решений и готовности нести ответственность за них. Под ответственностью я имею в виду простую способность признать ошибку и предложить пути решения. Это свойство тренируется, если есть желание. В продукт лучше не идти, если ты не ответственный, так как в продукте команды редко меняются, и за год разработчики хорошо узнают деловые качества друг друга. Возможности порхать с проекта на проект практически нет.
Практика vs Абстракция
Этот миф относится к особенностям продуктовой разработки. И их важно учитывать при выборе этого пути.
Дело в том, что существует некоторая невнятность требований к продуктам (само по себе это не ново и есть везде) и необходимость обобщения решения этой задачи с заделом на:
· возможность развивать и усложнять решение в дальнейшем;
· возможность переиспользования решения или его части в дальнейшем;
· допуск большего диапазона начальных условий, чем требовалось в постановке.
Нельзя просто сделать 1 в 1, как указано в ТЗ. Как минимум, нужно представить, что с этим будут делать дальше. Возможно ли развитие этой функции. Спрашивать себя “что, если…?”.
Если же вам повезло, и требования пришли от продуктового аналитика, то зачастую у вас не будет реальных данных/окружения/ситуации/пользователей для проверки решения. И вы будете придумывать какие-то “абстракции” для реализации задачи, и предполагать действия пользователя. Владелец продукта сможет вам помочь только на высоком уровне постановки.
При работе в продукте вы должны быть готовы к ситуации “вот вам карта наступления фронта, придумайте сами что делает ваш батальон”. Если вы ждете точных постановок, доступ к телу пользователя и прочее, то вам либо не надо в продуктовую разработку, либо ищите немецкую/швейцарскую продуктовую компанию.
Монотонность vs Новизна
Еще одна особенность продуктовой разработки. Она попадалась мне реже остальных, но важно и её упомянуть. Речь идет о готовности на протяжении долгого времени ходить примерно по одной и той же X (где X - область знаний, исходный код, функциональность).
Есть специалисты, которым важен именно эффект новизны, возможность отвлекаться и сталкиваться с новыми областями. В продуктовой разработке такие возможности ограничены самой природой. Естественно, продукт может быть большим и разноплановым, но он все равно конечен. Если вам важно пробовать новое, то есть риск, что продукт вам быстро надоест.
Есть еще особенности для разных специальностей. Частично затронем эту тему в других мифах.
Общий вывод по первому мифу: Какие-то особенности специалистов действительно имеют место быть. Но это не значит, что мы можем выделить продуктового специалиста как отдельную специализацию. Правильнее будет сказать, что в компании-вендоре будет комфортнее работать специалистам со склонностью к углублению в одну тему, с привычкой к монотонности и с умением абстрагироваться.
Миф 2. Особые продуктовые программисты
Продуктовые программисты сильно удалены от конечных пользователей. В заказной разработке между программистами и конечными пользователями находятся аналитики и руководители проектов. Передача обратной связи нарушена, и информация искажается, но проходит через пару рук. В продуктовой разработке добавляется еще несколько слоев в виде компаний-партнеров, отдела внедрения и владельцев продукта.
И к разработчику информация попадает или в сильно переработанном, и несколько раз интерпретированном виде, или практически без фильтрации. То есть падаем из крайности в крайность. И со временем программист начинает мыслить слишком уж абстрактно, и склонен заниматься усложнением. Один из вариантов борьбы с этим, это периодическая ротация продуктовых программистов на задачи внедрения, чтобы снять излишние фильтры, дать больше контекста и почувствовать боль пользователей.Еще одной особенностью является задача поддержания обратной совместимости. Что иногда может раздражать, требовать дополнительных затрат, и о чем никогда нельзя забывать.
Общий вывод по второму мифу: Эти особенности, безусловно, влияют. Но не до такой степени, чтобы менять работу в корне. Я бы сказал, что 80% профиля работы продуктового и проектного программиста совпадает. Это миф.
Миф 3. Особое продуктовые QA
В продуктовой практике представлены практически все виды тестирования: функциональное, интеграционное, нагрузочное, автоматизированное, UI и API, pixel hunting и UX, pen тесты. В принципе, не очень трудно представить сложную проектную разработку, где будет все тоже самое и даже больше. Но есть несколько важных отличий:
· цикл жизни артефактов QA равен или близок к времени жизни самого продукта;
· если в продукте поддерживается несколько версий, то и все тестирование должно поддерживать эту концепцию.
С точки зрения QA, они фактически создают свой собственный внутренний продукт, состоящий из методологии, инструментария, процесса тестирования продукта вендора. И, естественно, этот продукт требует ухода.
Особенностями, заслуживающими отдельного упоминания, служат:
· Проблема ведения регрессионного сьюта, достойная производственного романа. Регрессия постоянно растет, её всегда не хватает, она занимает много времени, и актуализация тестов при продолжающейся разработке начинает занимать времени больше, чем тестирование новых фич.
· Вместо единого окружения, на котором будут запускать ваш продукт, существует матрица совместимости с системным софтом, железом и т.д. И с этим приходится работать. Без автоматизации тут вообще нечего делать. Здесь возникает новая задача: управление тестовыми средами. Тут кроме QA задействуются и Devops.
· Тестирование производительности вообще трансформируется в другие задачи. Вы не только подтверждаете заявленные характеристики производительности, отказо- или стрессоустойчивости, но и исследуете вопросы масштабирования микро- и макроинсталяций в разных условиях. Фактически, в дополнение к традиционным задачам добавляется прогнозирование и, к примеру, разработка методики оценки производительности решения (с учетом нескольких измерений, параметров и т.д.). Это может быть необходимо, к примеру, для построения прайс-листа.
Общий вывод по третьему мифу:. Я бы сказал, что 65-70% профиля работы продуктового и проектного QA совпадает. Остальное - это довольно уникальный опыт.
Больше похоже на правду, чем в случае программистов. Но всё еще миф ;-)
Миф 4. Продукт — это очень технологично и свежо
Часто продуктовая разработка представляется очень продвинутой, разработчики могут творить, выбирать и рассуждать в то время, как разработчики заказных проектов кодят, не поднимая голову. Всё не так :-)
Chief-разработчик продукта с 97.7% вероятностью пурист и, немного, ретроград:
· он просто не понесёт в продукт новую технологию, если в продукте уже есть аналог;
· не примет лишние зависимости и попросит рефакторить существующий код для устранения лишних библиотек;
· не примет ваш синтаксический сахар со словами “а ты знаешь, ЧТО НА САМОМ ДЕЛЕ сделает компилятор/виртуальная машина в этом месте?”;
· не возьмет новую технологию или инструмент, пока не выйдет минимум третья версия. И технология должна быть с LTS;
· не возьмет то, что не имеет хорошей и активной пользовательской базы, не находится в активной разработке и не обладает хорошей документацией и, крайне желательно, нормально читаемыми исходниками.
В итоге технологический стек продукта чаще всего отстает от последней моды на пару лет и не содержит последних версий зависимостей. Выбор новых технологий не ограничен, но требует обоснования выбора. Во многом, технологический стек фиксируется в начале разработки продукта и в дальнейшем просто обновляется на новые версии.
В противовес продуктам, проекты хотят максимально эффективно/дешево/быстро решить задачу, и, не имея ограничений долгого жизненного цикла, вольны выбирать и пробовать новые и свежие технологии/техники.
Но обратная сторона медали состоит в том, что в продукте разработчики вынуждены действительно глубоко погружаться в выбранный стек и знать его действительно хорошо. Смотреть код зависимости, чтобы понять, как выжать еще пару % производительности или пофиксить раздражающий баг - это нормально для продукта. Так что продукт — это не всегда свежо, но весьма глубоко.
Общий вывод по четвертому мифу:У вендора вы, за очень редким исключением, не встретите модных и технологичных решений. Это скорее миф.
Миф 5. В продуктовой разработке самое главное - качество и красота решения
Миф про то, что в заказной разработке нет времени подумать, и разработчиков принуждают жертвовать красотой в пользу скорости, а вот в продукте радеют за качество.
Цель любого бизнеса состоит в прибыли, любой бизнес старается минимизировать time-to-market. И иногда продуктовому разработчику надо написать не очень качественно, но очень быстро.
Скорее различие между продуктом и проектом состоит в том, кто будет разбирать бардак, и поддерживать конструкцию, которая вот-вот развалится. В случае заказной разработки есть надежда, что этим придется заниматься другим людям. В продукте разгребать придется тем же людям. И это действительно приводит к системе сдержек и противовесов, заставляющей периодически заниматься рефакторингами и борьбой за красоту.
Общий вывод по пятому мифу: В целом это правда, но важно, в какой ситуации вы смотрите код.
Миф 6. Главное в продукте/вендоре - R&D
Прозвучит банально, но я считаю, что в вендоре важны все составляющие.
На стадии стартапа R&D - это, наверное, самое важное. Без продукта идея мертва. И от R&D, и его скилов, зависит, успеет ли вендор заявиться на рынок и выстоять.
С ростом вендора растёт и роль других подразделений. В какой-то момент главным становятся продажи. От них зависит выход на самоокупаемость. Затем на передний план выходит маркетинг, от него зависит то, как вендора воспринимают на рынке, какой будет воронка продаж и т.д.
Важны все части, и способность адаптироваться, переключать фокус в нужный момент.
Вендор можно сравнить с машиной по продаже лицензии и техподдержке. Если представить, что R&D ее двигатель, то без коробки передач или колес, вы никуда не поедете. Так и вендор: главное в нем, что все детали на месте и работают.
Продолжая аналогию, вендора могут купить как автомобиль. И причина может быть разная, могут купить работать в такси, а могут на разборку. И что будет главным зависит от ситуации. Автор был свидетелем череды сделок, в которых стартап покупался несколько раз. Сначала стартап и его продукт были ценными сами по себе, т.е. покупался прежде всего продукт и его разработчики. Через несколько лет купили уже покупателя стартапа. И в этот раз объектом покупки выступала клиентская база. Продукт после этой покупки ушел исключительно на поддержку, разработка была прекращена.
Общий вывод по шестому мифу: В таких вопросах нельзя обобщать или выделять кого-то на главную роль. Это миф.
Спасибо за чтение. Я был рад поделиться своим опытом и наблюдениями. Если ваш опыт отличается от моего, было бы интересно почитать о нём.
Руслан Трачук,
технический директор компании "Юнидата"
