От галеры к самолету за 21 день

«Нам все сложнее продавать людей...»
CEO украинской компании

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

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

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

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

Индустрия отчаянно искала выход из сложившейся ситуации. Ответ пришел в феврале 2001 в виде Agile Manifesto, который привел к расцвету использования гибких методологий в разработке ПО. Ценности гибкого подхода позволили значительно сократить дистанцию между бизнесом и разработкой, ставя во главу угла непосредственное и регулярное взаимодействие всех стейкхолдеров для выработки общего понимания цели проекта и контроля его выполнения. Это позволило значительно упростить этап проектного моделирования и в тоже время, по сути, совместить его с этапом непосредственной разработки. Очевидно, что данный подход неизбежно вел к широкому распространению outstaffing-модели. Когда у нас нет проектного моделирования, то нам не нужны целые пласты специалистов — так в тот период на обочине оказались аналитики, архитекторы, большое количество технических менеджеров.

Классика проектного взаимодействия в то время была такой:

— У меня есть классная бизнес-идея!
— Мы можем продать вам отличную команду из N разработчиков, с помощью которых вы можете попытаться ее реализовать!
— Profit!

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

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

Какую стратегию использует именно ваша компания?

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

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

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

Приходит в компанию N заказчик, который перед заключением контракта хочет, чтобы компания выполнила тестовое задание. Достаточно нередко встречающееся требование, особенно на небольших проектах. Задание представляет из себя небольшую практическую задачу из бизнес-домена заказчика, сформулированную в академическом объеме и достаточно урезанном скоупе — 4 несложных бизнес-сценария, 2 качественных требования к системе.

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

Дальше самое интересное — две недели! Sick! человек пишет код, присылает его на ревью с пометкой «пока реализовал только инфраструктуру, просмотри пока ее, а бизнес-сценарии допишу позже». Просмотрев код решения, который, к слову говоря, состоял из нескольких десятков, а может быть и сотен сущностей, которые делали все, что угодно — начиная от балансировки нагрузки и сервисной шины сообщений, заканчивая инфраструктурой для перевода типа приложения из настольного в сайт прозрачно для бизнес-логики. Однако нефункциональные требования заказчика были реализованы довольно кривовато, а бизнес-требования вообще реализованы не были. На вопрос, почему так? Был получен ответ: «Мне было интересно попробовать вот такие-то паттерны». Занавес..

При этом человек весьма серьезно подошел к работе: было написано много хорошего production ready кода. Менеджеры в это время тоже ответственно делали свои задачи по другим проектам, никто в потолок не плевал. Все люди весьма мотивированы работать на результат, но есть одна проблема — все они видят этот результат по-своему, и никто из них не смог найти время и подумать, а что такое результат для заказчика. Для чего он это просит, какую свою проблему он пытается решить, как мы можем помочь ему в этом? Это никого не волнует — люди просто делают свою работу :) При этом каждый из участников может честно бить себя пяткой в грудь, крича, что он result-oriented person. Легче ли от этого бизнесу? Очевидно, нет.

К сожалению, зачастую эта проблема неочевидна с верхушки, на которой сидит бизнес. Каким же индикатором можно пользоваться, чтобы понять, что компания продает заказчику процесс, а не результат? Основная доля доходов компании идет от её операционной деятельности, а не капитальной. Другими словами — мы выставляем инвойс, в котором пишем потраченные часы, а не поставку решения, даже если речь идет о промежуточных поставках. Фактически, мы занимаемся продажей человеко-часов. Гиперболизируя, чем больше часов мы продали заказчику до того момента, как он разорится — тем лучше. Заказчики больше не готовы брать на себя эти риски целиком.

2. Ориентированность на результат. В этот раз честно ориентируемся на результат и пытаемся осознать и выдать именно тот результат, который имеет ценность для бизнеса заказчика.

Как же мы можем увидеть, что мы продаем заказчику реальный результат, а не процесс? Самый простой индикатор — это способность компании успешно работать с fixed-price контрактами или другими формами контрактов, которые подразумевают ограничения сверху. По срокам, по бюджету, с жестким графиком поставок и т. д. Другими словами — компания умеет предоставлять сервис. Поздравляю! Вы на верном пути. Но опять же, ориентируясь на то, какие проекты и процессы распространены в украинских компаниях, можно сказать, что почти наверняка вы относительно неплохо работаете с контрактами, подразумевающими ограничения. Но как насчет чистой fixed-price модели? Каким критериям должна соответствовать компания, чтобы успешно удовлетворять потребности заказчика в рамках работы с котрактами, подразумевающими настолько жесткие ограничения и при этом быть прибыльной?

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

