analyst.by

Белорусское сообщество бизнес и системных аналитиков

Проектные деформации аналитика

Каждый аналитик, работая на долгоиграющем проекте или в одной предметной области длительное время, сталкивается с простой проблемой: привычка работать определённым образом и сложность перестройки под новые проекты. Мы привыкаем к команде, знаем назубок типажи заказчика в этой сфере, получаем одни и те же проблемы, к решению которых мы привыкли, привыкаем писать по одному стандарту документы, привыкаем к стилю изложения, организации процесса работы и коммуникаций команды и многому-многому другому. Это конечно же выгодно для компании и процесса и скорее всего характеризует вас как неплохого специалиста. Но появляется риск остаться на достигнутом уровне и скатиться до узкого профиля и неспособности переключиться на новый тип проекта. Уж так устроен человек, что привычки правят нашей жизнью. И будучи экспертом по аналитике в сфере, где ваша компания имеет собственный продукт, работая только с гос. заказчиками по каскадной методологии разработки ПО, мы навряд ли с той же легкостью вольемся в agile разработку для коммерческого заказчика.

 

Ограничения темы

Статья содержит информацию только о проектных деформациях и не имеет никаких связей с профессиональной деформацией.

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

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

 

Причины

  1. Участие в одном проекте в течение длительного времени (от 2-3 лет и выше).
  2. Участие только в одном направлении/предметной области/одном продукте.
  3. Один заказчик (группа компаний). Даже если вы делаете разного рода проекты, но для одного заказчика, вы все равно в зоне риска привыкнуть к договоренностям по построению коммуникаций и ходу проекта, стандартам написания документации.
  4. Работа в одной команде над всеми проектами. Не отношу эту причину сюда на 100%, но она тоже порой может инициировать такой процесс: вы привыкли к самоотверженным приветливым и участливым коллегам, а попали на проект, где каждый работает четко в отведенное время и минимизирует свою ответственность. Нужно уметь выстраивать отношения и работать с разными людьми.
  5. Написание требований посредством одного-двух инструментов. Например, в вашей компании используют только Word и требуют рисовать схемы только на языке UML в MS Visio.
  6. Участие только в проектах, где используют только одну методологию разработки программного обеспечения.
  7. Отсутствие возможности внедрения новых методов, инструментов, лучших практик, новшеств в проектную деятельность. Это может быть ограничением как компании, так и конкретных людей (проектные менеджеры, руководители отделов аналитики, владельцев продукта и т.д.).

 

С этим вы столкнетесь

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

 

Преодоление проблемы

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

Каковы возможные пути решения проблемы?

 

Методы решения проблемы:

  • Командный механизм.
  • Личностно-профессиональный механизм.

 

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

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

 

Предупреждение проблемы

Управленческий механизм. Давать людям разные проекты, учить новому. Тасовать команды. Приветствовать применения новых best practices. Должны быть люди ответственные за это – руководители отдела аналитики/ресурс-менеджеры компании.

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

 

Послесловие

Итак, чтобы проблема проектной деформации у вас не возникла, требуется её предупреждение. Для этого желательно совместить оба вышеуказанных механизма: управленческий и личностный.

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

Личностный механизм должен применяться самим сотрудником. Т.е. вы не должны «сидеть и ждать у моря погоды». Вы должны стараться получить и применить новые знания.

Если же так произошло, что у аналитика появилась проектная деформация, то также рекомендуется применять оба метода решения проблемы: командный и личностно-профессиональный.

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

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

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

 


