Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Инженер с продуктовым мышлением: кто он и зачем компании

Привет! Меня зовут Александр. Я продакт-менеджер с инженерным бэкграундом. Вот уже 11 лет я работаю в компании Railsware, где вместе с командой развиваю культуру продуктового подхода к веб-разработке. Будучи инженером больше 10 лет, я постепенно начал брать на себя дополнительные активности на проектах, в которых частично участвовал. Это помогло мне на практике почувствовать себя в смежных ролях, не отходя от написания кода.

Сегодня я с удовольствием делюсь с вами опытом расширения профессиональных возможностей и повышения своей ценности как инженера для проекта и компании в целом.

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

Среда, которая влияет на карьерный выбор

ИТ-индустрия молода и все еще продолжает формироваться. Она пока далека от того же сельского хозяйства, где процессы, роли и модели планирования уже давно устоялись. При том, что по всему миру технологии внедрялись относительно в одно и то же время, некоторые различия в регионах все же есть. Это значит, что бизнес-культура и типичный карьерный рост специалистов явно отличаются. Например, спрос на навыки в Восточной Европе далек от того, что в Северной Америке. Отличаются не только названия должностей, но и их наполнение.

Состояние отрасли неизбежно влияет на наш карьерный путь. Например, в Восточной Европе и Юго-Восточной Азии преобладает бизнес-модель аутсорсинга, что требует от специалиста наличия определенного набора навыков и мышления. Главная особенность этой модели в том, что команда разработчиков не участвует в процессе создания продукта от А до Я, видя лишь ту часть, которую ей передали в аутсорс. Здесь есть свои преимущества, но главный недостаток состоит в том, что без понимания целостной картины проекта, у специалистов часто формируется неправильная причинно-следственная модель. Например, когда проект закрывается с неясным комментарием от бизнеса «закончился бюджет», команда R&D может интерпретировать это как «слишком много потрачено на маркетинг и недостаточно инвестировано в улучшение кодовой базы». Это происходит потому, что команда видит лишь код, и не располагает в полной мере информацией, чтобы сделать другой вывод. В действительности же все может выглядеть иначе: «слишком много ресурсов потрачено на полнофункциональный продукт, недостаточно быстро внедряли инновации и проиграли конкуренту».

Во всем мире уже давно наблюдается культурный сдвиг от классической каскадной модели разработки и корпоративных процессов к более простой — где реализация проекта быстрее, а команды меньше и не изолированы друг от друга. Это означает, что в организациях стираются явные границы ответственности. 15 лет назад в украинских компаниях было обычным делом, когда менеджеры согласовывали требования и вели все коммуникации, инженеры писали код, а тестировщики занимались тестами. Если у клиента возникали вопросы к качеству продукта, а QA интересовали конечные пользователи, каждому приходилось миновать несколько уровней коммуникаций. Это было утомительно, демотивировало задавать вопросы и интересоваться смежными направлениями. Сегодня QA может напрямую общаться с клиентом, а клиент может присутствовать на стендапах команды разработки.

Очевидно, что акценты смещаются в сторону широкопрофильных специалистов, которых мы также называем T-shaped специалистами. Это люди, талантливые в своем ремесле, которые также имеют определенные знания в других областях и способны видеть более широкую картину проекта. Инженеры не исключение. В Railsware мы всегда уделяли много внимания идее продукта, проблемам, которые продукт должен решать, а также процессам разработки и чистоте кода. Инженеры подключаются к проекту со дня обсуждения идеи и участвуют во многих смежных активностях. Это помогает глубже понять предметную область, для которой разрабатывается продукт.

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

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

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

Коммуникации: do you read me?

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

Разработку продукта можно сравнить со строительством дома или ремонтом квартиры. Ведь это тоже сложные проекты, в которых неизбежно пересекаются специалисты разных профилей. Без хотя бы примерного понимания полной картины работ, а также желания найти со всеми общий язык, проект может, в лучшем случае, затянуться, в худшем — развалиться на этапе фундамента.

Представим, что команда должна разработать новую фичу — мастер оценки в государственной больнице. Анкета должна помочь оценить качество работы больницы и сформировать в конце общий балл. Проверяющий бы пришел в больницу и, воспользовавшись данной функцией, отметил, что хорошо, что плохо, и сформировал отчет. Для разработки такой фичи инженер формулирует ряд задач: на создание моделей и таблиц в базе данных, визуализации и API. Начинается разработка.

