В институте астрологии нас познакомили с методом, позволяющим на основе некоторых исходных данных построить модель мотивации конкретного человека. В ней используются семь движущих сил, пять из которых условно можно назвать “личными”, и две – “социальными”. Каждая сила может быть самодостаточной (являться мотивом для самой себя), а может вызываться к действию другой силой. Графически второй случай можно обозначить как X -> Y, где Y является мотивом проявления X. Из комбинаций этих двух случаев “собирается” вся модель.

После того, как модель для конкретного человека построена, ее можно оценить по двум критериям:

1. Цельность или раздробленность.
Цельная мотивация – такая, где все семь сил связаны между собой. Раздробленная мотивация состоит из несвязанных между собой фрагментов. Люди, обладающие цельной мотивацией, на мой взгляд, наиболее понятны самим себе. Они могут быть противоречивы внешне, но в них есть внутренняя гармония. У людей с раздробленной мотивацией зачастую есть несколько одинаково сильно привлекательных жизненных тем, между которыми они либо переключаются, либо пытаются развивать их все параллельно. В этом случае возможен эффект “растаскивания” в разные стороны.

Персоны с цельной мотивацией:
Айртон Сенна – лучший гонщик в истории Формулы 1
Тина Тернер – певица, актриса и танцовщица
Джон Бэкус – разработчик языка программирования ФОРТРАН

Персоны с раздробленной мотивацией:
Мартин Скорсезе – кинорежиссер
Роберт Плант – солист Led Zeppelin
Шри Ауробиндо – основоположник Интегральной йоги

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

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

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

И вот так я тоже иногда развлекаюсь… :)

Я в профессию попала случайно – а тогда, когда узнала о существовании такой отрасли как ИТ, меньше всего представляла свою жизнь связанной с ней. Но впечатление осталось.

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

Там работали большие и красивые мужчины. Они смотрели на меня и улыбались :)
Сейчас они улыбаются вокруг меня, и хотя с тех пор я немного выросла, а они стали казаться поменьше, чем в детстве, иногда я узнаю в их глазах то выражение. И думаю: “я дома…” :)

А пора бы уже переехать – внутренний голос.

ЭТО началось традиционно – с технической поддержки, в ИТ-службе банка. С тех пор у меня с банками вполне устойчивые и нежные отношения :) Наследственность, что поделаешь…

Потом у меня в трудовой книжке появилась запись “программист” (она и сейчас там есть), хотя чистым программированием (на PHP) я почти не занималась. Фирма развалилась через пару месяцев после моего увольнения.

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

Дальше был веб-мастеринг “с нуля”, то есть от верстки и до поисковой оптимизации. Так я познакомилась со своим хостером – у нас тоже по-прежнему очень нежные отношения :) Кстати говоря, это был еще и опыт фриланса, который позволил мне, появляясь на работе два раза в месяц, зарабатывать столько же, сколько подруга на вредном производстве с ночными сменами.

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

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

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

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

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

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

Согласование терминологии
В любой отрасли есть своя профессиональная терминология (речь в данном случае идет не о жаргоне – см. выше). Хорошая практика – в начале беседы определить основные понятия, которыми вы будете оперировать. То есть, объяснить, что под ними подразумевается именно в вашем бизнесе или сфере деятельности. В дальнейшем, когда вы будете использовать эти понятия, аналитику сразу станет ясно, о чем идет речь. Это необходимо по той причине, что в разных отраслях одними и теми же словами могут называть разные вещи, вплоть до использования внутренней терминологии в масштабах одного предприятия. Заказчик не всегда сталкивается с этим, так как работает только в своей сфере, но у аналитика, имеющего дело со многими заказчиками из разных отраслей, часто возникают вопросы в области терминологии.

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

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

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

Теперь я расскажу, как гнуть монеты :)

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

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

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

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

Успехов вам! :)