Про outsource и product компании

    Всем привет.

    Я team lead, сертифицированный коуч и начинающий психолог.

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

    Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.

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

    • За время работы заметил следующие интересные феномены:

    • В продуктовых компаниях люди чаще обсуждают что изменить в продукте (язык заплетается). В outsource компаниях – в процессах

    • В продуктовых компаниях меньше менеджмента

    • В продуктовых компаниях реже взаимодействие с заказчиком (или целевой аудиторией)

    Ни на одном проекте не встретил аналитику в outsource.

    Здесь думаю следует пояснить, что такое outsource.

    Аутсорсинг (своими словами) – это такая сфера, в которой заказчик очень не хочет что-то делать и решает передать эту работу отдельной команде, за счёт чего последние и живут.

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

    Здесь очень важно понимать, что заказчик в момент обращения за помощью уже находится в НЕ спокойном состоянии. Его напряжение настолько сильное, что он готов расстаться со своими деньгами, лишь бы его избавили от этого напряжения. Более того, он согласен принимать условия «scrum», «agile» и прочего, лишь бы только не встречаться снова с проблемой, которую он не хочет решать.

    Забегая вперёд, именно от незнания вышеизложенного часто идёт удивление – почему заказчик «вдруг» стал недоволен. Он и был недоволен, и это вообще не с вами связано.

    Так вот, помимо непосредственных задач, которые заказчик пытается переложить на outsource компанию он транслирует ещё и своё нежелание/сопротивление эту работу делать.
    Выражаться это может в чём угодно – он плохо сформулированных требования (ну, потому что не хочет он больше видеть эту проблему. «Решите уже её за меня»), он жалуется на плохую работу предыдущих исполнителей или текущих сотрудников и т.д.

    Причём всё это нужно трактовать не как объективные и осознанные недовольства заказчика, а как психологическую разгрузку. Что-то в стиле – пожаловаться друзьям. Однако в случае outsource компании – возможность пожаловаться является услугой, оказываемой такому заказчику.

    Здесь ни в коем случае руководство outsource компании не должно обесценивать работу менеджеров или бизнес-аналитиков. Эти люди стоят на передовой. Их задача состоит в том, чтобы путём снижения сопротивления заказчика составить понятные и хорошо описанные требования для команды разработчика.

    Таким специалистам необходимо иметь достаточно неплохие дипломатические навыки. И чётко разделять профессиональную и личную критику (вы делаете фигню и вы – козёл).

    Заказчик, каким бы он милым не казался, будет находиться в большом стрессе. И его логичным желанием будет слить своё напряжение в дипломата со стороны outsource.
    Таким специалистом не должен быть разработчик (либо это должно быть отдельно прояснено с ним).

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

    Думаю, здесь стоит упомянуть первый принцип гибкой методологии разработки:

    «Наивысшим приоритетом для нас является удовлетворение потребностей
    заказчика, благодаря регулярной и ранней поставке ценного программного
    обеспечения»

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

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

    Всё очень просто. Заказчик начинает использовать разработчика, как «бизнес-аналитика». И сливать в него своё раздражение от задачи, которую ему так не хочется делать.

    Так заказчик неосознанно пытается сказать – «Мне очень важно, чтобы вы это сделали. Я больше не хочу выносить это, избавьте меня от этой проблемы поскорее, вот вам деньги».

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

    И здесь есть интересная ловушка.

    Обычно в любой компании разработчики всё-таки являются подчинёнными. Над ними стоят менеджеры. А решения в беседах разработчику приходится принимать на менеджерском уровне, а-то и выше (переносы релиза, просьба о помощи других разрабов/девопса/тестировщиков и т.д).

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

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

    Для упрощения воспользуемся метафорой семьи.

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

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

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

    Здесь очень важно заметить про страх непринятия и обесценивания.

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

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

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

    Получается при сильной фигуре заказчика, старшие разработчики могут открыто выражать своё недовольство как менеджерам, так и заказчикам. И уже отстаивать свой личный интерес.
    Младшие же разработчики так делать не могут (чаще всего) в силу собственной идентичности в данной группе.

    И здесь важно заметить, что если человек деградирует до невербального периода (до того, как научился говорить), то он просто не будет выражать своё недовольство, замкнётся и выгорит.

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

    Со старшими же разработчиками всё сложнее. Здесь как раз могут возникать конфликты. Т.к. необходима сепарация от родителя-менеджера, для выстраивания адекватных отношений с заказчиком. Иначе – стресс (между двух родителей).

    В такой ситуации для менеджеров наступает момент встречи с "ребёнком в подростковом периоде". Когда он ещё не самостоятельный (человек всё-таки на контракте). Но уже требует своего признания (уважение его договоров с заказчиком).

    Данное признание очень помогает продвинуться всей компании, т.к у менеджеров убирается жёсткая необходимость ставить кого-то над таким разработчиком (бизнес-аналитика, менеджера).

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

    И менеджерам ещё долго придётся «вынашивать» своё «потомство», до появления следующей конфликтной ситуации.

    Такой конфликт – спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.

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

    Отсюда и появляется первый феномен (из начала статьи).

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

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

    Как следствие разворачивается и второй пункт – меньше менеджмента. Он практически не нужен. Всё прекрасно работает.

    По поводу меньшего взаимодействия. Я думаю – это связанно с тем, что признание отца коллектив будет заслуживать скорее с помощью реальных действий и просить оценить их. А в outsource скорее больше успокоения заказчика идёт, снятие напряжения, чем необходимость в оценке. Либо необходимость оценки смещается на заказчика.

    Про аналитику просто наблюдение. Ни с чем не смог связать.

    Комментарии 7

      +1
      А какой выход из ситуации? Рынок решил: outsource — рабочая модель ведения бизнеса.
        –1

        Просто проговаривать в коллективе реальные ценности.
        Чётко раскладывать, что хотят менеджеры и в какие сроки.
        Не забывать хвалить "дипломатов" от бизнеса как со стороны разработчиков, так и со стороны менеджмента (часто встречал, что разработчики критикуют BA или PM).
        В общем просто иметь более человеческие и менее "профессиональные" отношения

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

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


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


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


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

            –2

            Какое интересное начало комментария.
            Видимо вас чем-то лично задела статья, раз вы пытаетесь указать на мой малый опыт?


            Можете поделиться тем, что конкретно было для вас таким обидным? Вполне возможно этот опыт будет напрямую связан с ещё какой-то проблемой аутсорса, которую я не упомянул?


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

              +1

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


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


              Я же написал не просто про клиента, который не знает, чего хочет. Клиент может не уметь формулировать ТЗ, это довольно очевидно. Да просто хостинг от домена не отличать, это нормально.


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


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

            0

            Статья довольна тяжёлая для прочтения и каких-то выводов. Начали про аутсорт, закончили про семью в ИТ конторе.
            Про аутосорт не совсем согласен, я на мелком уровне ИП делаю услуги для разных организаций, по простой причине:
            ○такую работу выполняют с периодичностью в 3-5 лет
            ○делать ее можно от недели, до нескольких месяцев
            ○для такой работу нужен определённый формат знаний, который через курсы в пару месяцев не получишь
            ○стоимостная разница, держать сотрудника на 1/4 ставки или обратиться в аутсорт. Конечно же второй вариант дешевле
            Добавить можно еще тем, что разовая работа может предполагать затраты, которые очень не выгодны и даже несут за собой огромные финансовые потери. Мне дешевле будет обратиться к бухгалтеру на аутсорте, чем покупать все оборудование и платить после аренду программных продуктов.
            Боязнь сотрудника, обратиться в аутсорт, да есть такое, но это все только на уровне новичка. После определённого этапа, можно на самостоятельной основе, в голове, делать у себя тендеры, выбирать компанию для сотрудничества


            Ну а про продукт компании я не совсем уловил вектор мысли, поэтому от комментариев воздержусь

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

            Самое читаемое