Год назад я написал бы о том, что каждый может стать программистом, нужно лишь верить в себя, и всё получится. Два года назад я бы добавил пару строк про нити Вселенной, Закон притяжения и материальность мыслей.

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

Что я хочу сказать сегодня? Нет никакой гарантии, что все из вас, взявшиеся за изучение ИТ-профессии, в конце концов получат работу. Если ты остановил свой взгляд на этой статье в поисках решения своей проблемы, всё уже не замечательно. В статье расскажу, почему.

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

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

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

Как вы уже поняли, мы поговорим об отказоустойчивости.

Всегда мечтал управлять процессами, работать с людьми. Казалось, что я «знаю как правильно», как изменять процессы или учить ребят, чтобы они работали лучше. Хотелось помогать ребятам жить в лучшем мире. Мечта сбылась. Но, как говорится, есть нюанс. 

Поговорим о том, что вас ждёт, когда вы станете руководителем.

При "проработке нефункциональных требований", ИТ аналитик сталкивается с проблемой: "надежность/доступность системы должна быть 99.5%", "время открытия страницы должно быть 3 секунды". А почему не 99.9% или 99.99999% или не 1 или 0.0001 секунды ? В реальности, должен быть достигнут баланс обеспечения качества между потерями бизнеса от необеспечения и расходами на обеспечение.

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

В статье описана методика проработки качества ИТ систем на примерах для аспектов надежности/доступности, производительности и времени отклика.

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

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

Но вначале придется разобрать извечные вопросы: кто же такие аналитики, что такое данные и понять – должны ли они быть вместе?

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

Подобные процессы мы реализуем с помощью движка Camunda, который позволяет прототипировать и визуализировать сложную последовательность шагов и моделировать flow совместно с бизнес-заказчиком, а также обладает множеством инструментов для реализации интеграций, оркестрации, мониторинга, сбора бизнес-метрик и тестирования. + быстро и относительно незатратно менять процессы (можно привести пример с запретом перевода валюты в другие банки). Вдобавок Camunda является open-source решением, что крайне важно в текущих реалиях и т.д. 

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

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

Меня зовут Евгений Шалаев. Я Frontend-разработчик в команде СберЗдоровье. В этой статье я расскажу о теханализе в разработке, его пользе, принципах выполнения и своем опыте проведения подобных исследований.

Неделю назад ко мне обратились с просьбой подсказать по одному рабочему кейсу.

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

А некоторые уникумы еще разделяют зп на базовый оклад и премиальную составляющую. Которую естественно можно резать при любом удобном или неудобном случае.

?А что, вы думали шутки про IT-заводы - это все шутки?

Перейдем же к сути кейса: 

Как вы догадались уже из вступления, руководство компании X всем бизнес-аналитикам помимо базового оклада внедрило премию. 
Сумму премии завязали на KPI.
KPI же определили метрикой количества багов / change request’ов после внедрения проекта...

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

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

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

Но для начала все же стоит разобраться в терминах и ограничениях по нашей задаче.

Разработка хорошего API требует особого внимания к деталям и соблюдения ключевых принципов программирования прикладных интерфейсов. Поэтому важно, чтобы у разработчиков были необходимые знания. Меня зовут Анастасия Иванова, я работаю в МТТ (входит в экосистему МТС) техническим писателем МТС Exolve. В этой статье я дам рекомендации по созданию API, которые помогут вам сделать его надёжным, масштабируемым и удобным в использовании. Самое интересное — под катом.

Мы, как Банк, привлекаем новых корпоративных клиентов по всей сети отделений Альфа-Банка в регионах/городах РФ. И чтобы это делать эффективно, требуются инструменты, которые позволят оценивать результат тех или иных управленческих действий в разрезе конкретных регионов нашего присутствия. У каждого региона есть определенная специфика: географическая, экономическая, рыночная. И нам необходимо понимать: сколько наших продуктов мы можем потенциально продать в этом регионе и получить новых клиентов, и какой ресурс для этого требуется. 

Иначе говоря — бизнесу необходим инструмент эффективного управления численностью менеджеров с точки зрения того, сколько клиентов может привести каждый менеджер, и как это изменит рыночные показатели Альфы в динамике в среднесрочном и долгосрочном периоде. Например, оправдано ли стратегически решение об экспансии в регион на горизонте 3 лет? Удастся ли компенсировать понесённые затраты за счет роста доли рынка и количества активной клиентской базы? Эту задачу можно решить с помощью методов продвинутой аналитики.

В статье мы поделимся примером первого практического применения Продвинутой Аналитики в процессах стратегического бизнес-планирования численности ресурсов Сети для привлечения клиентов Юридических Лиц.

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

Что нужно делать, чтобы получилось MVP – тема не новая. Я же хочу порассуждать о том, КАК делать MVP, чтобы получилось одновременно результативно и недорого.
Приглашаю об этом почитать.

Сейчас в Альфа-Банке при построении моделей используется множество различных источников данных. Мы в Лаборатории машинного обучения уже несколько лет применяем нейронные сети на последовательностях для решения задачи кредитного скоринга и построили модели на данных карточных транзакций, транзакций расчетного счета и кредитных историй. Повышение качества в задаче кредитного скоринга позволяет банку выдавать большее количество кредитов при неизменном уровне риска, что напрямую влияет на его прибыль.

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

Изучение логических ошибок помогает в развитии критического мышления, необходимого во всех сферах жизни. School of Thought проделала отличную работу, описав 24 наиболее распространенные логические ошибки.

Данная статья вторая из цикла про создание Карт процессов. Как и в предыдущей статье я буду касаться применения гибких методологий в проектах Waterfall, то в данном материале я покажу как создать с заказчиком верхнеуровневую модель процессов и зафиксировать 90% функциональных требований за одну встречу.