Анна Федорова - Откровения модераторши

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

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

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

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

Эту историю мне рассказал ученик одной из С-Петербургских школ айкидо, в правдивости которого у меня нет оснований сомневаться.

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

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

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

Мне все больше кажется, что люди, которые осваивают профессию аналитика или говорят, что хотят ее освоить, считают самым главным нашим профессиональным качеством умение гнуть монеты. И я даже не знаю, что правильнее – попытаться объяснить или оставить в неведении.

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

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

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

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

На собеседованиях иногда приходится слышать вопрос: «Вы общительны?» И понимать, что общительность путают с коммуникативными навыками.

Успешному аналитику вовсе не требуется много чесать языком и получать искреннее удовольствие от этого процесса. Ему нужно уметь:

а) слушать;

б) направлять беседу (чтобы выполнить работу аналитика, а не психотерапевта для своего собеседника);

в) правильно формулировать вопросы;

г) интерпретировать ответы;

д) объяснять сложные вещи простым и понятным собеседнику языком.

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

Как я пишу техническое задание? Беру исходный материал и отрезаю все лишнее.

Требования, как правило, принимают в течение своей жизни следующие состояния:

1. понятны клиенту;

2. понятны мне;

3. понятны разработчику.

ТЗ появляется между вторым и третьим. То, что происходит между первым и вторым, называется анализ.

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

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