Через некоторое время QA спросит, что он может протестировать. И тут начинается самое интересное :) Рассмотрим два варианта развития событий:

Негативный. «Вы можете запустить AddHospitalController и StartAssessmentController с начальными данными и проверить, что таблицы Hospital, Cleanliness и Maintenance заполнены в базе данных. А затем можете проверить, отображает ли ScoringView все оценки». Для QA это будет звучать как птичий язык, и он явно захочет подождать финального пользовательского интерфейса. Очевидно, что тестирование отложится, и логические ошибки будут обнаружены на более поздних этапах.

Позитивный. «Мы реализовали логику для оценочных листов в больнице, но пользовательского интерфейса пока нет. У нас есть лишь упрощенный интерфейс, чтобы увидеть список оценок». С таким ответом QA, вероятно, попросит создать простой пользовательский интерфейс для тестирования добавления больниц и оценочных листов, или же спросит, как это сделать с консоли. В таком случае логические ошибки (например, в иерархии критериев оценки) будут обнаружены уже сейчас.

Иногда достаточно просто иметь возможность экспортировать данные из приложения, если пользовательский интерфейс сложный и еще не готов, или же показать его в сгенерированной панели администратора для дальнейшей проверки.

Стивен Кови в своей книге «The 7 Habits of Highly Effective People» выделил три уровня взаимодействия людей в группе: зависимость, независимость и взаимозависимость.

  • Зависимость. Худший случай, когда все зависят друг от друга. Здесь зависимость — это «ты заботишься обо мне». В таком случае возникают блокеры, которые не позволяют двигаться вперед. Снижается скорость и могут возникать конфликты.
  • Независимость. Когда специалист может все или многое делать самостоятельно и действует независимо. Для этого не нужно быть экспертом во всех областях, но вы всегда можете разблокировать себя. Т-shaped специалисты обычно независимы во многих аспектах. Они понимают общий контекст в рамках своего основного навыка, могут играть разные роли и говорить на понятном для всех языке.
  • Взаимозависимость. Кажется, что предыдущий уровень — самый оптимальный, но это не так. Дело в том, что независимость все же имеет свои границы. Да и один в поле не воин... Гораздо позитивнее все развивается на следующем уровне — взаимозависимости. Здесь все участники команды повышают навыки друг друга, помогают и понимают друг друга. Они с легкостью взаимозаменяются при необходимости. Важно то, что каждый вносит свой вклад в общий успех продукта и принимает лучшие решения во время такой командной работы.

Работая на проекте, важно помнить, что все движутся к одной цели, и стараться сохранять единство. Формулировать свои потребности так, чтобы информация была понятна не только техническим специалистам. Быть ответственным и переживать не только за свой кусок работы, но и думать о коллегах, которые будут продолжать работать над продуктом, используя ваши наработки.

Работа с требованиями

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

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

Иногда кажется, что если бы продакт-менеджеры готовили четкие требования, то код приложения можно было бы писать прямо по ним. Насколько подробными должны быть требования к коду? Я думаю, это одна из самых горячих тем.

Преобразовать бизнес-требования в функциональную систему сложно, и многие вещи могут пойти не так. Кроме того, ни одно из требований не бывает исчерпывающим. Никогда. Потому что невозможно продумать все заранее. Именно поэтому коммуникация между инженерными командами и бизнесом является здесь ключевой. Основное правило для бизнеса — это объяснять, что нужно сделать, а не как. Вы ведь не хотите, чтобы менеджер или генеральный директор указывал вам, как надо выполнять вашу работу. Тем не менее часто дискуссии поднимаются как раз относительно того, «как».

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

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

Помимо примеров для всех возможных случаев, он добавил утверждение «if-else» и приоритеты для каждой категории. Например, если несколько категорий совпадают в одной строке или не совпадают никакие категории. Конечно, это был далеко не идеальный план реализации, и возникало все больше вопросов, которые продакт-менеджер продолжал описывать в требованиях.

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

В конце концов пришлось все переделать с нуля. Организовали сессию, на которой команда вручную классифицировала множество примеров, объясняя, почему та или иная строка перемещается в определенную категорию. На этот раз все сработало. Такое описание помогло инженеру построить в голове собственную модель, которая не имела ничего общего с документом «if-else», который составил продакт-менеджер.