Эффективность работы компании измеряется по таким ключевым показателям:

  • Management overhead. Мне бы хотелось привести некую цифру, сколько процентов должен быть «здоровый» management overhead. Совсем грубо — 10 %. Но как только начинаем углубляться в специфику, то понимаем, что все очень индивидуально.

    С точки зрения бизнеса, у нас слишком высокий management overheads, в случаях когда мы не обладаем свободой маневра, когда нам приходится конкурировать pay-rate.

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

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

  • Наличие экспертизы, соответствующей международным стандартам. Сотрудники должны обладать навыками и иметь опыт, востребованный на международном рынке труда. Для обеспечения этого критерия, в компании должна быть модель компетенций, основанная на одном из международных стандартов.
  • Наличие элитной команды, делающей качественные выигрышные pre-sale. В такой команде должны эффективно сотрудничать представители каждого участка цикла разработки программного обеспечения: менеджер по продажам, delivery manager, архитектор, бизнес-аналитик, тестировщик, разработчик и DevOps.

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

Новые рельсы

Если вы хотите перевести компанию на новые рельсы и эффективно работать по сервисной модели, то вам необходимо сделать 3 вещи:

1. Выстроить в компании структуры, занимающиеся профессиональным ростом сотрудников, — центры мастерства.

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

2. Выстроить в компании структуры, обеспечивающие специальное (доменное) образование сотрудников, — центры компетенций.

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

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

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

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


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

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

Буду признателен за ваши комментарии и вопросы.

LinkedIn

60 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Придерусь к стилю. Очень советую автору книгу М. Ильяхова «Пиши, сокращай. Как создавать сильный текст». Длинные запутанные предложения, канцеляризмы, мало отсылок к фактам — в общем, может быть написано лучше. А по сути — интересно. Спасибо!

Спасибо за статью. Она напомнила выступление организационного психолога Адама Гранта «Are you a giver or a taker»: www.ted.com/...​re_you_a_giver_or_a_taker

Мне кажется, его подход хорошо ложится на разделение продавать сервис (givers) / продавать человекочасы (takers). Чисто субъективно, переделать takers в givers нельзя, у людей слишком другая картина мира — и мне кажется, что и перестроить культуру компании с продажи человекочасов на продажу сервиса тоже будет очень нелегко. Потому что даже малое количество takers (людей, привыкших к и настроенных на продажу человекочасов, а не интересы клиентов) портит атмосферу во всей группе.

Было бы интересно послушать о кейсах такого преобразования (успешных и неуспешных).

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

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

Прочитавши заголовок, я думав, що стаття буде про те, як нам в Україні перестати продвати людей і почати продавати продукт. Але, якщо я все правильно зрозумів, стаття про те, як перестати продавати людей і почати продавати якісний сервіс. Це звичайно краще, ніж те, що є зараз, але, мабуть, не зовсім те, до чого треба прагнути.

Разделение рисков должно подразумевать разделение прибыли, иначе оно того не стоит. Какой-то бонус/штраф и его размер должен зависеть от бизнесметрик. Не от количества реализованных фич, типа 5/10 — потому что может оказаться что пользователям нужны только первые 3, но реализованные качественно. Зафиксированная цена подразумевает зафиксированные требования — а это подразумевает детальную их проработку. Что лично я один раз видел, но... Таки да, это waterfall...
Для того чтобы аутсорсинговая компания на такой проект согласилась, увидела там прибыль для начала — необходимо понимание маркетинга этого бизнеса. Оценка рисков — по сути это уже инвестиционная деятельность. И вы не поверите но в одной из компаний я слышал о таком подходе (скидка на разработку — за долю) Стратегия «галеры» — опортунизм. Очень удобная позиция, именно поэтому самые крупные компании так работают. Они возможно не самые прибыльные в расчете на сотрудника. Я думаю что поменять что-то в рамках «галеры» невозможно, можно только сделать суб-бренд который при финансовой поддержке материнской компании, но других сейлзов, будет пытаться построить процессы по другому с более высокой нормой прибыли.

