Управление проектами *

Питеркин С.В., компания "Райтстеп"

Постановка задачи

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

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

Опыт этого проекта показывает, что техническая реализация системы управления производством это лишь полдела.

Знакомство с заводом

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

Производство — «черный ящик». На вход “черного ящика” передается материал, из него в течении месяца на склад отгружается продукция. Конечно же ведется учет, как без него! Учитываются только материалы на входе в цех и продукция, отгруженная на склад, без учета движения внутри «черного ящика». Норма расхода материалов завышена для покрытия неисправимого брака и поддержания запасов полуфабрикатов (НЗП) в цеху. В производстве нет возможности проследить сколько и какой поставки материал был использован в конкретной продукции. Да это и не требуется пока по бухгалтерии все сходится.

Особенности коммерческих APS-алгоритмов

Питеркин С.В.



«Продвинутые» коммерческие APS состоят, как правило, из 2 частей. Первую условно можно назвать APS–synchronizer’ы, их задача – рассчитать (синхронизированные и оптимизированные) планы по всему «дереву» изделия (далее – СИ — Состав Изделия) или заказа, и/или для всего производства-снабжения-цепочки поставок. Вторая — APS-scheduler’ы, задача которых – оптимизация по какому-либо критерию прохождения производственных, несвязанных между собой заданий через группу оборудования. Первые, как правило, при планировании рассматривают все ресурсы (материалы, производственные ресурсы,…), вторые, как правило (есть исключения), – только производственные. APS-scheduler’ы под разными названиями выступают в качестве «планировщиков» в MES-системах.

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

ERP не работает… Какая альтернатива? или Точно Вовремя. Для России?

Если ERP система ограничивает возможности вашего предприятия – самое время нажать на выключатель

Введение.

В ранее опубликованной в «ДИСе» статье рассматривались особенности алгоритмов планирования (MRP и APS алгоритмы) заложенные в большинстве доступных сегодня ERP систем. Так же, не мало внимания было уделено и практическим возможностям использования этих алгоритмов. Краткое резюме может быть сделано следующее: MRP алгоритм применим в очень ограниченном количестве случаев, на простых и стабильных производствах, APS алгоритм применим практически везде. Естественно, что сами эти алгоритмы не могут применяться сами по себе. Как правило, они встраиваются в ERP системы. Однако, даже с «правильной» методологической системой планирования, ERP система может и не заработать для решения задач планирования. Попробуем не сваливать все проблемы на типичные проблемы российского предприятия, о которых было написано во введении к первой части статьи, и посмотреть в корень. Может что-то не так с самой ERP?
Отрицать, как известно проще всего, поэтому во второй части статьи так же предлагается альтернатива.

Бизнес развивает свои IT-продукты постоянно. «Остановить мгновение» здесь нельзя, иначе даже лучшая программа неизбежно устареет. Рассказываем, как мы создавали новую версию медицинского приложения для Европы и какие проблемы при этом решили.

Профессиональная литература с термином «Agile» в названиях стала появляться на полках IT-экспертов после 2001 года, когда термин был использован во время представления Манифеста Agile.

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

Основатели компаний не любят ERP?

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

В обоих угольных холдингах собственники были не мифическими персонажами, а вполне себе реальными чуваками. Это в ЕВРАЗе и СУЭКе, кроме как на фото и по телевизору, 99% сотрудников их никогда не видели и не слышали. Мы же чувствовали своих постоянно. Ощущения довольно щекотливые, когда работаешь бок о бок с хозяином, создателем всего этого с нуля и миллиардером в конце концов. Все чувства резко обостряются, когда он спрашивает именно тебя на совещании, ставит в пример или отчитывает или жмет руку в коридоре и говорит «как дела?».

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

Первые, самые главные часы – те, что мы выставляем клиенту. В зависимости от ситуации, мы либо договариваемся о часах заранее, либо выставляем по факту – сколько затратил программист.

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

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

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

А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?

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