А вот еще один случай: как-то инженер решил уточнить у продакт-менеджера детали реализации, потому что при внедрении предыдущей фичи ему пришлось переписать некоторые части кода. Изначально требования были неоднозначными, но он продолжил работу, положась на свои догадки. Позже выяснилось, что некоторые предположения оказались неверными.

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

Классический пример Railsware с Calendly: владелец Calendly пришел к нам со своей идеей продукта, и захотел внедрить все возможные интеграции с разными календарями одновременно. Мы задокументировали все требования должным образом и помогли сосредоточиться лишь на одной интеграции с календарем Google, поскольку он был самым популярным. К нашему совету прислушались. Сегодня Calendly — это многомиллиардный продукт, и они все еще работают над этими интеграциями.

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

Ориентация на долгосрочную перспективу

В большинстве случаев инженер может не видеть долгосрочную перспективу свой работы для продукта. Он занят своей частью проекта, без малейшего понятия и желания знать, что будет происходить с его кодом дальше. Такой подход приводит в лучшем случае к ситуация, когда вроде бы и работы сделано много, и усилия приложены большие, и эстимейтов придерживались, но результат ни к чему не привел. Что еще больше, бизнес остался недоволен. Но в худшем случае все сводится к тому, что большую часть проделанной работы нужно переписывать или рефакторить после каждой итерации, потому что изначально не было понимания целостной картины и конечного результата. Дедлайны двигаются бесконечно, все вокруг нервничают, создается давление и всеобщие упреки.

Одной из таких ситуаций я хотел бы поделиться. Она возникла на проекте, который занимается импортом данных с различных приложение (Hubspot, Xero, Shopify, etc). Работа с данными имеет свою специфику, так как некоторые сервисы не могут возвращать данные достаточно быстро, а иногда таких данных может быть очень много.

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

В тоже время, работая над интерфейсом визарда в Coupler.io мы изначально вовлекли всю команду на самых начальных этапах. Инженеры участвовали над ревью ресерчей и прототипа интерфейса, который подготавливал продакт-дизайнер. Они видели результаты тестирования прототипа, которое проводил продакт менеджер вместе с пользователями. Помогали планировать этапы разработки, чтобы выпустить первую версию в продакшин как можно быстрее. И уже после этого все двигались шаг за шагом к конечному варианту, который был запланирован.

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

Демо, которое всем интересно и понятно

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

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

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

И в первом, и во втором случае, основная мысль, которую мы прочитаем между строк: «я сделал что-то настолько скучное, что даже не хочу делиться этим» или «я что-то сделал, но не уверен в конечной цели и не могу оценить результат». Команда может сделать свой вывод: «этот парень не приносит ценности продукту»

Некоторые думают, что работу над back-end и DevOps нельзя задемить. Однако, даже такую работу всегда можно представить в виде простой визуализации архитектуры в виде блок-схемы, рассказать на этом примере почему была использована именно такая модель, на какие компромиссы пришлось пойти, и как это приближает нас к первой версии фичи. Такая презентация даст прекрасный контекст для всех участников команды.

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

С командой Coupler.io мы проводим демо-сессии раз в две недели. В них участвует вся команда: разработчики, маркетологи, дизайнеры, контентщики, аналитики, а также ребята из поддержки. Такие сессии помогают команде поддержки понять, как изменения в продукте влияют на их взаимодействие с клиентом, какие ошибки уже исправлены. Получить информацию о том, что функциональность, которую они просили, или ошибка, о которой сообщил несколько дней назад клиент, уже в разработке или исправлена.

Маркетинговая команда видит, как далеко мы находимся от конечной цели и когда они могут приступать к подготовке коммуникаций.

В случае с моим проектом Coupler.io хорошо еще и то, что все члены команды сами являются пользователями продукта и могут поделиться обратной связью на ранних этапах. Ребята не стесняются быть проактивными и задавать вопросы, если не понимают чего-то. Инженеры, которые работают над определёнными фичами, демонстрируют их. Это помогает нам практиковать «human language».

Как развить продуктовое мышление