Так а прибыль и разделяется за счет более высокой стоимости контракта.

ключевой момент в привязке вознаграждения к бизнес метрикам. Или заказчик решает нанять CTO/PM с долей у себя в стране и чаще всего ключевых технических специалистов. И тогда программирующее туловище именно то что им можно продать. И тут не важна квалификация наших специалистов — ничего важного и заметного для бизнеса сюда не отдадут. Просто потому что и там есть технари. Бизнес будет доверять им больше из-за массы причин от культуры до я видел эту морду в нашем офисе каждый день. Зачем нужен ПМ в штатах если вся разработка тут ? Незачем — значит он уговорит своё начальство нанять несколько технарей там. Иначе он не нужен. Аутсорсинг не может выдавить in-house dev team если у бизнеса не наступил финансовый апокалипсис, а если наступил — то это временный клиент и наши девы там в роли сиделки в хосписе. Я видел полностью неадекватных технарей на стороне заказчика — и их наверно никогда не уволят. Такие переходят в менеджмент, и управляют нашими командами из туловищ.
Про центры компетенции — повторяющийся между проектами код или технические решения, который не является конкурентным преимуществом (а именно такое нам аутсорсят) отличный кандидат на вынесение в open source. Это менее вероятно в области финансов — поэтому такие центры компетенции процветают. Но по-моему просто увеличивают цену программирующего тела.
Глобально нацеленный продукт — единственный выход. А это долго, дорого и рискованно. Все клёвые идеи, простые в реализации и с относительно реалистичным product-market fit легче сделать американцу, в первую очередь по той причине что легче найти деньги (так что бы в случае неудачи в лес не вывезли).
За счёт низкой стоимости проживания долго копаться в мутной но перспективной тематике легче у нас. Но тут не будет «верняковой темы», по сравнению с аутсорсингом требуется другой способ мышления. Я не вижу что бы галеры создавали инкубаторы, я не вижу что бы они делали компоненты которые бы потом бесплатно получал заказчик (который бы больше платил за тело, обученное работать с компонентами), я не вижу даже инструментов для программистов сделанных гребцами для себя (потому что погонщик не оценит в принципе — это ведь меньше жопочасов продадим).
Это всё вопрос реинвестирования полученной прибыли. Сейчас мне кажется что она реинвестируются в продажи — это прагматично.
Продажи я думаю тоже можно делать по разному — забрать проект с которым не справились индусы это ведь самый низ пищевой цепочки. Продать даже команду туловищ в стартап из долины я думаю задача сложнее. И тут снова trade off : немного денег сейчас или больше но потом, с большим вложением труда. Я думаю что в условной «офицерской каюте» условной галеры — всё просто восхитительно и как говорится «не надо раскачивать лодку».
Что-то меня прорвало — только что уволился из одного из «лидеров рынка».

это все справедливо для заказчиков, у которых есть в каком-то виде in-house capability писать какой-то софт — тут действительно нужны только руки, но даже тут в последнее время желающих покупать кота в мешке все меньше.

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

кстати, о привязке вознаграждения к бизнес метрикам, тут вообще мы строго говоря от софта уходим в сторону и продаем capability, которое может быть интегрировано в инфраструктуру бизнеса заказчика, а для этого надо это capability спроектировать и выровнять относительно бизнес-стратегии целевого предприятия с точки зрения показателей. Это задача business и enterprise architecture областей. А специалистов в этих областях у нас даже в микроскоп не разглядеть.

Их можно нанять в штатах или Израиле. Не важно кого по национальности. Я думаю можно при желании найти русскоязычных для упрощения коммуникаций. Вопрос в том что это инвестиции.
Думаю будут вопросы со сложностью продажи таких проектов : «Как это вы долю хотите ? Это не вашего ума дело! Вы бы ещё первенца попросили в качестве оплаты»
Я наверно бы на месте американского бизнесмена нанял бы американского же ПМ под проект. Вот просто технаря который уже менеджил индусов например.

Такие проекты брать сц..трашно...
Нужно иметь представление о том какие хотелки бывают в этой предметной области и какие-то компоненты готовые (которые были бы действительно easy to compose).

