Опыт организации планирования в машиностроении и пробуем сопоставит с подходами при планировании разработки программного обеспечения
Приветствую всех читателей Хабра!
Меня зовут Константин, занимаюсь разработкой ПО, в компании «Автомакон». На данный момент работаю на проекте для «ВкусВилл».
Занимаясь разработкой программного обеспечения, очень часто сталкиваюсь с вопросами, связанными с организацией планирования. Основной мой опыт работы связан с автоматизацией на машиностроительных предприятиях, что в свою очередь накладывает определенный отпечаток на мой подход к работе.
Свой первый опыт работы в IT я получил на одном из «заводов гигантов» родом из СССР (в момент распада последнего). Мне повезло, что тогда еще работали специалисты, которые организовывали автоматизацию планирования на заводе (но об этом чуть ниже). Что в дальнейшем успешно применялось на целом ряде заводов поменьше.
Если упрощенно описывать процессы, происходящие на машиностроительном предприятии, то схема получится примерно следующая:
Схема производственного цикла изготовления сложных изделий при единичном и мелкосерийном производстве
Следует особо отметить, что данная схема очень условная и характерна только для единичного и мелкосерийного производства. Отдельные участки этой схемы применимы и для других видов производства. Но я хочу рассмотреть схемы относительно их применения в IT. В этом случае данную схему можно сравнить со схемой процесса разработки сложного программного обеспечения.
Считается, что с разработкой программного обеспечения все обстоит немного сложнее. Но если мы попробуем разобраться, то один из наиболее наглядных способов для отображения схемы разработки программного продукта это Спиральная модель развития программного продукта (Рисунок из Википедии)
На первый взгляд, ничего общего, но если мы развернем один виток развития в линию, то условно можно привести к следующей схеме:
Учитывая особенность человека подсознательно сопоставлять текущую ситуацию с имеющимся опытом, автоматом появляется следующая схема:
Предполагаю, что данное сопоставление является очень спорным, но я предложу к рассмотрению ряд тезисов, встречавшихся ранее на производственных предприятиях. Насколько они сопоставимы с разработкой ПО решайте сами.
Техпроцесс на большинстве малых предприятий создается только тогда, когда это необходимо, чтобы сдать продукцию. В результате в лучшем случае (!) составляется маршрутная карта.
На предприятиях, где ТП положен по регламенту, в большинстве случаев техпроцесс составляется не для того, чтобы по ТП работали, а для сдачи в соответствующую инспекцию.
Если техпроцесс существует, то рабочие (в том числе и высококвалифицированные) не работают по ТП, а к ТП, как правило, обращаются только при обосновании своих ошибок. (Это обуславливается и тем, что квалифицированный исполнитель зачастую умеет выполнять работу и без ТП, и тем, что они ближе к реальной жизни и много еще почему)
Своевременность отгрузки изделия очень сильно зависит от способности руководителя производства правильно организовать работу.
Руководителю приходится самостоятельно расставлять приоритеты для подразделений в «ручном режиме».
Возможности человека ограничены. С ростом количества изделий, одновременно находящихся в производстве, выясняется, что руководитель производства не в состоянии контролировать абсолютно все, и, как правило, может отследить своевременность изготовления только некоторого ограниченного количества изделий.
При дальнейшем росте количества изделий, одновременно находящихся в производстве, наблюдается периодически повторяющийся «авральный» режим работы, когда всеми возможными способами пытаются уменьшить отставание от графика. Надо отметить, что в силу специфики русского характера это иногда удается. Но эти успехи, как правило, не являются систематическим.
Ключевой проблемой при планировании является квалификация низшего руководящего состава и правильная организация мотивации. В большинстве случаев даже грамотный руководитель низшего звена занимается выполнением только тех показателей, по которым проводится регулярный контроль. Обычно это выработка. В свою очередь, квалифицированный рабочий персонал выполняет нормы выработки, а при появлении не совсем понятных коэффициентов от выполнения плана воспринимает это как снижение оплаты.
В следующей статье я постараюсь рассмотреть схему организации планирования и учета, которая вытекает из ЕСТД и применяется для организации работы на очень крупных предприятиях и/или в сложных проектах.
