[Управление разработкой, Управление проектами, Управление персоналом, Карьера в IT-индустрии, Бизнес-модели] Про outsource и product компании
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет.
Я team lead, сертифицированный коуч и начинающий психолог.
Недавно задумался на тему того, почему так много положительных отзывов о работе в продуктовых компаниях и почему так недолюбливают outsource.Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.В этой статье хочу поделиться своим видением текущей ситуации на рынке.
- За время работы заметил следующие интересные феномены:
- В продуктовых компаниях люди чаще обсуждают что изменить в продукте (язык заплетается). В outsource компаниях – в процессах
- В продуктовых компаниях меньше менеджмента
- В продуктовых компаниях реже взаимодействие с заказчиком (или целевой аудиторией)
Ни на одном проекте не встретил аналитику в outsource.Здесь думаю следует пояснить, что такое outsource.
Аутсорсинг (своими словами) – это такая сфера, в которой заказчик очень не хочет что-то делать и решает передать эту работу отдельной команде, за счёт чего последние и живут.Если у кого-то есть вопросы или несогласие по поводу «не хочет», идея ко мне пришла после прочтения статьи, с которой советую ознакомиться.Здесь очень важно понимать, что заказчик в момент обращения за помощью уже находится в НЕ спокойном состоянии. Его напряжение настолько сильное, что он готов расстаться со своими деньгами, лишь бы его избавили от этого напряжения. Более того, он согласен принимать условия «scrum», «agile» и прочего, лишь бы только не встречаться снова с проблемой, которую он не хочет решать.Забегая вперёд, именно от незнания вышеизложенного часто идёт удивление – почему заказчик «вдруг» стал недоволен. Он и был недоволен, и это вообще не с вами связано.Так вот, помимо непосредственных задач, которые заказчик пытается переложить на outsource компанию он транслирует ещё и своё нежелание/сопротивление эту работу делать.
Выражаться это может в чём угодно – он плохо сформулированных требования (ну, потому что не хочет он больше видеть эту проблему. «Решите уже её за меня»), он жалуется на плохую работу предыдущих исполнителей или текущих сотрудников и т.д.Причём всё это нужно трактовать не как объективные и осознанные недовольства заказчика, а как психологическую разгрузку. Что-то в стиле – пожаловаться друзьям. Однако в случае outsource компании – возможность пожаловаться является услугой, оказываемой такому заказчику. Здесь ни в коем случае руководство outsource компании не должно обесценивать работу менеджеров или бизнес-аналитиков. Эти люди стоят на передовой. Их задача состоит в том, чтобы путём снижения сопротивления заказчика составить понятные и хорошо описанные требования для команды разработчика.Таким специалистам необходимо иметь достаточно неплохие дипломатические навыки. И чётко разделять профессиональную и личную критику (вы делаете фигню и вы – козёл).
Заказчик, каким бы он милым не казался, будет находиться в большом стрессе. И его логичным желанием будет слить своё напряжение в дипломата со стороны outsource.
Таким специалистом не должен быть разработчик (либо это должно быть отдельно прояснено с ним).
Необходим именно отдельный человек, который будет поддерживать контакт в дальнейшем. Потому как снижение напряжения важно и в момент релиза. Даже если всё идёт по плану не стоит забывать – заказчик уже был на пределе, когда просил помощи. А в момент релиза она ему ещё больше будет необходима, даже если он не говорит об этом.Думаю, здесь стоит упомянуть первый принцип гибкой методологии разработки:«Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения»Очень важно понимать, что без качественной работы бизнес-аналитика (или любого другого дипломата) не удастся получить требования для регулярной поставки ПО.Так мы приходим к необходимости методологий разработки как таковых.
По моему сугубо личному мнению, не важно, какую методологию вы используете. Важно именно её популярность. Популярность необходима для преодоления сопротивления заказчика и выуживания из него требований для разработчиков. 
Всё очень просто. Заказчик начинает использовать разработчика, как «бизнес-аналитика». И сливать в него своё раздражение от задачи, которую ему так не хочется делать.
Так заказчик неосознанно пытается сказать – «Мне очень важно, чтобы вы это сделали. Я больше не хочу выносить это, избавьте меня от этой проблемы поскорее, вот вам деньги».
Заказчик как бы воспринимает разработчиков как «гуру», «мастеров», которые решат его вопрос и без подробных объяснений (возможно отсюда элитарность професси программистов в СНГ, помимо денег).
Он думает, что необходимо только заплатить деньги и кошмар закончится. И здесь есть интересная ловушка.Обычно в любой компании разработчики всё-таки являются подчинёнными. Над ними стоят менеджеры. А решения в беседах разработчику приходится принимать на менеджерском уровне, а-то и выше (переносы релиза, просьба о помощи других разрабов/девопса/тестировщиков и т.д).Обычно менеджеры нанимают на работу, дают на подпись договор, следят за работой разработчиков, ищут для них заказчиков и многое другое. И здесь очень важным является, как такие менеджеры позиционируют себя по отношению к заказчику.В некоторых компаниях, где я работал заказчик – это «царь» и «бог». Все должны работать чтобы удовлетворить его. В таких коллективах у меня, как разработчика всегда вставал вопрос, а кто же я в команде? Выше ли я, чем менеджеры или нет, раз уж я непосредственно занимаюсь заказчиком?
Для упрощения воспользуемся метафорой семьи. Здесь разработчики являются детьми в очень большой семье. А менеджеры - родители.
Ситуация аутсорса очень похожа на ситуацию, в которой разработчик является кем-то в стиле старшего брата, в семье без отца. И вот его просят другие взрослые дяди денег, а официально устроиться на работу он не может (заказчик хочет устного договора с представителем компании, а договор письменный у него с менеджерами).Поэтому разработчик находится в какой-то не совсем понятной ситуации. Как бы между двух родителей.Здесь очень важно заметить про страх непринятия и обесценивания. Каждый шаг в компании оценивается с двух сторон – заказчик и руководитель. Объективно – деньги платит руководство, но они опираются на удовлетворённость заказчика. Чаще всего диалог между ними не является чем-то публичным. Поэтому постоянно приходится строить догадки. И из-за этого у разработчика может появиться страх, что обесценит один из родителей – либо заказчик, либо менеджер.Так приходим к такому прекрасному феномену, как поведение человека в стрессе.
В стрессовой ситуации человек деградирует до уровня психологического развития (младшие разработчики обычно до детей, хорошо если поствербального периода, старшие же хотя бы уже до подростков, либо до взрослой личности).Получается при сильной фигуре заказчика, старшие разработчики могут открыто выражать своё недовольство как менеджерам, так и заказчикам. И уже отстаивать свой личный интерес.
Младшие же разработчики так делать не могут (чаще всего) в силу собственной идентичности в данной группе.И здесь важно заметить, что если человек деградирует до невербального периода (до того, как научился говорить), то он просто не будет выражать своё недовольство, замкнётся и выгорит.Так приходим к тому, что младшим разработчикам крайне необходим ярко выраженная фигура родителя, для адекватного функционирования.Со старшими же разработчиками всё сложнее. Здесь как раз могут возникать конфликты. Т.к. необходима сепарация от родителя-менеджера, для выстраивания адекватных отношений с заказчиком. Иначе – стресс (между двух родителей).В такой ситуации для менеджеров наступает момент встречи с "ребёнком в подростковом периоде". Когда он ещё не самостоятельный (человек всё-таки на контракте). Но уже требует своего признания (уважение его договоров с заказчиком).Данное признание очень помогает продвинуться всей компании, т.к у менеджеров убирается жёсткая необходимость ставить кого-то над таким разработчиком (бизнес-аналитика, менеджера).Однако если признания не наступает, а, не дай бог, ещё и обесценивание идёт. То это может сильно отодвинуть всю компанию от развития и приведёт к найму кучи бесполезных "руководителей".И менеджерам ещё долго придётся «вынашивать» своё «потомство», до появления следующей конфликтной ситуации.Такой конфликт – спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.В продуктовой компании скорее ярко выражена фигура отца и она практически неоспорима.
Дети бегут за признанием только к одному человеку, а он всё контролирует.Отсюда и появляется первый феномен (из начала статьи).Редко обсуждаются процессы, а преобладают усовершенствования продукта. При наличии одного родителя может быть много разработчиков, каждый из которых получит достаточное количество «любви», «внимания» от фигуры отца.А как следствие там будет скорее конфликт между детьми в коллективе в стиле «папа, посмотри, как я могу» (больше разговоров про непосредственно работу), чем про процесс. Никто не будет хотеть бороться за место отца, все будут бороться за его внимание друг с другом.Как следствие разворачивается и второй пункт – меньше менеджмента. Он практически не нужен. Всё прекрасно работает.По поводу меньшего взаимодействия. Я думаю – это связанно с тем, что признание отца коллектив будет заслуживать скорее с помощью реальных действий и просить оценить их. А в outsource скорее больше успокоения заказчика идёт, снятие напряжения, чем необходимость в оценке. Либо необходимость оценки смещается на заказчика.Про аналитику просто наблюдение. Ни с чем не смог связать.
===========
Источник:
habr.com
===========
Похожие новости:
- [Клиентская оптимизация, Бизнес-модели] Что нужно знать перед началом роботизации процессов?
- [Управление проектами, Производство и разработка электроники, IT-компании] Samsung будет закупать у LG OLED-панели для телевизоров. Впервые в своей истории
- [Программирование, Управление персоналом, Игры и игровые приставки, Логические игры] Совместная игра в Factorio — лучшее техническое собеседование, что мы проводили (перевод)
- [Карьера в IT-индустрии] Как стать высокооплачиваемым инженером в области электроники
- [Работа с видео, Управление проектами, Контекстная реклама, Копирайт, Социальные сети и сообщества] «Союзмультфильм» удалил видео с YouTube, так как лишился доходов из-за новых правил
- [Управление сообществом, Управление продуктом, Законодательство в IT, Бизнес-модели, IT-компании] Uber запретил калифорнийским водителям устанавливать свои цены
- [Анализ и проектирование систем, Карьера в IT-индустрии] – А у нас нет мышей! – А мы заведём… Какая польза от архитектора решений
- [Учебный процесс в IT, Карьера в IT-индустрии] Войти в IT и сразу получить работу: новые бесплатные курсы в Parimatch Tech Academy
- [Управление проектами, Венчурные инвестиции, Развитие стартапа, Финансы в IT, IT-компании] Сбербанк и РВК создадут фонд для инвестиций в стартапы
- [Программирование, Учебный процесс в IT, Карьера в IT-индустрии, Удалённая работа] Как развиваться в IT
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_upravlenie_personalom (Управление персоналом), #_karera_v_itindustrii (Карьера в IT-индустрии), #_biznesmodeli (Бизнес-модели), #_management, #_teamlead, #_business_analyst, #_project_management, #_outsourcing, #_outsourcing_companies, #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_personalom (
Управление персоналом
), #_karera_v_itindustrii (
Карьера в IT-индустрии
), #_biznesmodeli (
Бизнес-модели
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:42
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Всем привет. Я team lead, сертифицированный коуч и начинающий психолог. Недавно задумался на тему того, почему так много положительных отзывов о работе в продуктовых компаниях и почему так недолюбливают outsource.Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.В этой статье хочу поделиться своим видением текущей ситуации на рынке.
Аутсорсинг (своими словами) – это такая сфера, в которой заказчик очень не хочет что-то делать и решает передать эту работу отдельной команде, за счёт чего последние и живут.Если у кого-то есть вопросы или несогласие по поводу «не хочет», идея ко мне пришла после прочтения статьи, с которой советую ознакомиться.Здесь очень важно понимать, что заказчик в момент обращения за помощью уже находится в НЕ спокойном состоянии. Его напряжение настолько сильное, что он готов расстаться со своими деньгами, лишь бы его избавили от этого напряжения. Более того, он согласен принимать условия «scrum», «agile» и прочего, лишь бы только не встречаться снова с проблемой, которую он не хочет решать.Забегая вперёд, именно от незнания вышеизложенного часто идёт удивление – почему заказчик «вдруг» стал недоволен. Он и был недоволен, и это вообще не с вами связано.Так вот, помимо непосредственных задач, которые заказчик пытается переложить на outsource компанию он транслирует ещё и своё нежелание/сопротивление эту работу делать. Выражаться это может в чём угодно – он плохо сформулированных требования (ну, потому что не хочет он больше видеть эту проблему. «Решите уже её за меня»), он жалуется на плохую работу предыдущих исполнителей или текущих сотрудников и т.д.Причём всё это нужно трактовать не как объективные и осознанные недовольства заказчика, а как психологическую разгрузку. Что-то в стиле – пожаловаться друзьям. Однако в случае outsource компании – возможность пожаловаться является услугой, оказываемой такому заказчику. Здесь ни в коем случае руководство outsource компании не должно обесценивать работу менеджеров или бизнес-аналитиков. Эти люди стоят на передовой. Их задача состоит в том, чтобы путём снижения сопротивления заказчика составить понятные и хорошо описанные требования для команды разработчика.Таким специалистам необходимо иметь достаточно неплохие дипломатические навыки. И чётко разделять профессиональную и личную критику (вы делаете фигню и вы – козёл).  Заказчик, каким бы он милым не казался, будет находиться в большом стрессе. И его логичным желанием будет слить своё напряжение в дипломата со стороны outsource. Таким специалистом не должен быть разработчик (либо это должно быть отдельно прояснено с ним). Необходим именно отдельный человек, который будет поддерживать контакт в дальнейшем. Потому как снижение напряжения важно и в момент релиза. Даже если всё идёт по плану не стоит забывать – заказчик уже был на пределе, когда просил помощи. А в момент релиза она ему ещё больше будет необходима, даже если он не говорит об этом.Думаю, здесь стоит упомянуть первый принцип гибкой методологии разработки:«Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения»Очень важно понимать, что без качественной работы бизнес-аналитика (или любого другого дипломата) не удастся получить требования для регулярной поставки ПО.Так мы приходим к необходимости методологий разработки как таковых. По моему сугубо личному мнению, не важно, какую методологию вы используете. Важно именно её популярность. Популярность необходима для преодоления сопротивления заказчика и выуживания из него требований для разработчиков.  Всё очень просто. Заказчик начинает использовать разработчика, как «бизнес-аналитика». И сливать в него своё раздражение от задачи, которую ему так не хочется делать. Так заказчик неосознанно пытается сказать – «Мне очень важно, чтобы вы это сделали. Я больше не хочу выносить это, избавьте меня от этой проблемы поскорее, вот вам деньги». Заказчик как бы воспринимает разработчиков как «гуру», «мастеров», которые решат его вопрос и без подробных объяснений (возможно отсюда элитарность професси программистов в СНГ, помимо денег). Он думает, что необходимо только заплатить деньги и кошмар закончится. И здесь есть интересная ловушка.Обычно в любой компании разработчики всё-таки являются подчинёнными. Над ними стоят менеджеры. А решения в беседах разработчику приходится принимать на менеджерском уровне, а-то и выше (переносы релиза, просьба о помощи других разрабов/девопса/тестировщиков и т.д).Обычно менеджеры нанимают на работу, дают на подпись договор, следят за работой разработчиков, ищут для них заказчиков и многое другое. И здесь очень важным является, как такие менеджеры позиционируют себя по отношению к заказчику.В некоторых компаниях, где я работал заказчик – это «царь» и «бог». Все должны работать чтобы удовлетворить его. В таких коллективах у меня, как разработчика всегда вставал вопрос, а кто же я в команде? Выше ли я, чем менеджеры или нет, раз уж я непосредственно занимаюсь заказчиком? Для упрощения воспользуемся метафорой семьи. Здесь разработчики являются детьми в очень большой семье. А менеджеры - родители. Ситуация аутсорса очень похожа на ситуацию, в которой разработчик является кем-то в стиле старшего брата, в семье без отца. И вот его просят другие взрослые дяди денег, а официально устроиться на работу он не может (заказчик хочет устного договора с представителем компании, а договор письменный у него с менеджерами).Поэтому разработчик находится в какой-то не совсем понятной ситуации. Как бы между двух родителей.Здесь очень важно заметить про страх непринятия и обесценивания. Каждый шаг в компании оценивается с двух сторон – заказчик и руководитель. Объективно – деньги платит руководство, но они опираются на удовлетворённость заказчика. Чаще всего диалог между ними не является чем-то публичным. Поэтому постоянно приходится строить догадки. И из-за этого у разработчика может появиться страх, что обесценит один из родителей – либо заказчик, либо менеджер.Так приходим к такому прекрасному феномену, как поведение человека в стрессе. В стрессовой ситуации человек деградирует до уровня психологического развития (младшие разработчики обычно до детей, хорошо если поствербального периода, старшие же хотя бы уже до подростков, либо до взрослой личности).Получается при сильной фигуре заказчика, старшие разработчики могут открыто выражать своё недовольство как менеджерам, так и заказчикам. И уже отстаивать свой личный интерес. Младшие же разработчики так делать не могут (чаще всего) в силу собственной идентичности в данной группе.И здесь важно заметить, что если человек деградирует до невербального периода (до того, как научился говорить), то он просто не будет выражать своё недовольство, замкнётся и выгорит.Так приходим к тому, что младшим разработчикам крайне необходим ярко выраженная фигура родителя, для адекватного функционирования.Со старшими же разработчиками всё сложнее. Здесь как раз могут возникать конфликты. Т.к. необходима сепарация от родителя-менеджера, для выстраивания адекватных отношений с заказчиком. Иначе – стресс (между двух родителей).В такой ситуации для менеджеров наступает момент встречи с "ребёнком в подростковом периоде". Когда он ещё не самостоятельный (человек всё-таки на контракте). Но уже требует своего признания (уважение его договоров с заказчиком).Данное признание очень помогает продвинуться всей компании, т.к у менеджеров убирается жёсткая необходимость ставить кого-то над таким разработчиком (бизнес-аналитика, менеджера).Однако если признания не наступает, а, не дай бог, ещё и обесценивание идёт. То это может сильно отодвинуть всю компанию от развития и приведёт к найму кучи бесполезных "руководителей".И менеджерам ещё долго придётся «вынашивать» своё «потомство», до появления следующей конфликтной ситуации.Такой конфликт – спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.В продуктовой компании скорее ярко выражена фигура отца и она практически неоспорима. Дети бегут за признанием только к одному человеку, а он всё контролирует.Отсюда и появляется первый феномен (из начала статьи).Редко обсуждаются процессы, а преобладают усовершенствования продукта. При наличии одного родителя может быть много разработчиков, каждый из которых получит достаточное количество «любви», «внимания» от фигуры отца.А как следствие там будет скорее конфликт между детьми в коллективе в стиле «папа, посмотри, как я могу» (больше разговоров про непосредственно работу), чем про процесс. Никто не будет хотеть бороться за место отца, все будут бороться за его внимание друг с другом.Как следствие разворачивается и второй пункт – меньше менеджмента. Он практически не нужен. Всё прекрасно работает.По поводу меньшего взаимодействия. Я думаю – это связанно с тем, что признание отца коллектив будет заслуживать скорее с помощью реальных действий и просить оценить их. А в outsource скорее больше успокоения заказчика идёт, снятие напряжения, чем необходимость в оценке. Либо необходимость оценки смещается на заказчика.Про аналитику просто наблюдение. Ни с чем не смог связать. =========== Источник: habr.com =========== Похожие новости:
Управление разработкой ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_personalom ( Управление персоналом ), #_karera_v_itindustrii ( Карьера в IT-индустрии ), #_biznesmodeli ( Бизнес-модели ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:42
Часовой пояс: UTC + 5