Такие компоненты никто не делает в рамках коммерческих проектов с горящими строками. Правильное понимание того что и как абстрагировать не приходит в затраханный мозг.
Это значит что его может написать человек с опытом в предметной области, который при этом не сильно занят в текущих проектах (а это же потеря бабла вот прям сейчас + риски для этих проектов, ведь там будет кто-то менее опытный).
А теперь главный облом — этот чувак будет ходить по офису и улыбаться, у него не будет пота на лице и вообще начальству может показаться что он «волынит». Ну и риски — он может проиграться с технологиями и ничего годного не сделать, качество этой работы будут видно только через некоторое время. Как его мотивировать ? Снижать ЗП на этот период нельзя.

В общем у текущего положения дел есть весьма весомые причины.

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

можно ли эту ситуацию как-то изменить

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

текущая ситуация рисует весьма печальную картину на дистанции.

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

Собственно приходим к тому что из аутсорса надо бежать. Только бежать в Украине особо некуда — компаний типа Prom, Grammarly, Datarobot и им подобных — единицы. Вакансий там тоже очень мало на тысячи толковых разработчиков. Вот и остается один выход — заводим трактор и едем к бизнесу =)

При этом человек весьма серьезно подошел к работе: было написано много хорошего production ready кода.
«Мне было интересно попробовать вот такие-то паттерны». Занавес..

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

Сотрудники должны обладать навыками и иметь опыт, востребованный на международном рынке труда.

Стоп. Мы же хотели «перейти от продажи людей к продажам услуг». Какая разница что там за навыки востребованы на каком-то рынке? Компания предоставляет услугу по созданию чего-то, а то на основание чего они это создают — это уже «детали реализации». (Прим.: По структуре заголовков не очень понятно, была ли цитата решением или еще одним недостатком)

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

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

А ни продавец, ни пресейл инженер, ни кто другой из тех кто продает проект не понимали что это будет «выглядеть странно»?
Если понимали, то сроки должны устанавливать они, что-то вроде «где-то 16-24 часа работы, дедлайн где-то через неделю».

так этот лид и был фактически пресейл инженер, как сейлз мог угадать, что там на пару дней работы

так этот лид и был фактически пресейл инженер

То есть фактически, присейл инженера не было :)

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

Возвращаясь в контекст

преодолеть детский сад outstaff-подхода и перейти от продажи людей к продажам услуг.

Тут обучение и центры компетенций — это как раз та самая «ориентация на процесс».
Для того чтобы продавать услуги нужно ... продавать услуги. Нужно чтобы компания была готова брать на себя риски.
А чтобы компания продолжала существовать, нужно чтобы она умела управлять этими рисками. И это должно быть изменено на всех уровнях, и сама разработка — это один из последних уровней. Простой пример чтобы делать фиксед-кост по аджайл, нужны доверительные отношение между исполнителем и заказчиком, нужна увереность что заказчик не потребует деньги взад потому что «кнопа не того цвета». Если доверительных отношений нет, то тогда только «вотерфол».
А что мы получим когда посчитаем затраты на управление рисками? Скорее всего окажется что продавать «тушки» и ныть что разработчики и заказчики зажрались выгоднее, чем __продавать__ услуги.

За последний год, подавляющее большинство пресейлов у меня начиналось так, приходит человек и говорит — «здравствуйте, у меня есть 300к и вот такая хотелка, что вы мне можете сделать в эти деньги?». Для того чтобы дать ему нормальный ответ, нужен анализ, для того чтобы сделать нормальный анализ — нужны толковые спецы, для того чтобы спец был толковым ему нужны компетенции, которые он должен где-то взять. Т.к. на рынке в области анализа трэшак полный, то возвращаемся к тому что надо растить своих своих. Как это нормально сделать? правильно — организовать людей в структуры, где они могут учиться.
Жизнь она не черно-белая всегда есть немножко процесса и немножко сущностей, даже когда человек утром встает в туалет сгонять, там и процессная составляющая есть и объектная, так что зря вы пытаетесь меня в граничные условия вытащить.
Речь о том, что тушки продавать проще... сегодня... пока еще, но рынок заполняется понемногу. Если еще 5 лет назад компания человек в 300 даже слышать не хотела за проекты с бюджетом в 50к, то теперь берутся и делают дальше уже только рейтом можно конкурировать. Как вы думаете это отразится на вашей зп скажем в десятилетней перспективе?

