Менеджмент

Решили как-то предприниматели ИТ-фирму организовать. Офис открыли, дорогим оборудованием обставили, всё по-модному и современному. Тут тебе и чай с печеньками, и комнаты отдыха, и психолог молодая и красивая. Не фирма, а заглядение.

Нашли заказчика — и появился у них новый проект. Чтобы его реализовать, решили нанять одного программиста, такого, чтоб потолковее да по-покладистее, и платить ему решили побольше. В помощь ему взяли дешёвого менеджера проектов. От него требовалось, чтобы выглядел прилично и любую прихоть заказчика выполнял.

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

И вот начинаются рабочие будни. На любое совещание менеджер берёт с собой программиста. Надо же как-то задачи ставить, а разбираться в том, как и что писать — это не его забота. Его дело — «проект к успеху двигать». Программист же и по совещаниям бегает, и работу работает. Работы становится всё больше и больше, количество совещаний и их длительность тоже постоянно увеличиваются. Чтобы всё успеть, приходится писать в спешке. Местами уже не до идеального кода.

Заказчику, конечно же, промежуточные результаты не показывают. Зачем ему знать внутреннюю кухню? Вдруг заподозрит чего или разочаруется. Как итог, на первом релизе получают кучу замечаний, недовольного заказчика, и менеджер обещает всё переделать, и, конечно же, за счёт фирмы, в которой он работает. Они ведь сделали не то, что он ожидал. В итоге программист работает круглые сутки, чтобы всё исправить, а менеджер его ещё и дёргает по нескольку раз на день, а то вдруг он опять «дров наломает». Худо ли, бедно, всё доделывают-переделывают и показывают заказчику. Он недоволен, но так и быть запускает проект у себя и продолжает оплачивать дальнейшую разработку. А так как объём работ увеличивается и хочется, чтобы качество было получше, он соглашается увеличить финансирование.

Проработав почти 25 лет в ИТ, у меня накопилось то, о чём хотелось бы рассказать. Я изучил множество технологий, участвовал в массе проектов. Работал как в мелких фирмах, так и у мировых гигантов. Общался с разными людьми из разных стран и континентов. Основным моим мотивом всегда был успех проекта. Я всегда пытался сделать работу на максимуме своих возможностей. Много читал и изучал, анализировал, писал на разных языках и платформах. Всегда было стремление сделать проект как можно лучше. Но далеко не всегда это получалось. Когда давали возможность, что-то выходило, хотя не всегда. Иногда возникали обстоятельства, которые ставили крест на проекте.

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

В книге «Лоу-перформеры в ИТ: кто тянет команду вниз» я рассказываю о сотрудниках, которые делают вид, что работают. С такими приходилось очень часто встречаться, и я пришёл к выводу, что они негативно влияют и на проект, в котором задействованы, и на команду, частью которой являются.

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

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

Раньше я тоже был «горлышком». Однажды руководил сервисом для банка, но заболел ковидом и три дня не мог работать. Проект замер: разработчики ждали указаний, тестировщики сидели без дела, аналитики не могли ничего согласовать. Пришлось с температурой выйти с больничного и вести процесс самому, потому что кроме меня никто не понимал, как в банке устроена работа сервиса регистрации бизнеса.

Меня зовут Степан Сорокин, я delivery manager в Outlines Tech. Ниже поделюсь мнением, как перейти от роли пожарного к роли стратега: научиться делегировать, развивать команду и автоматизировать рутину, чтобы не переписывать код за разработчиков ночью и не выходить на созвоны с температурой. Ещё поделюсь своими артефактами, которые разгружают операционку и оставляют время на стратегию. 

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

А к вечеру — очередной релиз на костылях, баги в проде и геройская починка в ночи. И самое забавное, что команда не состоит из новичков. Все прекрасно знают, как делать правильно.

Машинное зрение работает, и работает хорошо. За год количество проектов выросло с 5 до 36. Мы привлекли много подрядчиков и знатно пробежались по граблям.

А теперь я хочу рассказать про эти самые грабли.

Первые же серьёзные — проверка качества решений. Как оценить чужое решение и работает ли оно так, как надо нам? Тут много подходов и способов, например, использовать скрытые выборки, оценка на потоке и базовое — проверка кода и всего пайплайна, от разметки до метрик обученной модели.

Вторые — что не стоит оставаться наблюдателем на протяжении всей разработки. Если вы начинаете изучать систему только на приёмке, вас наверняка ждёт дивный мир сюрпризов. Включаемся сразу, ещё и раньше разработчиков (ТЗ никто не отменял).

А самая большая для меня боль года — донести и согласовать фразу «понятный и читаемый код» с каждой командой со своим чувством «прекрасного», и это не только про длину строк или формат докстрингов, но и про общие понятия в разработке.

Но давайте по порядку.

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

Сегодня разберём на практике один из самых недооценённых, но при этом максимально полезных инструментов в арсенале любого тимлида — Delegation Poker из подхода Management 3.0. Это не игра ради фасилитации, а вполне рабочая методика, чтобы прозрачно и конструктивно обсудить распределение ответственности в команде. Без «угадай, чего я от тебя жду», без абстрактного «будь проактивным» и без пассивной агрессии на ретро.

Исповедь замученного директора: почему ваш главный враг — не хаос, а собственный образ мыслей

Статья из серии "Чем болен средний бизнес? Диагностика и лечение управленческих болезней"

Вы - самый занятой и самый уставший человек в своей компании. Хватит.

Вы - тот самый "пожарный", "нянька" и "арбитр", который лично разруливает каждый затык. А в это время ваш бизнес, как тот воз из басни, тянут в разные стороны. Знакомо?

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

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

Готовы посмотреть правде в глаза и начать строить систему, а не латать дыры?