Начните больше интересоваться тем, что не входит в написание кода. Это поможет понять цели и процессы в смежных командах на продукте. Интересуйтесь у менеджера, клиента или продакт-оунера, какую пользу продукт приносит конечным пользователям. Прислушивайтесь к коллегами в команде, старайтесь понять их. Все это в конечном итоге поможет вам доносить собственные идеи, формулировать проблемы и вопросы, на понятном окружающим языке.

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

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

Преимущества и недостатки продуктового мышления у инженеров

У любого подхода есть свои преимущества и недостатки. Наш случай не исключение. Давайте рассмотрим плюсы и минусы продуктового мышления с двух сторон: со стороны компании, в которой работают продакт инженеры, и со стороны самого инженера.

Начнем с преимуществ для компании:

  • Работая в команде с продакт инженерами, есть возможность если не искоренить, то свести к минимуму микроменеджмент. Команда будет более независимой, сможет принимать решения самостоятельно и делать это правильно.
  • Такие команды выгоднее с точки зрения бюджета. Особенно это хорошо видно на начальных этапах развития продукта. Это достигается за счет сокращения времени на взаимодействие между большим количеством людей.
  • Снижение bus factor-а, когда критичные знания и умения сосредоточены в руках или голове одного или нескольких человек. Зная и понимая смежные роли и процессы, люди могут заменить друг друга с минимальными потерями для бизнеса.

Преимущества для специалиста:

  • Возможность попробовать новые подходы, активности и функции в безопасной среде без смены своей роли.
  • Тренировка адаптации к переменам во внешней среде. Открываются возможности для потенциально интересного места работы.
  • Большее влияние на продукт, на его направление развития и возможность строить что-то полезное.

Если говорить о недостатках, то для компании он, наверно, единственный: тяжело нанимать людей, которые были бы хорошими специалистами и в то же время имели широкий кругозор (Т-shaped специалисты).

Для специалиста это скорее не недостатки, а необходимость дополнительных усилий:

  • Выход из зоны комфорта, который не всегда приятен.
  • Работа с большим количеством разных контекстов и хорошие навыки самостоятельной организации своего рабочего времени.

Вкладывать смысл во все, что мы делаем

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

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Із інженерами із продуктовим майнсетом приємно працювати.

говорю це як продукт менеджер"

От якраз для продукт менеджера, яки робить свою роботу, інженери з продуктовим мисленням часто можуть бути проблемою, бо починають лізти не в свою зону відповідальності (особливо недосвідчені).

Із задоволенням би почитав статтю, якби була написана українською або англійською мовою. А так, нажаль, «нехай щастить»...

Не варто :) Краще ппросіть маму купити вам Піковіт. Може стати в пригоді, якщо є проблеми із вивченням мов.

Есть проблемы с национально-озабоченными

Із задоволенням би почитав статтю, якби була написана українською або англійською мовою. А так, нажаль, «нехай щастить»...

От мені справді цікава логіка: Нафіка ви це написали?
Це треба було:
— відкрити статтю
— зрозуміти, що вона мовю, яка вам не цікава (хоча для цього можна було пропустити попередній пункт)
— проскрорили до коментарів і там щось написати

Я б закрив статтю на пункті 2.

Я написав, бо мав бажання написати. Для чого є ще писати?
Для чого ви читали мій комент і відписували на нього — дивна логіка :)

PS: тема, реально цікава і я майже не втримався... Але, пересилив себе і погуглив англійською.

Я написав, бо мав бажання написати. Для чого є ще писати?
Для чого ви читали мій комент і відписували на нього — дивна логіка :)

Зазвичай, адекватні люди публічно висловлюються, щоб
— спонукати людей до чогось
— звернути увагу на щось, чому приділяється недостатньо уваги
— отримати інформацію, яка їх цікавить (це власне те чому я писав свій коментар)

Це можна розглядати як заохочення писати більш доступною мовою в Україні (державною) або у світі (англійською).
І не орієнтуватись на іноземну мову, яку все ще розуміють на росии та у кількох її сателітах типу Білорусі чи Киргизстану. І особливо більше ніде. На рахунок Киргизстану навіть не впевнений.

Це можна розглядати як заохочення писати більш доступною мовою в Україні (державною) або у світі (англійською).

Ні, тому що автор (Ivan Solomichev) сам не сказав, що заохочення було метою. Власне, поведінка автора демонструє різницю між «спонукати» і «доіпаться».

