Как построить качественный процесс
Аусторсинг разработки ПО — это производство продукта, придуманного клиентом. Производство должно фокусироваться на качестве и предсказуемости результата. Единственное, что позволяет это обеспечить в масштабах крупнее гаража — процессы.
Что хотят заказчики?
Бывает, что заказчик не доволен качеством продукта или каких-то его частей. Раньше, работая по контракту Staff Augmentation или Time and Materials, мы могли объяснить заказчику, что так получилось из-за того, что он сам так «наменеджил», или что «какие требования — такой и результат». Но в последние годы ситуация меняется — всё больше и больше заказчиков, независимо от договоренного типа сотрудничества, имеют ожидания, свойственные модели Fixed Price/Fixed Bid.
Говоря простым языком: заказчик хочет, чтобы сотрудничество напоминало покупку хлеба в магазине. Он пришел, спросил, какой вкуснее, заплатил его стоимость, получил товар отменного качества и довольный пошел дальше. Он не хочет, чтобы ему продали часть буханки, отрезанной непонятным образом, а на вопрос «Почему так?» рассказали примерно такую историю:
«Видите ли, сработал риск возможного наезда на камень на дороге, и машина, которая везла эту буханку, качнулась. Далее сработал другой риск — человеческий фактор: дверь в машине была закрыта не совсем плотно, и поэтому буханка выпала на землю, где крыса случайно съела кусочек. Но вы не волнуйтесь, мы ее аккуратно вытерли и обрезали то, что надкусила крыса. Поэтому ваш кусок выглядит так странно».
Заказчики не хотят особо вникать в то, как получается результат. Их больше интересует сам результат, а не способ его получения. Бизнес заказчика — не разработка ПО. ПО для него либо продукт, либо часть продукта. Компонент, помогающий получать прибыль.
Помимо других компаний, я работал в Luxoft и EPAM. У обеих компаний есть заветная мечта. В Luxoft это Managed Delivery, а в EPAM — Product Development Services. Они обе стремятся предсказуемо получать результат определенного качества.
Обеспечиваем результат
Способность получать предсказуемый результат — цель стратегическая. Давайте разобьем ее на некоторые тактические действия, требуемые для ее достижения.
1) Описание процесса
Гиганты отрасли имеют красивый бейджик CMMI 4. Компании чуть поменьше стремятся получить ISO 9001 и другие уровни сертификации. Зачем? Потому что такой статус означает, что процессы компании:
— описаны;
— измерены;
— поддаются контролю.
Три перечисленных фактора — это минимум, необходимый для прогнозируемого результата.
В наших реалиях описание процессов часто делают «для галочки». Сотрудники могут не знать, что такое описание в компании вообще существует. А если и знают, то не особо хотят по нему работать, потому что непонятно/я умнее/я лучше знаю/это не Agile и т.д.
Поэтому первое, что необходимо сделать — детально определить, как именно компания будет обеспечивать качественный и предсказуемый результат. Это описание процесса можно сделать только на определенном уровне абстракции, так как детали более низкого уровня слишком разнятся в зависимости от контекста, и их невозможно учесть в рамках одного описания. Зачем тогда нам нужно высокоуровневое описание? Затем же, зачем мореплавателям в средние века нужны были звезды — для ориентирования. Этот высокоуровневый процесс должен стать для компании фундаментом и путеводной звездой, на которую будут равняться сотрудники. Иначе каждый будет делать «по-своему», и предсказуемость просто исчезнет.
После создания высокоуровневого процесса нужно провести инвентаризацию того, чем вы занимаетесь в текущий момент (какие именно проекты делаете) и чем планируете заниматься в будущем (какого типа проекты, из какой индустрии и т.д.). Цель — сформировать некие архетипы (категории) проектов и создать процесс-наследник от верхнеуровневого. Он будет обеспечивать предсказуемый результат определенного качества именно для такого типа проекта и именно в этой индустрии.
Как пример: в финансовом секторе при работе с UBS или Deutsche Bank вам бессмысленно внедрять «скрам в чистом виде», потому что вместо пользы он принесет проблемы. Коммуникации при работе с таким клиентом будут отличаться от коммуникаций со стартапом, у которого получилось выйти на рынок, и теперь он хотел бы переделать свой продукт с «на коленках» на «по-нормальному».
Все эти нюансы вполне поддаются категоризации с последующим созданием чек-листов для контроля «а не пропустили ли мы что-то важное», детальных инструкций для ролей в проекте, способов оценки сроков и стоимости работ, планов коммуникаций, шаблонов и методов отчетности. Именно эти нюансы и обеспечивают качество и предсказуемость. Удобнее всего их описывать как наследованные от высокоуровневого процессы, работающие в определенном конкретном контексте.
2) Компетенции
Имея производственный процесс, описанный от начала и до конца, мы уже можем прописать компетенции, требуемые для его успешного выполнения. В результате вы наконец-то сможете объяснить, зачем в вашей скил матрице у девелопера требуется навык владения циркулем. Или если этому нет объяснения — перестать проверять этот навык на собеседованиях.
Имея возможность доступно объяснить, зачем нужны определенные компетенции, вы можете проверить состав ваших ролей, поставив наконец-то перед HR задачу по-приятнее, чем «снизить аттришн».
Для иллюстрации приведу пример из тренинга про компетеции. Если вы не учитываете доступность ресурсов, в вашей скил матрице вполне может появиться «повар-сварщик». Потребность в компетенции повара и сварщика одновременно вполне может быть объяснима вашим производственным процессом (например, в пищевой промышленности). Попытка объединить эти компетенции в одной роли может быть объяснима либо недальновидностью, либо слепой уверенностью, что на рынке можно относительно легко найти поваров с прошлым сварщика (либо наоборот). Но процесс — явление более менее долговечное, а значит вам придется искать учебное заведение, выпускающее таких поваров-сварщиков. Иначе после того, как все существующие уйдут на пенсию либо уволятся, ваш процесс станет просто невыполнимым.
Итак, после того как вы поймете, какие именно человеческие ресурсы вам требуются, пора перейти к действию номер 3.
3) Образование
Зная конечную точку, куда вы хотите прийти (то есть зная конкретные требования к конкретной роли для конкретной категории проекта), вы можете заниматься развитием сотрудников.
Я не верю, что хотя бы в одной компании все роли в процессе заполнены людьми, хотя бы на 90% отвечающими требованиям. Поэтому первое, что нужно будет сделать — «доразвить» качество этих людей до заветных
Следующие действия касаются планирования загрузки «рабочей силы» (Workforce Planning) и внедрения программных продуктов, автоматизирующих управление людскими ресурсами (Human Resources Management), что выходят за рамки данной статьи.
Итоги
Таким образом, недопонимания, разночтения, разногласия и трактования разных ролей/вакансий/позиций исходят из того, что «формальная составляющая» бизнеса плохо проработана. Ни одна компания не может расти и быть успешной в средне- и долгосрочной перспективе, если сотрудники в ней работают по принципу «Сам додумай как — мы ж тебе за это деньги платим». Еще раз повторюсь — такой подход работает только в начале и должен быть заменен на более зрелый, описанный выше.
Предложенные действия проверенно и гарантировано работают как в масштабе компании целиком, так и в масштабе отдельных проектов (при условии, что вы сможете адаприровать изложенные концепции к конкретной ситуации).
Желаю удачи любому, кто захочет их выполнить.