Никак. Будет все то же, что и сейчас. Всё та же конкуренция с индусами по продаже тушек.

«здравствуйте, у меня есть 300к и вот такая хотелка, что вы мне можете сделать в эти деньги?». Для того чтобы дать ему нормальный ответ, нужен анализ, для того чтобы сделать нормальный анализ — нужны толковые спецы,

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

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

Это коммент за какой год? За 2017? Wipro и Infosys не заполнили рынок? Нет бума аутсорса в Польше и Странах Балтии (по слухам сюда еще можно включить Балканские страны, Ирландию и Испанию), которые как раз продают «тушки»?

---

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

---

Принципиальное отличие (одно из) аутсорса людей, аутсорса услуг, продуктовой разработки (в контексте инженера):
1) При аутсорсе людей, человек просто должен быть как можно дешевле.
2) При аутсорсе услуг, он должен уметь __быстро и качественно обучаться (постоянно) номому__.
3) При продуктовой разработке, обладать экспертизой в некоторой узкой области, которая нужна проекту/продекту.

Очень похоже что вы переход 1-2 предлагаете методами, которые работают при 1-3. Это немного не корректно.

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

Как можно мотивировать жирных котов?

Перевести с вискаса на более здоровое питание без усилителей вкуса, увлечь лазерной указкой — полно методов, ограниченных только фантазией и индивидуальным подходом. Только, конечно использовать только законные, а не то что некоторые (dou.ua/forums/topic/17132 ).

Я к тому, что как только в США все будут такими жирными котами как сеньоры в Украине то и педалить особо мало кто будет.
Будут тоже посты о выгорании о сплаве по Миссисипи и т.д.

Если сеньоры в США будут работать в таких же условиях, то вполне себе возможен такой сценарий. Например, довелось работать с человеком оттуда у которого в компании был такой график работы: проснулся в 7, проверил почту/раздал таски на аутсорс, в пол восьмого побежал на пробежку, занялся своими делами и т.п. К 9 — 10 подъехал на работу. Около 11 митинг, 12 — ланч, в 15 уже свободны почти все, разве что еще один митинг проведут. После 15 работы нет особо (аутсорсные украинцы закончили свой рабочий день).
Конечно, за эти 3-4 часа работы выгореть сложно. Вообще работа в радость. Уж не говоря об компенсации этого времяпрепровождения в размере $70k-120k в год.

Пожалуйста. Вы подменяете понятия, достижение бизнес-целей — это не синоним «выкатить что-то завтра». Это означает выкатить то, что нужно в балансе качества, стоимости и сроков. Для того чтобы этот баланс нормально находить, нужно выстраивать жизненный цикл разработки, который состоит из 5 шагов — анализ, моделирование/проектирование, разработка, тестирование, внедрение (наши центры мастерства). Начиная сразу мотивировать разработчиков вы пропускаете анализ и моделирование, а без них они хорошо сделать не смогут, как вы их не мотивируйте :)
Людям же которые сидят в фазах анализа и проектирования нужно разбираться в Business и Enterprise Architecture, для того, чтобы они могли выровнять архитектуру разрабатываемого решения с теми бизнес-показателями, которые ожидает заказчик. Исторически, разработчики не имеют компетенций в этих дисциплинах, только то, что интуитивно понятно из повседневного опыта. Поэтому мотивируя лишь разработчиков — максимум чего вы добьетесь, это то, что они будут деливерить быстрее, вопрос в том, что :)

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

В формате комментария на этот вопрос ответить не так уж просто, надо отдельную статью писать :)

Для того чтобы этот баланс нормально находить, нужно выстраивать жизненный цикл разработки, который состоит из 5 шагов — анализ, моделирование/проектирование, разработка, тестирование, внедрение (наши центры мастерства)

То есть по вашему в аутсорсе только ватерфол будет работать? Но мы же знаем что ватерфол ущербный.

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

у вас на agile проектах тестирование есть? наверняка есть. А оценка? тоже я уверен чо-нить там покерите. Ой, и сторя же тоже как-то получаются, наверное кто-то проанализовал задачу и выписал их. А ваш говнокод кто-то потом еще и на прод заливает, внедряет так сказать принимающей стороне. Таак, смотрим, что у нас тут получилось — оппа, анализ, оценка, разработка, тестирование, внедрение, ЛОЛШТО?

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

