Комментарии 17
Спасибо за статью! Я системный администратор и в своей области могу сказать так: существует очень много фирм которые не хотят платить большие зарплаты, покупать качественное оборудование и поддержку от производителя и... готовы мириться с ошибками и сбоями. Видимо при определенных обстоятельствах это оправдано и рентабельно. Вот это как раз хороший вариант для начинающих.
Совет номер 0: учите и знайте стандарты в своей области. Часто аналитик видит свою роль только как хранителя сакральных знаний о проекте. Первая проблема в том, что такой человек ВНЕ проекта не имеет ценности. Вторая проблема в том, что если ты знаешь только "как есть", то в следующем проекте ты способен максимум повторить "как есть". А когда ты знаешь "как надо", то ты можешь превратить "как есть" в "как надо", и своей следующий проект сразу делать "как надо".
может прибежать техлид советоваться по поводу архитектуры, а вам придется сидеть и мило улыбаться всем его предложением абсолютно не понимая, что с этим делать.
А техлид находится на позиции младшего помощника джуниора? Или просто вы милая девушка, с которой приятно поболтать опытным разработчикам?
А на Вашей практике аналитики не принимают участия в построении архитектуры?)
Требования от бизнеса не сразу же попадают техлиду, все равно базу выстраивает аналитик. Формирует ЧТЗ, строит UML различные при необходимости, делает например наброски для последующей проработки ролевой модели, схемы данных. Как же в данном случае тех.лид не будет коммуницировать с аналитиком?
По моему глубокому убеждению, в работе любого инженера (а в работе аналитика особенно) не бывает правильных или неправильных решений. Зато бывает валидная или невалидная аргументация этих решений (или, что бывает чаще, отсутствие любой аргументации). А для того, чтобы адекватно аргументировать свое мнение, требуется внушительный опыт, обширный кругозор и глубокие знания. А в данной статье (равно как и в остальных двух, опубликованных автором на сей момент) я вижу растерянную девушку, пытающуюся оправдать свой синдром проходимца, старающуюся угадывать "правильные" ответы, лишь бы себя не выдать. Не вижу, какую пользу такой аналитик может принести вменяемому техлиду, кроме как играть роль "резинового утенка" для принятия решения методом rubber duck debugging. А вреда, кстати, принести может немало.
Не могу, правда, не отметить подборку картинок в статьях этого автора. Предполагаю, что презентационные скилы у нее на высоте. Продолжив тему котенка по имени Гав (чьи изображения были использованы в соседней публикации), сыграю роль черного кота, заявив, что аналитика с таким подходом на улице ждут одни неприятности. Ну или улицу ждут одни неприятности с таким аналитиком.
Позволю себе предположить , что данный комментарий не является ответом на мой вопрос.
В данном случае , я говорю о необходимости коммуникации одного технического специалиста с другим , а не прошу Вас переходить на личности и оценивать меня и мои знания с Вашей точки зрения.
В статье , я поделилась исключительно своим опытом, не настаивая на том , что это единственно правильное мнение. А если по вашему мнению это бесполезный материал , то будьте добрее , просто пройдите мимо )
Непонятно, почему в данном случае вы выставляете крайним аналитика. Она на собеседовании себя сеньором выставила? Нет. Почему вообще джун, которому платят за и не увольняют, принимать импульсивные решения в духе "я не приношу пользы, я ухожу"? Это проблема бизнеса. Потому что как только такой джун хлопнет дверью, на его месте появится другой. И в отличие от этого джуна, который погружён в проекты и архитектуру, первым вопросом новичка будет "а как вас зовут?"
С чего вы взяли, что я кого-то выставляю крайним? Я предъявляю высокие требования ко всем инженерам. Но, как было сказано в статье,
Зачастую, все работодатели при поиске данного специалиста заинтересованы в том, чтобы человек был с опытом. Что крайне логично, потому что данная роль предполагает определенный уровень ответственности.
То есть решение компании взять джуна на позицию аналитика выглядит, как минимум, странно. Но оставим это на совести нанимателя.
Но что случилось, то случилось. Теперь мы выдим на Хабре три статьи от одного автора, где красной нитью проходит тема синдрома самозванца. Тема, кстати, важная, и против нее я ничего не имею, т.к. каждый из нас испытывает этот синдром, кто-то чаще, кто-то реже. Но это разные вещи, бороться с синдромом или бороться с собственной некомпетентностью. IMHO, в публикациях от автора намного больше внимания уделяется эгоистичному "как не выгореть, если сознаешь, что самозванец", нежели "как перестать быть самозванцем". Но это мое субъективное мнение, основанное на как бы извиняющемся тоне статей.
А далее моя личная мозоль: я слишком часто вижу поля, заботливо устланные граблями, где решения принимали некомпетентные люди. И я готов помочь коллеге с синдромом самозванца (все мы когда-то были джуниорами), но буду спрашивать за некомпетентные решения и с того, кто их принял, и с его руководства. От ошибок мы не застрахованы, на них мы учимся, но я бы предпочел на роли, "предполагающей определенный уровень ответственности" видеть человека, который уже успел и накосячить, и был пожурен, и исправить, и сделать выводы.
По моему глубокому убеждению, в работе любого инженера (а в работе аналитика особенно) не бывает правильных или неправильных решений. Зато бывает валидная или невалидная аргументация этих решений (или, что бывает чаще, отсутствие любой аргументации). А для того, чтобы адекватно аргументировать свое мнение, требуется внушительный опыт, обширный кругозор и глубокие знания. А в данной статье (равно как и в остальных двух, опубликованных автором на сей момент) я вижу растерянную девушку, пытающуюся оправдать свой синдром проходимца, старающуюся угадывать "правильные" ответы, лишь бы себя не выдать. Не вижу, какую пользу такой аналитик может принести вменяемому техлиду, кроме как играть роль "резинового утенка" для принятия решения методом rubber duck debugging. А вреда, кстати, принести может немало.
Не могу, правда, не отметить подборку картинок в статьях этого автора. Предполагаю, что презентационные скилы у нее на высоте. Продолжив тему котенка по имени Гав (чьи изображения были использованы в соседней публикации), сыграю роль черного кота, заявив, что аналитика с таким подходом на улице ждут одни неприятности. Ну или улицу ждут одни неприятности с таким аналитиком.
P.S. не туда ответил, но удалить коммент нельзя. Какой аналитик придумал неудаляемые комменты, даже в первую минуту после поста?..
NB: Если вы на курсе по REST не проектируете REST, то это какие-то странные курсы.
Вам не помогают не курсы вообще, а конкретные курсы, где вы не спросили, а будем ли мы на курсе ДЕЛАТЬ или только слушать?
https://medium.com/digi-edu/training-24ecc71b1588
другое дело, что ещё год назад русскоязычных курсов по REST ещё практически не было, а теперь — есть
Хоть уделайся на курсах, но ошибок не поймёшь, пока твой проект не побывает в бою. В реальных условиях: с раздолбаями-разработчиками, не читающими документацию; с падающими серверами; с изменениями бизнес-требований пост-фактум и т.д...
я отвечаю на конкретный пассаж:
«Поэтому, ты можешь бесконечно много читать, как проектировать REST, но если ты так ни разу пока его не проектировал, то шансов, что работодателя это устроит, честно говоря, маловато»
вот работодателя устроит учебный опыт проектирования джуна
«ошибок не поймешь» — это уже следующий уровень
Смотря какой работодатель. У крупных над тобой будет архитектор/ведущий аналитик или кто бы то ни было ещё, тот, кто своим опытом поможет обойти узкие места. А тех, кто помельче, устроит любой результат просто из-за недостатка компетенции. Другой вопрос, что со временем это может аукнуться самому работодателю.
Отличная статья для тех, кто только входит в эту непростую специальность. Из советов джуну добавил бы следующее: не доверяй своей памяти - она работает через призму имеющихся у тебя знаний. Записывай все, в блокнот на видео, пересматривай и ищи что пропустил. Очень часто оказывается, что ты понял кого - то с точностью до наоборот, только по тому , что человек в теме сто лет, а ты сам имеешь совсем далекое от реальности представление. Аналитик должен быть готов признавать свои ошибки и менять точку зрения, смотря на задачу глазами каждой из заинтересованных сторон. В этом помогают записи. Следующий необходимый скил - умение задавать вопросы, до тех пор пока не получишь удовлетворяющий тебя ответ. Не понял - уточняй. Думаешь, что понял - повтори то что ты понял тому кого ты спрашивал и получи подиверждение. Фраза "Правильно ли я понимаю, что ... " И далее по теме должна стать второй натурой. Третье - люди не понимают друг друга и не могут договорится, даже если сидят в одном кабинете за соседними столами. Не тешь себя иллюзией - тебе придется налаживать коммуникации между всеми участниками и доносить до членов команды не просто сообщения а их смысл. 90 процентов всех проблем в проекте - проблемы коммуникаций. И еще, хороший аналитик на самом деле очень разносторонний дилетант. Если тебе нравится узнавать что то новое и решать проблемы из серии как скрестить ужа с ежом, то профессия тебе зайдет.
Junior системные аналитики, или как не выгореть после первого проекта