BoatmansHome: ПрофилиКомпетенцииСпециалиста ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Нулевой навык


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


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


Проблемы с результатами, такие как низкое качество или сорванные сроки, могут возникать по разным причинам:
1. Недостаточная квалификация исполнителей;
2. Что-то в построении процесса,
– на уровне взаимодействия ролей,
– на уровне внутриролевых операций;
3. Недостаточно вложенных трудовых ресурсов нужных ролей (человеко-временем и машинным временем);
4. Нет нужных инструментов или они плохого качества;
5. Необходимые входы для работы не предоставлены или они недостаточного качества;
6. Управляющие сигналы мешают получить нужный результат (например, неадекватные планы по срокам или неясное описание требуемых результатов, меняющиеся требования или противоречивые указания по рабочему процессу).


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


Люди чаще всего приходят учиться пунктам 1 и 2 в то время, как у них на работе наибольшие резервы оптимизации лежат в пунктах 3–6. Хотя и по пунктам 1,2 обычно есть, что улучшить.
В таких ситуациях мы часто приходим к позиции, подобной «это великолепные практики анализа, но у нас нет времени, чтобы их использовать». А в ответ на рассуждение: «если вам не выделяют ресурсы на повышение качества результата, делайте плохо или мало и спите спокойно», мы встечаем глухое недовольство. И люди идут дальше искать серебряную пулю.


Таким образом первымы тренируемыми умениями для проектного специалиста должны были бы быть:
1. умение прояснять постановку задачи на пакет работ (область ответственности) и записывать проектное задание (должностную инструкцию) не для галочки, а по существу;
2. планировать работу так, чтобы образовывалось поле для «торговли», выставлять ресусный запрос, запрос полномочий и требования к обеспечению работы;
3. конструктивно проводить сессии «торговли», уточняя окончательные параметры проектного треугольника (как будем делать: качественно или дешево);
4. записывать окончательное письменное проектное задание;
5. с вероятностью >50% выполнять обязательства по объему, срокам, качеству и стоимости;
6. встречая ситуации, с которыми не могут справиться, конструктивно эскалировать и принимать конструктивное участие в решении проблем в рамках своих полномочий.


Это вкратце.


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

А вообще есть 3 условных уровня компетенции проектного специалиста:
1. идешь туда, куда пошлют, делаешь то, что скажут;
2. способен, получив ответы о том, какие артефакты, кому и для чего надо принести, спланировать работу и выставить запрос на потребные ресурсы и другое обеспечение работы, по дороге выполнив торговлю о форме проектного треугольника (как хотим: быстрее, дешевле или качественнее?) и зафиксировав на бумаге проектное задание, а потом с вероятностью между 50 и 100% удержаться в обязательствах (то, что перечислено в предыдущем списке);
3. способен, войдя в ядро команды, принять участие в выработке плана проекта и оценке его стоимости с последующей реализацией и плана и стоимости, но главное целей проекта, как в составе команды, так и с участием рук подчиненных.


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


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


Если расхождений нет, все ок. А если, например, зарплата от уровня 2, начальство грузит на уровень 3, а полномочия как на уровне 1, надо что-то делать.


Теперь что делать.


В моей практике консультаций по подобным темам в половине случаев работает самый простой совет: поймите и структурируйте, что от вас хотят, что хотите вы (чего не хватает для счастья) и идите мирно поговорите об этом. Люди (и начальство тоже) не умеют читать мысли, но это полбеды, беда в том, что их раздражает неструктурированное мычание, когда не ясно, что делать, но ясно, что есть проблема и большое недовольство.
В половине случаев никто не собирался зажимать ресурсы или полномочия, во второй придется вступить в торговлю. И лишь в малом проценте случаев кто-то осознанно хочет сэкономить бюджет или имеет другие причины напускать туман.
Дальше вступают ценности компании:
– Кто-то любит самоорганизацию и не любит эскалацию и говорит: «все, что тебе нужно от смежников – возьми сам», то есть иди и убеди или отбери.
– Кто-то спокойно дает то, что обосновано и аргументировано.


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


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


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


Значит ли это, что мы, понимая сказанное выше, можем перестать работать над своей технической квалификацией и начать работать над навыками переговоров?
Давайте смотреть.
Чтобы понять, в чем проблема, нужны как технические навыки, так и общий взгляд на процесс с пониманием взаимосвязи его частей.
Чтобы донести свое предложение или эскалацию и успешно торговаться, нужны уверенность в своих оценках и соответствующие навыки коммуникации.
Все хорошо в меру.
– Глубоко компетентный профессионал, не способный убедить команду в необходимости изменений процесса или перераспределения вложений ресурсов, становится конфликтным желчным социопатом и мизантропом.
– Прекрасный коммуникатор, не обладающий глубокой экспертизой и пониманием картинки, будет регулярно проваливать работу или подкладывать коллегам свинью, что в итоге испортит ему репутацию и карьерные перспективы.
– Недостаток уверенности в своих навыках и/или смелости в переговорах обрекает на переработки (вплоть до вреда здоровью) и/или вечное «а я говорил».


Существуют частые ловушки, которые мешают людям добиться сбалансированного взгляда.
1. комплекс самозванца;
2. перфекционизм;
3. локальная оптимизация;
4. неявные умолчания по целям, ценностям и обстоятельствам;
5. неясное разделение полномочий между ролями, и с начальством.


По первым двум пунктам я писал здесь: http://darkboatman.livejournal.com/11650.html


По вторым двум (3,4) приведу пример.
Программист жалуется, что код приходится часто переписывать, так как требования меняются.
Проблемы проекта можно искать много где (в такой ситуации), но основной ответ именно программисту такой: «если переписывание кода оплачено – то это не твоя проблема».
При более глубоком копании тут может всплыть, что люди хоте ли бы «пить кофе» вместо переделок, раз заказчик выделил бюджет такого роазмера, или забрать сэкономленное время в виде премии, или опасаются, что внесенные в код костыли и дефекты в будущем уменьшат производительность при развитии системы. Однако, все три предположения можно обсуждать «словами через рот» и явно записывать, до чего в итоге договорились.
Иногда не стоит оптимизировать свою личную продуктивность выраженную в человекочасах, затраченных на одну функцию, или любые другие локальные показатели процесса. Возможно такие переделки полезны или более дешевы для проекта, возможно заказчик хочет рассмотреть варианты, возможно, действительно ошиблись аналитики, но их замена нанесет проекту еще больший ущерб, чем их работа.


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


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


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


Решение в том, что проектный специалист должен сам очерчивать и оговаривать границы своей ответственности и полномочий, а так же все 6 пунктов, от которых зависит результат, из первого списка данной заметки.
А для этого необходимо
– точно различать между «я плохой специалист» и «на эту работу отведено недостаточно времени/недостает входов»;
– нести только свою ответственность и отдавать чужую;
– отстаивать свою позицию и вовремя (а главное мирно и конструктивно) обращаться к людям для обсуждения проблем.


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


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]