×

Как построить качественный процесс

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

Что хотят заказчики?

Бывает, что заказчик не доволен качеством продукта или каких-то его частей. Раньше, работая по контракту 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% отвечающими требованиям. Поэтому первое, что нужно будет сделать — «доразвить» качество этих людей до заветных 99-100%, без которых ваш процесс дает не совсем предсказуемый результат. Тогда вы сможете получить опыт создания действительно работающих планов развития (то, что в народе называют CDP/PDP и т.д.)

Следующие действия касаются планирования загрузки «рабочей силы» (Workforce Planning) и внедрения программных продуктов, автоматизирующих управление людскими ресурсами (Human Resources Management), что выходят за рамки данной статьи.

Итоги

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

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

Желаю удачи любому, кто захочет их выполнить.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



18 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Як зрозуміти «снизить аттришн»? Що таке «аттришин»?

Что такое Attrition и почему это важно для вашей компании
dou.ua/...​lenta/articles/attrition

Таким образом, недопонимания, разночтения, разногласия и трактования разных ролей/вакансий/позиций исходят из того, что «формальная составляющая» бизнеса плохо проработана.
Читал и плакалЪ сухими слезами!
Вакансия делается под позицию. Позиция под производственные или административные процессы.
Роль — под проекты.
Роль не то же самое, что и позиция.
Но большинство девочек-"рекрутёрок", вчерашних выпускниц педучилищ или психфаков, об этом понятия не имеют.

есть кнопка «редактировать» сообщение, доступная в течение нескольких часов после отправки сообщения. ну, чтоб четыре отдельных сообщения не делать.

вполне может появиться «повар-сварщик». Потребность в компетенции повара и сварщика одновременно вполне может быть объяснима вашим производственным процессом (например, в пищевой промышленности). Попытка объединить эти компетенции в одной роли может быть объяснима либо недальновидностью, либо слепой уверенностью, что на рынке можно относительно легко найти поваров с прошлым сварщика (либо наоборот)
попытка объединить модет также быть вызвана двумя этими причинами одновременно. Опять же такие компании легко вычисляются по описаниям их вакансий, как например «нам нужен ПМ с крепким опытом разработки в Azure, настройкой 1С 7 и офисной АТС, но работать он будет как тим лид по скраму» :)
В результате вы наконец-то сможете объяснить, зачем в вашей скил матрице у девелопера требуется навык владения циркулем. Или если этому нет объяснения — перестать проверять этот навык на собеседованиях.
Отсюда также следует упрощение требований к кандидатам в описаниях вакансий
Сотрудники могут не знать, что такое описание в компании вообще существует. А если и знают, то не особо хотят по нему работать, потому что непонятно/я умнее/я лучше знаю/это не Agile и т.д.
Это лечится
1) презентацией на онбординге нового человека в компании
2) периодическими тренингами
а тем более, если CMMI 4, когда еще на 3-м уровне должно работать Organizational Training

Спасибо за статью ... но раздел «3) Образование» обрезан по сути до одного предложения :( , а там полемизировать и полемизировать.

Я не верю, что хотя бы в одной компании все роли в процессе заполнены людьми, хотя бы на 90% отвечающими требованиям. Поэтому первое, что нужно будет сделать — «доразвить» качество этих людей до заветных 99-100%, без которых ваш процесс дает не совсем предсказуемый результат.
Слехка эти два предложения противоречат друг другу, Вам не кажеЦЦа? я вот однозначно склоняюсь к первому тезису :) Второй сформулировал бы так: чем ближе «доразвиваете» людей до 100%, тем больше бабла и нервов потратите (причом в экспотенциальной зависимости), но тем более предсказуемым будет результат процесса в результате.
Ни одна компания не может расти и быть успешной в средне- и долгосрочной перспективе, если сотрудники в ней работают по принципу «Сам додумай как — мы ж тебе за это деньги платим».
++ сколько угодно раз.

Добрый день. Под 100% имеется ввиду необходимый для работы процесса уровень владения навыком. «Хорошо» по шкале от «как попало» до «гениально». Если минимально необходимый уровень (который с точки зрения процесса составляет 100% т.к. все что выше использоваться все равно не будет т.к. процесс рассчитывается на людей, которых можно найти относительно безболезненно) обеспечить невозможно то имеет смысл переделать процесс. Иными словами — если в вашем процессе от программиста требуется знание особо узких областей астрофизики — проще создать в процессе две роли одну из которых займет программист без знаний астрофизики а вторую астрофизик без знаний программирования. Примерно как Форд сделал станки для одноруких чтобы поднять утилизацию и использовать именно то что люди могли делать лучше всего.

«Хорошо» по шкале от «как попало» до «гениально»... Если минимально необходимый уровень...
Мне нелегко представить, даже с т.з. процесса, что это 100%, но ок, я Вашу арифметику здесь понял, спасибо.
Форд сделал станки для одноруких чтобы поднять утилизацию и использовать именно то что люди могли делать лучше всего
так вот кто их придумал! :)
ru.wikipedia.org/wiki/Слот-машина

Хорошая статья, пасиб(:

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

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

Это второй шаг. Первый шаг — получить заинтересованность собственника предприятия в необходимости правильного внедрения процессного подхода. «Снизу» и «полноценно» оно не внедряется.

Картинка в тему. «Вы же все еще эффективная команда?»

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