Как стать автором
Обновить
0
0

Системный аналитик

Отправить сообщение

Сколько мне стоило попасть в Гугл и получить повышение, не проработав там ни одного дня

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров93K

Декабрь 2020, вторая волна Ковида в разгаре. Я ПМ на удаленке в Американской компании. После похорон отца в Тбилиси я находился в прострации, надо было возвращаться в США и как-то менять своё положение, ведь денег, которых я зарабатывал явно не хватало на нормальную жизнь. Сами воспоминания о моём предыдущем поиске вызывали во мне холодный озноб и какой-то внутренний голос тихо шептал «подожди, сейчас пандемия, многие и о таком мечтают, как-нибудь выкрутишься…».

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

Я зарегистрировал себе американский номер в Google Voice, чтобы мне начали звонить рекрутеры и начал рассылать резюме. Я разослал около сотни адаптированных резюме и указал в LinkedIn что активно ищу работу. Постепенно на меня начали выходить рекрутеры небольших компаний, но я понимал, что в них условия будут в лучшем случае на 40% лучше текущей и это все равно не решало моих проблем. Хоть и казалось, что на LinkedIn висят тысячи позиций, однако основных работодателей я этим исчерпал. Подавался я в основном на Sr. Project Manager или Engineering Manager позиции.

Осознание пришло, когда я стал читать teamblind.com – лучший ресурс в США по анализу рынка в ИТ и levels.fyi где можно посмотреть реальные зарплаты. Раньше я читал Glassdoor, но информация на нем устарела.

Оказалось, что в финансовой сфере в США, которая мне была интересна - плохие условия и токсичная культура, тоже самое в консалтинге кроме компаний из Big4 или MBB где надо работать долгие часы, но возможно получать 1+ миллион долларов в год дослужившись до партнёра. Самыми интересными оказались компании, которые называют FAANG (Fb, Apple, Amazon, Netflix, Google) иногда в место этого списка используют FAANGMULA справедливо добавляя туда Microsoft, Uber, Lyft и Airbnb – все они технологические, инновационные компании не просто создающие бизнес-продукты, но и технологии, которыми пользуются весь мир. Компании, создающие де-факто стандарты разработки цифровых продуктов, инвестирующие в научные исследования, создающие легендарные условия для своих сотрудников, чем привлекают умнейших инженеров и ученных со всего мира.

Читать далее
Всего голосов 104: ↑88 и ↓16+117
Комментарии125

Software Configuration Management // отслеживание запросов на изменение

Время на прочтение7 мин
Количество просмотров18K

Вместо предисловия

И снова доброго времени суток!

Продолжаю цикл заметок об основах управления конфигурацией программных средств. Чтобы долго не пересказывать краткое содержание предыдущих двух серий, предлагаю ссылки на них:
  1. Цикл статей по основам Software Configuration Management. О том, что такое СМ, каковы его задачи и за что отвечает в рамках проекта CM-инженер.
  2. Software Configuration Management // Конфигурации и baselines. О том, что такое рабочий продукт в терминах SCM, что такое конфигурация, как она стабилизируется, а так же что такое базовые конфигурации — baselines.
В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.

Ну, давай посмотрим...
Всего голосов 25: ↑17 и ↓8+9
Комментарии19

Agile API — возможно ли?

Время на прочтение11 мин
Количество просмотров14K
Множество статей и книг посвящено тому, как правильно проектировать API, но едва ли кто-то затрагивал тему постоянно меняющихся (гибких) API. Динамично развивающаяся компания зачастую выпускает по несколько релизов в неделю, а иногда и в день. При этом для добавления новых функций необходимо постоянно вносить изменения в существующее API. В этой статье мы расскажем о том, как мы в Badoo решаем эту задачу, какие подходы и идеи мы используем в своей работе.

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

Читать дальше →
Всего голосов 35: ↑34 и ↓1+33
Комментарии0

Использование JIRA и Confluence в большом проекте

Время на прочтение6 мин
Количество просмотров208K
Начало нового проекта как правило сопровождается решением массы организационных вопросов: как будут взаимодействовать участники проекта, где будут храниться документы и как будет построено их согласование, как будут ставить задачи и выдавать поручения… В каждой компании, у каждого руководителя проектов, уже есть заготовки и предпочтения. Но всегда полезно посмотреть, как это делают другие. Поэтому предлагаю познакомиться с примером из практики, который вышел весьма удачным.
Читать дальше →
Всего голосов 11: ↑11 и ↓0+11
Комментарии9

Scrum — реальный опыт работы по методологии

Время на прочтение5 мин
Количество просмотров146K
В данной статье я привожу обзор организации процесса создания программного обеспечения в команде, в которой работаю. Моя цель – это поделиться опытом разработки и управления командой разработчиков.

Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».
Читать дальше →
Всего голосов 51: ↑35 и ↓16+19
Комментарии54

Сервис-ориентированная архитектура (SOA)

Время на прочтение14 мин
Количество просмотров197K


Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:


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

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