У нас нет всего этого ватерфола о котором вы говорите. Поэтому мы одна из самых быстрорастущих коппаний в Европе. Вот почитайте — blog.bannerflow.com/...​vertising-company-europe

Мой говнокод никто на прод не заливает, не тестирует, не принимает и не внедряет. Я все делаю сам (или с такими же коллегами-программистами). Я же не просто тушка-кодерок с часовым рейтом — я инженер.

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

У всех свои интересы, это вообще ни от типа компании зависит. И это нормально, это должны решать менеджеры, можно решать в аутстафинге, можно в продукте.

Тут я вижу 2 большие проблемы: всё клёво, пока галера специализируется на 1..2 больших клиентах, особенно прекрасно, если их доменные области близки.
Центр подготовки радостно готовит спецов в доменной области, пони какают радугой, всё чудесно.
Но как только галера переходит определённый уровень — держаться за 1 клиента ей становится тяжело, поскольку операционные расходы растут и риск банкротства клиента или его отказ от сотрудничества ставит на галере крест, поскольку накоплений не хватит, чтобы поддерживать аренду + ЗП гребцам, пока найдётся настолько же большой клиент, способный выкупить необходимое кол-во человеко-часов. Поэтому возникает необходимость диверсификации.
Обычно галера не выбирает доменную область, как правильно было замечено в статье, ей важно продать человеко-часы, а что будут делать гребцы — танк, самолёт или неведому зверушку — топ-менеджменту галеры, в сущности, пофиг. Более того, если стремиться найти новых клиентов в той же или смежной доменных областях — во-первых, повышается риск массового отказа, например, в случае кризиса в данной доменной области, а, во-вторых, снижается темп нахождения новых контрактов, а значит, темп роста галеры.
В этом случае центру подготовки придётся гораздо труднее: во-первых, экспертизу в новой доменной области галера набить ещё не успела, во-вторых, после прохождения 1-2 курсов до ДО программист вряд ли станет спецом, особенно если доменная область объёмна. Я могу сказать по личному опыту, что, пройдя несколько курсов по 20 часов минимум каждый по ценным бумагам, трейдером я вряд ли смогу работать. Мой максимум — не пугаться страшных слов типа «фьючерс» и «акция» в требованиях. Но, например, предложить заказчику улучшенный алгоритм оценки рисков или проревьювать существующий с точки зрения бизнес-домена я не готов. Для того, чтобы стать спецом в ДО, не работая в ней напрямую, потребуются годы.
И тут мы подходим к проблеме 2: гребцу, по большому счёту, неинтересно становиться спецом в ДО, поскольку мат. стимуляция от этого будет ниже, чем от смены работы на +500 через 2 года.
Соответственно, избыток времени он скорее потратит на самообразование в своей рабочей области, нежели в ДО, поскольку именно от этого по большей части зависит его успех на рынке. И заставить его глубоко учить ДО стимулов, в общем-то, нет. Глубокое обучение ДО — удел манагеров и аналитиков, поскольку у них это коррелирует с успехом на рынке, но не для программеров и тестировщиков.

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

От этого уже отказались — не выгодно в сравнении с перепродажей тушек.

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

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

Логично, что местный бизнес выбирает перепродажу тушек.

Не нравится на галере — идите в НИИ или КБ. Там и инновации и продукт и много чего другого, только денег мало ;)

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

Галере нечего предложить хорошему специалисту. Ну разве что лычку типа «Директор центра разработки» — но сколько таких людей? 20 человек на всю Украину?

для трактористов статья действительно бесполезна :)

И что хорошего в этой лычке?

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

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

Хочу вторую часть :)
Наразі замечу, шо в конкретном случае для аутсорса оказалось невозможным предсказать какие компетенции будут востребованы в течение ближайшего полугода-года. Поэтому нужных не хватало, а созданные разваливались как неприоритетные. В результате у меня осталось впечатление, что эта схема подходит скорее для продуктовой компании, чем для ситуации перехода с аутстаффа на аутсорс и политики «делаем всё!».

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

...в аутсорсе уже появляются понятия наш клиент/не наш, интересный проект/не интересный...

