×Закрыть

Как неправильная роль в проекте приводит к катастрофам

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

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

Инициация процесса

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

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

На уровне ощущений все понимают разницу между ролью и профессией. Это примерно как «делать» и «уметь делать». Профессии оставим в стороне, так как они лишь косвенно относятся к теме статьи. Перейдем к ролям.

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

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

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

Создатели и исполнители

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

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

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

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

Поэтому с точки зрения «людей и процессов», людей можно разделить на две категории:
— Создатели процессов;
— Исполнители процессов.

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

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

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

Пример зрелого подхода

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

На британском рынке соков и смузи есть ключевой игрок Innocent. Офис этой компании выглядит так:

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

В ожидании вдохновения сотрудники могут кататься в таких вот креслах:

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

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

Что важно в этом примере:
— Цель сотрудников Innocent — создавать новые продукты;
— Цель завода — производить эти продукты.

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

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

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

Ищем исполнителя

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

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

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

Однако этот подход содержит в себе риски, так как предъявляет два противоречивых требования к специалисту: творчество (чтобы «доработать» процесс) и исполнительность.

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

Чтобы создать хороший процесс, нужно определиться, что же именно вам нужно. Человек не может быть хорош во всем. Также и компания — она может иметь одну «фишку», в редких исключениях две. Например, две их у Apple — дизайн и инновации (за первое отвечал Джобс, за второе Возняк). И не получится создать процесс без понимания того, в чем именно компания хочет стать лучшей и что в действительности отличает ее от конкурентов.

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

LinkedIn

23 комментария

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

Зачастую цель можно достичь более чем одним способом. Порой кажется что это не так. Что способ только один. Причина этого — ограниченность. Ограниченность взглядов, знаний, опыта, кругозора. Да, IT относительно молодая индустрия. Но далеко не всегда изобретение «велосипеда» оправдано. В этом мире очень мало принципиально нового. По большей части все существующее собирается из раза в раз из тех же самых кубиков поэтому понимание того как все работает сводится к способности мыслить абстрактно, находить аналогии и строить модели. Говоря о процессах, создателях и исполнителях я хотел обратить внимание на то как это делается в зрелых индустриях. И учитывая вышесказанное — предсказуемость есть наименее рискованный способ достижения цели. Учитывая существование «Черного лебедя» — все риски просчитать невозможно. Что возможно — исключить очевидную «лажу» в стиле вот мы собрали с улицы 4 программиста 1 тестировщика и 1 ба и сказали что отныне это SCRUM команда, с первого дня работающая на пике производительности. Или послали менеджера возрастом 20-23 года управлять проектом численностью 30-50 человек, разбросанных по всему земному шару. Делая так повышается предсказуемость провала а не успеха.

По поводу как понять к чему я более склонен — прислушайтесь к себе. Что говорит внутренний голос? Если он говорит «отлично. я знаю что я пишу код/тестирую/делаю анализ и т.п. с 9 до 18:00 и знаю что мне гарантированно за это заплатят — меня это устраивает т.к. больше всего в жизни я люблю петь в 20:00 в церковном хоре» — значит исполнитель. Нужно также учитывать что в зависимости от контекста человек может менять свои предпочтения. Например создавать процессы — не мое а создавать музыкальные произведения или картины — мое. Мы говорим лишь о контексте производства программного обеспечения на заказ. И раз уж это тот контекст, который вас кормит — именно в этом контексте и стоит понять кем вы являетесь т.к. это покажет на чем фокусироваться в дальнейшем развитии.

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

Сори, Вы доказываете ИМХО настолько очевидные вещи ... ну я лично имею вредную привычку сразу искать — а где тут с меня стебуЦЦа :)

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

следующая статья будет о компетенциях
заинтриговали, спасибо :8)

Я и сам когда то пытался сидеть на нескольких стульях сразу. ...как решали эту незадачу? вот если тянет на несколько профессий?

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

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

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

Напомню твой пост:

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

Возможно я запутал тебя словосочетанием «предположить риски» и показалось, что я себе противоречить начал (приношу извинения). В моем высказывании имелось ввиду лишь то, что предполагать — не значит хорошо, предполагать — это угадывать, по сути (будет не будет). А риски просчитываются (повторюсь, пусть и с погрешностью, но просчет рисков всяко лучше предсказаний). Ты на живом примере попробуй: Можно создать машину и провести просчет рисков (не будем углубляться в тонкости), но в целом получить какую-то оценку, например — подойдет для среднего класса, не дорога в обслуживании, прослужит 10 лет. Или вариант с предсказанием (включаем Вангу) — вроде будет продаваться, наверно купят все, хз сколько прослужит. Мы же не в каменном веке живем, чтоб на альтруизме во что-то вкладывать и надеяться на предсказания, которые не подкреплены цифрами.
З.Ы. я никого ни к чему не призываю, и честно, считаю, что каждый должен заниматься своим делом, и толпы молодых должны заниматься своим делом (ну так было бы правильно).

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

Ты меня конечно извини, но я и моя компания так не работает, тут я не советчик. В начале проекта закладывается время на ресерч, во время ресерча выявляется методология реализации проекта. После пишется таймлайн, в каждую итерацию закладывается время риска ( в среднем это +30 — 40%) и далее не может быть никаких отклонений. А риск здесь как раз то, что ты правильно назвал «всплывшие внезапно» — рассчитывается он компанией (или ответственным лицом) и да, это обязательно ложиться на того, кто занимался расчетом рисков, а не на Заказчика. (на правах рекламы=/). Потому и этому «ответственному лицу» лучше просчитать риски заранее, а не «тыкать пальцем в небо» и предсказывать «влетит в deadline проект или нет». Что в очередной раз подтверждает, что лучше просчитывать заранее что-то и иметь уже хоть какое-то понимание того, что тебя ожидает, чем быть предсказателем.
Дабы и дальше не продолжать флудить в чужой теме, предлагаю или закончить, или перенестись в лс, ибо мнение каждого имеет право на жизнь.

кагбе это сказать культурно ... я бы рекомендовал все-таки слушать такого сорта «песни Адриано Челентано» в оригинале, который называеЦЦо: И.Адизес, «Развитие лидеров...» :) сопсно можно и любую другую его книгу :). Быстро узнаЕшь, что производителя и предпринимателя взаимодополняют еще администратор (это касательно в т.ч. упоминаний про дисциплину) и интегратор, что не бывает «чистых» типов и не бывает людей, одинаково успешных во всем (т.е. и это деление достаточно условное) ... кароче, кому интересно — читайте оригинал ;)

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

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

создателя и исполтинеля. Тогда
исполнителя*

Первая часть по делу а вот дальше пошла ерунда. Цимес в чём: процесс создаётся для удобства для чисто технических нужд в т.ч. и человека креативного чтобы человеку креативному двигаться в креативных направлениях не отвлекаясь на детали «рутинно-процессуальные». Если же повернуть цель создания процесса якобы «креативные люди создают рутину для людей некреативных» то выходит полная ерунда которая правда уже намного ближе к тому как это и реализуется на самом деле. Особенно в отечественных условиях в виду сильной «пионерскости» суть проявляющейся в «креативности велосипедов» исходя из крайней молодости и образования без исторического фундамента всей индустрии.

— Криэйтором это в смысле творцом?
— Криэйтором, Вован, криэйтором. Творцы мне на**й не нужны.
© Пелевин

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

+1 за дисциплину, а то получаеться типа: «Я (дизнр.,мендж,прогр.), я креативен.. и я буду делать работу „креативно“, когда захочу» :D

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

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

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