Comments 7
Поэтому указанная инновационная модель в виде конвейера — на мой взгляд, все та же модель agile в виде последовательности спринтов, в которой каждому сотруднику дают задачи под его специализацию на весь объем спринта. Т.к. в методологии agile разработки — вовсе нет жесткого требования кустарного/мануфактурного производства всей командой всех видов работ. Да и редко какой разработчик сядет на аналитку, или там инженерную инфраструктуру. По моей практике — в более менее крупных командах (от 5ти человек) — есть эти специализации и они разделены между сотрудниками. Все простои решаются двумя смежными специализациями у сотрудников и периодизацией задач по году. Например у ИТ работающем в гос.секторе январь-февраль время доделки хвостов, март-июнь время продаж и разработки «новых продуктов», июль-ноябрь основной проектной реализации, декабрь — авральных допилов ключевой функциональности под требования закрытия контрактов + модель переработок с двойной компенсацией времени — достаточно мотивирующая и позволяет не набирать избыток специалистов, а работать всегда на неком «дефиците», чему кстати и дефицит ИТ-специалистов способствует.
У всех остальных — маржинальность разработки в ИТ отрасли пока такова, что можно направлять простаивающих сотрудников на «перспективные свои проекты», на устранение технического долга, переделку архитектуры и платформы, «новые продукты» и т.д. и т.п.
При этом дефицит ИТ-шников способствует высоким окладам и у них смещается модель мотивации в сторону «интересной, развивающей и разнообразной» работы, а это явно противоречит принципам конвейера.
День добрый!
Тут есть два момента организационный и философский.
Философский очень хорошо описан у Анчарова:
Главное правило для художника — быть исключением. Хочешь, не хочешь. Такая промышленность.
Потому что, если я два велосипеда сделаю вместо одного, то это будет — два велосипеда. А если я два раза один и тот же стих напишу, то это будет один стих, а не два. Стих или картину, любое сочинение — все равно. А сколько раз я эту картину изготовлю, сколько штук я этого сочинения изготовлю — это уже значения не имеет. Это называется тираж. Тираж, повторение, репродукция — это есть ремесло. А искусство каждый раз происходит по одному разу.
Вот в чем особенность, дорогой дядя.
В общем с этим нельзя не согласиться, что разработчик пишет однократно, но
- ПО всё ж таки продаётся по модели тиража, а не однократно, т.е. мы либо платим за лицензию, либо аредуем её(оптимизируя налогообложение)
- Производство искусства в отличие от производства ПО не формирует крупных контор, типа MS, по разработке и производству картин (иначе тираж), единственное — модные дома, но и там тираж и деньги.
Организационный — здесь в отличии от agile идея в том, что если заранее подумать о том, что включить в такт конвейера не придётся об этом думать потом.
Переключение специалистов между разными потоками объектов и циклами разработки — мне не кажется даже близко похожим на выполнение одной и той же рудиментной операции на своем участке. Даже противоположной — здесь мы не разные однотипные объекты подаем одному специалисту на один этап. А одного специалиста на разные типы объектов переключаем и зачастую разные задачи он решает, по специализации.
Вечер добрый!
Собственно что касается проектирования авто, то тут стоит различать проектирование новой модели и ежегодное обновление модели, — вот второе весьма, как кажется похоже на выпуск новой версии ПО, т.к. конструкция радикально не меняется, а появляются новые опции за которые собственно и платит конечный потребитель. В софте аналогично видим более или менее регулярный поток обновлений/улучшений и редкие мажорные релизы со сменой архитектуры.
Сам по себе конвейер нужен для выравнивания нагрузки, переключения же при таком подходе возникают с той частотой которой мы их спланируем, можно чаще, а можно и реже чем agile-спринты. Идея здесь в том, что эффекта с выпуском версии раз в две недели можно добиться не только путём сокращения цикл разработки ПО до двух недель (при этом на продуктивную разработку будет потрачено примерно неделя ), но и конвейеризацией (при этом на разработку будет потрачено уже две недели). Просто большие непрерывные куски времени позволяю решать более сложные задачи, не занимаясь их искусственным дроблением, что иногда полезно (при перекладке математической теории на код, например)
Что касается рудиментарности операций — то тут как посмотреть:
- если смотреть на суть работ т.к. программист практически всегда будет писать код, отличающийся от кода, который он писал в прошлом прошлом и так будет всегда — в этом суть
- если смотреть на конвейер как на свободные куски времени, которые можно заполнить полезной работой, то всё же две недели больше чем одна для нерутинной работы
Т.е. однотипность не в составе работ, а в объёме свободного времени на эту работу.
Вечер добрый!
Собственно что касается проектирования авто, то тут стоит различать проектирование новой модели и ежегодное обновление модели, — вот второе весьма, как кажется похоже на выпуск новой версии ПО, т.к. конструкция радикально не меняется, а появляются новые опции за которые собственно и платит конечный потребитель. В софте, аналогично, видим более или менее регулярный поток обновлений/улучшений и редкие мажорные релизы со сменой архитектуры.
Сам по себе конвейер нужен для выравнивания нагрузки, переключения же при таком подходе возникают с той частотой которой мы их спланируем, можно чаще, а можно и реже чем agile-спринты. Идея здесь в том, что эффекта с выпуском версии раз в две недели можно добиться не только путём сокращения цикл разработки ПО до двух недель (при этом на продуктивную разработку будет потрачено примерно неделя ), но и конвейеризацией (при этом на разработку будет потрачено уже две недели). Просто большие непрерывные куски времени позволяю решать более сложные задачи, не занимаясь их искусственным дроблением, что иногда полезно (при перекладке математической теории на код, например)
Что касается рудиментарности операций — то тут как посмотреть:
- если смотреть на суть работ т.к. программист практически всегда будет писать код, отличающийся от кода, который он писал в прошлом прошлом и так будет всегда — в этом суть
- если смотреть на конвейер как на свободные куски времени, которые можно заполнить полезной работой, то всё же две недели больше чем одна для нерутинной работы
Т.е. однотипность не в составе работ, а в объёме свободного времени на эту работу.
Главное — хвост. Технология конвейеризации разработки программного обеспечения