Потом на другую конференцию съездил, еще раз рассказал. Опять навалились с вопросами, загорелись желанием что-то изменить.

Я отвечал — пф, в чем проблема-то? Вы же программисты, возьмите и сделайте! Добавьте измерение задач, правильную систему приоритетов, учет компетенций и т.д.

Но, как ни странно, почти никто не кинулся менять свою систему. Сейчас, занимаясь несколькими проектами по ускорению команд, я продолжаю удивляться — блин, в чем проблема-то? Я же обо всем написал, что и как надо делать. Например, в «1С, не болей». Но нет, сидят, ничего не делают, только говорят — хотим ускориться, хотим больше денег зарабатывать, хотим прогресса.

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

Российское отделение PMI опубликовало исследование зарплат РП за 2017 год ещё в июле этого года, а на Хабре этот вопрос никак не обсудили. Поделюсь своими впечатлениями. В отличие от глобального исследования (Pulse of the Profession 2018) в российском исследовании есть особенности:

За основу взята не зарплата, а общий доход. За основу взяты числа получаемые на руки, а не до уплаты налогов. Добавлен ряд данных интересных для России — разрез по городам и “белизна” дохода.

Продолжаем рассказывать о том, как мы улучшаем жизнь не только нашим клиентам и партнерам, но и сотрудникам компании. Речь пойдет о внедрении системы согласования. Сознательно не указал согласования “чего”, так как в дальнейшем станет понятно, что чисто теоретически, согласования “всего”.

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

Сколько явно злых практик применяется у вас? Если только часть из перечисленных ниже, то можно подсунуть эту статейку своему начальнику и станет быстрее понятно куда всё движется.
Вредные советы очень полезны!



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

И да, ещё предлагаю устроить опрос на тему какие вредные советы используются в вашей компании. Там 10 вопросов с вариантами. После прохождения видна статистика по всем опрошенным.

Минимум инструментов для максимально успешных результатов — именно такому правилу следуют настоящие специалисты. К примеру, динамично развивающаяся сфера управления проектами избирательно подходит к используемым в работе техникам и методикам, оставляя лишь самое полезное. Эта статья — краткий гид по знаменитой технике НЛП (нейролингвистическое программирование), которая зарекомендовала себя как одну из повсеместно используемых в психологии и бизнес-процессах.

В век просвещённого аджайла негоже уже даже употреблять такие слова, как «график проекта». И хотя многие проджект менеджеры могут высоко поднять бровь, я всё-таки скажу:
График проекта не нужен, вреден, опасен и чреват!

А теперь, сделав, такое эпатажное заявление, я постараюсь объясниться и доказать вам, что все графики проекта должны быть заменены на бэклоги везде, где это возможно, а возможно это везде.

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

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

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

Большинство менеджеров проектов, особенно в разработке ПО, знают о диаграммах Ганта. Gantt Charts помогают повысить производительность и эффективность рабочих процессов и обеспечить своевременное выполнение задач. Такие графики могут быть применены к небольшим проектам и самым сложным. В чем секреты разработанных Гери Гантом графиков и что было в управлении проектами до их появления?

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

Выступал на конференции «ITAM & SAMday 2018» (IT Asset Management и Software Asset Management). Основной вектор дискуссии – обмен опытом в построении моделей управления ИТ-активами в компаниях самых разных отраслей.

Поделюсь тезисами доклада и затрону вопросы:

• с чего начать внедрение процессов управления ИТ-активами;
• из каких шагов оно состоит.

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

Всегда предлагаю есть «слона» по частям, поэтапно.

В некоторых компаниях количество менеджеров и тим лидов кажется неоправданно большим. Почему роль эффективного менеджера сегодня становится все популярнее, и какие качества помогут рядовому сотруднику быстро превратиться в грамотного управленца? Это зависит от сферы деятельности компании, ее роста и специфики рынка, но, в целом, хорошего менеджера можно “распознать” по его личностным и профессиональным характеристикам еще задолго до необходимости “закрыть” вакансию.