І не орієнтуватись на іноземну мову, яку все ще розуміють на росии та у кількох її сателітах типу Білорусі чи Киргизстану

Конструктивне спонукання виглядало б десь так:
Цікаво було б почитати таку статтю українською (Добре було б мати такий контент українською) та і англомовна версія допомогла б вам суттєво розширити аудиторію статті.

Ви б могли не відстоювати завідомо погану позицію.
Було б добре, якби ви просували якусь добру позицію.
Наприклад, заохочувати написання контенту державною мовою.
Було б добре прочитати таке заохочення також і англійською мовою.

Ви б могли не відстоювати завідомо погану позицію.

Яка це позиція? Чому вона «погана»?

Було б добре якби ви самі над цим подумали.
Цікаво було б якби ви це зробили також і англійською мовою. :-)
Але — дякую за пораду.

ну от він спонукає писати не на опщєпонятном

Приблизно таке ж враження склала ця стаття. Згідний.

Интересная статья. И много правильного написано.
Но я бы хотел бы уточнить один момент:

По сути инженеру предлагается дополнительно стать:
— частично менеджером
— частично доменным экспертом проекта с элементами аналитика

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

Но в это время инженеру необходимо много времени уделять регулярному улучшению своей экспертизы как именно что инженера. 101 вопрос каждый день к освоению, разбору.
Особенно если ты в тех. плане T-shape
А еще английский и так далее. Это все не считая основной работы.

Все сразу потянуть — я лично слабо верю в такие примеры. Где-то чем-то придется жертвовать.
И вот вопрос:
Инженер как инженер будет отлично востребован на рынке — с руками оторвут. Везде.

А вот та роль, о которой пишите Вы — будет ли она нужна на рынке ? Не загонит ли человек себя в такую роль, что при выходе на рынок завтра (выгонят, сократят, надо семье больше денег) его цена будет определена его изрядно дегр. инженерными навыками ?

А вот та роль, о которой пишите Вы — будет ли она нужна на рынке ?
Не загонит ли человек себя в такую роль, что при выходе на рынок завтра (выгонят, сократят, надо семье больше денег) его цена будет определена его изрядно дегр. инженерными навыками ?

Підозрюю, що ви знаєте відповіді на ці питання, але давайте проговоримо їх:
Ні, не потрібна. Людина буде цінуватись на ринку дешевше ніж «аутсорс інженери», бо хардскіли скоріше за все будуть не вище ніж «чистих інженерів» і наймаючі менеджери будуть думати, що чувака можна трохи прогнути.
Єдина альтернатива — це свій стартап або кофандером. Тоді бабла буде більше, але це трохи інший ринок.

Спасибо!

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

Смысл в том, что любые границы между всеми привычными нам ролями на проекте оказываются на практике размытыми. А если роли разрезаны по жестким границам, то между ними возникают пробелы, которые могут приводить к проблемам. Такие проблемы можно восполнить интересуясь и вовлекаясь в контексты других, смежных ролей. Как я писал не нужно пытаться стать экспертом во всех них (особенно на начальных этапах). В этом случае большее внимание и фокуса все таки остается на инжениринге.

Что касается времени: если смотреть в долгую, то такой подход очень часто может помочь принять более правильные решения на более ранних этапах, сэкономить время, а не итерировать кодом, переделывать и рефакторить по несколько раз. Знание доменной области, бизнес контекста и планов поможет лучше «написать код», который и будет покрывать проблему той самой доменной области.

В тоже время я соглашусь, что очень глубокая техническая экспертиза требует 100% вовлеченности. И тут каждый сам принимает решение в какую сторону расти: глубину или широту.

Теперь попробую поразмышлять на тему основного вопроса о востребованности. Да фиг его знает что будет завтра :)

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

Если инженер будет T-shape, то он заключит такой контракт, что при сокращении получит золотой парашют.

Ось цей «продукт майндсет» може бути корисним тільки для девів технічно нижче середнього.

Ніт. Ті ж фаанги, коли треба запускати новий проект будуть обирати людину з «продуктовим мандсетом».
«Продуктовий майндсет» — це перевага серед спеціалістів свого рівня (по хардскілам), але не перевага серед усіх спеціалістів. Ну і на нашому ринку такий скіл просто не дуже затребуваний у нормальних контор (з того що чув рейлсвер наче одна з них)

Стивен Кови

