Рубрика «управление проектами» - 30

image

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

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

По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.

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

image
А ведь в прошлом году это делали senior-разработчики.

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

image

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

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

Конечно, обошлось не без сюрпризов. Но давайте расскажу более конкретно, с числами и примерами.
Читать полностью »

Вместо привычных дайджестов избранных постов из нашего блога сегодня пробуем новый TL;DR-формат — рассказываем все самое главное из каждого материала. Если захотите детально изучить пруфы и углубиться в какую-либо тему, ссылки на полные версии — в подзаголовках.

Облачный TL;DR: что дает open source, почему разработчики дороже денег и пара слов о личной ИБ - 1Читать полностью »

Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».

Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?

Правда ли то, что скрам уничтожает отличных программистов, или дело в том, что его неправильно применяют? - 1

Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.
Читать полностью »

Я занимался стоматологией как главврач-управленец. В смысле директор клиники, но не практикующий доктор. Мы начали с убыточной клиники в неудобном месте города, где зубы лечили только когда адски болело, Инстаграма для ультрабелых улыбок не было, и вообще жизнь казалась не очень яркой. За четыре года сделали клинику лучшей в Ульяновске. А за следующие пять лет её рейтинги трижды признавали лучшей в Поволжье. Главным в этом процессе стало ИТ-ядро: мы дважды переделали все процессы от приёма и диагностики до плана лечения и сопровождения. Ключевым было то, что пациент возвращался до десяти и более раз в рамках комплексного лечения: из «гаражного автосервиса с хорошим ремонтом» мы превратились в клинику, которую нужно регулярно посещать для профилактики и совершенствования своей улыбки. И уходить с хорошим настроением.

Собственно, я бы хотел рассказать про предпосылки к тому, что и, главное, как нужно автоматизировать в клинике. Потому что тогда была только 1С, а, как известно, буква «У» в названии этого ПО отвечает за удобство. Но чтобы понять, почему же так важно делать те же планы лечения с визуализацией за три минуты, нужно будет немного рассказать, как вообще работает стоматология. И где, как и на чём она действительно зарабатывает.

Было — стало

image
Читать полностью »

Привет! Я управляю командами разработки уже 10 лет.

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

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

Поэтому выключаю тумблер «не будь выскочкой» и делюсь «секретами».

Советы руководителю от руководителя - 1

Тут не будет стандартных «делегируй», «налаживай процесс», «стой в правильной позе на стендапе» — об этом написано уже достаточно. Будет о другом.
Читать полностью »

image
Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки).

На протяжении нескольких лет мы очень быстро открывали магазины и росли. Закончилось это тем, что сейчас наши склады принимают и отправляют порядка 20 тысяч паллет в день. Естественно, сегодня у нас уже больше складов: два больших в Москве — 100 и 140 тысяч квадратных метров, но есть и небольшие в других городах.

Каждая сэкономленная секунда в процессах приёмки, сборки или отправки товара в таких масштабах — это возможность сберечь время на операции. А ещё это огромная экономия.

Именно поэтому два главных множителя эффективности — это продуманный алгоритм действий (процесс) и настроенные ИТ-системы. Желательно «как часы», но «работающие чуть менее, чем идеально» тоже вполне подойдёт. Всё же мы в реальном мире.

История началась шесть лет назад, когда мы присмотрелись к тому, как именно поставщики разгружают фуры у нас на складе. Это было настолько нелогично, но привычно, что сотрудники даже не замечали неоптимальности процесса. Более того, в тот момент у нас не было промышленной системы управления складом, и в основном логистические операции мы доверяли 3PL-операторам, которые использовали свой софт и опыт в построении процессов.
Читать полностью »

Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.

Скрам умер. Да здравствует канбан - 1

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

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

Наверное многие помнят скандальное заявление Грефа о том, что Сбербанку программисты не нужны: “У нас огромное количество программистов, с которыми мы боремся”. Давайте проанализируем откуда такие заявления взялись и чем все это закончилось.

Как Греф с программистами боролся - 1

Читать полностью »

Майки, деньги, два торта: как мы разучились оценивать задачи - 1

Привет! Меня зовут Артём и я тимлид в Skyeng. У моей команды разработки есть заказчик, он же продуктовый менеджер, он же просто Ваня. Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js