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

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

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

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

ISBN 978-5-4483-3074-2

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

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

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

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

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

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

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

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

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

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

Дзен-ИТизм

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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