«Нам все сложнее продавать людей...»
CEO украинской компании
В данной статье хотелось бы немного поговорить о том, почему разработка ПО в нашем регионе никак не может преодолеть детский сад outstaff-подхода и перейти от продажи людей к продажам услуг. Написано намеренно немного провокативно и с небольшой долей сатиры в расчете на дискуссию: какие именно изменения необходимы индустрии для совершения качественного шага в своем развитии.
Долгое время на рынке царили строгие подходы и методологии в разработке программного обеспечения, во многом близкие к тому, как это делалось на разнообразных проектах еще до появления IT-отрасли. Отличительной чертой этих методологий был большой объем работы по созданию проекта как такового. Обычно в виде проектной документации, в которой описывались как функциональные, так и качественные требования к создаваемому программному обеспечению. Это было необходимо в условиях жестких эксплуатационных ограничений, которые в то время царили на рынке. В ту эпоху железо стоило значительно дороже труда разработчиков, а типичная структура расходов бизнеса на поддержание цифровой инфраструктуры была сильно смещена в сторону капитальной.
Эти два фактора обуславливали значительное превалирование стоимости рисков внедрения относительно стоимости проектного моделирования. В то же самое время в абсолютных цифрах стоимость проектного моделирования даже небольших проектов была очень высока, что делало порог входа в разработку достаточно высоким и недоступным для мелкого и зачастую даже среднего масштаба предприятий.
Так продолжалось до появления технологии всемирной паутины, которая создала рынок цифровых продуктов и услуг, доступный массовому потребителю. Начиная с середины
Индустрия отчаянно искала выход из сложившейся ситуации. Ответ пришел в феврале 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. Довольно типична ситуация, когда основным игроком в этой активности становится менеджер, который делает практически все: от разбора требований до построения высокоуровневой архитектуры и составления плана проекта, консультируясь с соответствующими специалистами, если он сталкивается с проблемами.
Очевидно, что такой подход не работает с большими и сложными проектами в принципе, а в случае обработки небольших или средних реквестов, без слез на такое предложение смотреть нельзя. Когда приходит понимание, что с менеджером не выходит, то пытаются заставить делать технарей. Потом, наверное, заставят тестировщиков. На самом деле на земле не родился еще человек, который самостоятельно может закрыть все компетенции, необходимые для создания успешного решения. Единственно возможный подход — это тесная работа специально подготовленной команды, которая может быть создана только из лучших представителей центров мастерства.
Цельный результат от взаимодействия Центров Мастерства и Центров Компетенций обладает сильным синергическим эффектом и способен перенести качество предоставляемых услуг, соответственно и качество ваших предложений на новый уровень, обеспечив конкурентоспособность вашей компании на годы вперед.
Продолжение следует. В следующей серии статей будет более детально описано, что из себя представляет каждый центр мастерства и компетенций. А также способы их взаимодействия для достижения максимального результата.
Буду признателен за ваши комментарии и вопросы.