Менеджмент

Многие до сих пор воспринимают IT-индустрию как пространство для молодых: стартапы, хакатоны, agile-команды и шумные open space. В голове автоматически возникает образ 20–30-летнего разработчика в худи. А если добавить, что речь о программировании на 1С, — так вообще большинство подумает о крепком мужчине предпенсионного возраста с двадцатью годами стажа в одной системе.

Но бывают исключения, которые ломают шаблоны. И об одном таком исключении я расскажу сегодня.

Хотите разобраться с таинственной полярной звездой или North Star Metric (NSM)? Покажу примеры NSM для организаций и разберу несколько реальных продуктовых кейсов. После прочтения этой статьи вопросов про NSM у вас больше не останется!

Привет, Хабр! Меня зовут Тигран Басеян и я — руковожу ИТ-saas продуктом, развиваю российскую методологию управления ИТ в организациях РИТМ, автор телеграм-канала Black Product Owner (Чёрный продакт), где рассказываю о продакстве, менеджменте и стартапах. В индустрии уже больше 15 лет. Руководил различными технологическими командами и продуктами, в том числе высоконагруженными.

Эта статья написана по мотивам воркшопа про North Star Metric или Полярную звезду: расскажу, зачем нужна эта метрика и как её правильно выстраивать. Разберём, как NSM связана с различными бизнес-моделями и какие у неё есть связи с деревом метрик и юнит-экономикой.

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

Я ранее уже рассказывал о том, что некоторое время назад мы изменили подход к сборке MVP. Если лет 5 назад мы собирали MVP сразу после оценки идеи, то сейчас проекты проходят стадию анализа, затем - предтеста (некий аналог пред-MVP), и только потом, когда ценность проекта подтверждена у пользователей и нам понятно, какие фичи нужны проекту, мы выводим его на сборку MVP.

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

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

Для таких стартапов важным показателем является соотношение CAC к LTV 1:3 и выше (1:4 и т.д.). Напомню, что CAC - это стоимость привлечения клиента, а LTV - это его пожизненная стоимость, то есть, то количество денег, которые он приносит компании за все время взаимодействия с ней. Существует примерный ориентир, на который ссылаются инвесторы, фонды и бизнес-ангелы во всем мире: 1 доллар потраченный на привлечение, должен приносить 3 доллара прибыли, не ниже. Поэтому основная задача стартапа - добавиться соотношения 1:3. Все гипотезы, которые мы тестируем, должны быть направлены на сокращение стоимости привлечения и на повышение LTV.

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

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

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

В этой статье мы подробно расскажем о пути перехода платформы контейнеризации dBrain.cloud с MaaS на Metal³. Основная задача, которую решают оба этих проекта, состоит в установке операционной системы на серверы платформ. Озвучим причины, по которым мы искали альтернативные решения, и объясним, чем Metal³ превосходит MaaS.

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

Знаете, в чем сила канбан-досок? С их помощью можно организовать любой проект — и разработки, и крипто-стартапа, и контент-студии. Чего угодно. Рассказываю, как сэкономить время, силы и деньги и выбрать лучший сервис с канбан-досками.

Эта статья является дополненной адаптацией статьи профессора Леонардо Карвало. Сначала описывается структура ОБЛАСТЕЙ (выделены разным цветом), затем перечисляются блоки (пронумерованы). В каждом блоке есть: описание в чем его задумка и примеры вопросов, советы, пример заполнения.

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

- А давайте добавим ещё фильтр…
- Хорошо бы выгрузку в Excel
- Вот бы ещё график и пуши — красиво же будет!

Проект набирает скорость. Только вот в каком направлении?

Привет, Хабр!

Компания Lingvanex занимается машинным переводом с 2016 года и за это время убедилась, насколько сложным может быть «простой перевод текста».

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

Сегодня хочу рассказать о продукте, который появился как ответ на реальную и острую потребность наших пользователей — переводчик внутри Slack. Он помогает командам мгновенно понимать друг друга, даже если они говорят на разных языках.  Это история о том, как мы встроили качественный машинный перевод в мессенджер и сделали так, чтобы все «просто работало». Расскажу, почему мы создали переводчик для Slack, как он работает, в чём его преимущества и в каких сценариях он может стать незаменимым инструментом для вашей команды.

В условиях пандемии, когда многие компании терпели убытки, американская компания Walmart, управляющая крупнейшей в мире сетью оптовой и розничной торговли, не только выжила, но и увеличила онлайн-продажи на 74%! Как им это удалось? Все дело в умении слушать своих клиентов. В 2020 году компания провела исследование, которое выявило, что более 75% покупателей стремятся использовать бесконтактные способы оплаты и доставки. В ответ Walmart внедрила инновации, что привело к рекордному росту онлайн-продаж.

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