Читать дальше →
Всего голосов 28: ↑27 и ↓1+26
Комментарии2

Двадцать лет с юзкейсами: выжимаем практический опыт

Время на прочтение12 мин
Количество просмотров83K
У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.



Я буду использовать разговорное «юзкейс» вместо неуклюжей кальки «прецедент использования». Надеюсь, уважаемая публика меня за это простит.
Читать дальше →
Всего голосов 19: ↑19 и ↓0+19
Комментарии2

Документирование в разработке ПО

Время на прочтение5 мин
Количество просмотров146K

INTRO


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

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

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.
Читать дальше →
Всего голосов 26: ↑26 и ↓0+26
Комментарии42

Балансировка нагрузки: основные алгоритмы и методы

Время на прочтение11 мин
Количество просмотров188K
балансировка нагрузки

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

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

Балансировка нагрузки может осуществляться при помощи как аппаратных, так и программных инструментов. Об основных методах и алгоритмах и балансировки мы бы хотели рассказать в этой статье.
Читать дальше →
Всего голосов 36: ↑31 и ↓5+26
Комментарии15

Уход сотрудников на удалёнку снёс крышу менеджерам

Время на прочтение5 мин
Количество просмотров71K

Пустая парковка у офиса Facebook в Менло-Парк, 14 апреля 2020 года. Фото: Jeff Chiu/Associated Press

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

Но самая трагическая история произошла с менеджерами. Их судьба повисла на волоске. Профессиональные переговорщики всю жизнь оттачивали навыки презентаций, личных собеседований, психологического давления, плетения интриг. Они буквально лишились почвы под ногами — разработчики массово ушли из-под контроля, и что самое зловещее, они продолжают спокойно работать на удалёнке, разбирают таски и решают задачи, будто менеджеры и не нужны вовсе! Конечно, такая ситуация совершенно недопустима (по мнению менеджеров).
Читать дальше →
Всего голосов 146: ↑112 и ↓34+118
Комментарии284

PMP, кому и когда это нужно

Время на прочтение4 мин
Количество просмотров45K
Всем привет!

Сегодня хочу рассказать о своем опыте подготовки и сдачи экзамена PMP (Project Management Professional). Эта статья из-за объема разделена на две.

Первая статья будет полезна следующим категориям читателей:

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

Вторая статья будет полезна тем, кто уже готовится к сдаче PMP и хочет понять формат проведения экзамена и как к нему подготовиться. Перейти ко второй статье можно по этой ссылке: habr.com/ru/post/531474

1. Краткий вывод


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

Стоимость сдачи PMP без учета затрат на обучающие материалы и курсы составит 405 или 555 долларов США в зависимости от членства в PMI. По моим оценкам срок подготовки составит примерно 2-3 месяца при условии, что вы тратите около 10 часов в неделю на подготовку к экзамену.
Читать дальше →
Всего голосов 4: ↑2 и ↓2+3
Комментарии7

Социальные аспекты руководства, или как же всё таки «пинать» сотрудников. 2 года спустя.

Время на прочтение6 мин
Количество просмотров6.8K
Статья про «пинание», «закручивание гаек» и контроль задач, разные стили общения и руководства, про сложности делегирования, самомотивацию сотрудников.

Вопрос: Прочитал вашу статью «Социальные аспекты разработки» и был ошеломлен! До этого момента я считал, что такие идеи лишь из области утопий и невозможны к реализации.

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

99.77 КБ

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

Симптомы: падение дисциплины, низкая скорость разработки, потеря энтузиазма.
Свой же стиль руководства я бы теперь назвал «попустительским».

И вот, как только мое терпение кончилось, и я собрался на следующий день «закрутить как можно туже гайки», я натыкаюсь на вашу статью. Это было как бальзам на больное сердце. Я сразу с великим облегчением отказался от идеи пинания, но понимаю, что делать все равно что-то надо, а с чего начать не знаю? Хотелось бы вашего совета.

Ответ: В 2 словах это,
— Вносите элементарную организованность в процесс. Это не «пинание» — это ваша работа.
— Разный стиль. С крутыми – искренне, с молодежью – дружелюбно, с «примадоннами» – сухо
— Используйте эмоции для «поджигания» людей. Прочитайте Возьмите эмоции с собой
— Используйте 4 модели руководства исходя из задачи и человека. Это вопросы — Может? Возьмет?
— Готовьтесь к тому, что у вас будут проблемы с Директивным стилем и Делегированием.
— Стремитесь к тому, чтобы у вас в команде были только люди с сильной самомотивацией, для которых ваша работа это хобби, страсть, любимое дело. Помогите разобраться в себе другим людям.
— Сплачивайте команду: cобирайте в одной комнате, проводите общие собрания, ставьте общие достойные цели.

Читать дальше →
Всего голосов 94: ↑87 и ↓7+80
Комментарии22

Управление рисками

