Союз аналитика с разработчиком – вполне самодостаточная система (я имела возможность убедиться в этом даже на личном опыте :)). Такой себе инь-ян.

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

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

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

С другой стороны, нужно следить за тем, чтобы иньские мотивы не уничтожили фонтанирующее янское вдохновение и творческое начало – ибо без них, родимых, не будет на этом свете вообще ничего :) Ну вы поняли, о чем я…

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

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

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

На форуме программистов я когда-то открыла дискуссию на эту тему.
Основной вопрос звучал так: “Программист – творческая профессия?“

Ответы распределились следующим образом:

да – 68%
зависит от самомнения программиста – 24%
нет – 8%

всего ответивших: 63

А что вы думаете по этому поводу?…

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

Итак, я была специалистом, претендовавшим на вакансии аналитика в сфере коммерческой разработки программных продуктов и банковской сфере, с опытом работы по специальности более 3 лет, общим опытом работы в ИТ более 7 лет, в Санкт-Петербурге. Мои зарплатные ожидания находились около средней отметки для подходящих на тот момент вакансий.

Всего я посетила за тот период до двух десятков собеседований как с прямыми работодателями, так и в кадровых агентствах, по более чем десяти вакансиям. И вот на какие факторы обращала внимание.

Профессиональные
1. Непосредственные обязанности.
2. Непосредственный руководитель.
3. Подразделение, в котором предстоит работать, и направление его деятельности. Направления взаимодействия.
4. Организация процесса, степень его формализованности, использование специальных инструментов.

Официальные
1. Форма трудоустройства. Продолжительность испытательного срока.
2. Форма, размер и периодичность заработной платы.
3. Командировки: длительность, периодичность, дальность.

Организационные
1. Рабочий день, внутренний распорядок.
2. Транспортная доступность.
3. Как решается вопрос питания.

Общечеловеческие
1. Как общаются представители работодателя со мной.
2. Как они общаются между собой.
3. Как рассказывают о коллегах, о клиентах, о работе в других подразделениях.
4. Впечатление от обстановки и атмосферы в компании.

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

А общая статистика за два календарных года (2008-2009) получилась приблизительно вот такой:

25% от всех компаний, просматривавших резюме, приглашают на собеседования;
80-85% от всех компаний, пригласивших на собеседования, его проводят (остальные 15-20% приходятся на случаи, когда или мне не подошла вакансия, или я по каким-то причинам так и не дошла до компании);
12% от всех компаний, в которых я была на собеседовании, стали в результате местом моей работы.

То есть на стадии просмотра резюме мои шансы работать в компании оказались приблизительно 1/40, а на стадии приглашения на собеседование 1/10.

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

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

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

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

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

Мне настойчиво кажется, что люди, которые сильно боятся, что у них что-нибудь украдут (например – их “уникальные” авторские методики), сами что-то у кого-то украли :) И может быть даже боятся, что обворованные признают в их “уникальном” свое.

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

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

Недавно я стала участником этой социальной сети (как будто мне других мало! :))

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

Что происходило предыдущие несколько лет?… Если вы были соискателем, которому никак не найти подходящую работу, то могли купить книгу вроде “Секреты успешного трудоустройства”, пройти пару-тройку тренингов по самопрезентации и научиться вести переговоры с работодателем. Объем рынка подобных услуг и литературы достаточно велик, вырос он довольно быстро, а раз так, надо полагать, что прибыль от этого оправдывала вложения.
Только стратегический момент был упущен.

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

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

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

На собеседованиях меня больше всего удивлял вопрос: “Вас не пугает то, что заказчики часто сами не знают, чего хотят?”

Это все равно, что, нанимая на работу уборщика, спрашивать у него: “Вас не пугает то, что туалеты грязные?”

В последнем месте моего наемного труда на первый вопрос я ответила, что это нормальная ситуация, и, если заказчик может ясно выразить, чего хочет – то это большая удача.
В моей практике из шести крупных проектов (работала я с кредитными организациями) такой случай был всего один. Заказчик прислал такую постановку, что лично мне было стыдно за смету проекта, в которой значился пункт “Анализ”. К слову, это был белорусский банк.

В общем, мои собеседники – зампред правления и ИТ-директор – от такого ответа хорошо посмеялись и на работу меня приняли.

Хэмингуэй сказал: “Человеку требуется два года, чтобы научиться говорить. И еще пятьдесят лет, чтобы научиться слушать других.“

Месяц назад я была участницей следующего эпизода.

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

Что примечательно:
1. Мы не разговаривали.
То есть, никто не говорил: “Ребята, сейчас включат музыку, и мы будем стучать. Ты, Вася, стучи вот так, а ты, Петя – вот так.” Т.е. все общение происходило исключительно невербальными средствами.
2. Партии не повторялись.
Конечно, мы импровизировали, меняли руки, переходили с сильной доли на слабую и наоборот, отстукивали пальцами или ладонью, но в каждый момент времени все пятеро стучали по-разному.
3. Участвовали все.
Вся компания, которая была за столом, довольно быстро включилась в процесс.

Почему в ИТ нельзя получить такой результат?

Хотите верьте, хотите нет, но наше мышление и подход к делу в своей отрасли не научные.
Они мифологические.

Чтобы убедиться в этом, сравните результаты отчетов, приводимых в книге К.Вигерса “Разработка требований к программному обеспечению” за 1993, 1995, 1997 годы, с вот этой статьей (после недолгих поисков, уверена, найдется и сам отчет – за 2008 год). Разительных отличий я лично не наблюдаю. При том, что за это время вышла не одна хорошая книга по анализу и проектированию, уверена, еще больше – по управлению проектами, активно развивался стандарт UML, появлялись новые инструменты для облегчения разработки (средства моделирования, автоматизации тестирования, контроля версий, управления требованиями, автоматизации обработки заявок служб сопровождения, управления проектами и т.д.).

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

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

А мы продолжаем их совершать.

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

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

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

Дайте человеку десять картинок и попросите разделить их на две кучки.
Один разделит. Другой спросит: “По какому принципу?”
В аналитики берите второго.

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

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

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

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

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

Этот пленительный процесс создания из хаоса чего-то стройного и красивого.

На входе у нас некоторое количество неформализованной, разрозненной, слабо связанной информации. Вся она различной степени детализации, что-то лишнее, чего-то не хватает, нет единой позиции, с которой она рассматривается.

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

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

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

Успешному аналитику вовсе не требуется много чесать языком и получать искреннее удовольствие от этого процесса. Ему нужно уметь:
а) слушать;
б) направлять беседу (чтобы выполнить работу аналитика, а не психотерапевта для своего собеседника);
в) правильно формулировать вопросы;
г) интерпретировать ответы;
д) объяснять сложные вещи простым и понятным собеседнику языком.

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

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

С другой стороны, сфера достаточно узкая.

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

Посижу еще перед камнем :)

Вспоминается диалог где-то трехлетней давности:
- Вот Вася сказал, что надо сделать то-то и то-то…
- А кто такой Вася?…

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

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

И ведь я не против сделать это через аргументированное обсуждение. Я против только того, чтобы кто-либо, не предназначенный для этого, выполнял мои функции. В конце концов, я, черт возьми, не рассказываю вам, как нужно писать код!

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

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

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

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

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

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

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

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

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

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