Должны бы появляться, сорри :8) На практике, кроме наличествующих в компании компетенций, фильтром в первую очередь являются те проекты-услуги, которые в состоянии продать сейлзы, оттуда и танцы. Возможно, конечно, пахарошему сие называется «переходным периодом» от аутстаффа до аутсорса... :8)

почему разработка ПО в нашем регионе никак не может преодолеть детский сад outstaff-подхода и перейти от продажи людей к продажам услуг

по той же причине, по которой, к примеру, не переходят от экспорта стали к экспорту автомобилей

Продажники — самое слабое звено .. как в IT, так и на автоЗазе :8) Кроме того, что так старшим пацанам голову меньше мастити тра. Плюс в IT можна лёхко утверждать, что «аунас — всеравно аутсорс!».

Это не детский сад. Просто так выгоднее работать в ваших и наших условиях.

Почему то в реальности наблюдается тренд к продаже жопочасов, а не разработке проектов.
В 90-х, когда тут всё начиналось больше в ходу были проекты, но с каждым годом всё больше переходили к продаже жопочасов.
Кстати это можно пронаблюдать на примере конторы Научсофт в Минске.

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

Так Научсофт и прошел весь путь, что ты предлагаешь, только наоборот. Начал с продукта, сейчас обычная галера.

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

По крайней мере половина «дешёвых стартапов» получая инвестиции выше раунда Б тут же ж сбрасывают разработку как раз на аутсорс и то что они к тому моменту имеют из «технической реализации» сплошное такое отборное говно и палки что даже индусы о таком никогда не слышали и не догадались бы б так что лично я бы б по моему нескромному мнению самоназванного а может и нет технического эксперта «как на западе удел дешёвых стартапов» (к) (тм) к чему-либо сколь-либо прогрессивному и достойному последования бы б не относил.

Вторая половина источника стартаперского технического долга заливаемого на аутсорс это стартаперские экзиты причём одинаково что на IPO когда место «фаундеров» занимают специально обученные и нанятые уже акционерами менеджеры что на exit через M&A когда то же ж самое только многими уровнями ниже и уже в готовой корпорации в последнем случае операция проходит чаще даже через 2 уровня сперва всё накопленное техническое говно заливается на уважаемых индусов (как аутсорс так и собственные r&d офисы) и они там какое-то время варятся и может даже что-то делают но затем наступает момент признаться что всё ничего не выйдет и пора что-то делать и всё это «дело» заливается на территории с несколько более высоким уровнем инженерной культуры но всё ещё сходной ценой.

Родина в данной иерархии относится именно к последней но здесь есть нюанс...

Родина в данной иерархии _пока_ ещё относится именно к последней как только процесс будет завершён окончательно а дело к тому идёт Родина а) потеряет имевшуюся ранее составляющую «территории с несколько более высоким уровнем инженерной культуры» б) никак не приобретёт общий хайп типа с понтом стартаперского рынка просто исходя из технической невозможности роста рынка собственного просто исходя из того что Родине таки явно светит стать таки Европой и во вполне обозримом будущем но при этом оставаться бедной Европой в любом сколь угодно реально обозримом и доступном для прогнозов будущем.

Если говорить об «опоздании на 5 лет» что ж повидимому это вполне реальные сроки.

По моему нескромному мнению большей точностью в сторону более пессимистичного сценария следует будет сделать вывод по факту незахождения в Родину r&d офисов больших контор в ближайшие 2 года. По моему нескромному мнению в случае таки незахождения в течение 2-х лет можно уже гарантированно говорить о незахождении в горизонте 5 лет и тогда всё.

Запомните этот твит. (к) (тм)

стартапы на руби и питоне с джаваскриптом- это будущее украйти?)

Та лихко фейсбучик на PHP начинал потом оказалось что железко надо бы б утилизировать поэффективнее оно денег стоит всё равно дороже программеров за мивину пучок и пошли всяко разное Hack HipHop и #внезапно пакованчик собственных инфраструктурных проектиков на нехипстерских си/++ образовалось.

Денежки они такие...

Больше ответственности и оринтация на бизнес приводит к конкурентному преимуществу. Прям открытие.
Но галеры хотят продавать попочасы, а кодеры хотят просто играться с кодом. Мир не идеален.

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

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

HRSM по функциям

Краткое содержание статьи: «Make waterfall great again».

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

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