Текст книги "Откровения модераторши"

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

© Анна Федорова, 2017

ISBN 978-5-4483-3074-2

Создано в интеллектуальной издательской системе Ridero

Про этот сборник

В 2008—2012 годах я вела электронный журнал по адресу moderatorsha.ru.

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

Фактическими спонсорами издания являются все мои бывшие работодатели, без участия которых мне бы не удавалось спокойно и расслабленно получать новые впечатления в промежутках между офисным существованием. Поэтому выражаю особую признательность Леше Никитину из Bank’s Soft Systems, Диме Завалишину из Digital Zone и Serpent Angel из Smart Processing, за то, что вы еще принимаете на работу таких психопатов, как я.

Анна Федорова

https://www.linkedin.com/in/mswirt

Про профессию

Заказчик знает, чего хочет

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

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

Таким образом, если заказчик не знает, чего хочет, то он хочет, чтобы его оставили в покое.

Дзен-ИТизм

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

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

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

Девушка по вызову

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

Иногда вспоминаю свою бывшую коллегу по информагентству, которая входила в приемную губернатора со словами: «Здравствуйте! Я к вождю.» И свое первое посещение областной администрации, когда я всю пресс-конференцию просидела с неработающим диктофоном, не подозревая о разряженной батарее, а потом восстанавливала по памяти содержание беседы.

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

– Вы куда? – спросила озадаченная озабоченную.

– Я на рынок. А вы?..

– А я с рынка, – ответила озадаченная.

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

Но, хотя в целом у меня положительные впечатления, иногда всерьез задаюсь вопросом, кто же я на самом деле – руководитель проекта или девушка по вызову…

Изменение требований – катастрофа или признак жизни?

Если оно зелененькое или шевелится – значит, живое. Помните такой факт из общей биологии?

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

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

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

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

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

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

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

Знание и понимание

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

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

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

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

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

Продажа консалтинга

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

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

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

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

Общительность

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

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

а) слушать;

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

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

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

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

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

Мастер-класс

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

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

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

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

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

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

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

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

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

Готовые болванки начинаем обтачивать напильником. Добиваемся непротиворечивости формулировок и ситуации, когда каждое требование упоминается в ТЗ только один раз.

Когда все лишнее отпилили, можно заняться дизайном. Я строю ТЗ следующим образом: сначала очень сжатое описание всех функций, а потом по разделу на каждую группу родственных функций, где они описываются детально. Важно найти базовый принцип, на основании которого устанавливается родство. Скажем, если некая система печатает отчеты в файлы MS Excel, получает данные из системы 1С и отправляет смс-сообщения, то все три функции будут являться частными случаями обмена с внешними системами. Объединяет их как минимум необходимость шлюза и согласованности форматов между обменивающимися системами. Аналогично все требования к отображаемым меню и экранным формам объединяются в раздел, где описываются требования к дизайну.

Профессионал

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

Как заказчику понять аналитика

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

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

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

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

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

Преподавательство

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

Той, которую преподать труднее.

Структурный и объектный

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

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

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

Дистанционный консалтинг

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