Месяц в небе

[3eta]

После затянувшейся отправки Амазон извинился, и доставил новую книжку Инны Кузнецовой (karial) за 1 день. Так что выходные прошли как давно хотелось - на диване, с книжкой и ручкой для заметок по ходу.



Книга, разумеется, не только оправдала ожидания, но даже их превзошла - главы про борьбу со стрессом, мотивацию стали приятным сюрпризом. Но, разумеется, появились и новые вопросы, уже по прочтению. Например, когда логичнее всего совершать горизонтальный переход, чтобы не стать заложником узкой специальности?
Вообще идея горизонтальных перемещений для меня стала частично открытием. Я ее наблюдала на уровне наших директоров где-то с полгода назад, и наивно решила, что это вице-президент решила устроить ротацию, чтобы люди "не скучали" пока нет возможности повысить. Там натуральным образом народ по принципу хоровода по цепочке переместился в соседний отдел. А, оказывается, это обязательная практика. И только в России повышения преимущественно вертикальные или, в худшем случае, диагональные, - потому что карьерный рост в принципе более динамичный.

У меня было много догадок о том что и как работает для продвижения по карьерной лестнице, и какие-то предположения книга подтвердила, а вот какие-то придется пересмотреть. В частности, теперь я пытаюсь понять как же устроена у нас иерархия и матричная структура. Одно время я анализировала внутренние директорские вакансии и затем пришла к выводу, что работает следующая цепочка: Project Manager -> Program Manager -> Manager (уже с формальными подчиненными) -> Sr.Manager/Director. И, соответственно, следующей ступенькой для себя наметила позицию програм-менеджера. А несколько месяцев назад моя неформальная начальница обмолвилась, что нашему менеджеру нравятся мои аналитические навыки и та видит меня в роли аналитика. Добившись с ней встречи 1:1, я поинтересовалась и она объяснила, что по их меркам аналитик ничем не хуже програм менеджера, и в общем-то на обеих позициях требуются как аналитические навыки, так и умение управлять командой. А развитие и профессиональный рост определяются уровнем грейда, внутренней оценочной шкалой для постоянных сотрудников, и сложностью доверяемых проектов. У контрактников шкалы грейдов нет, поэтому весь расчет на то, что о твоих навыках в курсе твой непосредственный начальник.

В какой-то момент нам сообщили, что контрактники могут подчиняться только менеджеру, поэтому ветвистая структура отдела стала довольно прямолинейной, и наша формальная начальница стала неформальной. Теперь прошла новость, что будут уменьшать управленческую цепочку, хотят чтобы было не более 8 человек в иерархии от простого сотрудника до СЕО, и для того чтобы называться "менеджером", необходимо иметь не менее 8 фуллтаймеров в подчинении. Учитывая что соотношение фуллтаймеров в контракторам в компании примерно 1 к 4, то отдел должен быть довольно внушительным. При этом я пошла сегодня посмотреть структуру отдела маркетинга, в котором мне приглянулась директор в качестве потенциального ментора, - у нее в подчинении три "менеджера", у двоих из которых вообще нет подчиненных, а у одной - пяток контракторов и ни одного фуллтаймера. В общем, я поняла, что уже ничего не понимаю. Но надо разбираться. Потому что не понимая правил игры, трудно в нее выиграть.

Comments

[krisdenisova.livejournal.com]

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

[3eta.livejournal.com]

Я уже порой даже не знаю что они вкладывают в понятие "аналитик"))) Потому что в моём понимании QA, например, сложнее - ты не только делаешь тот же самый анализ требований и продумываешь всевозможные use cases, трансформируя их в тест кейсы, но потом ещё и несешь ответственность за результат, если где-то проскочил баг - это твой косяк, его не скрыть. Зато аналитикам неполные и противоречивые требования сходят с рук. Это же твои проблемы, если ты вовремя что-то не уточнил или не перепроверил. У меня зачастую именно QA сидит и часами разбирает что там нелогичного и чего не хватает в 200 user stories запланированных к релизу, и затем бегает за аналитиками, объясняет где и что нужно исправить.
Зато не так давно я на встрече с нашим менеджером и ее командой делала презентацию своего предложения по улучшению некоего процесса и чистке старого контента, все хорошо, менеджер меня перебивает в середине со словами: "Да-да, я давно считаю что нам пора это сделать!" И буквально через пару дней рекомендует меня подчиненной, которая приходит с просьбой выделить ей человека знающего Х для сравнительного анализа с новой системой Y. С этой подчиненной мы пересекались пару раз, знаем кто чем занимается, но вместе никогда не работали. И вот она приходит мне сообщить новость, и радостным тоном говорит: "Да, я видела твою презентацию на встрече у начальницы, так что думаю что у тебя есть basic skillset до того, чтобы сделать анализ этого продукта!"
Думаю, что-то в моём выражении лица меня выдало, потому что я даже ещё сформулировать ничего не успела, но она начала оправдываться, дескать, ну я не знаю точно чем ты занимаешься, знаю только что ты в QA. Она сама, понятно, аналитик и видимо считает аналитиков высшей кастой :)

