Практически повсеместно в производственных и коммерческих компаниях отделы ИТ сталкиваются со смешанной нагрузкой - часть “проектная”, часть “операционная”.
Как правило, операционная часть воспринимается сотрудниками как неинтересная и рутинная. Однако, от качества выполнения этих рутинных работ зависит то, как внутренние клиенты воспринимают отдел ИТ. Своевременно-ли доставляются сервисы? Быстро-ли устраняются инциденты? Поддерживается-ли адекватный уровень коммуникации с заказчиком во время разрешения проблемы? И так далее.
Понятно, что все ожидания внутренних клиентов от отдела ИТ должно выражаться в виде SLO (Service Level Objectives). Вот только количество сервисов и SLO со времененем растет, и сама задача контроля становится тяжелой рутиной.
Если у вас в компании есть процесс ежегодной поставновки целей для сотрудников и контроля достижения целей, то скорее всего этот процесс запускается в начале года - в течение следующих недель.
В этой статье я хочу поделиться практикой постановки и внедрения S.M.A.R.T. (Specific, Measurable, Attainable/Achievable, Relevant, Time-bounded) целей для операционной части загрузки отдела. Как мы к этому подходили, какие результаты получили и какие побочные эффекты наблюдаем.
На инязе (!) меня называли «ходячий словарь»: в досмартфоновую эпоху я уверенно справлялся с этой функцией при вполне средней памяти. Сейчас перечислю несколько приёмов, которые лично мне очень помогли.
Люди запоминают информацию по-разному, зависит от индивидуальных особенностей, и преподаватели тут особо не помогут. Не верьте рекламе, никаких универсальных методик запоминания не существует, каждый должен изучить работу своей памяти самостоятельно. В целом наша способность запоминать опирается на 2 столпа:
Пишу тексты для новых постов и статей, и очень уж мне захотелось создавать документы в Google Docs в конкретной папке «Посты» или «Статьи» 1 нажатием.
Поскольку основное рабочее пространство у меня организовано через вкладки в браузере, привык быстро все открывать по ссылке. Не люблю эти «зайди в папку, скопируй, вставь, открой» и вот это вот всё 🙃. Нашел, как создавать файл по ссылке сразу в нужной папке, и решил тут поделиться, так как штука удобная и лично мне душу греет теперь.
Вы пришли на новый проект и что же первым вам выдадут заботливые коллеги для начала погружения? Правильно, несколько документов со словами «Вот, почитай, что не понятно потом спрашивай.». И тут по вашей спине должен пробежать холодок, потому что вы вспомнили как читали такой документ, перечитывая разделы снова и снова успокаивая себя, что дальше будет понятнее, но увы.
Некоторые из вас скажут, что это нормально, и не нужно чувствовать себя никчемным, потому что не поняли документ с первого раза, и для погружения нужно больше времени и документов. И вы будете правы, но я хочу остановиться на документации и почему она так важна для становления специалиста.
Я пришел на свой первый проект и только спустя несколько лет я понял как мне тогда повезло. Отличительной чертой проекта было то, что все процессы были заботливо описаны аналитиками в документации, разработчиками в системе, тестировщиками прописаны все возможные сценарии.
Последующие проекты оказались самыми типичными в отношении к документации. В лучшем случае описано только первое ТЗ по первому MVP, так что по сути потомкам не оставили никаких артефактов.
Подобное не понимание важности документации приводит к некоторым очевидным и не очень последствиям:
Молодой предприниматель из Гоа Тедж Найк, основатель стартапа Powerland, успешно производит электрические квадроциклы и продает их в Индии и по всему миру. Однако первым продуктом Powerland был не электрический квадроцикл, а дизельный трактор.
Рынок квадроциклов (ATV – спортивные квадроциклы и UTV – грузовые утилитарные квадроциклы, подробнее об их разлиции – в конце статьи) является чрезвычайно нишевым. Он не остался в стороне от волны интереса к электрификации в Индии. Одной из компаний, которые активно отстаивают важность перехода на электрические средства мобильности, является Powerland из Гоа.
Получив образование в Великобритании, Тедж Найк решил вывести на индийский рынок квадроциклы и основал компанию вместе со своим отцом, автолюбителем-энтузиастом. Иначально Тедж и Нараян Найк планировали выпускать квадроциклы с дизельным двигателем и производить их на месте, что снизило бы затраты. Так была создана в 2014 году компания Powerland. Свой первый дизельный квадроцикл они выпустили в 2017 году – он был предназначен для использования в сельском хозяйстве.
«Будучи экологически сознательной командой, мы приняли коллективное решение перейти на производство полностью электрических автомобилей. В 2019 году мы начали тестировать разные компоновки и пришли к концепции с внутриколесным двигателем, параллельно с этим мы начали собирать команду нужного профиля», — рассказывает Тедж Найк.
Иногда причины депрессии очевидны, а иногда неуловимы. Особенно если все хорошо — работа нравится, личная жизнь тоже, СВО еще не началась, солнышко светит, а на душе тошно. В чем может быть причина? А вот в чем.
Disclaimer: Данная статья является основана на личном опыте и/или опыте знакомых и не претендует как на большую универсальность, так и на абсолютную точность.
О полезности ЕГЭ, сертификатов, дипломов.
К мнению о бесполезности стоит относится критически - человек критикующий их в интернете – нередко имеет и дипломы, и сертификаты. И казалось бы, раз он их имеет, то его мнению «ни разу не пригодился так и валяется на полке» можно доверять, но тут срабатывает эффект «своей колокольни». Он помещает упоминание диплома в резюме, там же указывает ссылку на подтвержденные сертификаты, у него ничего о них не спрашивают и вот – он уже думает, что они никому не нужны. Вот только его резюме выбрали с фильтром «наличие диплома» и не выкинули при вторичной обработке из-за «наличия сертификата». Или другой вариант, «звезда», который настолько крут, что его взяли бы в любом случае. Ему нередко тяжело понять, что его крутость на всех не распространяется, опять, эффект «своей колокольни». Рядовой человек без диплома не являющийся звездой – это совсем другое, поэтому как говорилось – «отучайтесь говорить за всех».
Про бритву Оккама хоть раз слышал каждый: во многих статьях и книгах встречается призыв не множить сущности без необходимости. Но не все знают, что в науке есть и другие «бритвы», которые помогают избавиться от лишнего. Термин «бритва» используется для обозначения метода, который помогает отбрасывать что-то ненужное, маловероятное, неправдоподобное. Принцип «бритвы» или «лезвия» — это на удивление универсальный инструмент, который помогает не только в процессе научного познания, но и в работе, и в повседневной жизни.
В этой статье я перечислю несколько известных «именных» бритв (про Оккама тоже не забуду) и покажу, как их можно использовать в работе IT-специалиста. Заодно я сформулирую несколько правил, которые сам стараюсь соблюдать при применении этих самых «бритв», чтобы ненароком не ошибиться и не получить результат, противоположный ожидаемому.
Всем привет!
Несколько недель назад Деливери Клаб (ДК) перестал существовать как отдельная компания. Он навсегда останется в моем сердце, как и у подавляющего большинства тех, кто застал последние его годы до сделки с Яндексом. Однако кроме общих теплых воспоминаний и огромного количества крутейших бывших коллег, я из ДК вынес и несколько историй (надеюсь, интересных), о которых охота рассказать. Ниже одна из таких историй.
Глава 1. Про рынок доставки еды и откуда у агрегаторов курьеры.
Агрегаторы вроде Деливери Клара (ДК) и Яндекс.Еды (ЯЕ), как и их международные собратья вроде DoorDash, Just Eat Takeway, Careem и прочие, не придумали доставку еды. Задолго до их появления существовали и рестораны, и курьеры. Именно поэтому в первые годы развития фудтеха доминировала модель маркетплейса. Фактически, фудтех компании решали задачу поиска ресторанов с доставкой и выбора, и на первых порах этого хватало. Возникли сайты и приложения с заметной аудиторией, фудтехи заключили контракты с тысячами ресторанов и стали работать - причем, преимущественно в плюс. Оно и понятно - расходов не много (только маркетинг, продукт и общие административные, никакой операционки), доходов - много (рестораны с хорошими чеками плюс комиссия в десяток-два процентов).
На этом этапе фудтех опирался на те типы ресторанов, что располагали своей доставкой - и 90% этих ресторанов были похожими с точки зрения типа компаний и кухонь. Это были заведения, готовящие пиццу, сущи, китайскую еду или фастфуд. Кроме того, большое количество точек (то есть физических ресторанов) представляли большие бренды вроде Subway или Domino’s. Рестораны при этом, даже имея доставку, далеко не всегда уделяли ей много внимания и внимательно работали с сервисом. По моему наблюдению, вообще большинство руководителей в ресторанном бизнесе мыслят не в терминах конверсий, юнит-экономики и ретеншна, а в более приземленных выручках и кэше. Поэтому они могут не видеть проблем там, где их увидит фудтех - например, в плохом клиентском опыте и том, что клиенты редко заказывают повторно.
В предыдущей статье мы подробно рассказали о первых попытках человечества запатентовать языки программирования и о первых созданных ЭВМ. В этой речь пойдет о современности.
Привет! Я Дмитрий Шувалов, руководитель компании УМ. Наша компания входит в экосистему AGIMA и занимается исследованиями клиентского опыта. Одна из наших сильных стороны — этнография труда. Моя коллега Ольга Пинчук координирует это направление и недавно написала статью об этом для журнала «СоциоДиггер». В ней она подробно описывает методы и задачи этого подхода, а также объясняет, почему крупный бизнес проявляют к нему интерес. А еще одна из задач текста — объяснить отличие корпоративной этнографии от маркетинговых исследований и аналитики.
Этот текст открывает цикл статей по рассмотрению проблемы управления знаниями в Obsidian. Эта часть почти не будет содержать практических советов о работе с заметками конкретно в Obsidian. Однако в ней будут раскрыты несколько более важные проблемы обработки различных источников информации. Несмотря на последовательное перетекание статьи из одной главы в другую, вы можете попробовать каждый пункт рассматривать как идею, как хак или как возможность внедрить в свою жизнь и рабочий процесс что-то новое.
Электронный документооборот становится не только выгодным, но и безопасным с точки зрения рисков судебных споров. Компании могут обмениваться электронными документами с контрагентами и даже сотрудниками. Что уже легально в части работы с электронной подписью (ЭП), а что пока не определено – рассказываем в этой статье.
Эта небольшая статья целиком состоит из полезных советов о том, как правильно составлять уважаемое и эффективное резюме. Без лишней воды и пространных рассуждений приводим основные моменты, которые стоит учитывать при создании идеального CV.
Материал создан руководителем группы фронтенд-разработки hh.ru Алексеем Анацким. Дальнейшее повествование пойдет от лица самого Леши. Поехали!
Озарения возникают в UNIGINE часто и внезапно, и затея провести стажировку для программистов С++ не стала исключением. Нам не привыкать - летом мы организовали Open Air всего за 6 недель. До старта стажировки времени было столько же, и набрать нужно не 200 человек, а 10, так что мы засучили рукава и взялись за дело.
О нашем первом опыте проведения стажировки, ожиданиях и результатах читайте под катом.
Вместе с Русланом Ахтямовым, сооснователем компании Napoleon IT объясним, почему компьютерное зрение — не просто игрушка, а полезный инструмент для фермеров. В статье приведены кейсы компании, реализованные с использованием собственной разработки Video Analytics Core.
Привет, Хабр! Меня зовут Игорь Рарог, в Банке ДОМ.РФ я совмещаю две роли: лид команды и релиз-менеджер, и сегодня поделюсь своим опытом ведения проектов в Jira.
Вначале хочу рассказать о нашем проекте под названием «Апикс» — это ипотечный конвейер (о нем мы уже писали тут: Методология разработки и архитектура кредитного конвейера АПИКС в Банке ДОМ.РФ).
В команде нас более 100 человек, и мы поделены на продуктовые команды, где каждая отвечает за свою часть функциональности или бизнес-направление.
К примеру, одна из команд занимается заявочной частью: пилит фичи по работе с персональными данными клиента, дорабатывает openAPI для работы с партнерами и т.д.
Другая делает доработки для выдачи ипотеки клиенту, множество интеграций с шиной, АБС (Автоматизированная Банковская Система) и другими внешними сервисами.
Всего таких команд 10, причём одна из них, платформенная, занимается только техническим долгом и не реализует никаких бизнес-фич. Данная команда отвечает за оптимизацию разработанных микросервисов, рефакторинг, сокращение времени обработки запросов, развязыванием микросервисов и много чем еще интересным.
В каждой команде, за исключением команды тех. долга, есть следующие роли: