Есть много разных методологий разработки: Waterfall, Agile, Lean и другие. Ситуацию усложняют различные схемы оплаты разработки в ИТ. Что лучше: Fixed Price, Time&Material или взять людей на аутстафф? Человеку, далёкому от коммерческой разработки, бывает сложно разобраться что и когда стоит использовать. Чтобы помочь с этим разобраться, рассмотрим разные методологии и схемы оплаты с точки зрения работы с рисками и права на ошибку. Попробую писать простым языком, чтобы было понятно всем.
Несмотря на опыт работы в проектном менеджменте более 10 лет, с продуктовой линейкой «atlassian» (Confluence и Jira) познакомился не так давно. Теперь же, после использования этих инструментов на «боевом» проекте, хочу поделиться своим опытом и видением их дальнейшего использования.
Для начала небольшая предыстория, без которой «картина», изложенная ниже, может быть не полной.
10 лет в проектном менеджменте, это в большей мере инфраструктурные «телеком» проекты. Возможно, по этой причине, долгое время не приходилось сталкиваться с линейкой «atlassian».
«Телеком» отрасль 10 лет назад жила в парадигме «эксель-менеджмента», и меняться не спешила.
Но все течет и изменяется, что в общем то хорошо.
Технологии становятся доступней, время меняет людей, кто-то учится, а кто-то уходит на покой (в смысле заслуженный, а не вечный).
В любом случае все отрасли подверглись «цифровой» трансформации, кто-то в большей, кто-то в меньшей степени. И сейчас Jira можно встретить в «телеком» проектах любой степени сложности, а бесплатную версию Confluence может установить себе студент любого учебного заведения.
Также стоит отметить, что нижеописанный опыт, это опыт применения стека методологий проектного менеджмента, в основе которых PMBoK.
Первое знакомство
По работе столкнулся с Confluence и Jira в крупной федеральной «телеком» компании в блоке инфраструктурных проектов, своих ИТ команд нет, при необходимости привлекаются отдельно.
Коллеги по отрасли с неохотой используют «новые» ИТ инструменты. Основной «таск-трекер» это служебная почта.
Много было уже было написано про Армению, хотелось бы немного остановиться на Грузии.
В Армении, в разрезе открытия счета в банке главный плюс, актуальный на 14 июня 2022 года - наличие банков, подключенных к СПФС. Главный минус - невозможность удаленного открытия.
В Грузии свои минусы, например нереально отправить SWIFT в РФ, но есть и плюсы, например более лояльные требования к открытию счета в банке. В большинстве банков требуется личное присутствие клиента, однако есть исключения (BoG, Liberty) когда открыть счет в банке удается удаленно по доверенности через знакомого или посредника. Основные банки работающие с россиянами, это Bank of Georgia и его «подразделение» банк SOLO, а также банки Credo, TBC, Liberty и некоторые другие.
Необходимыми документами для открытия счета являются загранпаспорт, документы о подтверждении дохода, также, в последнее время участились случаи требований грузинских банков предоставить документы об адресе проживания в Грузии.
Основным документом, который заполняется желающим открыть счет является анкета-заявка KYC (Know your client), которую требуют практически все банки. Существует много случаев, когда банки открывают счет или отказывают только после предоставления KYC и загранпаспорта. Пакет документов зависит от банка, его конкретного офиса и даже сотрудника, с которым ведется взаимодействие. В первую очередь следует внимательно отнестись к документам подтверждающим доход, так как это основное требование помимо загранпаспорта.
Мы MM.SUP – команда сопровождения аналитического CRM компании Glowbyte – хотим рассказать о том, как не усложнять все и прийти к простым и правильным решениям в сфере построения процессов сопровождения. Рассказ основан на собственном опыте нормализации процессов управления дефектами промышленной среды ведущего банка топ-5 России.
Сейчас трудно в это поверить, но полтора столетия назад самым быстрым транспортом были поезда – их скорость в 60-100 км/ч казалась умопомрачительной. Но на заре XX века автомобили и самолёты прогрессировали, как сейчас компьютеры, и железнодорожный транспорт почти без боя отдал им рекордные достижения. Последним очагом сопротивления был скоростной полигон Цоссен – Мариенфельде в Германии.
Привет! Меня зовут Роман Ленц, в Первой грузовой компании (ПГК) я занимаюсь анализом данных и машинным обучением в рамках проекта «Цифровой вагон», подробнее о котором рассказано здесь. Еще 3 года назад я работал инженером-конструктором в зарубежной строительной компании. Почему я решил кардинально поменять свою карьерную траекторию, почему выбрал именно Data Science, и как я к этому пришёл? Поделюсь опытом, который, возможно, окажется полезным для молодых специалистов, ищущих «работу мечты». Тем, кто задумался о смене профессии, думаю, информация тоже будет полезна.
Я получил высшее образование за границей. После окончания вуза устроился на работу в московское представительство иностранной строительной компании. Мы занимались проектированием объектов по всему миру, но на российском рынке количество заказов постепенно снижалось: стоимость услуг была слишком высокой для местных клиентов. Стало очевидно, что скоро придется искать другую работу. Именно тогда я задумался о том, чтобы сменить карьерную траекторию.
Не скажу, что выбрал Data Science совсем случайно. Как у инженера у меня был сильный математический бэкграунд, я был знаком с основами некоторых языков программирования, разбирался в работе с данными. Меня привлекали области, где можно применить эти навыки и знания, поэтому направление Data Science показалось мне интересным вариантом для более глубокого погружения.
Определившись, я стал постепенно вспоминать основы математики, линейной алгебры, статистики, теории вероятности. Параллельно начал проходить профильные курсы на крупных онлайн-платформах – DataCamp, Stepik, Яндекс.Практикум и других.
Состоялась конференция разработчиков Apple, вручены награды Apple Design Awards, выпущены технические новинки и стартовал бета-тест новых систем. А ещё слухи, инсайды и другие подробности о грядущих продуктах компании Apple. Всё это в свежем дайджесте от Apple Pro Weekly News.
Привет, Хабр! Я Ани, отвечаю в Ozon Tech за обучение.
Сегодня поводом для поста на столь многоуважаемую аудиторию стал разбор задач контеста, который прошёл в рамках отбора участников на курсы Route 256.
Контест нам заменяет скрининг — мы проверяем технические навыки и опыт работы будущих участников, так как курсы рассчитаны на мидлов.
Ранее мы публиковали разбор задач по направлениям Go и QA (раз, два), пришло время поделиться задачами для C#, iOS (Swift) и Android (Kotlin, Java).
В этот раз нам посчастливилось провести контест совместно с Codeforces, и, судя по фидбеку участников, задачи зашли на ура. Надеюсь, разбор будет полезен и вам. А если захотите попробовать свои силы и попасть на курс, ищите ссылку на регистрацию ниже.
Что спрашивают на собеседовании Golang разработчика? Асинхронщина? Контексты? Вторая часть статьи с вопросами и ответами, собранными на собеседованиях.
Термин «выгорание» вошёл в мою жизнь как-то неожиданно. Работал я. Работал много лет: сначала кодил, потом свои проекты делал, команды собирал, бизнес налаживал… И тут — Бац! Куча мемов на эту тему во всех связанных с IT-ресурсах. Не знаю, то ли я в какой-то тундре жил, то ли тундра жила во мне. Но да ладно: мемы почитал, поржал и забыл. А тут неожиданно этот термин вошёл в обиход моих ребят. Где-то как бы в шутку, где-то в серьёз. А мы все знаем: в каждой шутке есть доля шутки, а остальное — чистая правда.
Это начало влиять на рабочий процесс. Простые задачи стали требовать больше ресурсов, некоторые затягиваться на ровном месте. Люди начали чувствовать себя дискомфортно. При этом я заметил, что чем моложе команды (в плане рабочего стажа), тем больше тема выгорания поднималась и тем активнее в них стали развиваться проблемы.
Признаюсь, поначалу я закипел. Для меня было очевидно, что проблемы элементарны. Время и ресурс, которые уходят на разговоры про выгорание, можно было потратить на их решение, и проблем бы просто не было. Для меня это выглядело так: люди сами себе создали проблемы, а теперь говорят, что им дискомфортно. Накатил типичный сеньорский снобизм:
«Вот я в своё время по 10 часов работал без выходных и отпусков. Скучные проекты пилил, ночью на проде хотфиксил и т.д. и т.п. У ребят же условия другие: график нормированный (авралы, конечно, бывают, но всё в рамках), переработки оплачиваются х1,5-х2 (всё по ТК), проекты интересные. Премии! Отпуска! Работа, блин, командная! Не как дурак сидишь и всё в одного пилишь, а в коллективе ответственных товарищей. Какое, мол, выгорание? Я вам сейчас расскажу про выгорание!» Ну и прочая блаж в том же духе.
Последние два с половиной года показали, насколько важно уметь противостоять стрессу на длинной дистанции. Если в офисе есть коллеги и, в конце концов, пятничный бар, где можно слить накопившийся негатив, на удаленке приходится изыскивать собственные способы профилактики. И чем выше напряженность в обществе, тем более виртуозным должно быть умение не поддаваться унынию.
Эту подборку рекомендаций мы собрали по итогам внутреннего собрания, посвященного стрессу, где все желающие могли поделиться своими паттернами. Возможно, вы бы хотели что-то к ней добавить? В таком случае добро пожаловать в комментарии!
Поводом для написания этой статьи послужил случай, когда сотрудники нашего HR-отдела предложили мне взять в нашу проектную группу Департамента разработки программного обеспечения ЛАНИТ на производственную практику выпускника одного из московских техникумов. Кандидат обучался четвертый год по специальности «Прикладная информатика» и, судя по резюме, претендовал на должность «стажера-разработчика SQL, С#, HTML, CSS». Он уже прошел предварительные собеседования и, по словам наших кадровиков, показал себя наиболее адекватным из 15 других претендентов. Поскольку у меня это был не первый случай руководства практикой у студентов и предыдущие прецеденты имели положительный результат, я согласился.
Давно хотелось написать про корпоративных программистов, по своему опыту, какие они бывают, какой у них стиль работы. Речь идет о разработке в плане сопровождения или переработки больших систем.
Первый тип - быстрые программисты. С такими сталкиваешься редко. Это эрудированные и увлеченные люди, обычно занимающие высокое положение в иерархии разработчиков (тим лиды или что-то около). Основная особенность - высокая скорость написания кода и способность быстро осваивать новые технологии. Думаю, для корпоративной среды это ценные сотрудники, поскольку, чаще всего скорость в цене. Качество кода у таких программистов не всегда высокое, чаще наоборот. Иногда код сложный. Один раз я просматривал код за одним из таких специалистов и он меня поразил одной особенностью. Это был код высококлассного спеца, но выглядел он как набросок - широкими мазками была сформирована структура, но вот детали были иногда просто не реализованы. Обычно код таких программистов приходится допиливать, но главное преимущество, что код очень быстро появляется и сразу в больших объемах. Работая с таким кодом, чаще всего находишься в растерянности от широты мысли и идей автора.
Второй тип - педанты. Код этих программистов пишется со средней скоростью, обычно он качественный в плане надежности и отсутствия ошибок, но часто бывает перегружен количеством рассмотренных кейсов, проверок и т.д. Код сложный, со сложными для понимания структурами и алгоритмами, от него нет чувства полетности, код тяжелый и очень трудно воспринимается при чтении. Один раз я сталкивался с таким кодом, где практиковались очень длинные строки - по несколько сот символов, вызовы методов с большим количеством параметров, каждый из которых сам был вызовом других методов или конструкторов. Править такой код чрезвычайно сложно, очень тяжело понимать для чего сделаны те или иные вещи.
Новая неделя – новая статья. Сегодня про социалку, а в первую очередь про воспитание детей и пенсию в передовых айтишных странах как о двух основных критериях социальной защищённости. Сравнивать будем США, Канаду, Германию, Нидерланды, Швейцарию, Великобританию, Кипр, Польшу, Израиль и Австралию. А опираться предлагаю не на логику и умозаключения, а на индексы с проверенной статистикой и цифрами.
В прошлом материале мы считали, сколько лет жизни среднестатистического программиста уйдет на накопление на квартиру в 100м2. В некоторых популярных среди айтишников странах этим самым айтишников не хватит одной жизни, чтобы выплатить ипотеку. Но каким-то образом в этих странах пенсия у стариков оказалась в топе по счастью. Как это вышло? Давайте смотреть.
Социальное развитие
Для того, чтобы ответить на вопрос, насколько государства поддерживают граждан в тех или иных сферах жизни, я нашла отличный индекс Social Progress Index, который учитывает как базовые человеческие потребности (питание, медицинское обслуживание, доступность жилья, личную безопасность, доступ к образованию), так и возможности права и свободы. Изучить можно его отдельно по каждой категории на официальном сайте индекса.
Какие у вас ассоциации с Узбекистаном? Кто-то вспомнит узбекскую кухню с пловом, мантами и лепешкой. Любители путешествий представят себе древние города и здания с причудливыми узорами. И конечно, вспоминаются работящие парни из Средней Азии. Но времена меняются, миграционные потоки тоже. Sad but true. И уже парни с бледными лицами в обнимку с лэптопами уезжают в солнечный Узбекистан.
Я преподаю английский десять лет, но скажу честно: если вы разработчик, тестировщик, дизайнер – это значит, что вы сможете выучить английский сами. Конечно, нужны партнёры для общения, но ими могут быть ваши зарубежные клиенты или коллеги, интернет-знакомые, однокомандники в онлайн-играх. Но главное – получить необходимую базу – вы сможете самостоятельно, сидя дома за компьютером. И вот почему.
Возможно, вы уже ищете работу за рубежом, готовы релоцироваться или рассматриваете такую возможность в будущем. В этой статье я поделюсь своим мнением как подходить к выбору страны для релокации, к выбору компании, к выбору позиции или роли. Я также затрону вопросы о поиске работы за границей, что важно сделать до непосредственной релокации, а также на чем важно сфокусироваться сразу после релокации. Помимо России я жил в двух разных странах — в Финляндии и в США. Поэтому немного поделюсь своим опытом.
Хоть раз в жизни каждый из нас задумывался о том, как прошлый опыт, ошибки и достижения привели его в ту точку, в которой он находится в данный момент. Человеку свойственно рефлексировать, анализируя все плюсы и минусы собственных жизненных решений.
Для команды разработки такой процесс также не чужд. Мы называем его ретроспективой. Чтобы оптимизировать в будущем работу, необходимо регулярно проводить это безусловно важное мероприятие в agile методологии. Давайте детально разберём преимущества ретро и научимся правильно проводить такие встречи.