[krisdenisova.livejournal.com]

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

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

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

[3eta.livejournal.com]

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

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

[3eta.livejournal.com]

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

[krisdenisova.livejournal.com]

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

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

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

[3eta.livejournal.com]

Ага, ты абсолютно права. И я пожалуй "обижаюсь" на то, что аналитикам нашим недосуг обратить внимание, что на тех проектах над которыми мы работаем, аналитиков по сути и нет. Есть некие business owners, которые совершенно "не технические" и рассчитывают на то, что все технические нюансы распишет сам тех.лид или кто-нибудь еще. И работу аналитика выполняет именно QA. То есть для меня показатель:
1. Если QA высылает на одобрение бизнесу тест-кейсы, и бизнесу нечего добавить
2. Если бизнес делает приемочное тестирование после того как продукт проверил QA, и не может найти никаких дефектов
то в этом случае QA работает лучше "бизнеса", по крайней мере их в аналитической роли. Потому что упущения есть всегда, но если аналитики, которые сами создают требования, не могут их найти, то это определенный показатель.

[krisdenisova.livejournal.com]

но так тоже бывает ) зачем обижаться?
QA вообще ЧАСТО замещает системного аналитика когда есть бизнес-аналитик
это вообще разные роли
я в целом как аналитик всегда была ближе к заказчику при заказной разработке, щас доросла до бизнес-аналиста продукта который сам может формулировать задачу к системе и это дофига много работы, ну т.е. не обижайся что они все такие хайлевел. если пытаться быть и хайлевел и в деталях то мозг взорвется )))

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

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

[3eta.livejournal.com]

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

[krisdenisova.livejournal.com]

я тебя уверяю, нет никакого превосходства или ощущения превосходства у аналитиков
считают "просто тестерами" - ну так потому что основные обязанности они какбэ именно такие ) никто ж сходу не знает как оно. )

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

вот ты говоришь типа ты отвечаешь за качество продукта а аналитик так, фиг знает чо делает.
блин а аналитик отвечает за то чтобы качественный продукт не пошел в мусорку сразу после релиза! :) аналитикам такое меж тем тоже весьма обидно :)

[3eta.livejournal.com]

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

[krisdenisova.livejournal.com]

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

обычно это из разряда тех вещей которые пока по ушам не проедешься не заметят. :)

а аналитику карьерно расти действительно обычно не хочется. по крайней мере я по себе сужу - в менеджеры? да нууууу )) меня прельщает рост в экспертизе и в зарплате )) вертикальный рост не хочу не буду.

[3eta.livejournal.com]

У меня мальчик, который работает ведущим тестировщиком и замещающий меня время от времени, мечтает о переходе в аналитики с подтекстом: "наконец можно будет расслабиться!" ))) Но в основном конечно избавиться от стресса и ответственности QA, а также периодической необходимости тупого и монотонного регрессного тестирования.

[krisdenisova.livejournal.com]

ахахахаха )))
пусть не путает туризм с эмиграцией! )

[boriskhv.livejournal.com]

выигрывает обычно тот, кто играет не по правилам

[3eta.livejournal.com]

Ну, для этого их, опять же, нужно знать ;)

[hazy-amber.livejournal.com]

Вот поэтому я прихожу к выводу, что большие компании не для меня >.>

[3eta.livejournal.com]

В небольших свои слабые места :)

[hazy-amber.livejournal.com]

Безусловно! И немало. Но лично мне с ними удобнее мириться.
Это я к тому, что меня озарил твой пост по поводу одной из причин)

[3eta.livejournal.com]

да? какой именно?)

[hazy-amber.livejournal.com]

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

[3eta.livejournal.com]

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

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

[hazy-amber.livejournal.com]

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

[3eta.livejournal.com]

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