Что это за технический бэкграунд, без которого не стать менеджером?!
Неужели до конца жизни разносить бумажки?
Добрый день, Яна!
Спасибо за то, что вы делаете. Уже несколько лет читаю ваш блог, и во многом он очень помогает и поддерживает, поэтому решила обратиться со своей проблемой. Мне 28 лет, живу в одном из городов-миллионников России. До того, как в него переехать, я несколько лет работала редактором специфической литературы удалённо (нагрузка была высокая, но это окупалось более-менее свободным графиком и хорошей зарплатой). Потом все надоело, бросила работу, переехала. Решила стать писателем.
Тогда у меня было много иллюзий по поводу творчества. Я думала, что за полгода напишу книгу, и она будет продаваться, как «Сумерки»))) когда деньги начали заканчиваться, а книга так и не была написана, я вышла на работу в небольшой стартап. Это компания, выполняющая определённые работы для большого газового холдинга. Я устроилась администратором проектов — следила за тем, чтобы все в проекте шло, как нужно: сроки соблюдались, поручения выполнялись, на совещания приходили все необходимые люди.
Плюс протоколы, отчёты и другое размазывание «г…на по бумаге». Мне нравится участвовать в жизни проекта, устранять слабые места, договариваться и помогать разным участникам лучше понимать друг друга, переводить с английского на переговорах. Но бесит бумажная работа, эти протоколы + ко мне заказчик (да и у меня в компании) относятся, как к секретарше: подай, принеси, забронируй переговорку. И я не чувствую ответственности за проект.да и честно говоря, не особенно понимаю в этих «газовых делах». Поговорила с директором, чтобы мне дали более интересные проекты — их пока нет, только этот заказчик, на которого нужно молиться. Дела в компании идут не очень хорошо: у меня маленькая зарплата (намного меньше той, что была в издательстве), хороших проектов нет. Я ищу новую работу там, где будет интересно. Мне нужен драйв, ощущение ответственности за результат (а не просто «иди подпиши ту бумажку»), возможность самой планировать своё время, достойная зарплата. На рынке много вакансий для менеджера проекта, но.
.. везде нужен технический бэкграунд. А у меня самое что ни на есть гуманитарное образование, поэтому на hh.ru идёт отказ за отказом. Из-за этого я чувствую полную беспомощность. Про написание книги я не забыла — пишу ее час-два несколько раз в неделю в комфортном темпе, много читаю и учусь на писательских семинарах. Но сейчас не могу позволить себе только писать книгу — я сама себя обеспечиваю, в том числе, снимаю квартиру. Литературным редактором я не хочу работать (хотя иногда беру и такие подработки) — мне нравится общение с людьми. Ответственный редактор в городе, где я живу, зарабатывает меньше уборщицы. До «полноценного» переводчика на переговорах я не дотягиваю — знаний маловато, да и сейчас все инженеры говорят на английском. У меня есть несколько своих тренингов по презентациям и переговорам, но они, как и книга, в зачаточном виде. Да и как их продавать? Я хочу работать менеджером или координатом проектов (мне нравится видеть, как идея становится полноценным продуктом + я люблю и умею общаться с людьми), но как приобрести этот прокляты технический бэкграунд? Хотя бы техническую грамотность, которая требуется везде.
И может ли это сделать такой закостенелый гуманитарий, как я? С чего начать? Курсы, книги, видео (конкретные названия)?Или нужно 6 лет отучиться в Политехе? Яна, может, среди ваших подписчиков есть люди, которые работают в этой сфере и помогут разобраться? Спасибо!
Пожалуйста, анонимно
***
Здравствуйте!
Ну вот — редактором не хочу, менеджером не могу. А что это за таинственный «технический бэкграунд», который требуется менеджеру? Я никогда менеджером не работала, но что-то не помню, какие у них там специальные скиллы. Они в целом хорошо владеют интернетом, работой с соцсетями, с интранетом еще хорошо работают. А что еще?
В общем — я не поняла, что там. Какие-то конкретные программы освоить надо? Есть ведь наверняка стандартные программы, которыми они работают. Мне кажется, что любую современную программу можно научиться обслуживать, если просто за нее сесть с ее же туториалом в руках, и начать пытаться выполнять некие задачи. А если вам такой способ не подходит — по абсолютно любой софтине уже есть курсы.
А для многих и на ютюбе бесплатных туториалов полно.
Программировать надо уметь? Я не могу себе представить, что менеджеру нужно программировать. Я могу себе представить, что такую вещь как программирование не может научиться делать каждый. Но обслуживание любого софта — может. И еще — если существует профессия, то есть и пути входа в нее.
В современном мире практически всегда есть путь длинный, через какой-то вуз, и короткий — через повышение квалификации и курсы. Я, как уже сказано, не поняла, чего именно вам для этой работы не хватает. Но наверняка же есть какие-то экспресс-курсы, которые можно пройти, и научиться всему тому, чего вам еще не хватает?
В общем — дорогие читатели — объясните мне, что тут требуется? А автору письма подскажите, где и как это поскорее пройти, чтобы найти работу, какую она хочет.
В остальном — можно и продолжать работать на нелюбимой работе, просто сказать себе что это — временный вариант. И побыстрее усиленно книгу дописывать. Пишите ее каждый день, сделайте план, допиливайте быстрее, чтобы она пошла.
Вообще проще ходить на любую работу, если вы знаете, что это — временный вариант, и это служит какой-то более высокой цели. Издадите книгу — сядете писать следующую. Пойдет первая, купят вторую. И если так дальше пойдет, через сколько-нибудь книг проценты от них станут похожи на зарплату, и тогда вы дальше сможете писать книги «за зарплату». Если вы видите в себе силы вот это продолжать бесперебойно хотя бы книг на 10 вперед — беритесь за это и воплощайте свою мечту. Если запала на столько книг нет, тогда конечно лучше искать хорошую работу, которая кормит, а книги писать как что-то побочное, в свое удовольствие и для «карманных денег». 🙂
В общем, давайте почитаем советы читателей. И я вам желаю успехов — с работой и с книгой.
Когда книга выйдет — пришлите ссылку?
***P.S. Дорогие читатели. Я уже давно копирую свои посты в фейсбук, и в последнее время там тоже появились читатели, которые оставляют под постами очень поезные комментарии и советы. Если вам интересно увидеть ВСЕ, что кто-то посоветовал в связи с данным постом, заглядывайте и сюда: https://www.
facebook.com/mammamiu
ПРАВИЛА:
— Если вы хотите, чтобы ваше письмо опубликовали и обсудили здесь в рубрике «Вопрос-ответ», напишите мне на [email protected] письмо с заголовком «Вопрос-ответ».
— Если вы НЕ хотите, чтобы ваше письмо было опубликовано, НЕ пишите в заголовке «Вопрос-ответ»!
— Письма с заголовком «Вопрос-ответ» содержащие в теле письма фразу «это не для публикации» выбрасываются в помойку независимо от содержания!
— Если вы написали письмо в эту рубрику, оно будет опубликовано! Если вы не уверены в ваших намерениях — не пишите мне! Походите, подумайте, прежде чем писать!
— Я очень серьезно отношусь к своим читателям и их письмам. Пожалуйста, относитесь так же уважительно к моему труду и времени!
Каждый час, который я тут сижу и пишу, ходит неглаженной кисонька!
Кстати! По мотивам публикаций в этой рубрике возникли гадальные карты!
Вы уже можете погадать себе на них, и скачать бесплатно всю книжку к ним!
Подробности и все ссылки — тут:
http://miumau.
livejournal.com/2438946.html
Смотрите также:
Магазин Белолапик
Все новости в Телеграме
Недетские картинки в Телеграме
Уютный чат в Телеграме
Мой Youtube
Проспонсируйте вкусняшку брошенным кисонькам: http://paypal.me/mammamiu
Метки: вопрос-ответ, вопрос-ответ-2019, вопрос-ответ-профессия, вопрос-ответ-творчество, вопрос-ответ-учеба
Какая техническая экспертиза нужна проджект-менеджеру сегодня
Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.
За 5 лет в разработке я сталкивался как с чистыми гуманитариями в IT, так и с теми, кто перешел в PM’ы с технической позиции.
И мне, как разработчику, оказалось легче договариваться с менеджерами, у которых есть хотя бы базовые технические знания. Тем более сегодня, когда все коммуникации серьезно просели в условиях удаленки. Если PM знает, как происходит процесс разработки, это экономит кучу времени и сил всей команде.
В статье расскажу, что значит базовая техническая экспертиза в моем понимании.
На практических примерах посмотрим, как знание процессов разработки помогает менеджеру эффективнее управлять проектом.
Еще минутка мотивации: почему технические знания важны для PM’а
Давайте сразу разведем технический бэкграунд и экспертизу. Технический бэкграунд — это когда человек пришел в PM’ы с технической должности. Например, был тестировщиком или писал код. Такой опыт может помогать, а может и мешать в работе, если менеджер путает роли и занимается не своим делом. Для PM’а ценится умение понимать, что делают разработчики, но не делать работу вместо них.
Что точно важно для PM’а, так это техническая экспертиза — понимание, как работают технологии, которыми пользуется команда.
Менеджер без технических знаний:
- Не может понять эстимейт: отводит на задачу неоправданно много времени или, наоборот, эстимейтит слишком оптимистично — и команда срывает дедлайн.
- Слабо различает зоны ответственности в команде, кто в чем виноват, кому адресовать задачу.
Например, с кем говорить, если поплыл логотип на сайте? С дизайнером или веб-мастером? - Не может объяснить клиенту сложность или выгоду определенных решений. Часто 80% работы бэкенда абсолютно не очевидны для пользователей (например, оптимизация компонентов системы), но без этой технической части продукт не будет работать нормально.
Например, с кем говорить, если поплыл логотип на сайте? С дизайнером или веб-мастером?Приведу пример, как технические знания помогают PM’у эстимейтить задачи и принимать решения. Допустим, команда выпустила в продакшн приложение с функцией загрузки картинок. В какой-то момент изображения перестали загружаться. PM советуется с разработчиком и выясняет, что есть два варианта решения: пофиксить все за три дня или решить быстрее, но в будущем могут появиться проблемы в работе приложения.
Какой вариант правильнее выбрать? Учитывая, что приложение уже работает и люди им пользуются, три дня на исправление — это слишком много. Выгоднее внедрить быстрое решение, а потом постепенно «разруливать» технический долг.
Менеджеру с технической экспертизой проще понять внутреннюю кухню и ответить на вопросы заказчиков без дополнительных синхронов с разработчиками.
Как распределяются роли в команде
Разобраться, кто за что отвечает, — это базовый уровень технических знаний для PM’а. Дальше посмотрим на практическом примере, кому адресовать разные задачи, если что-то пошло не так.
В создании любого приложения или сервиса задействованы 5 компонентов: Design, Backend, Frontend/Mobile, QA, SysAdmin/DevOps. За каждую составляющую в команде отвечают разные специалисты. Когда менеджер различает сферы ответственности, то не будет отвлекать фронтенда, если долго обрабатываются запросы.
- Дизайнер (UX и UI Design) — создает дизайн и выделяет бизнес-требования, продумывает сценарий пользования. Несет ответственность за то, как будет выглядеть продукт и насколько удобно взаимодействовать с сайтом или приложением. Все должно быть продумано, расположение кнопок интуитивно понятно. От дизайна во многом зависят задачи фронтенда и бэкенда.
- Backend — пишет логику и API (интерфейс приложения), чтобы с этим могли работать фронтенды или мобильные разработчики.
- Frontend или Mobile — заботится о том, как работает видимая, клиентская часть сайта (Frontend) или приложения (Mobile).
- QA (тестировщик) —тестирует продукт на соответствие оговоренным требованиям и стандартам качества. Самая важная цель тестировщика — это не количество выявленных багов на этапе тестирования, а чтобы пользователи не находили дефекты после релиза продукта.
- SysAdmin/DevOps — следит за тем, чтобы все важные части приложения были доступны 24/7 и отлаженный процесс доставки кода происходил непрерывно. Это тихий наблюдатель, который работает параллельно со всеми процессами «в фоновом режиме». Чаще всего работу сисадминов или DevOps не замечают до тех пор, пока что-то не сломалось. Если все идет как надо, работа DevOps’а так и остается незаметной.
От дизайна во многом зависят задачи фронтенда и бэкенда.
Мы посмотрели на отдельные компоненты разработки, теперь давайте разберем, как распределяются зоны ответственности в команде на примере практической задачи.
Игра: кому адресовать задачу
Давайте представим, что от заказчика поступает ТЗ: создать MVP сайта по сокращению ссылок, на котором пользователь сможет:
- регистрироваться/логиниться;
- создавать сокращенные ссылки;
- смотреть статистику по ссылкам.
Логика в таком приложении очень простая: есть основная ссылка и то, до чего она сокращается. Когда запрашивают сокращенную версию — приложение отдает настоящую.
Допустим, наш сервис по сокращению ссылок запустили в работу и посыпались первые баги от пользователей. Проблемы появляются разные, и хорошо, когда PM понимает, на кого ставить задачу исправить конкретный баг.
Рассмотрим на примерах:
- График переходов по ссылке не рисуется в Safari. А в Chrome все происходит как положено. С такой ошибкой нужно подходить к фронтенду, потому что разбираться с отображением данных в браузере — это его работа.
- Не собирается статистика переходов по ссылкам. Пользователи переходят по созданным ссылкам, но обновления статистики в консоли не видно. Здесь сможет помочь бэкенд, так как подсчет переходов — задача, не связанная с отображением данных, это исключительно внутренняя логика, которая живет на бэкенде.
- Ссылки долго открываются для пользователей из Латинской Америки. В Европе ссылка открывается за 300 миллисекунд, а в Латинской Америке — 1,5 секунды. Вероятнее всего, это задача для DevOps: надо либо настроить DNS, либо продублировать сервер приложения где-то в регионе Латинской Америки.
- При попытке открыть сайт появляется ошибка 500. Это один из случаев, когда не получится сразу идентифицировать, чья проблема. Скорее всего, решать будут бэкенд вместе с DevOps’ом.
- Не работает создание новых ссылок. Есть какая-то форма на сайте, ее надо заполнить, ввести длинную ссылку, нажать «сохранить» — и получить сокращенный аналог. В какой-то момент эта форма перестала работать.
В какой-то момент эта форма перестала работать.У такой ошибки может быть несколько причин:
- бэкенд выдает 500 ошибку, и ссылка не формируется;
- на фронтенде что-то сломали, поэтому не передается параметр, который показывает, что пользователь авторизован. Тогда ссылки не будут сокращаться, потому что бэкенд не считает пользователя авторизованным;
- возможно, проблемы на стороне DevOps: упал один из серверов и сайт показывается, но вся логика заблокирована.
Кому-то приведенные выше примеры покажутся элементарными, но без понимания этих элементарных вещей менеджер рискует неправильно адресовать задачи. Когда так происходит много раз, люди отвлекаются, нервничают, возникают ненужные конфликты.
Даже с технической экспертизой найти решение бывает непросто, потому что есть много проблем, которые лежат на пересечении зон ответственности специалистов. Не всегда получится сразу идентифицировать источник проблемы, особенно если он связан с взаимодействием компонентов системы.
На такой случай у PM’а есть самый важный инструмент — коммуникация. Всегда можно пообщаться и спросить.
А вот чтобы коммуницировать правильно, менеджеру нужно иметь хотя бы верхнеуровневые представления о зонах ответственности каждого специалиста.
Понимание основ разработки — это базовый уровень технических знаний PM’а. Следующий этап — прокачивать навыки оценивания вместе с командой.
Понимание эстимейтов
Без технической экспертизы менеджеру трудно адекватно заэстимейтить общее время работы даже над одной задачей. Всегда есть ситуации, когда разработчики либо преувеличивают сроки, либо, наоборот, говорят слишком оптимистичный эстимейт, и потом команда не успевает, потому что работа заняла не 5 запланированных часов, а 15.
При оценивании количества часов на разработку PM’у важно уметь декомпозировать задачу, разбивать решение на небольшие пункты. Как только задача декомпозирована, становится яснее, о чем идет речь в эстимейтах, что предстоит делать разработчикам.
Приведу такой пример. Бэкенд может быть написан на PHP, а может — на Java. PHP отрабатывает запросы быстро, а Java — это отдельное приложение, которое постоянно крутится в ожидании запросов. В зависимости от языка программирования, время на исправление ошибки будет разным. В случае с PHP, можно быстро запушить изменения с сервера, фактически незаметно для пользователя. В случае с Java, чтобы все заработало, надо пересобирать весь бэкенд сначала. Если РМ понимает разницу между языками, он не будет рассчитывать, что ошибку поправят быстро, не будет ругаться, что прошел уже целый час, а разработчик все еще не пофиксил проблему.
Другой пример о разнице эстимейтов в работе фронтенда и мобайла. Код фронта для нового пользователя каждый раз запрашивается браузером с сервера. Поэтому, даже если где-то допустили ошибку, вопрос ее срочного исправления — дело одного часа. Мобильное же приложение пользователи загружают через App Store: не факт, что у них включено автообновление, плюс нужно учесть время, пока ваш билд пройдет аппрув.
Как происходит оценка на практике
Допустим, что в наше приложение для создания сокращенных ссылок нужно добавить оплату через PayPal.
Сначала решаем, кто из команды понадобится:
- дизайнер: создать дизайн страницы, модального окна или окна в мобильном приложении, на котором будет происходить оплата;
- фронтенд и бэкенд, чтобы написать логику;
- QA, чтобы протестировать весь процесс по итогу работы команды.
Теперь PM’у нужно понять, за сколько времени можно достичь цели. Поставленную задачу заэстимейтили фронтенд и бэкенд.
- Фронтенд оценил работу в 4 часа, включив туда верстку, логику запрос/ответ на бэкенд — и все.
- Бэкенд оценил задачу в один месяц: написать новые таблицы в базе данных, логику запрос/ответ к серверам PayPal, API, с которыми будет работать фронтенд.
Оценка фронтенда выглядит реалистично. Когда есть задача, например написать «модалку», чтобы можно было платить через PayPal, то 4 часа кажутся вполне подходящим сроком.
Затем PM начинает декомпозировать задачу, и выясняется, что фронтенд учел не все пункты. То, что верстка должна быть адаптивной, адекватно выглядеть на мобильных устройствах и в разных браузерах.
Когда PM с командой проговаривает составляющие задачи шаг за шагом, то приходит понимание пропущенных шагов: верстка может включать дополнительные опции, логика — тоже. Фронтенду надо будет обрабатывать ошибочные ответы от бэкенда.
То же самое с бэкендом. Когда озвучены все части задачи, например создание новых таблиц базы данных, логика запрос/ответ, API, могут появиться граничные условия, которые могут пойти не по плану.
Допустим, с новыми таблицами в базе данных вопросов нет, также как и с логикой запросов для фронтенда. У нас рабочее приложение и, скорее всего, ребята договорились, в каком формате принимают и отдают данные.
Зато сложность появляется при работе с PayPal. Если на логику запросов к PayPal заэстимирован один месяц, безо всякого основания, то такая оценка будет нереалистичной и малопредсказуемой без достаточных данных.
Прежде чем оценивать, надо собрать статистику по спринтам и, исходя из нее, выстраивать какие-то гипотезы.
Из своего опыта могу сказать, что мы ведем статистику, как разработчики справляются в спринтах, и выявляем коэффициенты для каждого из них. На эти коэффициенты мы потом и умножаем эстимейты. Чаще всего средний коэффициент у разработчиков — 1,6. Ребята, у которых коэффициент — 1,5 и ниже, имеют хороший показатель, достаточно прогнозируемый.
С абсолютной точностью оценить сложность задачи и время на выполнение не получится: как только появляется взаимодействие между людьми, все гарантии перестают быть чем-то вещественным. Но умение декомпозировать помогает PM’у лучше ориентироваться в сроках, адекватно оценивать как крупные фичи, так и весь проект в целом.
Итоги
PM с технической экспертизой:
- различает зоны ответственности специалистов в команде;
- понимает, к кому с какой проблемой обращаться;
- умеет декомпозировать задачи и оценивать эстимейты вместе с командой;
- может обосновать заказчику выгоду определенных решений или сложность задачи.
Конечно, человек может прийти в PM’ы из абсолютно гуманитарной сферы, и я знаю вполне успешные примеры. Если компания согласится обучать нового специалиста, то знания придется нарабатывать в процессе руководства проектом. Учиться и одновременно решать задачи по проекту будет нелегко, поэтому лучше заранее понимать, кто чем занимается в команде, что делают разработчики, из чего состоит система.
PM с технической экспертизой понимает больше, умеет больше, а значит, у него больше шансов найти хорошую работу даже во времена кризиса.
Все про українське ІТ в телеграмі — підписуйтеся на канал редакції DOU
Теми: project management, менеджмент
техническое определение фона | Словарь определений английского языка
adj
1 относящийся к промышленным, практическим или механическим искусствам и прикладным наукам или специализирующийся на них
технический институт
2 практические и механические искусства, а не теоретическое или абстрактное мышление
3 относящийся к определенной сфере деятельности или характерный для нее
технический жаргон лингвистики
4 существующий благодаря строгому применению правил или строгому толкованию формулировки
техническая лазейка в законе, техническая победа
5 из, производная или демонстрирующая технику
техническая блеск
6 (финансового рынка), цены которого определяются внутренними спекулятивными или манипулятивными факторами, а не общими или экономическими условиями
техническое ралли
♦ технически нареч
♦ техническое образование n
технический колледж
n (Британия) учреждение дополнительного образования, предлагающее курсы технологий, искусства, секретарских навыков , сельское хозяйство и т.
д., (иногда (неофициально) сокращается до) техника
технический рисунок
n изучение и практика, особ. как предмет, преподаваемый в школе, основных приемов черчения, используемых в механическом рисовании, архитектуре и т. д., (Сокращение) TD
технический институт
n (N.Z) высшее учебное заведение, (иногда (неформально) сокращается до) tech
технический нокаут
n (бокс) оценка нокаута, выносимая, когда боксер, по мнению рефери, слишком сильно избит, чтобы продолжать игру без риска серьезной травмы
технический сержант
n унтер-офицер Корпуса морской пехоты или ВВС США, непосредственно подчиненный старшему сержанту
Английский словарь Коллинза — определение английского языка и тезаурус  
Смотрите также:
техникум, техническое рисование, технический институт, технический нокаут
Collaborative Dictionary Определение английского языка
| ||||||||||||||||||||||||
| Вы хотите отклонить эту запись: дайте нам свои комментарии (неправильный перевод/определение, повторяющиеся записи…) |
Чтобы добавлять слова в свой словарь, станьте участником сообщества Reverso или войдите в систему, если вы уже являетесь его участником. Это просто и занимает всего несколько секунд:
Или зарегистрируйтесь традиционным способом
Как техническое образование помогает профессионалам
За последнее десятилетие меня неоднократно спрашивали, требуется ли техническое образование для успеха менеджера по продукту.
Ответ — нет. Но это, безусловно, помогло мне стать более эффективным. Это личный и ситуативный вопрос, на который нет четкого ответа, но мой опыт может помочь вам более эффективно работать с менеджером по продукту или в качестве менеджера по продукту с техническим образованием.
Внутренняя проводка
Я не знаю, пошел ли я в школу инженеров из-за того, как устроен мой мозг, или это из-за того, что Карнеги-Меллон перемонтировал мой мозг для меня — но я всегда говорю, что именно там я «научился учиться». То, как я подхожу к обучению и как применяю различные аналитические методы для синтеза, ситуационного анализа и развития идей, зависит от того, как устроен мой мозг. Говоря языком управления продуктом, то, как я узнаю что-то, является отличительной чертой, и это объективно делает меня лучше как менеджера по продукту. Я бы сказал, что это из-за моего технического образования. Я ожидаю, что люди с похожим прошлым будут иметь аналогичные преимущества.
The Inside Track
Чаще всего я работаю с компаниями, которые включают разработку программного обеспечения в разработку решений для своих клиентов. Так случилось, что я также несколько лет занимался разработкой программного обеспечения и, в конечном счете, руководил командами, которые разрабатывали программное обеспечение. Это тайное знание тайного рукопожатия помогло мне установить эффективные рабочие отношения с членами команды, которые фактически создают продукт. Когда вы что-то делаете, вы учитесь этому более интуитивно, чем если бы вы только читали об этом. Опираясь на этот более глубокий уровень понимания, который приходит только в процессе работы, — это один из способов наладить товарищеские отношения с командой людей, создающих ваш продукт.
Временный костыль
С точки зрения того, что вы уже знаете, техническое образование помогает только на короткое время. В конце концов, полученная вами информация станет неактуальной и, в конце концов, будет вводить в заблуждение.
Представьте себе, что вы пытаетесь применить взгляды на базу данных до SQL в разговорах о NoSQL и архитектурах распределенного хранения данных, а также в последующей деятельности по планированию выпуска. Вы также можете, конечно, иметь пакет технических знаний, которые не имеют отношения к вашей проблемной области. Уравнение Бернулли не поможет мне повысить коэффициент конверсии на веб-сайте или оценить ценность непрерывной интеграции.
Мой подход к применению вещей, которые я уже знаю или знал раньше, заключается в использовании этих знаний для общего контекста в разговоре, распознавании образов при воздействии новой для меня информации и обычном применении принципов обучения ко всему, что передо мной. Я не пытаюсь применять знания для решения, кроме как использовать их, чтобы направить некоторые направленные вопросы или помочь с формулировкой гипотезы.
Одной из фраз, которые я помню на тренингах Pragmatic Institute, был вопрос моего инструктора: «Если вы собираетесь делать их работу, то кто будет делать вашу работу?» Именно этот вопрос помогает мне уйти, когда я начинаю слишком углубляться в сорняки, обсуждая, как мы собираемся решать проблемы.
Это скользкий путь, особенно когда вы действительно любите технологии и втайне хотите, чтобы вы могли программировать (или проектировать, или тестировать) вместе с остальной командой.
Полезно, с изюминкой
Суть в том, что преимущество технического образования заключается не в участии в технической работе, а в том, как оно помогает вам сотрудничать с технической командой. Сотрудничество — это мягкий навык, и ему в целом помогает наличие технической проводки.
Иногда мы работаем над продуктами, которые помогают нашим клиентам решать проблемы в технической области. В этих случаях техническое знание может немного помочь — и даже может быть действительно необходимо — для понимания вашего рынка.
Рассмотрим, например, разработку штатного расписания для крупной больницы. Вы должны быть в состоянии синтезировать технические проблемы, сочетая абстрактную математическую задачу (задача составления списка медсестер — классическая вычислительная головоломка) с деловой оценкой определения «достаточно хорошего» решения.
На мой взгляд, понимание того, как конкурировать на этом рынке, требует от вас способности оценить математическую сложность ценностного предложения, чтобы вы не считали его тривиальным или неразрешимым. Это проблема, за решение которой люди будут платить. Это также проблема, которая требует сочетания технического решения и бизнес-перспективы.
В конце концов, если вы разрабатываете продукт, направленный на решение конкретной технической проблемы, я не верю, что вы можете быть эффективными без достаточной «технической проводки» в вашем мозгу, чтобы в полной мере оценить проблемы. (и возможности) в игре. Один из лучших (и очень техничных) продакт-менеджеров, с которыми мне доводилось работать, имел степень по истории, но его мозг был полностью приспособлен для того, чтобы мыслить технически. Продемонстрированный успех в технической роли (или образовании) является вероятным показателем, но несовершенным фильтром.
В двух словах
Иметь в голове совокупность технических знаний имеет ограниченную и сомнительную пользу.
Ограниченный, потому что он более полезен в приложении, чем в совместной работе, и подозрительный, потому что он станет неактуальным или даже неправильным быстрее, чем вы ожидаете. Я думаю об этом как о косвенном результате наличия технического образования, а не как об активе, который можно использовать напрямую.
Но даже когда вы создаете продукты, которые не являются «техническими», техническая перспектива может значительно помочь вам в процессе создания этих продуктов. И это не потому, что это помогает вам выполнять какую-либо техническую тяжелую работу, а потому, что это помогает вам более эффективно работать с людьми, которые выполняют техническую работу.
]’4701
Автор
Скотт Селхорст
Скотт помогает компаниям добиваться успеха в разработке программных продуктов с 1997 года и основал Tyner Blain в 2005 году. Скотт является консультантом по управлению продуктами и стратегии, а также приглашенным лектором программы DIT по управлению продуктами.
