Комментарии 15
Ну если "программист + бизнесмен" это Product Manager, то я китайский летчик.
У меня ощущение, что я помру, но так и не прочитаю на этом ресурсе какое-то более-менее правильное определение этой роли. Печаль.
Не, я могу представить себе этакий конфликт. Бывает так (и чаще, чем хотелось бы), что те, кто по идее должны отвечать за продукт, планомерной работы по custdev-у, поведенческой аналитике, росту метрик не ведут. Просто генерируют задачи из того, что на глаза попадётся, или вообще транслируют хотелки начальника повыше. Тогда — да, отсутствующую работу или часть её может взять и разработчик.
Но это — просто через не то место построенная работа. Костыль, отнюдь не заменяющий профессиональных продактов (которые, к слову, как раз в «бизнес-команде» должны сидеть).
Впрочем, соглашусь с тем, что когда разработчик стремится посмотреть на то, что он делает, не просто как на код, а именно как на решение задач людей — это всегда классно и продакту очень помогает.
Разработчик, безусловно, должен делать работу, соответствующую решению задач пользователя, но в разрезе технологий. Условно говоря, чтобы работало быстрее, хранилось надежнее, откликалось эффективнее и т.д. Это синергия, а у нас вечно х*ями меряются — кто главнее. Как маркетинг и продажи. Теперь программисты и бизнес (продакты). Ну окей, поезд-то (рынок) идет не останавливаясь, а ехать в нем или драться, выйдя на полустанке — дело вольное. Я об этом.
Так я о том же. В команде здорового человека для каждой задачи есть специально обученные люди. Более того, с разными майндсетами (далеко не каждый разработчик в принципе согласится провести пару десятков глубинных интервью).
Совмещение (как в статье) — это вынужденная мера, когда кто-то мышей не ловит. И да, я такое видел вживую (компания не-айти, но без цифры никуда — а в неё почти никто не умеет), очень так себе работает.
Но. Разработчик, понимающий боль пользователя, работает в разы эффективнее. Со своей стороны. Это и есть синергия — говорю как продакт, который не стесняется погружать свою команду (и даже внешних подрядчиков) в задачи именно юзерские по-максимуму.
На моем опыте разработчики менеджеры делают гораздо более успешные продукты чем менеджеры проекта. А термин Product Engineer поможет таким людям самоопределиться и заняться своё место в продукте.
Продакт инженер это как эникейщик в ит. Занимается всем и сразу и много. Растет по чуть чуть, но везде. Это все проходит, когда продукт или Ит подразделение вырастает. Ты занимаешься чем-то одним (двумя, тремя, но не двадцатью) вещами, или по крайней мере отвечаешь за узкий скоуп (в качестве развлечения конечно можешь покодить в свободное время).
Если пойти в Ит сервисы, то эникейщик на собеседовании в крупную ит аутсорс контору квалифицируется как младший инженер в какой то узкой команде, который растет и развивается в узком направлении.
Частые смены контекста вредят здоровью.… таким как уменьшение плотности нейронов (1, 2).Вот за это отдельное спасибо. Не знал.
Частые смены контекста вредят здоровью.… таким как уменьшение плотности нейронов (1, 2).Можно этому как-то противостоять? Может выделять время на погружение?
Могу поделиться тем, что сработало для меня. Некоторые пункты могут показаться банальными, но тем не менее для меня это сработало.
1. Чётко приоритизировать задачи. Не обманывать себя, и отделять «интересное и то что хочется сейчас сделать» от «срочного и по-настоящему важного». Не срочное и не важное фиксировать в виде списка и откладывать на позже. Периодически делать ревью этого списка.
2. Создавать примерный план задач на день. Если сразу становится понятно, что за день не получится их все закончить – сразу же переносить часть задач на другие дни.
3. Если задача срочная и/или важная и занимает меньше 5 минут – сделать прямо сейчас.
4. Как вы правильно отметили, если задача большая и/или сложная и/или требует высокой концентрации – лучше не брататься её делать сразу же, а выделить время когда вы сможете заниматься только ей.
5. Уметь смело выбросить задачу и не делать её, если задача очень минорная и не принесёт никакой пользы.
6. Периодически проводить «ценностное ревью». Поясню что я имею ввиду. Это ревью ваших личных целей и желаний. Зачем вы делаете то, что делаете, чего добиваетесь, как вы измеряете что достигли целей, не поменялись ли ваши ценности и не сбились ли вы с пути. Про честных ответах на эти вопросы, стресс связанный с большим количеством хаоса вокруг переносится легче и воспринимается как challenge.
7. Стараться чётко разграничивать личное и рабочее. Например – до 10 утра и после 19 вечера это только личное время.
Написал то, что вспомнилось сразу же. Если тема интересна, то могу дополнить если что-то ещё вспомнится :)
Ну и из личного опыта — еще полезно научиться говорить «нет».
В этом плане очень помогает визуализация текущих задач, да хоть личным канбаном каким. И вопрос который всегда можно задать когда давят: «Хорошо, я конечно же сделаю это, но давайте вместе решим что именно мне стоит бросить». :-) В 9 из 10 случаев помогает, а 1 оставшемся — это повод приглядеться внимательнее — раз такие упорные, то видимо есть причина.
Не могу не согласиться сильнее )
Умение сказать «нет» коллеге, задаче, боссу, своей собственной мысли или идее, да чему угодно, сразу же отбросит минимум половину из потока новых задач (а скорее всего даже больше)
Сказанное «нет» чему-то или кому-то неважному, освободит место в голове для важного «да».
Только пока не сказал бы, что уровень интеллекта падает. Бывает трудно включиться в такой режим, но в нём соображаешь всё так же быстро
Software Engineer + Product Manager = Product Engineer?