16 Октября, 2015


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

        • Андрей, да, безусловно, специализация подразумевает и наработку определенных навыков, которые приходится использовать.
          Дополню про разницу:
          Специализация — это хорошо. Это позволит аналитику стать экспертом в одной предметной области (конечно же с соответствующими навыками и знаниями) и экономить деньги Компании. Но это совершенно не значит, что при переходе на новое направление у аналитика возникнут проблемы.
          Проектная деформация — это плохо. При переключении на новое направление или даже оставаясь на том же (например, сменился подход в разработке на гибкую методологию, заказчик с ГОС на коммерческого) у аналитика возникнут проблемы, с которыми он не в состоянии справится.

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

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

            • Андрей, почему компания не сможет пользоваться плюсами специализации (какие слова в моей статье натолкнули на такой вывод)?
              Аналитик может спокойно работать на одном направлении (сфере) и периодически привлекаться к проектам из другой сферы. Да и обучение тоже должно присутствовать.
              Также хочу отметить, что аналитик после 3 лет (на мой взгляд) работы на одном проекте\направлении должен пробовать новые направления и проекты, иначе как раз и будет проектная деформация.

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

    • Melissa,
      углубленные знания и навыки в узком поле деятельности в рамках работы аналитика, я называю экспертными знаниями специалиста. Чем больше таких знаний, тем качественнее человек может выступать в роли консультанта\эксперта.
      Возможно, Вы имели что-то иное ввиду, поэтому можем углубиться в данный вопрос.
       
      По поводу телекома: если Компания, работающая на ГОС заказчика, и Компания, работающая на рынке Японии, своим ПО решают схожие задачи (например, учет базовых станций и сбор данных с различного телекоммуникационного оборудования), то специализация у аналитиков разных компаний одна. Выбор методологии разработки прерогатива PM и Product Owner; работа с разными типажами клиента (коммерческий\гос) — задача опытного аналитика и т.п.
      Дополню касаемо телекома: если в одной компании аналитик занимается 90% времени системным анализом, а в другой аналитик заточен больше под бизнес анализ, тогда это скорее всего будут разные специализации.

  2. Выскажу своё мнение.
    С одной стороны, вроде бы всё складно написано. С другой стороны, а есть ли такая проблема?
    Начнем с определения. «…приводящая к плохой адаптации сотрудника…»
    1. Что такое «плохая адаптация»?
    2. В каких попугаях её измерить?
    3. Насколько (опять же в попугаях) она (адаптация) изменится после применения предложенных методов?
    Раздел «С этим вы столкнетесь»
    1. Чем вы можете подтвердить данные утверждения? «Это и так всем понятно» приравнивается к «мамой клянусь» ;)
    2. Является ли это именно какой-то деформацией? Или же это нормальные явления для любой смены деятельности?
    3. Все ли люди (какой процент) людей этому подвержен?
    Я к тому, что а) отсутствие скиллов (может, всё-таки, будем называть это навыками?) — это нормально (нельзя уметь всё) б) применять свои наработанные практики — нужно и можно.
    Вашу «проектную деформацию» нельзя диагностировать. Вы всегда будете оперировать какими-то внешними «кажущимися» факторами для того, чтобы «доказать» свой «диагноз». Например:
    1. «ах, он же работал 3 года на одном проекте, значит у него проектная деформация».
    2. «Так, у него каждые 2 месяца был новый проект с новыми заказчиками, технологиями и методами работы. Это не может быть проектная деформация.»
     
    Также я бы не вводил новые термины без очень сильной необходимости, особенно в таких тонких вещах как психология.

    • Денис, буду отвечать комментариями по каждому абзацу:
      [Denis S]: Выскажу своё мнение.
      С одной стороны, вроде бы всё складно написано. С другой стороны, а есть ли такая проблема?
      [Oleg D]: Лично я сталкивался с этой проблемой. Также исхожу из опыта знакомых коллег. Собственно поэтому и написал об этом. И речь именно о проектной деформации, а не специализации или недостатке опыта\знаний.
      [Denis S]: Начнем с определения. «…приводящая к плохой адаптации сотрудника…»
      1. Что такое «плохая адаптация»?
      2. В каких попугаях её измерить?
      3. Насколько (опять же в попугаях) она (адаптация) изменится после применения предложенных методов?
      [Oleg D]: слова «плохой\хороший» являются качественной оценкой, поэтому мерить в «попугаях» не получится. Если у аналитика возникли видимые трудности подключения к проекту, то думаю это и есть «плохая адаптация». Видимые трудности — это то, увеличит вам сроки реализации проекта или снизит качество проведенной аналитики по проекту.
      [Denis S]: Раздел «С этим вы столкнетесь»
      1. Чем вы можете подтвердить данные утверждения? «Это и так всем понятно» приравнивается к «мамой клянусь» ;)
      2. Является ли это именно какой-то деформацией? Или же это нормальные явления для любой смены деятельности?
      3. Все ли люди (какой процент) людей этому подвержен?
      [Oleg D]:
      1. Личным опытом, ощутил один раз на себе проектную деформацию. Также опытом знакомых ИТ-специалистов, с которыми обсуждал проблему, с которой столкнулся.
      Кроме слов, подтвердить иначе не могу, хотите верьте, хотите нет.
      2. Я написал о деформации. По поводу «нормальные явления для любой смены деятельности» — нужно смотреть по ситуации.
      3. По моему личному мнению, большинство аналитиков (со стажем работы >2 лет, менее опытных аналитиков не рассматриваем) не сталкивалось с этой проблемой. Сбором статистики не занимался и не планирую, поэтому количественно не могу Вам сказать.
      [Denis S]: Я к тому, что а) отсутствие скиллов (может, всё-таки, будем называть это навыками?) — это нормально (нельзя уметь всё) б) применять свои наработанные практики — нужно и можно.
      Вашу «проектную деформацию» нельзя диагностировать. Вы всегда будете оперировать какими-то внешними «кажущимися» факторами для того, чтобы «доказать» свой «диагноз». Например:
      [Oleg D]:
      1) Мне нравятся оба слова, поэтому не будем трогать «скиллы», раз его понимает и употребляет большое количество наших коллег.
      2) «Отсутствие скиллов — это нормально». Согласен, а если у специалиста достаточно скиллов, но он переносит на новый проект свой опыт, хотя это может оказаться не всегда уместно и специалист этого не понимает, т.к. привык так работать. То как предлагаете назвать данную проблему?
      3) «Вашу «проектную деформацию» нельзя диагностировать….» Откуда такая категоричность? С чего Вы взяли, что я «всегда будете оперировать какими-то внешними «кажущимися» факторами для того, чтобы «доказать» свой «диагноз»»? Жду ответ на данный вопрос :-) Мне кажется, чтобы так рассуждать нужно хотя бы знать лично автора статьи.
      [Denis S]: Также я бы не вводил новые термины без очень сильной необходимости, особенно в таких тонких вещах как психология.
      [Oleg D]: я психологии и не касался. Интересно откуда у вас такое мнение возникло? Проектная деформация не имеет отношения к психологии (в частности психической деятельности). Здесь речь о профессиональной деятельности.
       
      PS: спасибо на насыщенный комментарий, чужое мнение всегда интересно послушать :-)

      • Спасибо за развернутый комментарий.
        Кроме слов, подтвердить иначе не могу, хотите верьте, хотите нет.

        [Denis S.] Я охотно верю, что вы испытали трудности при переходе. Но у вас в разделе (в самой статье) про это написано так, что создается впечатление — с этим столкнется каждый при любом изменении. В это я не верю.
        он переносит на новый проект свой опыт, хотя это может оказаться не всегда уместно и специалист этого не понимает, т.к. привык так работать. То как предлагаете назвать данную проблему?

        [Denis S.] Нет в этом проблемы. Это нормальная ситуация — когда вы попадаете в любые новые условия, вам надо принимать какие-то решения. Мозг не может работать «с чистого листа», поэтому подсовывает вам те решения, которые хорошо работали в прошлом. И это, на мой взгляд, абсолютно нормально. Вы пробуете, если не подошло — пробуете что-то другое. И естественно то, что разным людям надо разное время на то, чтобы отказаться от старого или взять что-то новое. Кстати, от контекста (конкретной ситуации) это тоже зависит.
        Именно поэтому я категорически не согласен с вашим изначальным утверждением (в статье) про «применять свои наработанные практики там, где это сделать нельзя.» Всё можно, только надо не забывать думать и анализировать.
        Откуда такая категоричность? С чего Вы взяли, что я «всегда будете оперировать какими-то внешними «кажущимися» факторами для того, чтобы «доказать» свой «диагноз»»? Жду ответ на данный вопрос :-) Мне кажется, чтобы так рассуждать нужно хотя бы знать лично автора статьи.

        [Denis S.] Не принимайте так близко к сердцу. У меня не было цели уязвить лично вас. Замените «Вы» в моем комментарии на «Мы» или «Те, кто будет заниматься выявлением проектных деформаций».
        Смысл моего комментария в том, что доказательства проектной деформации у конкретного человека, по моему мнению, всегда будут «видимыми/псевдо».
        И да, я считаю, что нет проектной деформации. И не надо вводить новые ненужные понятия. Просто любому человеку нужно время на адаптацию. Приведу такой пример. Например, вы переехали в новый город и пока что плохо ориентируетесь, куда ехать/идти. Но мы же не называем это «деформацией от постоянного проживания в одном месте».  И достаточно неразумно призывать менять место жительства раз в несколько лет, чтобы развивать чувство пространства.
        Также и с проектной деятельностью. Нельзя знать и уметь всё. Есть узкая специализация, есть широкая специализация. У каждой специализации есть свои плюсы и минусы, которые надо понимать и пользоваться ими. При этом не забывать, что надо оставаться гибким и «аналитическим».
        Спасибо за внимание, я свою точку зрения высказал.
         
        з.ы. Про психологию немного не понял. Термин не может существовать сам по себе. А науки «профессиональная деятельность» не существует. И мне кажется, что это в данном случае ближе всего к какому-нибудь из направлений психологии (например, социальной).

Добавить комментарий
Также Вы можете войти используя: Facebook Google