Первая статья из серии уже ждет вас. Осторожно, может быть больно.

**#бизнеспроцессы #управление #менеджмент #хаос #стартап #дракон

Ведение сложных международных переговоров в условиях кризисной ситуации с учётом менталитета заказчика.

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

Через три месяца меня повысили, но теперь мне нужно вычислять таких, как я.

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

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

И вот первые судебные ласточки по этому поводу...

Всем привет!

В последнее десятилетие бизнес развернулся в сторону автоматизации и цифровизации, активно стал внедрять ERP, BPM, OLAP-системы и многое другое в целях повышения эффективности, прозрачности и улучшения своего P&L.

С момента массового бума ChatGPT в 2022 году бизнес решил активно исследовать и эту область– по данным отчета McKinsey не менее 78% компаний уже сейчас используют генеративный интеллект (GenAI) как минимум в одном своем бизнес-процессе. Для России по разным источникам этот показатель на уровне ~37%.

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

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

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

Как я уже упоминал выше 78% компаний уже внедрили GenAI хотя бы в один свой процесс – но где именно подавляющее большинство компаний нашли применение большим языковым моделям? В большинстве своем, GenAI решение в бизнесе AS IS – это помощник (co-pilot) сотрудника или клиента, при этом не всегда проводится дообучение / адаптация модели под реалии непосредственно компании. А на сколько это эффективно?

После двух лет работы в технической поддержке крупной ИТ-компании я искала новые вызовы. Мне предложили необычную роль: консультирующий бухгалтер с функцией проектного менеджера в крупнейшем аутсорсинговом бухгалтерской компании России. 

Проблему мне описали без прикрас: «Маргарита, у нас горит. Десятки клиентов месяцами не могут работать из-за заблокированных счетов. Нужно навести порядок в этом хаосе — найти причины, создать систему и всех разблокировать. Это твой «чёрный ящик». Разберешься — станешь проектным менеджером». 

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

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

Первый успешный кейс: выяснилось, что отчет не был сдан из-за отсутствия подтверждения от клиента. После моего звонка клиент дал добро, отчет был сдан, штраф — уплачен. Через официальный запрос по ТКС блокировку сняли за 10 дней.

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

Мы приняли непростое решение: убедили клиента повторно оплатить налог, чтобы приставы сразу его списали и разблокировали счёт. Это позволило беспрепятственно выдать зарплату. А первоначальный платёж мы позже вернули как переплату.

Люди вспоминают Kodak со смесью ностальгии и недоверия. Ностальгия по тем временам, когда её жёлтые коробки определяли мир фотографии для миллионов, и недоверие к тому, что столь доминирующая компания может всё потерять. От первой камеры для масс до изобретения самой цифровой камеры, Kodak помогала формировать будущее. Но оказавшись в тисках дилеммы инноватора, где прошлый успех порождает осторожность, а осторожность подавляет импульс, Kodak колебалась, пока другие адаптировались, и цифровая революция оставила её позади. Это история о том, как компания, когда-то определившая мир фотографии, стала её самой известной жертвой.

Привет Хабр! Меня зовут Владимир Понаревский, я руковожу разработкой бэкенда антиспама в Mail. За моими плечами более десяти лет опыта управления самыми разными людьми и процессами, от которых зависит информационная безопасность миллионов пользователей почты. Сегодня мы поговорим о том, с чем рано или поздно сталкивается каждый руководитель: когда в команде или организации что-то начинает работать не так, как задумывалось.

Привет, Хабр! Меня зовут Маша Даровская, я шефред издания Тпрогер, веду канал Деврелишна, снимаю подкасты про айти.

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

Кого опрашивала:
Итак, я опросила 128 человек, из которых 50,4% сеньоры, 41,2% мидлы, остальные 5% и 3,4% — CTO/CEO и джуны соответственно.

Представьте, что вы работаете по скраму, но без скрам-мастера. Его задачи распределены между участниками команды. Представили? Отлично! Усложним задачу: представьте, что тимлида тоже нет. «Хаос» — скажете вы? Вовсе нет! Мы так работаем уже несколько лет.

Привет, я — Иван Зверев, фулстэк в Додо. Сегодня я расскажу о том, как круто может самоорганизоваться здоровая команда, если довериться ей, обозначить прозрачные правила работы и дать свободу экспериментировать с процессами. Вперёд!

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

Для упрощения восприятия сократил немного деталей, но с сохранением сути.
Представленные данные на экране СберБанк Онлайн – вымышленные.

Описание постановки задачи

Подразделением, отвечающим за улучшение клиентского опыта в СберБанк Онлайн (далее - СБОЛ), была поставлена задача: «Отображать секции «Инвестиции» и «Сбережения и пенсии» в раскрытом виде на экране «Накопления» с выводом текущего состояния счета и дохода по каждому из продуктов".

«Человек всегда велик в намерениях. Но не в их выполнении. В этом и состоит его очарование» — что-то на глубоком из Ремарка «Три товарища»

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

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

Самая интересная часть начинается с главы «Возвращение: новая команда и быстрый релиз», но я искренне рекомендую читать статью с самого начала. Так будет проще уловить весь контекст и понять, почему проект получился именно таким, каким он получился.

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

Меня зовут Евгений Рошковский, я специалист по процессному управлению в ПСБ. Расскажу, как мы выстраиваем работу с процессным репозиторием.

Производственная система «Росатом» (ПСР) – это культура бережливого производства и система непрерывного совершенствования процессов для обеспечения конкурентного преимущества на мировом уровне.

Она была разработана на базе лучших образцов отечественного и зарубежного опыта, в частности, системы научной организации труда, производства и управления (НОТПиУ) Министерства среднего машиностроения СССР и Toyota Production System японской автомобильной компании «Тойота».