Обрыв каналов связи, багованный релиз, мискоммуникация… Серия загадочных событий, авантюрный детектив из цикла «Следствие вели…» — нет, не с Леонидом Каневским, и даже не Колобки, а команда разбора инцидентов, или просто Post. 

Хей-хей! Я Юля, и я специалист по сопровождению инцидентов в команде Post департамента SRE (Site Reliability Engineering). Когда я рассказываю своим друзьям, чем я занимаюсь на работе, мне часто говорят, что я работаю в детективном агентстве. 

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

Согласно своду по управлению знаниями PMBoK существует 4-е ключевые плана, характеризующие любой проект, в том числе внедрение ERP-систем: график проекта, ресурсный план, план затрат и закупок. В литературе обычно описывают только построение плана-графика проекта с использованием методов критического пути и цепи, однако взаимосвязь с ресурсным планом и прочими планами обычно опускают. В работе [1] сделана попытка одновременного построения первых трех планов в виду их корреляции, способ базируется на бенчмаркинге этапов проекта и оценщике разработок. Однако вопрос оптимизации построенного ресурсного плана обсуждается лишь вскользь.

В данной работе мы выполним анализ примеров построения ресурсного плана в проектах внедрения ERP-систем, что позволит планировать человеческие ресурсы более точно и обеспечит более эффективное и качественное имплементирование программной системы. Для начала более подробно разберемся, как взаимосвязаны между собой три плана: проекта, ресурсный и затрат. Обычно план проекта ведется в разрезе задач, далее на него налагается ресурсный план, показывающий, какое число человеческих ресурсов требуется для выполнения активностей. Зная число и квалификацию ресурсов, а также их ставки, возможно рассчитать план по затратам. Таким образом все три плана связаны между собой и изменение одного из них непременно приводит к обновлению других. Наконец, построив ресурсный план, мы фактически формируем планы проекта и затрат.

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].

На дворе лето, середина года уже позади. Самое время оглянуться назад и критически взглянуть на прогнозы, которые делались в декабре-январе. Итак, давайте посмотрим, что обещали нам по части BPM в 2025 году и что из этого сбылось, а что осталось лишь в фантазиях авторов этих прогнозов. В принципе все писали более-менее одно и то же, поэтому для разбора взял один рандомный прогноз «BPM Solution for 2025: Trends and Updates».

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

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

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

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

Давайте рассмотрим примерный алгоритм делегирования Исполнения, я распишу обязательные пункты и их цели, но можно при кастомизации под определенную деятельность компании или сотрудника добавить дополнительные пункты:

1. Выбор сотрудника и объяснение ему цели задания. Сотрудник должен быть новичком в компании или этот процесс новый для сотрудника. Он должен понимать смысл задания, мы же помним, что труд рабов неэффективен, а значит нам необходимо вовлечь сотрудника в процесс, объяснив ему смысл задания.

2. Подробная инструкция задания и сроки, а также объяснение какие инструменты для этого необходимо использовать. В этом пункте есть различия для нового сотрудника и опытного сотрудника в новом задании. Для нового сотрудника мы четко проговариваем все, получая подтверждение его понимания, но не спрашиваем его мнение по выполнению, он должен научиться выполнять задание в тех стандартах, что приняты в данной компании, иначе есть опасность, что новый сотрудник перенесет стандарты корпоративной культуры своей прежней компании в вашу, а это может быть противоположные для вашей компании ценности. Для опытного сотрудника мы четко проговариваем все, но при этом спрашиваем его мнения, может он готов предложить свое видение выполнение этого задания. Таким образом, мы не унижаем его самоуважение (у опытных сотрудников оно очень чувствительно) и вовлекаем в процесс.

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

Попахивало, конечно, скамерством, но уж больно я люблю смузи. Поэтому решилась. Уйти от токсичного начальника, начать зарабатывать 3х больше, путешествовать по миру и работать 1,5 часа в неделю.

Потому что до этого работала по 14 часов в день. Без перерывов и с редкими выходными.

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

Привет, Хабр! Меня зовут Настя. Я операционный директор в компании Metalab. Мы интегрируем ИИ-решения и поставляем ИТ-оборудование. Каждый день наша команда сталкивается с вопросами от клиентов и закупщиков о разнице между типами сборок серверов и другого ИТ-оборудования.

В этой статье разберем, чем отличаются CTO, BTO и OEM — и почему это важно, если вы собираете железо для машинного обучения, анализа данных или просто для того, чтобы ИИ быстрее сочинял вам стихи.