дальше можно не читать. В церкву идите с вашими проповедями высокоэффективных макак

Это да, але я тут більше бачу шлях з гребца в продакт овнера(як і ТС), який і за енд гоал з баблодержателями поговорить може і макакам на понятном таску написать вміє і, якщо треба, піднакодіть фічу-другу самостійно. Краснокніжна птіца, насправді.

Коментар порушує правила спільноти і видалений модераторами.

Красивые иллюстрации! Кто автор?
Статью ещё не читал, простите.

Иллюстрации для этого материала заботливо нарисовали наши дизайнеры. Комплимент уже передали 🤗 Спасибо!

только не Realisation, а Implementation (на одной из иллюстраций)

только не Realisation, а Implementation

Why not? ’Realisation’ is a perfectly cromulent word.

ну чисто теоретически можно и молотком шурупы устанавливать, но зачем?

www.oxfordlearnersdictionaries.com/...​that changes must be made.

vs

www.oxfordlearnersdictionaries.com/...​on/english/implementation

ну чисто теоретически можно и молотком шурупы устанавливать, но зачем?

Никакой теории. ‘Realisation’, особенно в контексте ‘idea’ и ‘concept’, не только уместно и грамотно, но и очень даже благозвучно. Пусть и немного старомодно.

‘Implementation’ просто более популярно в современном английском лексиконе, особенно айтишном. Но не более того.
Придирка неуместна.

books.google.com/...​t1;,implement an idea;,c0

books.google.com/...​l=t1;,realize an idea;,c0

только еще раз глянь на иллюстрацию, при чем здесь ’Realisation’ в контексте идеи? Изображение про Idea>POC>MVP

только еще раз глянь на иллюстрацию, при чем здесь ’Realisation’ в контексте идеи?

Идея, концепция, осуществление. В чем проблема-то?

І не раджу читати. Там багато тексту на іноземній мові.
І це не англійська, на жаль.

Там багато тексту на іноземній мові.

Іноземною мовою.

Придивився ще раз — там таки «на іноземній мові». :-)

Имхо не понятно зачем инженеру продуктовое мышление, если платят все равно за код т только за код

За код платят копейки. Много платят за доменную экспертизу + инсайты принесённые с собой от конкурентов + желание этим делиться + код. Это и есть квинтэссенцией «продуктового мышления». Но в Украине это имеет мало ценности для программиста, так как мало спроса и негде это монетизировать.

Если и есть успешные кейсы, то и они выводят человека из инженерии в менеджмент: dou.ua/forums/topic/35212

Совершенно верно. Основной смысл развития «продуктового мышления» это расширение горизонта своих знаний, которые в том числе могут помочь, при желании, сменить свою роль.

И в Украинских реалиях это знания нормально не продать. Я понимаю зачем это вам, я не понимаю зачем это инженеру.

Уточнение — тебе не платят. Твои проблемы это только твои проблемы.

так значит все таки платят за код?

Тоже нет, к сожалению. Бизнес модель аутсорсинга, которая доминирует в Украине, не построена на извлечение реальной ценности ни из продуктового, ни из инженерного таланта программистов. Они не могут продать заказчикам наработки таких людей, потому что те не ищут здесь ни инженерных, ни продуктовых экспертов. Заказчик ищет «двигателей тасок в джире» приемлемого качества, в большом количестве и по низкой цене. Чтобы легко масштабироваться. Исключения есть, разумеется, но на то они и исключения.

В этом плане даже фриланс, за который выступает Кожаев, намного адекватнее. Потому что там проще найти покупателя именно для твоего уникального инженерного/продуктового опыта; чем на галерах, где нужен безликий Middle Python Developer.

Так что нет, за код в Украине тоже почти не платят. Платят за занятую строчку в биллинге и отсутсвие жалоб от клиента.

фриланс, за который выступает Кожаев,

Заметочка: я не выступаю за фриланс. Мне так удобнее, кому-то по другому — все люди разные

так значит все таки платят за код?

Приведу конкретный пример, когда платят именно «за код».

Мы когда-то наняли в штат мейнтейнера популярного open-source проекта, который мы использовали в компании, чтобы принести уникальную инженерную экспертизу in-house.

В Украине подобную практику представить практически нереально. За исключением, возможно, пары продуктовых компаний.

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

Підписатись на коментарі