Как заставить всё работать
Фича-тоглы: мир удобства без лишней настройки
В мире кубов и контейнеров JVM приложения чувствуют себя немного странного когда речь заходит о вопросах: кто сожрал все ресурсы в кластере? или как же мне вывернуть приложение чтобы не рестартить его? Со вторым вопросом предлагаю ознакомится ближе.
Каждый раз, когда какой‑то продакт с гордостью говорит: «Я сам собрал прототип за вечер на AI/no‑code», я не вижу в этом геройства. Я вижу главу продукта, который превратился в ещё одну пару рук для дешёвого билдинга. Вижу человека, который перестал быть «мозгами продукта» и стал универсальным солдатом, которого удобно использовать, но невозможно уважать как продуктового специалиста.
Продолжение цикла про карьерные переходы моего клиента топ-менеджера из IT-блока в “Газпром”. Четвертая тактика - про репутацию без рилсов, подписчиков и погони за охватами.
Коллеги, предыдущие три статьи цикла были про нетворкинг, целевое трудоустройство и переход «вслед за руководителем». Сегодня - четвертая, и, пожалуй, самая противоречивая. Про личный бренд.
Я сразу хочу предостеречь вас от самой распространенной ошибки. Не нужно строить личный бренд по лекалам известных блогеров или федеральных спикеров. Их бизнес - это массовая аудитория, и они зарабатывают на выступлениях и рекламе. Аудитория у них соответствующая: руководители среднего звена, линейные специалисты, микро-предприниматели. Возможно, это ваша сегодняшняя аудитория, но не та, которая даст вам следующий оффер.
Вам же, если вы читаете этот текст, скорее всего, нужно другое.
Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»
В крупных корпорациях сотрудники всех уровней часто попадают в ловушку «зеленых дашбордов», когда на экранах всё светится успокаивающим изумрудным светом, а в реальности бизнес «горит»: люди уходят, вакансии висят месяцами, а вовлеченность падает. Аналитика в таких случаях превращается в дорогую декорацию. Чтобы перестать «махать цифрами» и начать реально влиять на бизнес, нужно признать несколько неудобных истин.
Ваш мозг - самый ненадежный инструмент
Любое управленческое решение принимается в условиях ограниченного времени, пространства и мышления. Мы часто полагаемся на «экспертную оценку», но на деле это часто лишь попытка «натянуть сову на глобус», основываясь на личных травмах и профдеформациях. В психологии выделено около 200 своеобразных проекций, через которые мы смотрим на мир.
Аналитика признана, и призвана для того, чтобы это мышление чуть-чуть расшатать и расширить. Если вы хотите глубоко разобраться в том, как мы обманываем сами себя, крайне советую книгу Никиты Непряхина «Анатомия заблуждений».
Понимание данных прошло эволюционный путь от структуры хранения информации до ключевого элемента в конкурентной борьбе. Сегодняшние информационные технологии, такие как: искусственный интеллект, машинное обучение, предиктивная аналитика, рекомендательные технологии, существуют благодаря большим данным, анализу данных и стремительному развитию вычислительной техники.
Раньше все было иначе. Изначально данные рассматривались как составной, но обязательный элемент компьютерной программы, наряду с командами и алгоритмами. Постепенный функциональный рост софтверных программ от приложения до программного обеспечения, программной системы, информационной системы и корпоративной информационной системы менял взгляд на данные. Уходя от рассмотрения данных только лишь в контексте нормализации данных и СУБД, акцент последовательно перешел к вопросам миграции данных, поддержания их качества и, наконец, бизнес-процессу управления данными.
Сейчас существует отдельный класс программных систем MDM, ориентированный на управление данными. Ведение основных и переменных данных, НСИ и обработка остатков – все это существенные операции бизнес-процесса над данными. Не так много литературных источников, содержащих анализ именно бизнес-процесса работы над данными, исключая детали нормальных форм, SQL-запросов и прочих технических вопросов. Среди них выделяется свод знаний по управлению данными или DAMA-DMBoK, рассмотрению которого будет посвящена данная работа.
Цель статьи состоит в обзоре свода знаний DAMA-DMBoK по управлению данными и его применения в проектах внедрения ERP-систем. Достижение указанной цели потребует реализации следующих задач:
Цифровые продукты не развиваются в отрыве от среды. И пока проект находится в разработке, меняются приоритеты бизнеса, ситуация на рынке, а исполнитель продолжает работать по уже устаревшему ТЗ. В итоге проект сдан в срок, но результат не решает актуальные задачи бизнеса.
Но возможен и другой подход к работе, когда подрядчик и заказчик действуют как партнёры. Он предполагает не только совместную работу над решениями, но и общую ответственность за лучший результат. В таком формате появляются договорённости и требования к обеим сторонам, но именно это позволяет двигаться к результату, а не просто закрывать список задач.
В статье операционный директор CleverPumpkin Владислава Ларкина рассказывает, как компания выстраивает отношения со своими клиентами, чтобы знакомство переросло в долгосрочное партнёрство. И какие процессы помогают команде брать на себя больше ответственности, а бизнесу получать предсказуемый результат.
Привет! Меня зовут Света и я — project manager. Или, по мнению разработчиков, человек, который превращает «надо подумать» в «обещали к пятнице».
За время работы я успела побывать в самых разных контекстах. Через меня проходило всё подряд: от историй уровня «давайте аккуратно распилим монолит банка и никого не убьём по дороге» до вполне безобидных, на первый взгляд, продуктовых изменений, и вот что я заметила.
На самом деле не так важно, какой у тебя проект, потому что картина всегда одна и та же. Проект зачастую начинает ехать не в тот момент, когда «разработчики не вывезли». И даже не тогда, когда «аналитик что-то недожал» или бизнес в очередной раз опомнился слишком поздно. Он начинает ехать в стену сильно раньше — в тот самый момент, когда кто-то в команде уже всё понял, но решил пока не портить атмосферу добра и счастья.
То есть уже понятно, что:
Последние годы в IT-командах регулярно встречаю один и тот же паттерн - у техлидов и различных руководителей самого среднего звена.
Назову его Геннадий. Техлид. В команде за глаза зовут «Ещё Подумаем». Восьмой год в роли. Выбор фреймворка - две недели. Приоритеты спринта - три встречи. Даже «куда идём обедать командой» превращается в опрос в чате.
Геннадий - человек, который всегда знал, как надо. Уверенный. С позицией. Решал сам - это было его.
Перестало работать.
HR считает его выгоревшим, отправляет в отпуск. Он возвращается посвежевшим - ничего не меняется. Вопросы продолжают висеть.
Выгорания нет. Анализы чистые, сон нормальный, отпуск освежил. Он не устал - он просто больше не принимает решения. Ни он сам, ни его руководитель, ни HR не знают, как это называть. В их словаре такого слова нет.
Слово есть - в нейробиологии.
Пациент Элиот
В 1994 году нейробиолог Антонио Дамасио опубликовал книгу «Ошибка Декарта». В ней - история пациента по имени Элиот.
Элиот был финансовым аналитиком. В среднем возрасте у него нашли опухоль в передней части мозга, в зоне, которая называется вентромедиальная префронтальная кора. Опухоль удалили. Операция прошла успешно: IQ 140 сохранился, речь чистая, память работает, логика идеальна.
И Элиот больше не мог выбрать.
Куда пойти обедать - два часа колебаний между двумя ресторанами. Какой отчёт подать первым - парализованная нерешительность. Блестяще рассуждал: перечислял плюсы и минусы, учитывал риски, строил сценарии. Выбрать не мог.
Элиот потерял работу. Потом жену. Потом всё.
Говорят: “выстраивать процессы”. А откуда они берутся, как это обычно происходит, и вообще, зачем это всё?
Что такое процесс? Это то, как организована повторяющаяся работа, взаимодействие между участниками, ради какого-то общего результата.
Процесс никогда не должен быть самоцелью. И нет никакого универсального процесса на все случаи жизни.
Мы хотим достичь какой-то большой и сложной цели, или регулярно достигать какие то цели похожего типа. И чтобы делать это хорошо, эффективно, нам нужно структурировать взаимодействие разных участников. И мы это делаем в какой-то нашей конкретной ситуации: жизненной, рабочей, глобальной и т.д.
В Agile и Scrum есть почти священная заповедь: команда должна быть стабильной, долгоживущей. Люди притираются друг к другу, учатся работать вместе, растёт доверие и предсказуемость.
Но вообще, люди уходят, приходят новые, компания растёт, появляются новые продукты, кто-то выгорает, кто-то засиделся и перестал развиваться.
Хайди Хелфанд, автор книги "Dynamic Reteaming: The Art and Wisdom of Changing Teams", проработавшая в AppFolio, ExpertCity и других компаниях, утверждает: изменение состава команды - это не проблема, а нормальный и правильный процесс, которым можно управлять. Она собрала реальные кейсы и показала, что пересборка команд даёт результаты, которых не может дать стабильная команда.
Спорт и бизнес управляют одним и тем же — временем, людьми, ограниченными ресурсами и чьей-то надеждой на результат. Разница лишь в том, что в спорте провал виден сразу: не забил, не доплыл — проиграл. В крупном бизнесе проекты могут разваливаться полгода, при этом каждое утро начинаться с бодрого «всё идёт по плану». Ирония в том, что большинство бизнес-проектов проваливается из-за ошибок, которые в спорте искоренили ещё в прошлом веке. Но бизнес упорно наступает на те же грабли, называя это «уникальным опытом».
Три месяца закрывали вакансию сеньора разработчика, а может и все шесть, но после адаптации человек уволился. Есть у компаний системная ошибка — онбординг в вакууме, который может проходить даже качественно, но в итоге оставляет сотрудника предоставленным самому себе.
В условиях глобальной неопределенности финансовое планирование и бюджетирование перестает быть ритуалом подготовки отчетов – сегодня это живой процесс, который определяет жизнеспособность компании, развивая базовые подходы в комплексную систему интегрированного планирования.
Бюджетирование – очень важная, интересная и нетривиальная задача, которую в современном мире принято решать при помощи автоматизации. Если еще 5 лет назад в системе бюджетирования видели инструмент консолидации и план-факт анализа, то сегодня это комплексная высокотехнологична модель бизнеса.
В этой статье мы поговорим о том, как сама природа процесса бюджетирования влияет на задачи автоматизации и критерии подбора ИТ-системы для решения этих задач.
Всем привет! Практически любая организация — от муниципалитета до стартапа — постоянно принимает поток разнообразных обращений. Навести порядок и ускорить их обработку можно с помощью простой заявочной системы: назначить ответственных, быстро подготовить нужные документы. Для этого подойдут готовые Helpdesk- или Servicedesk-системы, но их часто нужно интегрировать с уже имеющимися инструментами. Они хорошо работают для сложных бизнес-процессов с большими объемами заявок, но стоят дорого и требуют затрат на внедрение и поддержку. В общем, это развлечение для крупных и средних компаний. Для более простых кейсов можно собрать свою небольшую систему, используя no-code-платформы.
Меня зовут Иван, я бизнес-аналитик в MWS. В этом материале расскажу о реализации заявочной системы на платформе MWS Tables, где я взял на себя не только свою работу, но и функции всей команды — от архитектора до тестировщика. Таких примеров много, и на этом видно, как no-code и разумное использование нейросетей позволяют быстро автоматизировать бизнес-процесс и адаптировать его под меняющийся ИТ-ландшафт.
Когда ко мне обратился клиент, он сформулировал проблему примерно так: «Вся информация есть, но связана только у меня в голове».
Он технический директор в сфере силовой электроники. Рабочий день — проекты, схемы, переписки, документация. Всё это жило в разных местах, и только он сам знал, где что лежит и как одно связано с другим.
Замечаю, что часто люди подстраиваются под инструменты для работы, а не наоборот
Подумаем в статье почему так происходит и что с этим делать
Третья неделя в новой компании. меня спрашивают кто в соседней команде отвечает за конфиги админки и где лежит контракт по realtime-интеграции с витринами партнёров. отвечаю без открытия браузера.
Я ж не гений. просто всё это уже в одном каталоге и достаётся одной командой в терминале.
Сколько людей - столько и мнений о процессах в команде (с).
Давайте поразмышляем - как выстроить процесс анализа так, чтобы он стал для команды не формальным набором этапов, а рабочим инструментом? Опираемся на наш опыт работы в командах разработки одного из операторов электронного документооборота. Все описанные процессы формировались и развивались на практике.
За отправную точку возьмем несколько потребностей:
• управлять неопределённостью,
• повышать качество требований,
• снижать риски на этапе разработки.
Поделимся опытом работы в команде разработки продукта электронного документооборота.
Расскажем о своих решениях, ошибках, находках, и компромиссах и о рабочей модели, которой мы сейчас придерживаемся.
Всем привет. Меня зовут Данил, я учредитель агентства WallMates. Никогда раньше не писал на Хабр, потому что здесь принято обсуждать архитектуру высоконагруженных систем, а не колеровку RAL. Но этот кейс заставил меня сесть за клавиатуру по двум причинам.
Во-первых, я чуть не завалил проект из-за банальной колориметрии. Во-вторых, наблюдая за командой заказчика после сдачи объекта, я понял, что офис — это такой же интерфейс для сотрудника, как IDE для разработчика. И если UX в помещении кривой, продуктивность падает, даже если у вас MacBook Pro и кресло Herman Miller.