Время на прочтение4 мин
Количество просмотров125K
В Deadline, Том Демарко пишет о том, что для управления проектом, достаточно управлять его рисками. Действительно, всю работу ПМа можно свести к одному — борьба с рисками, которые могут помешать проекту завершиться в срок, в бюджет и с необходимым уровнем качества. Если, по какой-то причине, рисков в проекте нет, то нет и предмета работы ПМа.

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

Читать дальше
Всего голосов 59: ↑55 и ↓4+51
Комментарии63

SQL: разбор задачи на поиск последней цены

Время на прочтение10 мин
Количество просмотров11K

В эфире снова Радио SQL, здравствуйте, согалактчики!

Сегодня у нас обещанный разбор задачи на поиск последней цены.

Давай, уже заждались
Всего голосов 6: ↑6 и ↓0+6
Комментарии17

Философия SLA: что такое эскалация и зачем она нужна

Время на прочтение8 мин
Количество просмотров39K

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.


Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.


Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!


КДПВ


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

Читать дальше →
Всего голосов 14: ↑14 и ↓0+14
Комментарии25

Ошибки, которые погубят проект любой сложности. Опыт менеджеров Redmadrobot

Время на прочтение10 мин
Количество просмотров10K


Мы, электрические, запускаем проекты с 2008 года, и за 11 лет сформировали сильную команду робоменеджеров. Прокачивать железных помогают боевые задачи и одна из самых сложных — управлять проектом. Ситуации, при которых появляется необходимость взять на себя обязанности PM (project manager), бывают разные: в маркетинге — при создании сайта, в HR — при организации мероприятий. Мы вспомним десятки подобных случаев.

Мы подготовили список ошибок, которые допускают новоиспеченные руководители проектов и дополнили их своими рекомендациями. В статье два варианта рекомендаций: простые и для тех, кто хочет заморочиться — с референсами и ссылками на полезные ресурсы. Так что у вас не останется и шанса их повторить при надлежащем внимании. Надеемся, что это позволит сделать ваш проект проще, качественнее и внесет предсказуемость в процесс его создания.
Читать дальше →
Всего голосов 13: ↑11 и ↓2+14
Комментарии7

Эффективное распределение ролей посредством RACI матрицы (Обновлено)

Время на прочтение5 мин
Количество просмотров164K
Часто ли Вы сталкивались с таким явлением, как нерациональное распределение обязанностей? Сколько раз приходилось наблюдать за тем, как один человек «на все руки мастер» выполняет работу за пятерых? А так называемый «специалист, занимающийся не понятно чем» — знакомо? Такие варианты, а также им подобные нередко приходилось видеть ранее в отечественных реалиях. Этот же «совок» многим приходится наблюдать, и что хуже, чувствовать на своей личной шкуре и поныне во многих госструктурах.

О таком умном словосочетании, как «разделение полномочий» говорят часто. Но все ли знают, как его применять на практике, и кому удается этим реально воспользоваться? Приглядевшись внимательно, делаем вывод, что такое явление происходит по большому счету, в компаниях частного сектора, в особенности тех, кто работает с иностранным клиентом.

Именно из-за «бугра» до нас дошла любопытная аббревиатура под названием RACI. При этом, зачастую перед ней можно наблюдать разного рода умности а-ля «матрица» или «модель». Что это и с чем его едят, попытаюсь объяснить читателю далее. Возможно, кому-то уже повезло работать в коллективах, где каждый знает свои обязанности и область ответственности – за таких людей можно только порадоваться. При этом лично я верю, что далеко не у всех всё идеально в сфере разделения полномочий. Для таких людей данная статья может оказаться полезной.
Читать дальше →
Всего голосов 21: ↑21 и ↓0+21
Комментарии10

Четырехдневная рабочая неделя: результаты разных экспериментов. Плюсы, минусы и перспективы

Время на прочтение7 мин
Количество просмотров39K

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

Именно поэтому правительство страны решилось на проведение крупнейшего в мире эксперимента по сокращению рабочей недели. Его авторы посчитали проект успешным, и теперь этот опыт могут перенять и другие страны. К слову, это далеко не первый эксперимент, проводились подобные тесты “четырехдневки” и раньше, хотя и не на уровне целого государства. Давайте посмотрим, где еще реализовались подобные проекты и насколько они были успешными.
Читать дальше →
Всего голосов 48: ↑46 и ↓2+58
Комментарии90

Confluence для публичной базы знаний: меняем дизайн и настраиваем разделение по языкам

Время на прочтение12 мин
Количество просмотров33K
У нас есть шесть продуктов, которые используют в России и за рубежом. Это значит, что документация к ним должна быть в одном месте, но разделена по продуктам и языкам.

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

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

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


Читать дальше →
Всего голосов 19: ↑19 и ↓0+19
Комментарии14

50 вопросов для работы над документацией

Время на прочтение5 мин
Количество просмотров9.1K
Как бы ни старался UX-дизайнер, не сможет человек с улицы разобраться в интерфейсе управления космическим кораблём без подсказки. И даже не с улицы. Просто потому, что ракета большая и настроек много.

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

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


Читать дальше →
Всего голосов 20: ↑20 и ↓0+20
Комментарии0
1
23 ...

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность