Аналитик · Организация работ · Развитие

Как растить и развивать аналитиков в своих рядах?

Автор статьи: Илья Корнипаев, автор книги «Требования для программного обеспечения: рекомендации по сбору и документированию», которую вы можете найти в разделе Книги по управлению требованиями


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

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

Как это сделать? Хороший вопрос. Постараюсь рассказать вам о том, как это делали мои коллеги и я. О том, что действительно работает и действительно помогает.

Сразу оговорюсь. Здесь я позволю себе не останавливаться подробно на том, что же такое хороший аналитик (как бы эта роль у вас в организации не называлась).  Об этом я говорю на каждом своем тренинге, на каждом семинаре. Об этом великолепно написал Борис Шалаин в своей статье «Бизнес-аналитик – свой человек за линией фронта» (2).

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

Дело в том, что сам факт того, что в вашей компании кто-то подумал о профессиональном росте сотрудников, всегда дает положительный эффект.

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

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

Самое главное понять, что развитие аналитиков в рамках компании требует затрат рабочего времени. Если вы не выделяете рабочее время на профессиональный рост, то вы вряд ли можете его ожидать. В моей практике удавалось согласовывать с руководством выделение на постоянной основе до 20% рабочего времени на внутреннюю аналитическую кухню, часть этого времени шла на обучение и обмен знаниями.

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

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

Если меня привести в любую команду, где больше одного аналитика пишут проектную документацию (любую: требования, ТЗ, спецификации), и спросить, как улучшить работу аналитиков, первое что мне придет в голову, это предложить обязательную 100%-ую проверку работы одного аналитика другим. Т.е. как говорят наши коллеги за рубежом – peer review.

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

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

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

Мы очень быстро поняли, что для того чтобы процедура peer review работала эффективно необходимо уделить внимание следующим важным аспектам:

  1. Peer review должно быть спланировано. У нас были в разное время недельные и двухнедельные циклы планирования задач. В начале каждого цикла планирования мы встречались аналитической командой, и каждый аналитик кратко описывал каждую новую назначенную ему задачу. Один из аналитиков добровольно вызывался ее проверять. Если доброволец не находился, его назначали, при этом старались не назначать аналитиков в пару, если у них «не складывались отношения».  В результате для всех новых задач определялись проверяющие (один или более для каждой задачи). Проверяющим планировалось время на эту работу, из 20% временного запаса, о котором я упоминал выше. Проведение peer review за счет личного времени одного или обоих аналитиков – плохая идея.
  2. Культура peer review. Первое, о чем нужно попросить аналитиков, до того как начать пробовать применить peer review, это проявлять уважение друг к другу. Каждый из них должен попытаться понять, почему его коллега написал то, что он написал, и зачем он это сделал. Если есть много ошибок – почему? Если проверяющий не нашел ни одной – может он вообще ничего не понимает в документе? И тот и другой случай, это повод встретиться и пообщаться. Любые замечания, устные, а тем более письменные должны быть сформулированы в вежливой форме. Замечания, сформулированные в виде вежливого вопроса или предложения изменения формулировки, обычно воспринимаются благожелательней, и работа проходит конструктивнее и быстрее. Лучше провести пару показательных peer review, задав тем самым правильный тон.

Иногда мы доводили peer review до того, что занимались парным анализом (pair analysis), взяв за основу правила парного программирования у Кента Бека (3). С точки зрения развития аналитиков это дает то же самое, что и review, но, на мой взгляд, это значительно сильнее с точки зрения воспитания командного духа.

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

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

  1. Обзорные доклады. Периодически мы собирались на внутренние мини-конференции, на которых аналитики делали доклады, чтобы поделиться знаниями. Эти встречи планировались обычно на 4 часа. Доклады были посвящены методологиям разработки, методам и нотациям моделирования, системам качества и другим вопросам. Главная цель каждого доклада заключалась в том, чтобы доступно рассказать о рассматриваемом предмете, и определиться можем ли мы что-то для себя почерпнуть практически из этого или нет. В качестве тем докладов были особенно популярны различные buzz words, причем не только из мира аналитики, например – CMM(I), XP, Agile, 6 Sigma, SOA, BPML и т.п.
  2. Внутренние курсы. Мы делали внутренний курс по управлению требованиями и написанию проектной документации применительно к действующему процессу и шаблонам документов и назвали его Analysis Essentials. Также аналитики делали курсы по предметной области для специалистов наших поставщиков. Курсы по предметной области записывались на видео и затем широко и неоднократно использовались.
  3. Обмен информацией. Если кому-то попадалась интересная статья, он присылал ее всем аналитикам. Если кто-то привозил что-то с курсов – это распространялось среди аналитиков. Все что можно было получить в электронном виде лежало в библиотеке, которая была доступна всем аналитикам.

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

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

Продолжая разговор о роли руководителя и наставника в процессе становления и развития аналитиков внутри компании нужно сказать самое, на мой взгляд, главное. Самое лучшее, а порой и единственное средство которое есть у руководителя для стимулирования аналитика, как в прочем и любого другого специалиста, это его (руководителя) собственное время! Если вы руководитель, как часто вы можете повысить человеку заработную плату? Повысить в должности? Дать более интересную работу? Думаю не очень часто. Точно не каждый день. А внимание сотруднику вы можете уделить буквально каждый день. От того как вы это будете делать зависит, во многом, то как будет человек работать, в том числе расти и развиваться. Peopleware (4) вам в помощь! Аминь.

Ссылки:

  1. Илья Корнипаев. «Актуальные проблемы управления требованиями»
  2. Борис Шалаин. «Бизнес-аналитик – свой человек за линией фронта»
  3. Кент Бек. Экстремальное программирование. Библиотека программиста. — СПб: Питер, 2002. — 224 с.: ил.
  4. Ларри Константайн. Человеческий фактор в программировании. — СПб: Символ-Плюс, 2004. — 384 с.,  ил.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *